Jump to content

Static sc_vpool objects to cause initialization order fiasco

Recommended Posts


I recently experienced an issue related to the static sc_vpool objects used in some classes in the SystemC kernel.
Here is an example:

#include <systemc.h>

class Dummy {
  Dummy(int a) {
    sc_int<32> my_int(a);

Dummy dummy(12);

int sc_main(int argc , char *argv[]) {
  return 0;

This program crashes at startup with the following stack trace:

#0  0x0000000000404e66 in sc_dt::sc_int_subref_r::initialize (this=0x0, obj_p=0x7fffffffdde0, left_i=2, right_i=1)
    at /remote/vgrnd104/julient/OSCI/linux/systemc-2.3.3/include/sysc/datatypes/int/sc_int_base.h:338
#1  0x0000000000405102 in sc_dt::sc_int_base::operator() (this=0x7fffffffdde0, left=2, right=1)
    at /remote/vgrnd104/julient/OSCI/linux/systemc-2.3.3/include/sysc/datatypes/int/sc_int_base.h:1282
#2  0x000000000040513f in Dummy::Dummy (this=0x701b11 <dummy>, a=12) at test.cpp:7
#3  0x0000000000404d81 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at test.cpp:11
#4  0x0000000000404d97 in _GLOBAL__sub_I_dummy () at test.cpp:15
#5  0x00000000004c623d in __libc_csu_init ()
#6  0x00007ffff702ecb0 in __libc_start_main () from /lib64/libc.so.6
#7  0x0000000000404c29 in _start ()

Note that the example only crashes when it is statically linked to the SystemC library. It does not crash when it is dynamically linked to the SystemC library.

This crash is caused by a wrong order of initialization of the static and global objects:
 - The dummy global variable is initialized first.
 - The constructor of Dummy calls sc_int_base::operator() which uses the static sc_int_subref::m_pool object (sc_int_base.h line 1281).
 - But m_pool has not yet been created. This leads to the crash.
So this crash is a typical static initialization order fiasco situation.

However, the above example is very simple and does nothing uncommon.
And the crash is related to an internal implementation of the SystemC kernel.
So it is very hard for the SystemC user to understand why his program crashes and why he should change his code to make it work.

So I would suggest to change the internal implementation to avoid using static sc_vpool objects.
Current implementation:

sc_int_base.h line 527:
    static sc_core::sc_vpool<sc_int_subref> m_pool;
sc_int_base.h line 1281:
    sc_int_subref* result_p = sc_int_subref::m_pool.allocate();

Maybe I'm missing something, but the following might be a possible new implementation:

sc_int_base.h line 527:
    static sc_core::sc_vpool<sc_int_subref>& pool() {
        static sc_core::sc_vpool<sc_int_subref> subref_pool;
        return subref_pool;
sc_int_base.h line 1281:
    sc_int_subref* result_p = sc_int_subref::pool().allocate();

Similar changes should be done for all the static sc_vpool objects. Thus, static sc_vpool objects would not be necessary anymore, and this would avoid this crash.

Any opinion about that?




Link to post
Share on other sites
  • 1 month later...
  • 4 months later...

It bothers me a bit that we got all the way to sc_int_subref_r::initialize() with a NULL this pointer, rather than having things die in sc_vpool::allocate(). If hoisting the sc_vpool object so that the static initialization is within a method is the way to go I would prefer to place things where the invocation is made:


    sc_int_subref& operator() ( int left, int right )


        static sc_vpool<sc_int_subref> pool(9);

        sc_int_subref* result_p = pool.allocate();

        result_p->initialize( this, left, right );

        return *result_p;


Link to post
Share on other sites

I will try an implementation along the lines of:


    sc_int_subref* temporary_subref()


        static sc_vpool<sc_int_subref> pool(9);

        return pool.allocate();



    sc_int_subref& operator() ( int left, int right )


        sc_int_subref* result_p = temporary_subref();

        result_p->initialize( this, left, right );

        return *result_p;


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...