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. Adrian> 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. Adrian> How about this Backtrace then? :-) Here's another. This time it occured when I tried to bring up the CVS menu for a cvs-examined directory. Adrian> This occured after rebuilding with you patches successfully applied. Adrian> I assume it's correct that only Adrian> event-msw.c had to be re-compiled (for WidowsNT native build) Adrian> before link.exe ＠C:\WINNT\Profiles\AichnerA\tmp\nma00176. That's what Adrian> xemacs.mak did anyway. Adrian> Here's the VC++ 5.0 CallStack, edited for bandwidth: Adrian> allocate_lisp_storage(unsigned int 2044) line 482 + 3 bytes Adrian> Fcons(Lisp_Object {...}, Lisp_Object {...}) line 1143 + 71 bytes Adrian> list2(Lisp_Object {...}, Lisp_Object {...}) line 1197 + 15 bytes Adrian> throw_or_bomb_out(Lisp_Object {...}, Lisp_Object {...}, int 0, Lisp_Object Adrian> {...}, Lisp_Object {...}) line 1432 + 13 bytes Adrian> Fthrow(Lisp_Object {...}, Lisp_Object {...}) line 1468 + 28 bytes Adrian> Fsignal(Lisp_Object {...}, Lisp_Object {...}) line 2036 + 18 bytes Adrian> throw_or_bomb_out(Lisp_Object {...}, Lisp_Object {...}, int 0, Lisp_Object Adrian> {...}, Lisp_Object {...}) line 1432 + 29 bytes Adrian> ABOVE THREE LINES REPEATED 326 TIMES Adrian> Fthrow(Lisp_Object {...}, Lisp_Object {...}) line 1468 + 28 bytes Adrian> It occured after XEmacs had started, reading my extensive Adrian> site-start.el and .emacs (crashes usually don't happen with Adrian> -no-init-file -no-site-file, sorry). Hitting the News toolbar button, Adrian> which starts Gnus for me, crashed XEmacs-21.0-b5++++++ Adrian> Thanks for looking into this! I am confident that this is the right Adrian> way to a robust XEmacs, EVEN on WindowsNT ;-> Adrian> I'll try my best to give crash feedback. Let me know what additional Adrian> information might help. Adrian> Regards, Adrian> 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 Adrian> Qnil, not Martin> Qnull_pointer, which is now illegal.