<div style="font-family: Verdana; font-size: 12;"><br><div><br>wow....so? what can I do? is this cppunit stage necessary to complete the build?</div><div>What if I could disable this and go on? would it possibly work?</div><tt><br>----------------------------------------------------------------------------------<br><br>Da: Stephan Bergmann <sbergman@redhat.com><br>A: libreoffice@lists.freedesktop.org <br>Data: 27 febbraio 2015 18.34.08 CET<br>Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos<br><br></tt><blockquote style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><tt>On 02/26/2015 12:35 PM, Gabriele Bulfon wrote:<br>> 0803d0e8 libc.so.1`_lwp_kill+0x15(1, 6, 10e3, fef66000, fef66000, 0)<br>> 0803d108 libc.so.1`raise+0x2b(6, 0, 803d120, efe70dd9, 0, 0)<br>> 0803d158 libc.so.1`abort+0x10e(0, f0100000, 803d308, effda2d3, 1, f00b877d)<br>> 0803d168 libjvm.so`__1cCosFabort6Fb_v_+0x51(1, f00b877d, 1, 7d0)<br>> 0803d308 libjvm.so`__1cHVMErrorOreport_and_die6M_v_+0xab3(803d380, 803d4b4)<br>> 0803d3d8 libjvm.so`JVM_handle_solaris_signal+0xa6e(b, 803d6b4, 803d4b4, 1)<br>> 0803d3f8 libjvm.so`signalHandler+0x26(b, 803d6b4, 803d4b4, fef66000,<br>> 803d470, feee7f73)<br>> 0803d410 libc.so.1`__sighndlr+0x15(b, 803d6b4, 803d4b4, ef81acd4, 0, 29)<br>> 0803d470 libc.so.1`call_user_handler+0x292(b, 803d6b4, 803d4b4,<br>> fe0749ee, 0, 29)<br>> 0803d4a0 libc.so.1`sigacthandler+0x77(b, 803d6b4, 803d4b4)<br>> 0803d758 libc.so.1`memcpy+0x1b(8, fd35c7bc, 1b, 0, fef6a380, fea90180)<br>> 0803d788 libuno_sal.so.3`rtl_uString_newFromStr_WithLength+0x63(803d7cc,<br>> fd35c7bc, 1b, fe0768b3, fef6ca00)<br>[...]<br>> libfwklo.so`_ZN3com3sun4star3uno13WeakReferenceINS1_5frame7XFrame2EED1Ev+0x1d(f35cfc40,<br>> fef6a380, 803dab8, fec06f85, fec19ac0)<br>> 0803da98<br>> libfwklo.so`_Z41__static_initialization_and_destruction_0ii+0x4c(0,<br>> ffff, feffc480, ef2800c4, 803dad0, fefca3b1)<br>> 0803dab8 libfwklo.so`_GLOBAL__sub_D_frame.cxx+0x1a(803daf0, fefca394,<br>> feffb0a4, f32ed90a, f34cc000, f7b60018)<br>> 0803dad8 0xf32ed950(feffb0a4, fefcebf3, feffb0a4, f7b60018, 803db30,<br>> fefd21a8)<br>> 0803daf0 libfwklo.so`_fini+0x1b(feffc480, 0, f7b60018, f, 0, 8e)<br>> 0803db30 ld.so.1`call_fini+0xb3(feffc480, ef280018, 0, 0)<br>> 0803db60 ld.so.1`atexit_fini+0x66(0, 10, fef804f0, fef804f0, 101a, 6cf04)<br>> 0803dbb0 libc.so.1`__cxa_finalize+0x85(0, 10, 80560af, 0, fef66000, 803dbbc)<br>> 0803dbd0 libc.so.1`_exithandle+0x37(feffb0a4, 80560af, 0, 0, 803dc58,<br>> 8056042)<br>> 0803dbf4 libc.so.1`exit+0x12(15, 803e978, 803ea01, 803ea9d, 803eaa8,<br>> 803eb28)<br><br>That would be apparently be<br><br>> static css::uno::WeakReference< css::frame::XFrame2 >                   m_xCloserFrame;<br><br>in framework/source/services/frame.cxx wreaking havoc when destroyed <br>during exit.  Looks like in your case rtl_allocateMemory is already <br>returning nullptr, probably indicating that atexit handlers of sal are <br>run prior to those of fwk, which would be a bug.<br><br>That said, static data with destructor is always bad (and just a lucky <br>coincidence this one appears to not wreak havoc elsewhere) and should be <br>removed, but also I don't see any immediate way how to do it in this case.<br>_______________________________________________<br>LibreOffice mailing list<br>LibreOffice@lists.freedesktop.org<br>http://lists.freedesktop.org/mailman/listinfo/libreoffice<br><br><br></tt></blockquote></div>