From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: staticpro everything Date: Thu, 02 May 2024 21:46:08 +0300 Message-ID: <86v83wjbm7.fsf@gnu.org> References: <87ttjlabic.fsf@gmail.com> <87v8408wsr.fsf@gmail.com> <87o79sasl5.fsf@gmail.com> <87plu72y8h.fsf@gmail.com> <877cgfwe5g.fsf_-_@gmail.com> <871q6mptkj.fsf@gmail.com> <86frv2pse5.fsf@gnu.org> <87v83ynhuc.fsf@gmail.com> <86v83xof5w.fsf@gnu.org> <878r0thbfl.fsf@gmail.com> <86jzkdo9rm.fsf@gnu.org> <87jzkdfres.fsf@gmail.com> <86plu4mylj.fsf@gnu.org> <87sez06yj3.fsf@gmail.com> <878r0s6w1m.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17470"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 02 20:47:17 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s2bSf-0004IR-IV for ged-emacs-devel@m.gmane-mx.org; Thu, 02 May 2024 20:47:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2bRs-0004eP-1R; Thu, 02 May 2024 14:46:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s2bRj-0004bK-Np for emacs-devel@gnu.org; Thu, 02 May 2024 14:46:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s2bRa-0001sS-Se; Thu, 02 May 2024 14:46:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Rf7+fxxBYp7utjVyJgJsxDCcBYN2+1N2KmUutDgtBNE=; b=X0atlfq5/KmU siOSGDNNi+RSE39+Rs1dRRwbh9y27fykn7SJufk/hC6xauKaayp38aUy5FLUg6mwqBORp0+dgNb7j +TTQXj5E2rL/nrHquYgi8hJwsDZKa+lSASXWz9w24nw1X4oHgKQNKP5YruLu6v8RRffadqhJ0TjD3 5EuLTmN8GEF9lvd4+MldhKg9mmGP4wjQNY/IAF5F0CXcbyDY1pHopTzyd9rLp7QU67QoIY65pzJuo /mc403rrQK51Iq/L1DP1xFGmQJV7MXbTsyfcC+r8FpJfMEedcjnLQsOP0oyfxQgdoZF5J+mxVwD15 DqCCLkPJ2qsiUjO6ug/LLQ==; In-Reply-To: <878r0s6w1m.fsf@gmail.com> (message from Helmut Eller on Thu, 02 May 2024 18:03:17 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318607 Archived-At: > From: Helmut Eller > Cc: Eli Zaretskii , emacs-devel@gnu.org > Date: Thu, 02 May 2024 18:03:17 +0200 > > > BTW, I sent the last mail an Emacs build from scratch/igc, without > > native compilation, but with my init file). It didn't survive very long > > though :-). I guess I'Ll try to do more in that direction. > > (add-hook 'post-command-hook 'igc--collect) helps to crash it sooner. Confirmed. > For me, that always seems to involve some mouse interaction. Maybe, not sure. But anyway, I had one crash like this: keyboard.c:4269: Emacs fatal error: assertion failed: FRAMEP (frame) Thread 1 received signal SIGTRAP, Trace/breakpoint trap. 0x75f45693 in KERNELBASE!DebugBreak () from C:\WINDOWS\SysWOW64\KernelBase.dll (gdb) thread 1 [Switching to thread 1 (Thread 148160.0x23404)] #0 0x75f45693 in KERNELBASE!DebugBreak () from C:\WINDOWS\SysWOW64\KernelBase.dll (gdb) bt #0 0x75f45693 in KERNELBASE!DebugBreak () from C:\WINDOWS\SysWOW64\KernelBase.dll #1 0x00bc1bb6 in emacs_abort () at w32fns.c:11262 #2 0x00a742b0 in terminate_due_to_signal (sig=sig@entry=22, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:480 #3 0x00ae8a00 in die ( msg=msg@entry=0x105899d "FRAMEP (frame)", file=file@entry=0x1058992 "keyboard.c", line=line@entry=4269) at alloc.c:8337 #4 0x00a864ec in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=0x72bf7fb, kbp=) at keyboard.c:4269 kbd_buffer_get_event does this where it aborted: /* If this event is on a different frame, return a switch-frame this time, and leave the event in the queue for next time. */ Lisp_Object frame; Lisp_Object focus; frame = event->ie.frame_or_window; if (CONSP (frame)) frame = XCAR (frame); else if (WINDOWP (frame)) frame = WINDOW_FRAME (XWINDOW (frame)); focus = FRAME_FOCUS_FRAME (XFRAME (frame)); <<<<<<<<<<<<<<<< So we abort because of assertion violation in XFRAME, meaning that 'frame' is not a valid frame object. This frame comes from the input event, where we have: struct input_event { /* What kind of event was this? */ ENUM_BF (event_kind) kind : EVENT_KIND_WIDTH; /* Used in scroll back click events. */ ENUM_BF (scroll_bar_part) part : 16; /* For an ASCII_KEYSTROKE_EVENT and MULTIBYTE_CHAR_KEYSTROKE_EVENT, this is the character. For a NON_ASCII_KEYSTROKE_EVENT, this is the keysym code. For a mouse event, this is the button number. */ unsigned code; /* See enum below for interpretation. */ unsigned modifiers; /* One would prefer C integers, but HELP_EVENT uses these to record frame or window object and a help form, respectively. */ Lisp_Object x, y; /* Usually a time as reported by window system-specific event loop. For a HELP_EVENT, this is the position within the object (stored in ARG below) where the help was found. */ Time timestamp; /* This field is copied into a vector while the event is in the queue, so that garbage collections won't kill it. */ Lisp_Object frame_or_window; /* This additional argument is used in attempt to avoid extra consing when building events. Unfortunately some events have to pass much more data than it's reasonable to pack directly into this structure. */ Lisp_Object arg; /* The name of the device from which this event originated. It can either be a string, or Qt, which means to use the name "Virtual core pointer" for all events other than keystroke events, and "Virtual core keyboard" for those. */ Lisp_Object device; }; The input events are stored in kbd_buffer: union buffered_input_event kbd_buffer[KBD_BUFFER_SIZE]; In init_keyboard we do this: void init_keyboard (void) { #ifdef HAVE_MPS igc_root_create_ambig (kbd_buffer, (char *) kbd_buffer + ARRAYELTS (kbd_buffer)); #endif But is that enough to protect all the Lisp objects in each element of kbd_buffer? Evidently, in the above crash the frame object was moved, without updating the events in kbd_buffer that reference it. I'd expect the frame to be unmovable when there's a reference to it in the kbd_buffer, because there could be quite a lot of events there waiting for processing.