Hey guys, This relates somewhat to the message that I sent last night / early this morning. I have a custom $SIG{__DIE__} handler defined within an object. Upon a die, this handler runs the object's DESTROY method. As I stated in my earlier message, I'm doing this because the object contains an Apache::Session object. Sometimes the calling script would die and the wrapper object which holds a Session object was not undef'd. Because of this, the Session wouldn't go out of scope, and the session would stay locked forever (and Apache processes 'hang' because they sit there waiting for the lock to go away, but it doesn't). Anyway, I realize now that when the calling script does NOT die, my object is now not undef'd, even if I have an explicit undef at the end of the script. Why is this? I figure that it must be because there's still a reference to the object that's in scope and 'alive'... this reference is within the custom sighandler... After all, I set $SIG{__DIE__} to a sub that contains $self references. What I'm doing is setting $main::SIG{'__DIE__'} to this anonymous subroutine... I'm pretty sure that this sighandler is also sticking with the process that it runs on. For example, I'll run the script once... later, a script that does not use this 'wrapper' object dies and calls the custom sighandler... Why should it? Shouldn't the sighandler revert to CORE::die() at the end? On that note, I even tried changing DESTROY (of the wrapper object) to re-set the sighandler to the CORE::die() function. Of course this doesn't work because DESTROY is never even being executed :-(. Any ideas? These scoping issues can be tricky... Thanks, Russ Russell Weiss Founder and Technical Manager InfoRelay Online Systems, Inc. http://www.InfoRelay.net/