Re: what causes a segmentation violation

What is happening with a segfault is that the CPU is trying to use an invalid address. While this can potentially have many causes, the two most common are:

Dereferencing an invalid pointer (typically a null pointer). You need to think in C rather tham perl. Buggy code that tries to dereference a null pointer results in a segfault and core dump. This doesn't happen with perl references as they maintain their own integrity. But if you are calling out to C libraries via XS, problems with the XS code or external C library could give you this behaviour.

Overwriting memory. Examples are the buffer overflow attacks one reads about in security journals. If something unexpected has been written over data structures, this may result in invalid pointers (see above), or worse, something may have overwritten code, though this may result in a different exception to segfault.

Coming back to your problem, it will almost certainly be in one of two places: external C code or perl itself. I recommend that you follow the debugging guidelines given by BrowserUK, and try and isolate the line of perl code where the segfault is happening.

Once you have this information, report a bug to http://rt.cpan.org if it's in a module's XS code, or use perlbug to report the bug if it's in perl itself.

--
wetware hacker
(Qualified NLP Practitioner and Hypnotherapist)

Comment on Re: what causes a segmentation violation

Replies are listed 'Best First'.

Re^2: what causes a segmentation violation
by fhew (Beadle) on May 14, 2007 at 13:27 UTC

I took the suggestion of looking at what the core dump could provide. A gdb stack trace told me that it was dying during signal handling. (Unfortunately I didn't write down the exact routine name, but... So without attempting to understand and diagnose Perl itself, I looked at where my code dealt with signals. I narrowed it down to 'death of a child' in my forking TCP server code.

My server is bsed on the standard skeleton from 'the cookbook'. What happens in my code is that on occasion, the main listener may choose to shut itself down and all children (for example, say when it catches a CTRL-C) The mainline would go through and kill off all forked children, and then die itself.

What was happening was (or at least _my impression_ was) that the children would be killed off, but not dead yet. Then the mainline would die, but the perl interpreter would still be around. Then the interpreter for the main-line would receive the 'death of a child' signal for (one or more of) the children, but could no longer handle it, because the mainline was (just about...!) dead. So it would issue a segfault and core dump.

My solution/workaround under this situation was to signal the children to die, and then have the mainline actually wait around (perhaps forever) for the children to die, and then (and only then) exit/die itself. I.e.

sub reaper { 1 until (-1 == waitpid(-1, WNOHANG)); }

$SIG{CHLD} = \&reaper;
kill 9, $childPid;  # signal the child to die
reaper();           # IMPORTANT! ...wait for the child to go away
                    # (else we might get perl seg faulting on exit)
exit;               # and die ourselves
[download]

So in the end, I was seeing this on a number of my apps that have used the same philosophy on shutdown of forking server apps, and the reason it was intermittent failure/warnings was all due to the random timing of the parent/child dying/exiting relationship.

...Sometimes the signal catcher would get invoked... but sometimes the interpreter seemed to have been shutdown far enough that the catcher was no longer there when the signal arrived, so it would core dump on shutdown.

[reply]
[d/l]


XP is just a number
	PerlMonks