I have a problem debugging a core file of a web application server with
the gdb. The application server is written in objective c, running in a
GNUstep environment, the binary is compiled with debugging information
and is not stripped.
when I try to examine the file I load it with gdb -c core-file
then in gdb I issue a symbol-file /usr/local/sbin/ogo-webui-1.1
this will load the symbols of the file.
then I looked with ldd /usr/local/sbin/ogo-webui-1.1 which shared
libraries are loaded. (well every output of ldd differs because of the
then in gdb I did add-symbol-file ...
for each shared library I saw in the ldd output, well I skipped to tell
gdb the address because I did not find out where these are because of the
whatever I tried, when I issue a bt in gdb, then I get lots of:
#0 0x0fd6e61c in ?? ()
#1 0x241aba78 in ?? ()
#2 0x08760d2c in ?? ()
#3 0x087619b2 in ?? ()
#4 0x7d984e40 in ?? ()
#5 0x0007d990 in ?? ()
#6 0x00000000 in ?? ()
#7 0x8bb1f000 in ?? ()
#8 0x8bb1f000 in ?? ()
#9 0x8bb1f000 in ?? ()
#10 0x2fd6500c in ?? ()
#11 0x2fd66898 in ?? ()
#12 0x221ef039 in ?? ()
#13 0x221f70c0 in ?? ()
#14 0xcfbf61e8 in ?? ()
#15 0x0fd6f987 in ?? ()
is there a way to find out at which starting points the shared libraries
were loaded as the application crashed? tried ldd, nm, objdump on the
core file, but without luck. Do I have to disable the randomness for
testing/debugging? If yes, where do I have to disable it,
-fno-stack-protection, /etc/malloc.conf, syctl kern.stackgap_random,
when I load a core file of the application in linux, and issue a
symbol-file command, then not only the symbols of the given binary but
also from all shared libraries are loaded automatically. Then issuing a
bt command in gdb shows me all the information I want. Does this somehow
work in the openbsd gdb?
i am a bit clueless now, so what can I do to find out why the application
crashed in openbsd?