This happens to me every now and then, especially when debugging XEmacs. I submitted a fix a few months ago [1] that simply retried the wait ignoring the bad handle but it was vetoed because it masked a problem instead of fixing it. [1] http://list-archive.xemacs.org/xemacs-patches/200006/msg00024.html Mike Alexander mailto:mta＠arbortext.com Arbortext, Inc. +1-734-997-0200 --On Tuesday, May 29, 2001 6:01 PM +0200 Adrian Aichner <aichner(a)ecf.teradyne.com&gt; wrote: > > I got this today. > > Adrian > > Call Stack: > > NTDLL! 77fa018c() > mswindows_need_event(int 0) line 1515 + 52 bytes > emacs_mswindows_event_pending_p(int 1) line 3310 + 7 bytes > event_stream_event_pending_p(int 1) line 441 + 21 bytes > detect_input_pending() line 895 + 7 bytes > run_pre_idle_hook() line 2006 + 18 bytes > Fnext_event(long 51415980, long 20508696) line 2182 > Fcommand_loop_1() line 574 + 16 bytes > command_loop_1(long 20508696) line 495 > condition_case_1(long 20503992, long (long)* 0x01051526 > command_loop_1(long), long 20508696, long (long, long)* 0x01050f40 > cmd_error(long, long), long 20508696) line 1651 + 7 bytes > command_loop_3() line 256 + 35 bytes > command_loop_2(long 20508696) line 269 > internal_catch(long 20322984, long (long)* 0x01051090 > command_loop_2(long), long 20508696, int * volatile 0x00000000) line > 1317 + 7 bytes initial_command_loop(long 20508696) line 305 + 25 bytes > STACK_TRACE_EYE_CATCHER(int 1, char * * 0x00e643a0, char * * > 0x00e62ee0, int 0) line 2350 main(int 1, char * * 0x00e643a0, char * > * 0x00e62ee0) line 2718 mainCRTStartup() line 338 + 17 bytes > KERNEL32! 77e97d08() > > Relevant assert in src\event-msw.c (line 1515): > > /* This will assert if handle being waited for becomes > abandoned. Not the case currently tho */ > assert ((!badly_p && active == WAIT_TIMEOUT) || > (active >= WAIT_OBJECT_0 && > ------> active <= WAIT_OBJECT_0 + mswindows_waitable_count)); > > Variables: > > active -1 > badly_p 0 > mswindows_waitable_count 1 > + mswindows_waitable_handles 0x011c9c9c mswindows_waitable_handles > what_events 255 > > -- > Adrian Aichner > mailto:adrian＠xemacs.org > http://www.xemacs.org/ > >

Yes, it seems to be associated with having run processes in the recent past. It doesn't seem to be related to running more than one at a time, although I don't know for sure since I'm not always aware of when xemacs runs something on my behalf. I actually don't see this all that much since my copy of xemacs has this patch applied. I've run a few times recently without it and have seen the problem then. If I let xemacs sit at a breakpoint for a while it seems to make the problem more likely to occur. This is another reason I think it is a timing problem of some sort.

Mike --On Tuesday, May 29, 2001 6:30 PM -0700 Ben Wing <ben(a)666.com&gt; wrote: > does this tend to occur after you've run some processes, esp. more > than one at once? > > Mike Alexander wrote: >> >> This happens to me every now and then, especially when debugging >> XEmacs. I submitted a fix a few months ago [1] that simply retried >> the wait ignoring the bad handle but it was vetoed because it masked >> a problem instead of fixing it. >> >> [1] >> http://list-archive.xemacs.org/xemacs-patches/200006/msg00024.html >> >> Mike Alexander mailto:mta＠arbortext.com >> Arbortext, Inc. +1-734-997-0200 >> >> --On Tuesday, May 29, 2001 6:01 PM +0200 Adrian Aichner >> <aichner(a)ecf.teradyne.com&gt; wrote: >> >> > >> > I got this today. >> > >> > Adrian >> > >> > Call Stack: >> > >> > NTDLL! 77fa018c() >> > mswindows_need_event(int 0) line 1515 + 52 bytes >> > emacs_mswindows_event_pending_p(int 1) line 3310 + 7 bytes >> > event_stream_event_pending_p(int 1) line 441 + 21 bytes >> > detect_input_pending() line 895 + 7 bytes >> > run_pre_idle_hook() line 2006 + 18 bytes >> > Fnext_event(long 51415980, long 20508696) line 2182 >> > Fcommand_loop_1() line 574 + 16 bytes >> > command_loop_1(long 20508696) line 495 >> > condition_case_1(long 20503992, long (long)* 0x01051526 >> > command_loop_1(long), long 20508696, long (long, long)* 0x01050f40 >> > cmd_error(long, long), long 20508696) line 1651 + 7 bytes >> > command_loop_3() line 256 + 35 bytes >> > command_loop_2(long 20508696) line 269 >> > internal_catch(long 20322984, long (long)* 0x01051090 >> > command_loop_2(long), long 20508696, int * volatile 0x00000000) >> > line 1317 + 7 bytes initial_command_loop(long 20508696) line 305 + >> > 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x00e643a0, char >> > * * 0x00e62ee0, int 0) line 2350 main(int 1, char * * 0x00e643a0, >> > char * * 0x00e62ee0) line 2718 mainCRTStartup() line 338 + 17 bytes >> > KERNEL32! 77e97d08() >> > >> > Relevant assert in src\event-msw.c (line 1515): >> > >> > /* This will assert if handle being waited for becomes >> > abandoned. Not the case currently tho */ >> > assert ((!badly_p && active == WAIT_TIMEOUT) || >> > (active >= WAIT_OBJECT_0 && >> > ------> active <= WAIT_OBJECT_0 + >> > mswindows_waitable_count)); >> > >> > Variables: >> > >> > active -1 >> > badly_p 0 >> > mswindows_waitable_count 1 >> > + mswindows_waitable_handles 0x011c9c9c >> > mswindows_waitable_handles what_events 255 >> > >> > -- >> > Adrian Aichner >> > mailto:adrian＠xemacs.org >> > http://www.xemacs.org/ >> > >> > > > -- > ben > > I'm sometimes slow in getting around to reading my mail, so if you > want to reach me faster, call 520-661-6661. > > See http://www.666.com/ben/chronic-pain/ for the hell I've been > through.