APA> case timeout_event: -> markobj (event->event.timeout.function); APA> markobj (event->event.timeout.object); APA> break; APA> where event->event.timeout.function is: APA> - event->event.timeout.function {...} APA> - gu {...} APA> type 0 APA> val 0 APA> - s {...} APA> bits 0 APA> val 0 APA> - u {...} APA> bits 0 APA> val 0 APA> ui 0 APA> i 0 APA> v 0x00000000 APA> cv 0x00000000 Martin> Ah, yes. Lisp_Objects which are Qnull_pointer have been Martin> outlawed and will crash in mark_object. This is an Martin> intentional change. This is to catch uninitialized Martin> Lisp_Objects (also makes garbage collection faster). Martin> Now we will crash quickly in the first garbage collection Martin> instead of crashing rarely and more obscurely later, Martin> e.g. in print_event. Trust me, this is short term pain Martin> for long term gain. That sounds promising! Martin> The event object type is particularly prone to Martin> non-initialization since it contains a union of structs Martin> possibly containing Lisp_Objects. Martin> Please test out this patch. Especially Adrian, I would Martin> appreciate if you could give me a `thumbs up' by Sunday. Martin> Untested on NT, as usual. How about this Backtrace then? :-) This occured after rebuilding with you patches successfully applied. I assume it's correct that only event-msw.c had to be re-compiled (for WidowsNT native build) before link.exe ＠C:\WINNT\Profiles\AichnerA\tmp\nma00176. That's what xemacs.mak did anyway. Here's the VC++ 5.0 CallStack, edited for bandwidth: allocate_lisp_storage(unsigned int 2044) line 482 + 3 bytes Fcons(Lisp_Object {...}, Lisp_Object {...}) line 1143 + 71 bytes list2(Lisp_Object {...}, Lisp_Object {...}) line 1197 + 15 bytes throw_or_bomb_out(Lisp_Object {...}, Lisp_Object {...}, int 0, Lisp_Object {...}, Lisp_Object {...}) line 1432 + 13 bytes Fthrow(Lisp_Object {...}, Lisp_Object {...}) line 1468 + 28 bytes Fsignal(Lisp_Object {...}, Lisp_Object {...}) line 2036 + 18 bytes throw_or_bomb_out(Lisp_Object {...}, Lisp_Object {...}, int 0, Lisp_Object {...}, Lisp_Object {...}) line 1432 + 29 bytes ABOVE THREE LINES REPEATED 326 TIMES Fthrow(Lisp_Object {...}, Lisp_Object {...}) line 1468 + 28 bytes It occured after XEmacs had started, reading my extensive site-start.el and .emacs (crashes usually don't happen with -no-init-file -no-site-file, sorry). Hitting the News toolbar button, which starts Gnus for me, crashed XEmacs-21.0-b5++++++ Thanks for looking into this! I am confident that this is the right way to a robust XEmacs, EVEN on WindowsNT ;-> I'll try my best to give crash feedback. Let me know what additional information might help. Regards, Adrian Martin> 1998-12-11 Martin Buchholz <martin(a)xemacs.org&gt; Martin> * events.h (struct timeout_data): Martin> * event-tty.c (tty_timeout_to_emacs_event): Martin> * event-msw.c (mswindows_wm_timer_callback): Martin> * event-Xt.c (Xt_timeout_to_emacs_event): Martin> * event-msw.c (mswindows_cancel_dispatch_event): Martin> Make sure Lisp_Objects inside events are initialized to Qnil, not Martin> Qnull_pointer, which is now illegal.