Fatal error disappeared when running with GDB

Question

I have a program which produces a fatal error with a testcase, and I can locate the problem by reading the log and the stack trace of the fatal. It turns out that there is a read operation upon a null pointer.

But when I try to attach GDB to it and set a breakpoint around the suspicious code, the null pointer just cannot be observed! The program works smoothly without any error.

This is a single-process, single-thread program, and I didn't experience this kind of thing before. Why is it?

Appended: I also tried to call the pause() system call before the fatal-trigger code, and expected to make the program sleep before the fatal point and then attach GDB on it on-the-fly, sadly, no fatal error occurred.

ahh, Heisenberg's Uncertainty Principle, applied to programming — K Mehta, Jul 05 '11 at 08:04
The notorious [heisenbug](http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug) — Fredrik Pihl, Jul 05 '11 at 08:10
Likely an uninitalized pointer, or a value that is used as condition for setting the pointer, that happens to be zero in non-debug. When debugging it has a different start value. — Bo Persson, Jul 05 '11 at 08:45
Related: *[Crashes normally, but not with GDB](https://stackoverflow.com/questions/7507336/)* (2011) — Peter Mortensen, Jul 28 '23 at 11:19

score 2 · Accepted Answer · answered Jul 05 '11 at 08:03

It's only guesswork without looking at the code, but debuggers sometimes do this:

They initialize certain stuff for you
The timing of the operations is changed

I don't have a quote on GDB, but I do have one on valgrind (granted the two do wildly different things..)

My program crashes normally, but doesn't under Valgrind, or vice versa. What's happening?

When a program runs under Valgrind, its environment is slightly different to when it runs natively. For example, the memory layout is different, and the way that threads are scheduled is different.

Same would go for GDB.

Most of the time this doesn't make any difference, but it can, particularly if your program is buggy.

So the true problem is likely in your program.

score 1 · Answer 2 · answered Jul 05 '11 at 08:13

There can be several things happening.. The timing of the application can be changed, so if it's a multi threaded application it is possible that you for example first set the ready flag and then copy the data into the buffer, without debugger attached the other thread might access the buffer before the buffer is filled or some pointer is set.

It's could also be possible that some application has anti-debug functionality. Maybe the piece of code is never touched when running inside a debugger.

One way to analyze it is with a core dump. Which you can create by ulimit -c unlimited then start the application and when the core is dumped you could load it into gdb with gdb ./application ./core You can find a useful write-up here: http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php

Thanks, but as I've said, there should be any thread issue, since it's single-threaded. And, unfortunately, I don't have the permission to run ulimit :\ — solotim, Jul 05 '11 at 08:34

score 0 · Answer 3 · answered Jul 05 '11 at 08:04

0

If it is an invalid read on a pointer, then unpredictable behaviour is possible. Since you already know what is causing the fault, you should get rid of it asap. In general, expect the unexpected when dealing with faulty pointer operations.

answered Jul 05 '11 at 08:04

Sriram

10,298
21
83
136

Fatal error disappeared when running with GDB

3 Answers3