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>
#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 ()
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.
i am wondering what signal is being handled there as well. sigpipe?
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.
thanx,
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
