Abort (core dumped)

[ricomoss]

I've got a good question for you guys. I'm making some changes to existing code and have run into an issue I'm not sure how to fix.

I'm trying to compile and run this program on Solaris and Linux. As of now the program compiles and runs. There are still some changes to be made but before I continue I'd like to fix the following issues.

On Solaris I get this upon the program's completion:

pure virtual method called
terminate called without an active exception
Abort (core dumped)

On Linux I get this upon the program's completion:

Segmentation fault (core dumped)

So, I've tried to do some core dump analysis on both and have run into issues.

Core Dump Analysis On Solaris:

bash-3.00$ dbx MyProgram core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc
Reading MyProgram
core file header read successfully
Reading ld.so.1
Reading librt.so.1
Reading libboost_iostreams-mt-d.so
Reading libboost_system-mt-d.so
Reading libboost_program_options-mt-d.so
Reading libclntsh.so.10.1
Reading libstdc++.so.6.0.10
Reading libm.so.2
Reading libgcc_s.so.1
Reading libpthread.so.1
Reading libc.so.1
Reading libaio.so.1
Reading libmd.so.1
Reading libbz2.so.1
Reading libz.so.1
Reading libnnz10.so
Reading libkstat.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libgen.so.1
Reading libdl.so.1
Reading libsched.so.1
Reading libm.so.1
Reading libc_psr.so.1
Reading libscf.so.1
Reading libdoor.so.1
Reading libuutil.so.1
Reading libmd_psr.so.1
Reading libmp.so.2
Reading nss_files.so.1
Reading nss_vas3.so.1
Reading libvas.so.4.5.1
Reading libresolv.so.2
t@1 (l@1) program terminated by signal ABRT (Abort)
0xffffffff7ceda210: __lwp_kill+0x0008:  bcc,a,pt  %icc,__lwp_kill+0x18  ! 0xffffffff7ceda220

dbx: internal error: signal SIGSEGV (no mapping at the fault address)
dbx's coredump will appear in /tmp
Abort 

Yeah, you read it right. If I do dbx core analysis dbx core dumps. Lovely.

Core Dump Analysis On Linux:

bash-4.1$ gdb MyProgram core
GNU gdb (GDB) Fedora (7.1-34.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from MyProgram...done.

warning: core file may not match specified executable file.

warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386

warning: Architecture rejected target-supplied description

warning: Couldn't find general-purpose registers in core file.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
warning: the debug information found in "/usr/lib/debug//lib64/ld-2.12.1.so.debug" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).


warning: the debug information found in "/usr/lib/debug/lib64/ld-2.12.1.so.debug" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2

warning: Couldn't find general-purpose registers in core file.
#0  0x0000000000000000 in _start () from /lib64/ld-linux-x86-64.so.2
Missing separate debuginfos, use: debuginfo-install glibc-2.12.1-4.x86_64
(gdb) where
#0  0x0000000000000000 in _start () from /lib64/ld-linux-x86-64.so.2
Cannot access memory at address 0x0
(gdb)

I know the issue isn't the switch between Linux and Unix (compile with gcc on both). I've rebuilt the environment before each compile, have all the make files and such configured right, etc.

I don't completely understand how to interpret a core dump analysis and I can't seem to make any forward progress.

Does anyone have any useful suggestions on what I need to do?

[vvadan]

Just a guess,

if your program is getting aborted at the end of execution, it could be that its trying to clean up global / extern variables twice. Just check whether you are cleaning up all the variables fine. I mean you are not trying to delete a variable that is already deleted.

Also, the warning "Selected architecture i386:x86-64 is not compatible with reported target architecture i386" indicates that you built on 32 bit architecture and trying to run your application on 64 bit architecture.

[ricomoss]

Thanks, vvadan. I'm looking into the issue right now but since it is now a C++ issue I've moved the question to the appropriate forum. I'll follow up here when I determine what could be the underlying cause.

About the 32-bit/64-bit stuff...we're slowly (very slowly) migrating our software from Solaris to Linux and haven't completely standardized our hardware (we have many Linux boxes and not all are 64-bit). Thanks for the heads up though.

[juliepainting]

thank you for this information. Glad I have found it.