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.

In reply to Another good reason to "use strict"? by graff

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.