in reply to Re: Re: Objects and undefined values
in thread Objects and undefined values

You also mention that $log is a global object. By the end of the program, are all references to it explicitly destroyed, or are you relying on Perl to clean it up for you as the main package goes out of scope?

If it's the latter (and you're usually okay doing that, except for when you aren't), you're probably getting tripped up by Perl's unreliable destruction order. Instead of What We All Expect, where objects and variables are cleaned up in reverse order of their creation, there's a mad rush for the exit, and occasionally things get trampled underfoot. Unfortunately, that appears to mean the FileHandle is gone before $log is.

You have two solutions -- move your final log message out of DESTROY, or explicitly undefined the last reference to the $log object before falling off the end of the program.

  • Comment on Re: Re: Re: Objects and undefined values

Replies are listed 'Best First'.
Re: Re: Re: Re: Objects and undefined values
by SwellJoe (Scribe) on Feb 08, 2002 at 02:31 UTC
    chromatic, you are my hero!

    I thought I was cleaning up all references. But your post made me look again, and I realized that the problem was that I'm using interrupts to end the program when it runs as a daemon, and I wasn't cleaning up $log in the interrupt function which performs an 'exit'. And this tells me why I wasn't getting the error when I first started using the class, because I was working with the build mode, which doesn't fork and needs no signal to be stopped.

    Thanks so much for your guidance. Happily, I can now move onto the problem that lead me to add extensive logging to my program in the first place!

[reply]

In Section Seekers of Perl Wisdom