If you're getting both SEGVs (hitting an address outside your process' address space) and bus errors (usually trying to address an unaligned memory address (pulling a 4-byte float from an odd address)) it sounds like something's giving perl a bad pointer. If you've got any modules using XS code something could be returning junk data, or something could be trying to access something that's already been free()'d. strace (or your platform's variant) might also be useful to see what underlying system calls it's doing before dying.

All of what Fletch said is good advice.

Don't try to make the problem "go away" with changes like adding log4perl.

If you manage to make it "go away" temporarily, you may never be able to recreate it under your control in order to diagnose the issue.

This is a symptom of a real problem somewhere either in your code, in perl, or in a module you're using, and think of this as your only chance to track it down before it breaks at 2am someday and you get paged :)

Take a look at the contents of %INC and @INC before your code dies. Any chance you're picking up a module built for a different perl version or slightly different platform?


Mike

Thanks to everyone for the help so far.

I wasn't actually trying to make the problem go away by adding the call to log4perl. I was hoping to work out what was going on.

I'm using version 5.8.3 and don't think it is a problem with incorrect modules or the like. However, I don't know how I would look at %ENV and @INC immediately before the seg fault or bus error.

I suspect it is the recursion - the function being called uses LibXML version 1.58 to check some attributes of an XML tree. Although, even just putting a print in the loop over the children where the function calls itself also "removes" the problem, so this assumption may also be incorrect. As I now have another bug to correct, I shall return to the last working version, fix the second problem and try to implement and test the correction for the first problem more incrementally.

I would post some code but:

1. The program is written like C and peolple would laugh.
2. It is rather convoluted (see 1) and it would probably take more more time to produce a simple example than to solve the problem in the first place (although maybe that would be a good approach to solving the problem anyway).

Thanks again for the advice.

loris

Update

OK, now I know what is causing the problem. It is something to do with LibXML (V 1.58). If I do:

$parent->replaceChild($newNode,$oldNode);
[download]

I get a segmentation fault. If I do:

$parent->removeChild($oldNode);
$parent->addChild($newNode);
[download]

everything works OK. I would rather replace the node so that I don't have to worry keeping the ordering the same. Has anyone seen behaviour like that before? Thanks again for the help.

loris

I haven't run into the particular case you describe, but I have had similar experiences. I suggest you try replacing the log4perl call with a simple sleep 1;. If that fixes your problem as well, you probably have a strange syntax error -- one that the compiler doesn't puke on, but causes your logic to behave oddly. Somtimes the extra, seemingly meaningless call will "fix" the problem. (Well, not fix...)

If that isn't it, I would post the relevant snippets of your code into your question so we can pick it apart. :)

Thanks for the tip, radiatmatrix.

If I uses sleep 1; as you suggest, I get a segmentation fault.

I don't have currently have time but shall try to post some code soon. By the way, I have noticed that the problem occurs when the function in question is called recursively.

loris