topic Segmentation Fault in Operating System - Linux

Segmentation Fault

rajanandhini — Thu, 21 Jun 2007 10:51:41 GMT

Hi,

I would like to know some info regarding segmentation fault. We are migrating our old PA-RISC architectured server to a new IPF architecture. We have compiled the codes and when we execute the codes, we get some errors. On debugging, we found that the system was throwing segmentation fault. Also, each time we debugged the code, we got this segmentation fault at a different step.i.e. The first time we got it in line number 5 and the second time when we tried to debug the same, we got the error in some other line number, say 15. We are stuck here and any help in this regard will be greatly appreciated. Please let me know in case any more details are required.

Thanks,

nan

Re: Segmentation Fault

Steven Schweda — Thu, 21 Jun 2007 11:11:26 GMT

It's hard to say much without seeing line 5,
or 15, and the rest of the code. Many
problems are possible, like storing pointers
in 32-bit integers, which works much better
with 32-bit pointers than it does with 64-bit
pointers, for example.

Re: Segmentation Fault

Don Morris_1 — Thu, 21 Jun 2007 11:19:20 GMT

Segmentation fault is a SIGSEGV signal from the OS to the process. In the general sense, this is sent on an attempted access to a virtual address which is not considered valid for the process by the kernel (can be untranslated, outside architectural bounds, invalid permissions, etc.)

Unfortunately for you -- that means that you're asking about the most common signal that programming bugs can generate. [You can get this from not checking the return of malloc(), trying to use an uninitialized pointer, accessing a pointer whose value was passed to free(), growing the stack beyond the limits, failing to grow the register stack, etc. etc.]

So... my question would be: What are lines 5 and 15 _doing_? If they're accessing dynamic memory, have you tried monitoring the pointer to and values within that memory [to ensure that it isn't freed by another thread in the application?] If this is MT code, race conditions can easily give you different results on different runs...

But in general -- this is Magic 8 Ball stuff.
Either show some code -- or pay very close attention in the debugger as to what's being accessed via what addresses, etc.

Re: Segmentation Fault

Dennis Handly — Fri, 22 Jun 2007 02:40:59 GMT

Have you compiled with -g? Are you optimizing? Are you using threads and have a thread stack overflow? (This will look very random!)
Have you compiled with +check=uninit and +check=bounds

As the others have asked, what are on those lines?

Of course you can always debug at the machine level after you abort:
(gdb) bt
(gdb) info reg
(gdb) disas $pc-16*20 $pc+16*4