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

[Gabriele Bulfon]

Ok, I disabled dbaccess_macro cppunit test.
Had also to disable dbaccess_hsqldb cppunit test, because of a coredump there too.
Now it's going on...
Da:
Gabriele Bulfon
A:
Stephan Bergmann
libreoffice at lists.freedesktop.org
Data:
27 febbraio 2015 20.19.38 CET
Oggetto:
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
wow....so? what can I do? is this cppunit stage necessary to complete the build?
What if I could disable this and go on? would it possibly work?
----------------------------------------------------------------------------------
Da: Stephan Bergmann
A: libreoffice at lists.freedesktop.org
Data: 27 febbraio 2015 18.34.08 CET
Oggetto: 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
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.
_______________________________________________
LibreOffice mailing list
LibreOffice at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
_______________________________________________LibreOffice mailing listLibreOffice at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150228/5617fd4c/attachment.html>