Trying to catch a difficult bug

[Kempelen]

I have a crash (program unexpectly exited) in my code. Trying to debug it with printf, I come to the line:

Code: Select all

int tiempo_seguridad[12] = { 0, 25, 100, 100, 200, 200, 200, 300, 300, 300, 300, 300};

where it looks it is the problem.

If I put:

Code: Select all

int tiempo_seguridad[12] = { 0, 25, 100, 100, 200, 200, 200, 300, 300, 300, 300, 300};
printf("Aqui\n");

the program crash and I dont see the printf

But if i write

Code: Select all

printf("Aqui\n");
int tiempo_seguridad[12] = { 0, 25, 100, 100, 200, 200, 200, 300, 300, 300, 300, 300};

the program does not crash never and I can see the printf!

how can I see where is my problem?. I dont see any problem in that line. If I use a debuger I dont see nothing special?. I have even trying with different mingw compiler versions without success.

thanks.

[AlvaroBegue]

You are probably invoking undefined behavior somewhere. There are tools that can help with some of the memory management issues that are often the cause of these things, like Valgrind.

[Ras]

Remember that standard printf might be delayed. That means, the actual output of printf might occur AFTER the crashing line, in which case this isn't useful because the program has aborted by then. For standard debug outputs, it is ok, but not for crashes. Do a printf to stderr, that isn't delayed.

If you are using GCC, then try also using GDB with a catch on the relevant signal, e.g. that one for a segfault. That will even give you the precise line of the crash (if compiled with -g), and you can inspect the variables.

[Evert]

It could be that you run out of stack space. This array is small, but if you have large objects on there already it might be the straw that breaks the camel's back.
Try moving some large datastructures to the heap.

[hgm]

Debugging with printf for crashes has failed me several times now, and I guess it just isn't a reliable method any more with current compilers. I have had several cases where the code

Code: Select all

printf("A\n"),fflush(stdout);
a=b;
printf("B\n"),fflush(stdout);

printed A and crashed before it could print B, and the cause of the crash (as reveald by compiling with the -g option and running gdb) was nowhere near the statement a=b, and not related to it in any way, but just an out-of-bounds read access to an array elsehwere.

[Kempelen]

Debugging with printf for crashes has failed me several times now, and I guess it just isn't a reliable method any more with current compilers. I have had several cases where the code

Code: Select all

printf("A\n"),fflush(stdout);
a=b;
printf("B\n"),fflush(stdout);

printed A and crashed before it could print B, and the cause of the crash (as reveald by compiling with the -g option and running gdb) was nowhere near the statement a=b, and not related to it in any way, but just an out-of-bounds read access to an array elsehwere.

The problems is "elsewhere". I am crazy for a week searching where the bug could be without any success. I have gone version back until the error happens, but I dont see nothing in the code because I think it is an error that was in the code hidden before for lot of time without appearing.
I am loss and exhausted with this bug. I have passes cppcheck, drmemory, ... etc and no one found nothing. The corious thing is that if I remove that line the code work. I dont understand why the program hang in a line is not executed never at runtime.
any idea on how to found "elsewhere"?

[Evert]

The problems is "elsewhere". I am crazy for a week searching where the bug could be without any success. I have gone version back until the error happens, but I dont see nothing in the code because I think it is an error that was in the code hidden before for lot of time without appearing.
I am loss and exhausted with this bug. I have passes cppcheck, drmemory, ... etc and no one found nothing. The corious thing is that if I remove that line the code work. I dont understand why the program hang in a line is not executed never at runtime.
any idea on how to found "elsewhere"?

As I said, it sounds very much like the symptoms I've seen from running out of stack space.

[Kempelen]

The problems is "elsewhere". I am crazy for a week searching where the bug could be without any success. I have gone version back until the error happens, but I dont see nothing in the code because I think it is an error that was in the code hidden before for lot of time without appearing.
I am loss and exhausted with this bug. I have passes cppcheck, drmemory, ... etc and no one found nothing. The corious thing is that if I remove that line the code work. I dont understand why the program hang in a line is not executed never at runtime.
any idea on how to found "elsewhere"?

As I said, it sounds very much like the symptoms I've seen from running out of stack space.

I dont fully understand this. I dont use stacks in my code, and if you refer to the compiler stack, I dont know exactly how to fix it. I dont have any large structures in that function to move up.

Anyway your comments point me to make a test. I have executed that function but in the main thread (I have 2 one for io and the other for thinking) and it does not crash. Surely can be a problem with the stack of the other thread? but what is curious is that the thread never "start thinking" because it crash in "calculate time to use function" that is executed first .

[Henk]

I remember difficult bugs when multiple threads and global variables. So only use thread safe constructs or no global variables.

In principal only functional programming is ok.

[Ras]

I guess the compiler optimisation can be an issue here. In C, the compiler is free to re-order non-volatile memory access as long as the result is equivalent - under the assumption that no undefined behaviour happens.

But crashing is pretty much the most undefined behaviour possible.

So it may happen that the compiler is moving the crashing instruction before the printf although in the source text, it is after the printf.

On the CPU level with out-of-order execution of modern x86 CPUs, there may be some additional fun.