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.bugs Subject: bug#71224: 30.0.50; SIGSEGV in start_display Date: Thu, 30 May 2024 15:05:29 +0300 Message-ID: <86jzjbqzcm.fsf@gnu.org> References: <86o78rv499.fsf@gnu.org> <86msoaszgj.fsf@gnu.org> <86jzjdu7iq.fsf@gnu.org> <86cyp5u4o5.fsf@gnu.org> <86mso8shj2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7434"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71224@debbugs.gnu.org To: Daniel Clemente Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 30 14:06:29 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sCeY7-0001eg-Ps for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 30 May 2024 14:06:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCeXc-0005sm-Cq; Thu, 30 May 2024 08:05:56 -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 1sCeXZ-0005sE-4p for bug-gnu-emacs@gnu.org; Thu, 30 May 2024 08:05:53 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sCeXY-0002vs-3L for bug-gnu-emacs@gnu.org; Thu, 30 May 2024 08:05:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sCeXi-0005lJ-3A for bug-gnu-emacs@gnu.org; Thu, 30 May 2024 08:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 30 May 2024 12:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71224 X-GNU-PR-Package: emacs Original-Received: via spool by 71224-submit@debbugs.gnu.org id=B71224.171707075122113 (code B ref 71224); Thu, 30 May 2024 12:06:02 +0000 Original-Received: (at 71224) by debbugs.gnu.org; 30 May 2024 12:05:51 +0000 Original-Received: from localhost ([127.0.0.1]:60293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCeXW-0005kb-L5 for submit@debbugs.gnu.org; Thu, 30 May 2024 08:05:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCeXV-0005kA-Bo for 71224@debbugs.gnu.org; Thu, 30 May 2024 08:05:49 -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 1sCeXF-0002uD-E5; Thu, 30 May 2024 08:05:33 -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=7vz0E2T/6B2dRpSrG5M78gDk8p/eJpXdpOEdJd4lN9U=; b=KDeaMNyx2pMz FWsa17Dg/G8Hnh1dMGDdApU72ycHsaI1+rgG285NsIeFMEfhun4ZPi1xtBjBia+e0kfyPcX6qxB5v LqCFNa5WqgMQ1oCTWHYJUXU8b33ZIy7shMADTxN57pr6XFSVvqDI+4peZoX6xk0kILii7mHYYsWc4 hMIc1+nsqimWUjV9SHM1VXYQKnsoNzEArBP4nPmsbXS/OBUqPnJ+coyZH1J6+NwsU372f6sTpJGIf kccEvteLz/4c0TNKYE+zK2H4ITvJxZ6oF5y13sQmzNug6zmeoQJSv/ZihC0IgTsL7bAurbG1ubSBm NqqashpsFiJ30b/Sq6Swqg==; In-Reply-To: (message from Daniel Clemente on Thu, 30 May 2024 09:55:20 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:286218 Archived-At: > From: Daniel Clemente > Date: Thu, 30 May 2024 09:55:20 +0000 > Cc: 71224@debbugs.gnu.org > > Program received signal SIGSEGV, Segmentation fault. > 0x00005555555d772f in redisplay_window (window=XIL(0x555556d13e05), > just_this_one_p=false) at xdisp.c:19961 > 19961 *w->desired_matrix->method = 0; > > (gdb) pp window > # > > (gdb) list 19961 > 19956 > 19957 SET_TEXT_POS (lpoint, PT, PT_BYTE); > 19958 opoint = lpoint; > 19959 > 19960 #ifdef GLYPH_DEBUG > 19961 *w->desired_matrix->method = 0; > 19962 #endif > 19963 > 19964 if (!just_this_one_p && needs_no_redisplay (w)) > 19965 return; That's not what I hoped for, sadly. It's the same problem, just detected a bit earlier. A window with NULL glyph matrices cannot be redisplayed, period. That's why leaf windows _must_ have glyph matrices. > Maybe we need more GLYPH_DEBUG assertions to catch null glyph matrices sooner? Yes, but where? I don't understand how this situation could happen, so it's hard to think about a good place to add assertions. > I see similar checks in dispnew.c, e.g.: > eassert (current_matrix && desired_matrix); This is too late: update_frame_1, where this assertion lives, is called after redisplay_window did its job. > A next step for me could be setting up a breakpoint (or message) in > the place where the glyph matrix is defined, to see if it's ever being > defined, vs. it's defined and then cleared. But I'm still learning > about glyph matrices and I don't know where they're expected vs. where > null. AFAIK, the glyph matrices are assigned to windows on TTY frames in allocate_matrices_for_frame_redisplay: /* If not already done, allocate sub-matrix structures. */ if (w->desired_matrix == NULL) { w->desired_matrix = new_glyph_matrix (f->desired_pool); w->current_matrix = new_glyph_matrix (f->current_pool); *window_change_flags |= NEW_LEAF_MATRIX; } And new_glyph_matrix cannot return NULL (if we run out of memory, new_glyph_matrix will signal a "memory-full" error). It might be possible that the glyph matrices of a window are somehow freed later, perhaps in free_window_matrices. But all these places are run as part of deleting a window under block_input, so I don't quite see how a window with NULL glyph matrices could have been used for anything... > I'm also trying to get better at gdb to detect when a variable (e.g. > w->desired_matrix) changes. You are talking about watchpoints. Something like (gdb) watch -l w->current_matrix If nothing else helps, try that. But I suspect it will be hard to find the window whose matrices to watch, and the problem is how to distinguish between windows that are being killed in your high-speed scenario and windows that are still being used. Thanks. P.S. If no other ideas are brought up, I can think about a simple band-aid we could try: refrain from redisplaying a window that doesn't have glyph matrices.