in reply to Bad file descriptor when trying to close file handle

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.