Re: XEmacs freezes under virtual windows on Win2K

>>>>> "Andy" == Andy Piper <andyp(a)bea.com&gt; writes: Andy> At 04:11 PM 1/19/2002 +0100, Adrian Aichner wrote: >> >>>>> "Andy" == Andy Piper <andyp(a)bea.com&gt; writes: >> Andy> At 07:31 AM 1/18/2002 -0800, David M. Karr wrote: >> >> By "native", do you mean "non-cygwin"? I only use the Cygwin >> >> version. In any >> >> case, I haven't set up to build either native or Cygwin >> >> XEmacs on Windows. >> >> That would be a good thing to do, but I doubt I could get >> >> this done and tested >> >> today. Failing that, it would be good if I knew when an installable >> >> release of >> >> >> this would be available. >> Andy> I'm back in the US and online once again. A binary release Andy> should show up sometime this coming week. >> >> Great! >> >> Welcome back! >> >> I finally got around to submit some Call Stack and Variable >> information for my recent XEmacs crashes of native W2K 21.4.6 XEmacs >> including this patch to xemacs-winnt. >> >> All crashes are unrelated to my patch AFAICT. >> >> Didn't you already have a fix for earlier crahes related to failed >> assertions for >> >> /* If you hit this, rewrite the offending API call to occur after GC, >> using register_post_gc_action(). */ >> assert (!gc_in_progress); >> in >> mswindows_wnd_proc(HWND__ * 0x00100148, unsigned int 257, unsigned >> int 81, long -1072693247) line 2075 + 41 bytes Andy> If you see these you need to figure out what is causing events to be Andy> processed while GC'ing. Right, got another one of this and am already in the debugger -- what would you say is the offending API or how would I find out? Would it possibly be update_window_scrollbars? Actually, mark_redisplay () has a comment by Ben which might be worth worrying about: void mark_redisplay (void) { Lisp_Object frmcons, devcons, concons; FRAME_LOOP_NO_BREAK (frmcons, devcons, concons) { struct frame *f = XFRAME (XCAR (frmcons)); /* #### urk! this does tons o' crap, such as creating lots of structs, doing window system actions, etc. we DO NOT want to be doing this -- marking should never change any state. i think we can just delete this. --ben */ update_frame_window_mirror (f); mark_window_mirror (f->root_mirror); mark_gutters (f); } } What to do? Excerpt from complete Call Stack below: > update_window_scrollbars(window * 0x08925cc0, window_mirror * 0x022ae898, int 0, int 0) line 294 + 46 bytes > update_mirror_internal(long 143809728, window_mirror * 0x022ae898) line 390 + 26 bytes > update_frame_window_mirror(frame * 0x022ecdc8) line 462 + 22 bytes > mark_redisplay() line 7107 + 9 bytes > garbage_collect_1() line 3483 Here's the complete Call Stack: NTDLL! 77fa018c() mswindows_wnd_proc(HWND__ * 0x001d0396, unsigned int 132, unsigned int 0, long 21693196) line 2080 + 41 bytes USER32! 77e12e98() USER32! 77e139a3() USER32! 77e1395f() NTDLL! 77fa032f() USER32! 77e1569d() mswindows_drain_windows_queue() line 1286 + 18 bytes emacs_mswindows_quit_p() line 3553 event_stream_quit_p() line 597 check_quit() line 514 unbind_to_hairy(int 35) line 4967 unbind_to(int 35, long 20613800) line 4952 + 174 bytes dfc_convert_to_external_format(int 0, dfc_conversion_data * 0x0082b890, long 21742968, int 0, dfc_conversion_data * 0x0082b89c) line 1948 + 16 bytes std_handle_out_va(_iobuf * 0x10261868, const char * 0x012daea4, char * 0x0082d8e0) line 188 + 99 bytes stderr_out(const char * 0x012daea4) line 211 + 55 bytes assert_failed(const char * 0x011cd5dc, int 2080, const char * 0x011cd5cc) line 3309 + 22 bytes mswindows_wnd_proc(HWND__ * 0x001d0396, unsigned int 20, unsigned int 973147397, long 0) line 2080 + 41 bytes USER32! 77e12e98() USER32! 77e139a3() USER32! 77e1395f() NTDLL! 77fa032f() update_window_scrollbars(window * 0x08925cc0, window_mirror * 0x022ae898, int 0, int 0) line 294 + 46 bytes update_mirror_internal(long 143809728, window_mirror * 0x022ae898) line 390 + 26 bytes update_frame_window_mirror(frame * 0x022ecdc8) line 462 + 22 bytes mark_redisplay() line 7107 + 9 bytes garbage_collect_1() line 3483 Ffuncall(int 2, long * 0x0082e4fc) line 3479 execute_optimized_program(const unsigned char * 0x013f6078, int 4, long * 0x0149ae60) line 746 + 16 bytes funcall_compiled_function(long 21739132, int 3, long * 0x0082e7d8) line 518 + 53 bytes Ffuncall(int 4, long * 0x0082e7d4) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x013f60d0, int 5, long * 0x0149aea0) line 746 + 16 bytes funcall_compiled_function(long 21739160, int 3, long * 0x0082eab4) line 518 + 53 bytes Ffuncall(int 4, long * 0x0082eab0) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x013f6108, int 5, long * 0x0149aed4) line 746 + 16 bytes funcall_compiled_function(long 21739188, int 3, long * 0x0082ed90) line 518 + 53 bytes Ffuncall(int 4, long * 0x0082ed8c) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x013f6168, int 5, long * 0x0149af14) line 746 + 16 bytes funcall_compiled_function(long 21739216, int 2, long * 0x0082f074) line 518 + 53 bytes Ffuncall(int 3, long * 0x0082f070) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x013f61c0, int 8, long * 0x0149af6c) line 746 + 16 bytes funcall_compiled_function(long 21739272, int 5, long * 0x0082f354) line 518 + 53 bytes Ffuncall(int 6, long * 0x0082f350) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x013f6230, int 6, long * 0x0149afc4) line 746 + 16 bytes funcall_compiled_function(long 21739300, int 6, long * 0x0082f634) line 518 + 53 bytes Ffuncall(int 7, long * 0x0082f630) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x013f6278, int 7, long * 0x0149b008) line 746 + 16 bytes funcall_compiled_function(long 21739328, int 3, long * 0x0082f918) line 518 + 53 bytes Ffuncall(int 4, long * 0x0082f914) line 3563 + 17 bytes execute_optimized_program(const unsigned char * 0x0289ad18, int 15, long * 0x014905d8) line 746 + 16 bytes funcall_compiled_function(long 21723088, int 1, long * 0x0082fc88) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082fc84) line 3563 + 17 bytes run_hook_with_args_in_buffer(buffer * 0x00e6ad80, int 2, long * 0x0082fc84, int 0) line 4020 + 13 bytes run_hook_with_args(int 2, long * 0x0082fc84, int 0) line 4033 + 23 bytes va_run_hook_with_args(long 20536976, int 1) line 4104 + 18 bytes redisplay_frame(frame * 0x022ecdc8, int 0) line 6299 + 17 bytes redisplay_device(device * 0x0225cdc8, int 1) line 6476 + 11 bytes redisplay_without_hooks() line 6563 + 11 bytes redisplay() line 6626 Fnext_event(long 51194052, long 20613800) line 2179 Fcommand_loop_1() line 574 + 16 bytes command_loop_1(long 20613800) line 495 condition_case_1(long 20613440, long (long)* 0x01051d06 command_loop_1(long), long 20613800, long (long, long)* 0x01051720 cmd_error(long, long), long 20613800) line 1651 + 7 bytes command_loop_3() line 256 + 35 bytes command_loop_2(long 20613800) line 269 internal_catch(long 20441216, long (long)* 0x01051870 command_loop_2(long), long 20613800, int * volatile 0x00000000) line 1317 + 7 bytes initial_command_loop(long 20613800) line 305 + 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x00e62e68, char * * 0x00e62f50, int 0) line 2355 main(int 1, char * * 0x00e62e68, char * * 0x00e62f50) line 2723 mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e97d08() >> and/or >> /* 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)); >> in >> mswindows_need_event(int 0) line 1519 + 52 bytes Andy> No, this has been around for ages, but the binary dist does not have Andy> debug on so it ends up being harmless. However, if we could actually Andy> fix it that would be great. Andy> andy -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/