Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


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.