Crashes normally, but not with GDB?

Question

My program crashes with a segmentation fault when ran normally. So I run it with gdb, but it won't crash when I do that. Does anyone know why this might occur? I know that Valgrind's faq mentions this (not crashing under valgrind), but I couldn't really find anything about this related to gdb in google. If someone could tell me why, or recommend something to look for when this happens I would be very grateful.

Answer 1

I've had this happen to me before (you're not alone), but I can't remember what I did to fix things (I think it was a double free).

My suggestion would be to set up your environment to create core dumps, then use GDB to investigate the core dump after the program crashes. In bash, this is done with ulimit -c size, where size can be anything; I personally use 50000 for 25MB max size; the unit is in 512-byte increments.

You can use GDB to investigate a core dump by using gdb program core.

Answer 2

Sounds like a Heisenbug you have there :-)

If the platform you're working with is able to produce core files it should be possible to use the core file and gdb to pinpoint the location where the program crashes - short explanation can be found here.

Let it crash a couple of times though, when the crash is caused by stack smashing or variable overwriting the bug may seem to "walk around".

Answer 3

Well I tracked it down to a pthread_detach call. I was doing pthread_detach(&thethread). I just took away the reference and changed it to pthread_detach(thethread) and it worked fine. I'm not positive, but maybe it was a double free by detaching the reference then destroying it again when it went out of scope?

Answer 4

Try attaching to the running process within gdb, continuing, and then reproducing the crash. In other words, don't start the program within gdb; instead, start the program normally and then attach <pid>.

Sometimes when stepping through lines individually, a race condition that causes the program to crash will not manifest, as the race hazard has been eliminated or made exceedingly improbable by the "lengthy" pauses between steps.

Answer 5

Check for return value of pthread_detach call. According to your answer, you are probably passing invalid thread handle to pthread_detach.