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@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.