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)