Re: another cppunit test core dump, java this time, building on xstreamos/illumos
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@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 wowso? 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, f010, 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, , 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 ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
...also postprocess services cpp unit test coredumps...disabled this too... Gabriele Bulfon - Sonicle S.r.l. Tel +39 028246016 Int. 30 - Fax +39 028243880 via Santa Maria Valle 3 - 20123 - Milano - Italy http://www.sonicle.com Da: Gabriele Bulfon A: Stephan Bergmann libreoffice@lists.freedesktop.org Data: 28 febbraio 2015 9.02.26 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos 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@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 wowso? 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, f010, 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, , 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 ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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, f010, 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, , 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 css::frame::XFrame2 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
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
. #28 0xf33c5c4a in _GLOBAL__sub_D_frame.cxx () from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/libfwklo.so No symbol table info available. #29 0xf32ed950 in __do_global_dtors_aux () from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/libfwklo.so No symbol table info available. #30 0xf348acab in _fini () from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/libfwklo.so No symbol table info available. #31 0xfefd21a8 in call_fini () from /lib/ld.so.1 No symbol table info available. #32 0xfefd22cd in atexit_fini () from /lib/ld.so.1 No symbol table info available. #33 0xfee6e5f6 in __cxa_finalize () from /lib/libc.so.1 No symbol table info available. #34 0xfee6e98d in _exithandle () from /lib/libc.so.1 No symbol table info available. #35 0xfee623e2 in exit () from /lib/libc.so.1 No symbol table info available. #36 0x080560af in _start () No symbol table info available. Da: Gabriele Bulfon A: Stephan Bergmann libreoffice-dev Data: 27 febbraio 2015 9.28.38 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos Tried adding the join call, but no luck. Now I tried to run make for debugging, entered gdb and issued run. Looks like I need to enable some debugs. What module though? GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-pc-solaris2.11. For bug reporting instructions, please see: ... Reading symbols from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Executable/cppunittester...(no debugging symbols found)...done. (gdb) run Starting program: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Executable/cppunittester /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/CppunitTest/libtest_dbaccess_macros_test.so --headless -env:BRAND_BASE_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir -env:BRAND_SHARE_SUBDIR=share -env:UserInstallation=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/dbaccess_macros_test.test.user -env:CONFIGURATION_LAYERS=xcsxcu:file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/share/registry\ xcsxcu:file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/unittest/registry -env:UNO_TYPES=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/types/offapi.rdb\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/types/oovbaapi.rdb\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/share/misc/types.rdb -env:UNO_SERVICES=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/Rdb/ure/services.rdb\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/basic/util/sb.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/comphelper/util/comphelp.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/configmgr/source/configmgr.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/dbaccess/util/dba.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/dbaccess/util/dbu.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/dbaccess/util/sdbt.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/dbaccess/source/filter/xml/dbaxml.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/filter/source/config/cache/filterconfig1.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/forms/util/frm.component\ file:///sources
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
wowso? 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, f010, 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, , 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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
/scriptframe.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/sfx2/util/sfx.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/sot/util/sot.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/svl/source/fsstor/fsstorage.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/svl/util/svl.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/toolkit/util/tk.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/ucb/source/core/ucb1.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/ucb/source/ucp/file/ucpfile1.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/ucb/source/ucp/tdoc/ucptdoc1.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/unotools/util/utl.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/unoxml/source/rdf/unordf.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/unoxml/source/service/unoxml.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/xmloff/util/xo.component -env:URE_INTERNAL_LIB_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/lib -env:LO_LIB_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program -env:LO_JAVA_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/classes --protector /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector --protector /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Library/unobootstrapprotector.so unobootstrapprotector --protector /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] [New LWP2] gobject.py: gdb was not built with custom backtrace support, disabling. [New LWP3] [New LWP4] [New Thread 4 (LWP 4)] [New LWP5] [LWP3 exited] [New LWP6] [New LWP7] [LWP5 exited] [LWP6 exited] OK (1) [New LWP8] [New LWP9] [New LWP10] [New LWP11] [New LWP12] [New LWP13] [New LWP14] [LWP4 exited] [Switching to Thread 4 (defunct)] sol_thread_fetch_registers: td_ta_map_id2thr: no thread can be found to satisfy query sol_thread_fetch_registers: td_ta_map_id2thr: no thread can be found to satisfy query sol_thread_fetch_registers: td_ta_map_id2thr: no thread can be found to satisfy query Da: Gabriele Bulfon A: Stephan Bergmann libreoffice-dev Data: 27 febbraio 2015 8.55.41 CET Oggetto: 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
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, f010, 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_10XInterfaceC1El+0x54(803d968, 11, 0, fee839fe, 8f, fe692000) 0803d988 libuno_cppuhelpergcc3.so.3`_ZN4cppuL23sequenceRemoveElementAtERN3com3sun4star3uno8SequenceINS3_9ReferenceINS3_10XInterfaceEl+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, , 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
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, f010, 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_10XInterfaceC1El+0x54(803d968, 11, 0, fee839fe, 8f, fe692000) 0803d988 libuno_cppuhelpergcc3.so.3`_ZN4cppuL23sequenceRemoveElementAtERN3com3sun4star3uno8SequenceINS3_9ReferenceINS3_10XInterfaceEl+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, , 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
another cppunit test core dump, java this time, building on xstreamos/illumos
Hi,
build is moving forward, got past the nss/openssl issues (I will want to see
how to let nss work later).
All libs and binaries look to be built correctly under instdir/program, ldd
shows no unresolved issues now.
Here is what happens now.
Let me know if you need any other log/dump infos
[build CUT] dbaccess_macros_test
S=/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3
I=$S/instdir W=$S/workdir mkdir -p $W/CppunitTest/ rm -fr
$W/CppunitTest/dbaccess_macros_test.test.user mkdir
$W/CppunitTest/dbaccess_macros_test.test.userrm -fr
$W/CppunitTest/dbaccess_macros_test.test.core mkdir
$W/CppunitTest/dbaccess_macros_test.test.core cd
$W/CppunitTest/dbaccess_macros_test.test.core
(LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/ure/lib:$I/program:$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_dbaccess_macros_test.so --headless
-env:BRAND_BASE_DIR=file://$S/instdir -env:BRAND_SHARE_SUBDIR=share
-env:UserInstallation=file://$W/CppunitTest/dbaccess_macros_test.test.user
-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry
xcsxcu:file://$W/unittest/registry
-env:UNO_TYPES=file://$I/program/types/offapi.rdb
file://$I/program/types/oovbaapi.rdb file://$I/ure/share/misc/types.rdb
-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
file://$W/ComponentTarget/basic/util/sb.component
file://$W/ComponentTarget/comphelper/util/comphelp.component
file://$W/ComponentTarget/configmgr/source/configmgr.component
file://$W/ComponentTarget/dbaccess/util/dba.component
file://$W/ComponentTarget/dbaccess/util/dbu.component
file://$W/ComponentTarget/dbaccess/util/sdbt.component
file://$W/ComponentTarget/dbaccess/source/filter/xml/dbaxml.component
file://$W/ComponentTarget/filter/source/config/cache/filterconfig1.component
file://$W/ComponentTarget/forms/util/frm.component
file://$W/ComponentTarget/framework/util/fwk.component
file://$W/ComponentTarget/i18npool/util/i18npool.component
file://$W/ComponentTarget/oox/util/oox.component
file://$W/ComponentTarget/package/source/xstor/xstor.component
file://$W/ComponentTarget/package/util/package2.component
file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component
file://$W/ComponentTarget/scripting/source/basprov/basprov.component
file://$W/ComponentTarget/scripting/util/scriptframe.component
file://$W/ComponentTarget/sfx2/util/sfx.component
file://$W/ComponentTarget/sot/util/sot.component
file://$W/ComponentTarget/svl/source/fsstor/fsstorage.component
file://$W/ComponentTarget/svl/util/svl.component
file://$W/ComponentTarget/toolkit/util/tk.component
file://$W/ComponentTarget/ucb/source/core/ucb1.component
file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component
file://$W/ComponentTarget/ucb/source/ucp/tdoc/ucptdoc1.component
file://$W/ComponentTarget/unotools/util/utl.component
file://$W/ComponentTarget/unoxml/source/rdf/unordf.component
file://$W/ComponentTarget/unoxml/source/service/unoxml.component
file://$W/ComponentTarget/xmloff/util/xo.component
-env:URE_INTERNAL_LIB_DIR=file://$I/ure/lib -env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector --protector
$W/LinkTarget/Library/libvclbootstrapprotector.so
vclbootstrapprotector$W/CppunitTest/dbaccess_macros_test.test.log 21;|| (
RET=$?; $S/solenv/bin/gdb-core-bt.sh $W/LinkTarget/Executable/cppunittester
$W/CppunitTest/dbaccess_macros_test.test.core
$RET$W/CppunitTest/dbaccess_macros_test.test.log 21; cat
$W/CppunitTest/dbaccess_macros_test.test.log; $S/solenv/bin/unittest-failed.sh
Cppunit dbaccess_macros_test))
/bin/sh: line 1: 22271: Abort(coredump)
OK (1)
#
# 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
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
