From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Clemente Newsgroups: gmane.emacs.bugs Subject: bug#71224: 30.0.50; SIGSEGV in start_display Date: Fri, 7 Jun 2024 16:08:11 +0000 Message-ID: References: <86o78rv499.fsf@gnu.org> <86msoaszgj.fsf@gnu.org> <86jzjdu7iq.fsf@gnu.org> <86cyp5u4o5.fsf@gnu.org> <86mso8shj2.fsf@gnu.org> <86jzjbqzcm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8778"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71224@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 08 01:43:18 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 1sFjEs-0002Av-FS for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 Jun 2024 01:43:18 +0200 Original-Received: from [::1] (helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sFd65-0001Yy-LI; Fri, 07 Jun 2024 13:09:49 -0400 Original-Received: from [2001:470:142:3::10] (helo=eggs.gnu.org) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sFd63-0001Yb-Rw for bug-gnu-emacs@gnu.org; Fri, 07 Jun 2024 13:09:47 -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 1sFd63-0004fq-KL for bug-gnu-emacs@gnu.org; Fri, 07 Jun 2024 13:09:47 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sFd6I-0002eT-RN for bug-gnu-emacs@gnu.org; Fri, 07 Jun 2024 13:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Clemente Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 07 Jun 2024 17:10: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.171778020110177 (code B ref 71224); Fri, 07 Jun 2024 17:10:02 +0000 Original-Received: (at 71224) by debbugs.gnu.org; 7 Jun 2024 17:10:01 +0000 Original-Received: from localhost ([127.0.0.1]:43629 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sFd6G-0002dv-3S for submit@debbugs.gnu.org; Fri, 07 Jun 2024 13:10:01 -0400 Original-Received: from mail-qt1-f179.google.com ([209.85.160.179]:49638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sFd6E-0002dV-LN for 71224@debbugs.gnu.org; Fri, 07 Jun 2024 13:09:59 -0400 Original-Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-4404fae8c6aso3468181cf.3 for <71224@debbugs.gnu.org>; Fri, 07 Jun 2024 10:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717780117; x=1718384917; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CsjZ4hRHWLZRnAceO+osh7TRLEuzKyr5gcqrR5Cc1EU=; b=LdrchSjCuLLQ609zBtoubDESFN31RqSjmYcSJ7yTYTGRRYJCWMRmMn9PI5VLldMrT4 7qRfeUIzlpZV9wUDvpKFPiE+woPbJxpYr5LyGYhcOg7SUx9jabOS9dM4NJLpzZ6TE4bV B7QtGBKcj3vfxUDGQw9lBH6U9hGVprMUO/J2T+E0V7inUy3eQWo4xUWVpOgYpbK9z3rC kX0tp0x+K3Kd1AbYj8rC4dQFbj2F/3ZAuIF2B2cJ6QodtZNp5KbgZa3JGWhyxaO2Y2Aa CMEGj5xU2tcppNj+nlynZeHfMk90xeJwCYxy5sBKWzjyYQaosKwAa8zMUcY5JVCGZmNW MYTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717780117; x=1718384917; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CsjZ4hRHWLZRnAceO+osh7TRLEuzKyr5gcqrR5Cc1EU=; b=tm9YmTzJy3xpZ2p2/26M9uxG1+/MAUBdgUoCxJj1Nfy54+C1Gh9057EoLZw+pdU49+ mtpqX+GS4wOjVfxH1D0WbeGSiBx2uSJP0N6hORAJ8LPjxjlOo3/FIpDkyqDu1fM+O0yp AsdSfkDYXRFVmK52Mh/h/5drlQv+LnPhbD1ABrnTN4iNcjn22v6DJrrSzi/Cw7oCt102 KzlCDIjC3YQK9VHW7GvEBtguWIs8NWtEhEwIN1OvxncSbAj1MXZ3AOGQtZtKLo8TRkrB 3I/g9ls21o0hSicTKD5pPJBite96c2c52PFFZ3Dfsw7gdk7DD7oxYx5UYpjTHvDcZbLn l2bg== X-Gm-Message-State: AOJu0Yz43meQjKPQ0phqDTW4emwvWJwmCtZd7fmY+oXQzNR+8zl9FvgI TG0q7zg09/P9IZ0RVLkmK4YHMGKMqMd1T+xq0IZ6kEBlx7JFk9B9739FyLRkmFW45yRJncgWUoQ sMNSFS+EhZNV2c4A8Af9IW5bFkOOp5qZj X-Google-Smtp-Source: AGHT+IEsnIcbv3IRqnXI7bTJ7oMU3q04NofQm/2Cx4DyFdjMg/GueghYVyFUQRTmlTqYi+lUshnmLZTn6A7VebvaN+c= X-Received: by 2002:a05:6122:3111:b0:4eb:1be0:3398 with SMTP id 71dfb90a1353d-4eb56234aabmr3621177e0c.5.1717776518779; Fri, 07 Jun 2024 09:08:38 -0700 (PDT) In-Reply-To: <86jzjbqzcm.fsf@gnu.org> 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:286791 Archived-At: Sorry for the long wait, I was focused on other bugs. This one is about the null glyph matrices. It still happens after the fixes in 71223 that improve fast opening+closing. I'm using 7d36bb0547f, fairly recent. After a few hours of debugging and learning. I found a very simple formula to produce the SIGSEGV. No GC involved, and no automated window opening/resizing. To reproduce it: emacs --fg-daemon -Q emacsclient -c Open a buffer with this code in it: (defun recurse () (recurse)) (recurse) And eval the defun. Don't call (recurse) yet. Do: M-x debug This opens the backtrace window. Use C-x o to go away from the backtrace window and back to that buffer with the Lisp code. Now eval (with C-x C-e) the call to (recurse) You get a message in the minibuffer: cl-prin1, excessive-lisp-nesting, and the backtrace window is updated. Don't close that backtrace window. Open a new frame, as before: emacsclient -c The daemon crashes with SIGSEGV. Program received signal SIGSEGV, Segmentation fault. 0x00005555555d7833 in redisplay_window (window=3DXIL(0x55555631d5e5), just_this_one_p=3Dfalse) at xdisp.c:19961 19961 *w->desired_matrix->method =3D 0; (gdb) bt #0 0x00005555555d7833 in redisplay_window (window=3DXIL(0x55555631d5e5), just_this_one_p=3Dfalse) at xdisp.c:19961 #1 0x00005555555d0a95 in redisplay_window_0 (window=3DXIL(0x55555631d5e5)) at xdisp.c:18016 #2 0x000055555576c9e2 in internal_condition_case_1 (bfun=3D0x5555555d0a53 , arg=3DXIL(0x55555631d5e5), handlers=3DXIL(0x7ffff1e5506b), hfun=3D0x5555555d0931 ) at eval.c:1637 #3 0x00005555555d0907 in redisplay_windows (window=3DXIL(0x55555631d5e5)) at xdisp.c:17985 #4 0x00005555555cf486 in redisplay_internal () at xdisp.c:17384 #5 0x00005555555cffcc in redisplay_preserve_echo_area (from_where=3D2) at xdisp.c:17743 #6 0x00005555555950e6 in Fredisplay (force=3DXIL(0)) at dispnew.c:6368 I tried to use watchpoints to track w->desired_matrix or w->current_matrix but found it difficult because of what I explain below. In particular, if I set the watchpoint *after* I get the SIGSEGV, then isn't it too late? Next time I run the program I may be seeing something else in that part of the memory. > > 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 =3D=3D NULL) > { > w->desired_matrix =3D new_glyph_matrix (f->desired_pool); > w->current_matrix =3D new_glyph_matrix (f->current_pool); > *window_change_flags |=3D 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 > While doing that, I saw some normal changes like Old value =3D (glyph_matrix *) 0x1b000a006d37325b New value =3D (glyph_matrix *) 0x1b000a006d373220 But if I wait for situations when w->current_matrix becomes nil=E2=80=A6 we= ll, I'm seeing many weird cases like the ones I post below, but I think they're not valuable, so you can skip them. It feels like I'm watching (with the watchpoint) a memory position that *was* storing w->current_matrix but is now being used for other things. I see how others (e.g. init_tty below) reuse that memory position for other things. I hope this is not a case of a buffer overflow (i.e. the glyph_matrix being null not because someone explicitly freed it, but because some other code overwrote that value with 0x0). Hardware watchpoint 2: -location w->current_matrix Old value =3D (glyph_matrix *) 0x1b000a006d37325b New value =3D (glyph_matrix *) 0x0 __memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336 336 ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file or directory. #0 __memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336 #1 0x000055555572a256 in lmalloc (size=3D8824, clearit=3Dtrue) at alloc.c:= 1402 #2 0x0000555555729693 in xzalloc (size=3D8824) at alloc.c:789 #3 0x0000555555675856 in init_tty (name=3D0x7fffffff9fd0 "/dev/pts/21", terminal_type=3D0x7fffffff9fb0 "rxvt-unicode-256color", must_succeed=3Dfalse) at term.c:4140 #4 0x000055555559a694 in Fmake_terminal_frame (parms=3DXIL(0x7ffff19a7a83)) at frame.c:1414 Lisp Backtrace: "make-terminal-frame" (0xf0dff188) "tty-create-frame-with-faces" (0xf0dff150) 0xf1aa00d0 PVEC_CLOSURE "apply" (0xf0dff0c8) "frame-creation-function" (0xf0dff068) "make-frame" (0xffffae08) "server--create-frame" (0xffffb0b8) "server-create-tty-frame" (0xffffb318) "server--process-filter-1" (0xffffb4f8) "server--process-filter-all-pending" (0xffffb680) "server-process-filter" (0xffffb7f8) Another one; it happened just the first time I'm doing the opening+closing of frames. Hardware watchpoint 2: -location w->current_matrix Old value =3D New value =3D (glyph_matrix *) 0x0 __memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336 336 ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file or directory. #0 __memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336 #1 0x00005555555850d2 in memclear (p=3D0x55555631e090, nbytes=3D272160) at /w/emacs/src/lisp.h:2030 #2 0x0000555555589719 in realloc_glyph_pool (pool=3D0x5555561860f0, matrix_dim=3D...) at dispnew.c:1401 #3 0x000055555558a805 in adjust_frame_glyphs_for_frame_redisplay (f=3D0x55555622b8f0) at dispnew.c:2077 #4 0x0000555555589dfd in adjust_frame_glyphs (f=3D0x55555622b8f0) at dispnew.c:1850 #5 0x0000555555599211 in adjust_frame_size (f=3D0x55555622b8f0, new_text_width=3D90, new_text_height=3D62, inhibit=3D5, pretend=3Dfalse, parameter=3DXIL(0xf720)) at frame.c:898 #6 0x000055555559a7a3 in Fmake_terminal_frame (parms=3DXIL(0x7ffff1998fa3)) at frame.c:1424 #7 0x0000555555770a5b in funcall_subr (subr=3D0x555555eb0020 , numargs=3D1, args=3D0x7ffff0dff188) at eval.c:3161 Lisp Backtrace: "make-terminal-frame" (0xf0dff188) "tty-create-frame-with-faces" (0xf0dff150) 0xf1aa00d0 PVEC_CLOSURE "apply" (0xf0dff0c8) "frame-creation-function" (0xf0dff068) "make-frame" (0xffffae08) "server--create-frame" (0xffffb0b8) "server-create-tty-frame" (0xffffb318) "server--process-filter-1" (0xffffb4f8) "server--process-filter-all-pending" (0xffffb680) "server-process-filter" (0xffffb7f8) Another case in which it was set to 0: Hardware watchpoint 2: -location w->current_matrix Old value =3D (glyph_matrix *) 0x55555618f98d New value =3D (glyph_matrix *) 0x0 __memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336 336 ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file or directory. #0 __memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:336 #1 0x00005555555850d2 in memclear (p=3D0x55555631b2c0, nbytes=3D267840) at /w/emacs/src/lisp.h:2030 #2 0x0000555555589719 in realloc_glyph_pool (pool=3D0x5555561fc660, matrix_dim=3D...) at dispnew.c:1401 #3 0x000055555558a7e8 in adjust_frame_glyphs_for_frame_redisplay (f=3D0x555556270c70) at dispnew.c:2076 #4 0x0000555555589dfd in adjust_frame_glyphs (f=3D0x555556270c70) at dispnew.c:1850 #5 0x0000555555599211 in adjust_frame_size (f=3D0x555556270c70, new_text_width=3D90, new_text_height=3D61, inhibit=3D5, pretend=3Dfalse, parameter=3DXIL(0xf720)) at frame.c:898 #6 0x000055555559a7a3 in Fmake_terminal_frame (parms=3DXIL(0x7ffff194b943)) at frame.c:1424 #7 0x0000555555770a5b in funcall_subr (subr=3D0x555555eb0020 , numargs=3D1, args=3D0x7ffff0dff188) at eval.c:3161 Lisp Backtrace: "make-terminal-frame" (0xf0dff188) "tty-create-frame-with-faces" (0xf0dff150) 0xf1aa00d0 PVEC_CLOSURE "apply" (0xf0dff0c8) "frame-creation-function" (0xf0dff068) "make-frame" (0xffffae08) "server--create-frame" (0xffffb0b8) "server-create-tty-frame" (0xffffb318) "server--process-filter-1" (0xffffb4f8) "server--process-filter-all-pending" (0xffffb680) "server-process-filter" (0xffffb7f8) In other cases, that memory position doesn't look like a pointer anymore, e.g. that 0x10bf0 below. Hardware watchpoint 2: -location w->current_matrix Old value =3D (struct glyph_matrix *) 0x10bf0 New value =3D (struct glyph_matrix *) 0xd build_marker (buf=3D0x5555562c6c60, charpos=3D13, bytepos=3D13) at alloc.c:= 4066 4066 m->insertion_type =3D 0; #0 build_marker (buf=3D0x5555562c6c60, charpos=3D13, bytepos=3D13) at allo= c.c:4066 #1 0x0000555555756a62 in Fpoint_marker () at editfns.c:202 #2 0x00005555557584d4 in save_excursion_save (pdl=3D0x555556164c30) at editfns.c:782 #3 0x000055555577235c in record_unwind_protect_excursion () at eval.c:3660 #4 0x00005555556c8b57 in Fkill_buffer (buffer_or_name=3DXIL(0x5555562c6c65)) at buffer.c:1917 #5 0x0000555555770a5b in funcall_subr (subr=3D0x555555eba460 , numargs=3D1, args=3D0x7ffff0dff0a0) at eval.c:3161 #6 0x00005555557ccdda in exec_byte_code (fun=3DXIL(0x5555562c708d), args_template=3D0, nargs=3D0, args=3D0x7fffffffa3b0) at bytecode.c:812 #7 0x00005555557710d4 in funcall_lambda (fun=3DXIL(0x5555562c708d), nargs=3D0, arg_vector=3D0x7fffffffa3b0) at eval.c:3252 Lisp Backtrace: "kill-buffer" (0xf0dff0a0) 0x562c7088 PVEC_CLOSURE "pp-to-string" (0xffffa698) "pp" (0xffffa838) "server-eval-and-print" (0xffffaa00) "server-execute" (0xf0dff038) 0x5660f010 PVEC_CLOSURE "server-execute-continuation" (0xffffb310) "server--process-filter-1" (0xffffb4f8) "server--process-filter-all-pending" (0xffffb680) "server-process-filter" (0xffffb7f8)