Re: analysing a coredump

From: Cy Schubert <Cy.Schubert_at_cschubert.com>
Date: Wed, 29 Nov 2023 20:51:56 UTC
In message <ZWchjl9RYH0fc6AF@int21h>, void writes:
> Hi,
>
> httpd had an unexpected coredump. I installed gbd and with
> what little i know of it, ran gdb against the dump:
>
> (gdb) core /httpd.core
> [New LWP 101030]
> Core was generated by `/usr/local/sbin/httpd -DNOHTTPACCEPT'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> Address not mapped to object.
> #0  0x000000083f237930 in ?? ()
> (gdb) bt full
> #0  0x000000083f237930 in ?? ()
> No symbol table info available.
>
> (goes on like this for another 10 lines)
>
> I *guess* [1] I'll need to recompile apache24 with debug symbols then 
> wait for another crash. Is there anything else i can do regarding this proble
> m?

That usually helps.

Back in the day, on the mainframe, the compiler would print a list of 
statement offsets and variable offsets that one could derive as offsets 
from the function's base address. I don't believe our current compilers can 
do this and even then, building and linking after the fact just to get 
offsets may not result in the same map as your executing program. You're 
better off recompiling with debugging  symbols.

If you've used another debugger before, like on a different platform, the 
transition won't be as painful as you think. The concepts are similar. If 
you haven't before, it will take a bit of learning.


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0