dbx: internal error: signal SIGSEGV (no mapping at the fault address)

I trying to debug a 64-bit program on Suse-Linux Enterprise Server 9 SP3 but get only following error messages instead:

(dbx) cd /local/billit/billitdev/mdvt072/vs-4.0

(dbx) debug /local/billit/billitdev/mdvt072/vs-4.0/bin64/bse

Reading bse

Reading ld-linux-x86-64.so.2

Reading libclntsh.so.10.1

Reading libboaldbidlg.so

Reading libboalappidlg.so

Reading libboalidlg.so

Reading libbseparserg.so

Reading libmico2.3.12g.so

Reading libmicocoss2.3.12g.so

Reading libstdc++.so.6

Reading libm.so.6

Reading libgcc_s.so.1

Reading libc.so.6

Reading libnnz10.so

Reading libdl.so.2

Reading libpthread.so.0

Reading libnsl.so.1

dbx: internal error: signal SIGSEGV (no mapping at the fault address)

dbx's coredump will appear in /tmp

[854 byte] By [Dzianis_Mazuronak] at [2007-11-26 8:34:54]
# 1
It's definitely a dbx bug, but it's not possible to tell what is the problem from error message. Could you please post crashed dbx stack trace here (it can be obtained with "dbx - /tmp/core")?
MaximKartashev at 2007-7-6 22:03:06 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 2
I would do it, but it is no file "core" in /tmp directory
Dzianis_Mazuronak at 2007-7-6 22:03:06 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 3
Hmm... There's a workaround: run dbx from dbx and when the one being debugged crashes, its "parent" should be able to display stack trace.
MaximKartashev at 2007-7-6 22:03:06 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 4

> dbx

For information about new features see `help changes'

To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc

(dbx) cd /opt/sun/sunstudio11/prod/bin/amd64/

(dbx) debug dbx

Reading dbx

Reading ld-linux-x86-64.so.2

Reading libdl.so.2

Reading libstdc++.so.5

Reading libm.so.6

Reading libgcc_s.so.1

Reading libc.so.6

(dbx) cd /local/billit/billitdev/mdvt072/vs-4.0

(dbx) debug /local/billit/billitdev/mdvt072/vs-4.0/bin64/bse

Reading bse

Reading libclntsh.so.10.1

Reading libboaldbidlg.so

Reading libboalappidlg.so

Reading libboalidlg.so

Reading libbseparserg.so

Reading libmico2.3.12g.so

Reading libmicocoss2.3.12g.so

Reading libstdc++.so.6

Reading libnnz10.so

Reading libpthread.so.0

Reading libnsl.so.1

dbx: internal error: signal SIGSEGV (no mapping at the fault address)

dbx's coredump will appear in /tmp

Aborted

and I have my prompt again

Dzianis_Mazuronak at 2007-7-6 22:03:06 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 5
So, both dbx die... By the way: are you able to successfully debug any other application with dbx (for example, /usr/bin/sort)?
MaximKartashev at 2007-7-6 22:03:06 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 6

I compiled very simple programm to test and i got no problem running it in dbx.

I noticed, that dbx is linked with libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x0000002a95770000), but there is another stdc++library:

libstdc++.so.6 => /usr/local/gcc-3.4.6/lib64/libstdc++.so.6 (0x0000002a9566d000)

Could this be a reason for dbx crash?

Dzianis_Mazuronak at 2007-7-6 22:03:06 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 7
No, it shouldn't be. Currently all Sun Studio binaries are linked with 5th version of libstdc++ on Linux.
MaximKartashev at 2007-7-6 22:03:06 > top of Java-index,Development Tools,Solaris and Linux Development Tools...