On Wed, Jan 19, 2000 at 12:19:34AM -0500, [EMAIL PROTECTED] wrote:
> well, i said i would hammer event.pm and i just got a core dump. here is
> the stack trace from gdb:
>
> (gdb) bt
> #0 0xff216870 in _kill ()
> #1 0x99ac4 in Perl_apply ()
> #2 0x92e20 in Perl_pp_kill ()
> #3 0x9ef6c in Perl_runops_standard ()
> #4 0x27000 in perl_call_sv ()
> #5 0x5b328 in Perl_sighandler ()
> #6 <signal handler called> **** Yikes! ****
> #7 0x6b2d4 in Perl_sv_clear ()
> #8 0x6b694 in Perl_sv_free ()
> #9 0x7e588 in Perl_free_tmps ()
> #10 0x27178 in perl_call_sv ()
> #11 0xff0f6654 in pe_callback_died ()
> #12 0xff0f681c in pe_check_recovery ()
> #13 0xff0fcd30 in XS_Event__loop ()
> #14 0x65114 in Perl_pp_entersub ()
> #15 0x9ef6c in Perl_runops_standard ()
> #16 0x26714 in perl_run ()
> #17 0x242c4 in main ()
Hm, an event handler died and the recovery was interrupted by a signal.
> i can send you the code (a client, a server and a pm, all fairly short)
> if you want to generate the bug. it occurs during the async connect i am
> doing. after i get a writable event on the socket i cancel that event it
> the callback. then in that callback i call the higher level
> object/method and in there create a new read and a new write event on
> that socket.
Sure. I've never seen the code for an async connect.
> i am wondering what signal is being handled there as well. sigpipe?
You are aware that signal handlers are not safe?
> on another event.pm note, it seems to easily go into infinite loops with
> die. i would just as well have it exit after seeing one die or have that
> under some control.
Correct, the default behavior is to trap the error and try to continue
looping. If you want to exit, just set up your own handler:
$Event::DIED = \&my_exception_handler;
You can adapt the code from default_exception_handler in Event.pm if you
like.
--
"Does `competition' have an abstract purpose?"
via, but not speaking for Deutsche Bank
