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            }
[download]

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/master_log.pm line 498.
Can't use an undefined value as a symbol reference at /u1/stat/global/
+bin/perllib/master_log.pm line 483.
[download]

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”;
[download]

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.