Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

Dear wise monks,

In follow-up to your feedback I updated my code as follows:

line_no 480 my $subroutine_name = (caller(0))[3]; 481 print “Arrived in the $subroutine_name subroutine.\n”; 482 483 print $fh_debug "jj\n"; 484 485 print $fh_debug "\$fh_debug is defined\n" if (defined ($fh_ +debug)); 486 487 if (close ($fh_debug)) 488 489 { 490 print “The close function call was successful.\ +n”; 491 <do some stuff>; 492 } 493 494 else 495 496 { 497 print STDERR "\nCould not close \$fh_debug: $!\n"; 498 die; 499 }

The output then became the following:

Arrived in the custom_functions::master_log subroutine. The close function call was successful. Arrived in the custom_functions::master_log subroutine. Could not close $fh_debug: Bad file descriptor Died at /u1/stat/global/bin/perllib/ line 498. Can't use an undefined value as a symbol reference at /u1/stat/global/ +bin/perllib/ line 483.

Well, that confirmed what most of you had suspected, that somehow I had called the close function more than once. It was not evident in the code of the module. There were no threads or forks involved. The variable $fh_debug had in fact been declared as an "our" variable higher up in the module which wasn't shown, and I was by intent using the expression "defined ($fh_debug)" as a Boolean to indicate whether or not an optional debugging file had been instantiated in the new () constructor for the module. So those considerations seemed okay. But given your feedback, I modified the code again as follows:

480 my $subroutine_name = (caller(0))[3]; 481 my $invoker = (caller(1))[3]; 482 print “Arrived in the $subroutine_name subroutine.\n”; 483 print “My invoker is $invoker.\n”;

The output from that second modification confirmed that the subroutine was not being called twice within the same module, it was being called more than once by the invoker. That allowed me to refocus my attention entirely from the module code to the invoker code, where I found that indeed, the invoker was the guilty one, calling the module to do the close more than once. Once I corrected the invoker code the problem disappeared.

I had been studying the module code for days trying to figure out why a call to a simple file close operation could trigger the error messages that I had been experiencing. It wasn’t until posting here and reading your comments that I was able to diagnose what was really going on and resolve the problem.

Thanks much for your feedback.

In reply to Re: Bad file descriptor when trying to close file handle by fireblood
in thread Bad file descriptor when trying to close file handle by fireblood

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

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2023-02-07 01:33 GMT
Find Nodes?
    Voting Booth?
    I prefer not to run the latest version of Perl because:

    Results (38 votes). Check out past polls.