Date: Wed, 29 Nov 2023 20:58:01 -0000 (UTC) From: "Peter 'PMc' Much" <pmc@citylink.dinoex.sub.org> To: freebsd-hackers@freebsd.org Subject: Re: analysing a coredump Message-ID: <slrnumf9ep.mn0.pmc@disp.intra.daemon.contact> References: <ZWchjl9RYH0fc6AF@int21h>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2023-11-29, void <void@f-m.fm> wrote: > 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 problem? > > [1] gdb etc aren't my wheelhouse *at all* but i'm willing to learn, and any > tips/pointers would be much appreciated, thanks Hi, there are certainly people here who are doing such regularly. I am only doing it when a bug hits me. I recommend recompiling with debug symbols, and also setting -O0 (because otherwise many interesting things get "optimized away"). Then a backtrace should give proper locations to be found in the source, and probably understood from there. Since I cannot remember the options, I coded them into my build engine, as such: https://gitr.daemon.contact/sysup/commit/?id=3e15a711236c90ac9d525b83d1388cb8e4e1141d Adding these options to make.conf has worked for me (but may depend on how the port is designed). Also there is a "lldb" command on the system, which may or may not give better results, anyway that has elaborate features. cheerio & good luck!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnumf9ep.mn0.pmc>