I saw this odd behavior with a script, using Perl 5.8.5 on freebsd (5.3-STABLE, i386); I was going to ask for ways to diagnose it, then noticed that the script didn't have "use strict", so I thought I'd better fix that first, and lo-and-behold, the problem went away. Still, I'm curious if anyone has ideas or similar experiences that might help to explain the odd behavior -- because I'm still mystified.

The script uses Getopt::Long and DBI (and DBD::Oracle, not that this should matter?); the wierdness was that it produced a segmentation fault if it read data from STDIN and its STDOUT was going to the terminal or being redirected to a file. In any other case, there was no seg.fault. In all cases (with and without seg.faults), the output was correct and complete. In other words:

my_script in.file | other_process [>out.file]
    # no seg.fault

my_script < in.file | other_process [>out.file]
    # no seg.fault

my_script in.file [>out.file]
    # no seg.fault

my_script < in.file [>out.file]
Segmentation fault
    # or, equivalently:
cat in.file | my_script [>out.file]
Segmentation fault
    # seg.fault whether or not output is redirected;
    # output is always the same as in the first 3 cases
[download]

In the first two usage examples, "other_process" could be anything (even just "cat -") -- if output went to a pipe, there was no seg.fault; likewise, if the perl script was not reading from STDIN, no seg.fault.

I didn't try a non-DBI test case, and as I've said, once I applied "strict", and scoped all the variables (option variables for Getopt::Long were set to "our", everything else to "my"), the seg.fault behavior disappeared.

Anyone have a clue about how to explain this?

UPDATE: I went back and commented out "use strict", and started removing "my" from the first mentions of various things until the seg.fault showed up again.

Turns out that the one item to trigger it was a scalar that held the return value from DBI's $dbh->prepare method -- when the scalar holding the reference to the prepared statement object was lexically scoped, everything worked fine; but turn off strict and leave that variable unspecified as to scope, and Perl would apparently hit a snag when trying to do an orderly shutdown (no actual effect on execution prior to shutdown).

Still, why this should depend on what's happening with STDIN and STDOUT is pretty baffling.