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

Maybe this is related?
http://nabble.documentfoundation.org/dbaccess-macros-test-no-orderly-shutdown-td3748013.html
Looks like it's trying to exit, but causing the coredump.
The patch proposed seems to be in conflict with the current source:
m_pEventBroadcaster-removeEventsForProcessor( this );
m_pEventBroadcaster-terminate();
//TODO: a protocol is missing how to join with the thread before
// exit(3), to ensure the thread is no longer relying on any
// infrastructure while that infrastructure is being shut down
// in atexit handlers; simply calling join here leads to
// deadlock, as this thread holds the solar mutex while the
// other thread is typically blocked waiting for the solar mutex
m_pEventBroadcaster.clear();
maybe I should try anyway?
Da:
Gabriele Bulfon
A:
Stephan Bergmann
libreoffice-dev
Data:
26 febbraio 2015 12.35.40 CET
Oggetto:
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
Thanks. Here is what illumos mdb shows of the core:
$C
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)
0803d7a8 libuno_sal.so.3`rtl_uString_newFromSubString+0xa0(803d7cc, fd35c7b0, 2, 1b, 803d884, 
86c04f0)
0803d7d8 libuno_cppu.so.3`_ZNK3rtl8OUString4copyEl+0x48(803d818, 803d884, 2, 6, 859a3b8, fe670270)
0803d878 libuno_cppu.so.3`typelib_typedescription_getByName+0x66a(803d8f4, fd35c7b0, fd310738, 
803da4c, f1fe0920, 803da40)
0803d8a8 libuno_cppu.so.3`typelib_typedescriptionreference_getDescription+0x122(803d8f4, 84b88f8, 
52, f1f221f4, fea92a40, fe0a8000)
0803d8c8 libuno_cppu.so.3`TYPELIB_DANGER_GET+0x61(803d8f4, 84b88f8, 0, fef66000, fea92a40, 8092c50)
0803d908 libuno_cppu.so.3`uno_type_sequence_construct+0x35(803d968, 84b88f8, 0, 11, fe5df8aa, 
ef2800c0)
0803d948 
libuno_cppuhelpergcc3.so.3`_ZN3com3sun4star3uno8SequenceINS2_9ReferenceINS2_10XInterfaceEEEEC1El+0x54(803d968,
 11, 0, fee839fe, 8f, fe692000)
0803d988 
libuno_cppuhelpergcc3.so.3`_ZN4cppuL23sequenceRemoveElementAtERN3com3sun4star3uno8SequenceINS3_9ReferenceINS3_10XInterfaceEEEEEl+0x41(f1863270,
 e, 803da78, fda35530, fd35f000, 6)
0803d9d8 
libuno_cppuhelpergcc3.so.3`_ZN4cppu25OInterfaceContainerHelper15removeInterfaceERKN3com3sun4star3uno9ReferenceINS4_10XInterfaceEEE+0xb8(857594c,
 803da18, fea92a40, feeebd0a, fea92a40)
0803d9f8 
libuno_cppuhelpergcc3.so.3`_ZN4cppu20OWeakConnectionPoint15removeReferenceERKN3com3sun4star3uno9ReferenceINS4_10XReferenceEEE+0x2f(8575940,
 803da18, fea92a40, feeebd0a, fec19ac0, 0)
0803da38 
libuno_cppuhelpergcc3.so.3`_ZN3com3sun4star3uno19WeakReferenceHelper5clearEv+0x6e(f35cfc40, 
fef66000, fea92a40, 0, 803da60)
0803da58 libuno_cppuhelpergcc3.so.3`_ZN3com3sun4star3uno19WeakReferenceHelperD1Ev+0x1d(f35cfc40, 
fef66000, fea92a40, fef6a3c0, 803dab0)
0803da78 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)
----------------------------------------------------------------------------------
Da: Stephan Bergmann
A: libreoffice-dev
Data: 26 febbraio 2015 12.29.00 CET
Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos
On 02/26/2015 12:10 PM, Gabriele Bulfon wrote:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xfee6293b, pid=22271, tid=1
#
# JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
1.7.0_45-b18)
# Java VM: Java HotSpot(TM) Client VM (24.45-b08 mixed mode solaris-x86 )
# Problematic frame:
# C [libc.so.1+0x4293b] memcpy+0x1b
#
# Core dump written. Default location:
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/dbaccess_macros_test.test.core/core
or core.22271
#
# An error report file with more information is saved as:
#
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/dbaccess_macros_test.test.core/hs_err_pid22271.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
It looks like
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Executable/cppunittester
generated a core file at
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/dbaccess_macros_test.test.core/core
Backtraces:
so use a debugger to inspect the core file and find out what's wrong
(the JRE output is most likely a red herring---once a JVM is
instantiated in-process, it hooks into the signal handler and produces
output even if the fatal signal isn't JVM-related at all)
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
_______________________________________________LibreOffice mailing 
listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice