Bug #12954 2008-01-17 08:55
dalex
Core dump on Solaris 10 x86 when exiting CB
This seems to happen with quite a few recent versions. When exiting the Code::Blocks the core dumped during deinitializing plugins. The stack trace is below. It looks like the problem lies in wxsItemFactory destructor.
080470c4 libc.so.1`_lwp_kill+7(1, 6)
080470dc libc.so.1`raise+0x1f(6)
08047128 libc.so.1`abort+0xcd(0, fe008000, 804714c, fdfe001f, b, 0)
08047138 0xfe172fee(b, 0, 80471e0)
0804714c libc.so.1`__sighndlr+0xf(b, 0, 80471e0, fe172fc0)
080471a8 libc.so.1`call_user_handler+0x22b(b, 0, 80471e0)
080471cc libc.so.1`sigacthandler+0xbb(b, 0, 80471e0)
08047438 libwxsmithlib.so.0.0.1`_ZN14wxsItemFactoryD2Ev+0x97(fbf74ee0, fbeec1b4, 8047518, fbd97d29, fbf74dec, fbeec1b4)
08047518 libwxsmithlib.so.0.0.1`_Z41__static_initialization_and_destruction_0ii+0x34f(feffa1c8, fbeec1b4, 8047534, fbe20c55, feffa840, 8047554)
08047528 0xfbcbd7ab(feffa840, 8047554, fefd5acd, feffc908, feffa220, feffa840)
08047534 libwxsmithlib.so.0.0.1`_fini+0x15(feffc908, feffa220, feffa840, 0, fbe20c40, 8047570)
08047554 ld.so.1`call_fini+0x99(feffa220, fbf80578)
08047570 ld.so.1`atexit_fini+0x5b(804766c, 8047574, fe008000, fe00c6c0, 80475ac, fdf63f22)
08047588 libc.so.1`_exithandle+0x4e(feffa840, 8073a66, 0, 0, 80475ac, 80739fe)
080475ac libc.so.1`exit+0x12(1, 80476d4, 0, 80476df, 804771b, 804776a)
- Category
- Application::Crash
- Group
- Status
- Open
- Close date
- Assigned to
History
I did some analysis. This seems to happen because static instance of ItemMapT (in declared in ItemMap() method) is getting destructed somewhere in the middle of the destruction processes while it seems that there are still some wxsItemFactory classes being destructed and trying to refer to that ItemMap.
However moving this static ItemMap in different context does not help. It seems that wxsItemFactory constructors/destructors are called from other static initialisation/destruction code and it seems that there is a great chance they are called before the static ItemMap is initialised or after it is destroyed.
The only reasonable solution is to allocate the ItemMap object on-demand dynamically first time it is used.
Incidentally, all the wxsItemFactory classes seem to initialise with the same classname. This results in that they use the same element of the ItemMap pointing to the last initialised wxsItemFactory. What is the point of using Map structure then?