analysing a coredump

[void]

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

[Cy Schubert]

Post by void
Hi,
httpd had an unexpected coredump. I installed gbd and with
(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 <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: https://FreeBSD.org
NTP: <***@nwtime.org> Web: https://nwtime.org

e^(i*pi)+1=0




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[George Mitchell]

[...] I recommend recompiling with
debug symbols, and also setting -O0 (because otherwise many
interesting things get "optimized away").
[...]

I've seen "-O0" cause bugs to disappear, though, as suggested by Werner
Heisenberg. You never know ... -- George



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[void]

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
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).

I have poudriere-devel, and was thinking of doing it like so:

poudriere bulk -j 132Ramd64 -O sccache -f portslist.txt -i
(finishes bulk build, go into interactive mode)
cd /usr/ports/www/apache24
make -DBATCH -DDEBUG && make

but not sure here how I'd modify CFLAGS for -O0

There's no DEBUG in the options for this port

[Alastair Hogge]

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,
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).

poudriere bulk -j 132Ramd64 -O sccache -f portslist.txt -i (finishes
bulk build, go into interactive mode)
cd /usr/ports/www/apache24 make -DBATCH -DDEBUG && make
but not sure here how I'd modify CFLAGS for -O0
There's no DEBUG in the options for this port

You can use make.conf, or whatever make conf poudriere is using.

[void]

Post by Alexander Leidinger
A port-build normally strips away debug info. But we have
https://wiki.freebsd.org/DebuggingPorts
You can even add this to the poudriere make.conf.

this EXACTLY is what I needed, TYVM :D

[Dave Cottlehuber]

Post by void

Post by Alexander Leidinger
You can even add this to the poudriere make.conf.

this EXACTLY is what I needed, TYVM :D
--

You can localise this to a single port by wrapping that inside make.conf

endif
# debug only this port
.if ${.CURDIR:M*/www/h2o}
…. magical dust goes here
.endif

A+
Dave


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alexander Leidinger]

Post by void

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
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).

poudriere bulk -j 132Ramd64 -O sccache -f portslist.txt -i
(finishes bulk build, go into interactive mode)
cd /usr/ports/www/apache24
make -DBATCH -DDEBUG && make
but not sure here how I'd modify CFLAGS for -O0
There's no DEBUG in the options for this port

A port-build normally strips away debug info. But we have infrastructure
for this:
https://wiki.freebsd.org/DebuggingPorts

You can even add this to the poudriere make.conf.

Bye,
Alexander.