cc "-g" option fixes SIGSEGV?

[Neil Pike]

I was asked to debug a C program that had been moved from one machine to another - it was, allegedly, working with the same data on the source machine.

I re-compiled it on the new machine - no joy, still SIGSEGV'd, but the core dump was useless because there were no symbols.

I amended the compile just to use "-g" to get the symbols into the executable. And guess what - the program ran fine.

Any ideas why -g fixed the problem? I can't "debug" the problem now because it won't occur!!

(The original program was written and compiled 3-4 years ago and hasn't been touched since...)

[A. Clay Stephenson · Accepted solution]

Typically when you compile with -g you also disable the optimizer. It could well be that the non-optimized code does not exhibit the behavior. There have been a number of bugs in various optimization routines.

The other likely explanation is that the code is still broken; it's just not broken enough.

Consider this example:

int my_array[100];

my_array[-1] = 100;
my_array[100] = 200;

Now, you might expect either of these bogus assignments to cause a segmentation violation; in many cases, neither of these might because no page boundary was crossed so that the hardware might not detect it.

What you might try is compiling without -g but do not run 'strip' on the code file. This will certainly not give you enough data to zero in on the offending line but a stack trace should still work so that you can at least identify the function.

[Deepak Extross]

Neil,

I've seen this behavior over and over in poorly written code. As Clay says, -g retains the symbol table, which in turn, results in some of pesky bugs 'being suppressed'.

I'd strongly recommend using Rational's Purify. It can help to zero in on array overflows, uninitialized memory access, freeing unallocated memory, etc.

[T G Manikandan]

Did you check the kernel parameters on both the machines.

Just check for the
maxdsiz
maxdsiz_64bit
maxssiz
maxssiz_64bit
values

Probably the program is exceeding the value of data segment size for a process.


Thanks

[Martin Schneider_2]

This is a common phenomenon, it even has a name: Heisenbug. (This goes back to the Heisenberg Uncertainty Theorem which implies that you cannot measure an particles' speed and place without altering both).

The most common cause is that when you compile code with debug information, the memory layout of your program is a little different. Now when you have bad memory writes in your code, they can go unnoticed because now, by conincidence, the memory area you write too belongs to your process, and the program does not crash. (However, it alters data it should leave alone, so it is obviously still broken.)

[Jeff Billman]

The problem all boils down to a bad pointer. When you change the compile options to include debug code it moves the memory location where the "bad" pointer is pointing too. This new location just happens to be in a location that doesn't cause you program to fail. I would check for pointers which are not initiialized properly and string manipulations that cause memory to be accessed outside the bounds of the memory allocated for them.

[Neil Pike]

Thanks for all the very fast replies!

I'd already checked all the stack sizes etc. on both machines, both globally and the ulimit on the users concerned. All looked fine. If it was a "size" issue I'd have expected the debug version to fail as well.

I suspected the lack of optimisations and/or the different offsets/code padding (the symbols could well be getting corrupted, but that's not going to stop the program running!)

Just downloading an eval of Rational's Purify stuff. I'll see if that helps - thanks for the pointer.

I did try compiling it on NT (with Visual Studio .NET) because I'm far more au fait with NT development and tools. Unfortunately it gpf's on that when the filehandle for a file gets overwritten for some reason - different problem to that on the Unix system, as on Unix I can get it to process some files, but even the files that work on Unix crash on NT, so I suspect another bug got introduced then.

Anyway, enough rambling.

Thanks again