Re: another cppunit test core dump, java this time, building on xstreamos/illumos

On 02/26/2015 12:35 PM, Gabriele Bulfon wrote:
> 0803d0e8 libc.so.1`_lwp_kill+0x15(1, 6, 10e3, fef66000, fef66000, 0)
> 0803d108 libc.so.1`raise+0x2b(6, 0, 803d120, efe70dd9, 0, 0)
> 0803d158 libc.so.1`abort+0x10e(0, f0100000, 803d308, effda2d3, 1, f00b877d)
> 0803d168 libjvm.so`__1cCosFabort6Fb_v_+0x51(1, f00b877d, 1, 7d0)
> 0803d308 libjvm.so`__1cHVMErrorOreport_and_die6M_v_+0xab3(803d380, 803d4b4)
> 0803d3d8 libjvm.so`JVM_handle_solaris_signal+0xa6e(b, 803d6b4, 803d4b4, 1)
> 0803d3f8 libjvm.so`signalHandler+0x26(b, 803d6b4, 803d4b4, fef66000,
> 803d470, feee7f73)
> 0803d410 libc.so.1`__sighndlr+0x15(b, 803d6b4, 803d4b4, ef81acd4, 0, 29)
> 0803d470 libc.so.1`call_user_handler+0x292(b, 803d6b4, 803d4b4,
> fe0749ee, 0, 29)
> 0803d4a0 libc.so.1`sigacthandler+0x77(b, 803d6b4, 803d4b4)
> 0803d758 libc.so.1`memcpy+0x1b(8, fd35c7bc, 1b, 0, fef6a380, fea90180)
> 0803d788 libuno_sal.so.3`rtl_uString_newFromStr_WithLength+0x63(803d7cc,
> fd35c7bc, 1b, fe0768b3, fef6ca00)
[...]
> libfwklo.so`_ZN3com3sun4star3uno13WeakReferenceINS1_5frame7XFrame2EED1Ev+0x1d(f35cfc40,
> fef6a380, 803dab8, fec06f85, fec19ac0)
> 0803da98
> libfwklo.so`_Z41__static_initialization_and_destruction_0ii+0x4c(0,
> ffff, feffc480, ef2800c4, 803dad0, fefca3b1)
> 0803dab8 libfwklo.so`_GLOBAL__sub_D_frame.cxx+0x1a(803daf0, fefca394,
> feffb0a4, f32ed90a, f34cc000, f7b60018)
> 0803dad8 0xf32ed950(feffb0a4, fefcebf3, feffb0a4, f7b60018, 803db30,
> fefd21a8)
> 0803daf0 libfwklo.so`_fini+0x1b(feffc480, 0, f7b60018, f, 0, 8e)
> 0803db30 ld.so.1`call_fini+0xb3(feffc480, ef280018, 0, 0)
> 0803db60 ld.so.1`atexit_fini+0x66(0, 10, fef804f0, fef804f0, 101a, 6cf04)
> 0803dbb0 libc.so.1`__cxa_finalize+0x85(0, 10, 80560af, 0, fef66000, 803dbbc)
> 0803dbd0 libc.so.1`_exithandle+0x37(feffb0a4, 80560af, 0, 0, 803dc58,
> 8056042)
> 0803dbf4 libc.so.1`exit+0x12(15, 803e978, 803ea01, 803ea9d, 803eaa8,
> 803eb28)

That would be apparently be

> static css::uno::WeakReference< css::frame::XFrame2 >                   m_xCloserFrame;

in framework/source/services/frame.cxx wreaking havoc when destroyed 
during exit.  Looks like in your case rtl_allocateMemory is already 
returning nullptr, probably indicating that atexit handlers of sal are 
run prior to those of fwk, which would be a bug.

That said, static data with destructor is always bad (and just a lucky 
coincidence this one appears to not wreak havoc elsewhere) and should be 
removed, but also I don't see any immediate way how to do it in this case.