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: Mon, 10 Jun 2024 19:30:04 +0300 Message-ID: <86bk4892wj.fsf@gnu.org> 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> <86wmn0edt0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16750"; 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 Mon Jun 10 18:41:45 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 1sGi5Z-0004AO-Kn for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Jun 2024 18:41:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sGi4j-0005Ac-8K; Mon, 10 Jun 2024 12:40:53 -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 1sGi4f-00059V-IM for bug-gnu-emacs@gnu.org; Mon, 10 Jun 2024 12:40:49 -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 1sGi4e-0001gs-Ll for bug-gnu-emacs@gnu.org; Mon, 10 Jun 2024 12:40:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sGi4v-0005Bx-Lg for bug-gnu-emacs@gnu.org; Mon, 10 Jun 2024 12:41:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Jun 2024 16:41:05 +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.171803762119682 (code B ref 71224); Mon, 10 Jun 2024 16:41:05 +0000 Original-Received: (at 71224) by debbugs.gnu.org; 10 Jun 2024 16:40:21 +0000 Original-Received: from localhost ([127.0.0.1]:45596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sGi4C-00057C-80 for submit@debbugs.gnu.org; Mon, 10 Jun 2024 12:40:20 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sGhui-00037I-9R for 71224@debbugs.gnu.org; Mon, 10 Jun 2024 12:30:33 -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 1sGhuL-0007fH-KG; Mon, 10 Jun 2024 12:30:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=iGhqH7uldhek3j3pebFgjUYSpFVl0CSOxSJ3hEyz8MM=; b=Sr7ksim7MO3u7MzxWjOK RbhBBiExxEVsNYAxz/PXW1X4npYsDpZPv7OFlLdSmIYymJx91W6xJxQLjFjU3HvDezz/HmNsnT6Cr Rgq1mfhhGaQNwNvYC3h230j+YpBRn0oYcYTA4SP/uoFi5aw+dyAUIGkWaNC5Hp7VO1zAwm3OV5CJC 9WeCkL77cvumaWKRub34QnXsTq99T2kqle3Oc2j1hGMNGGfDr/eboM20y17vTDQOXVb9OIuQUKFT4 TmW8PUQa37dUWsKq+U5R8nQ9pfqiQzqZ+dMsoROyY7/MLa2omxtAGTI82E+xs2yMLKptFdXj/tJa8 KmlvywvgYBNRTw==; In-Reply-To: (message from Daniel Clemente on Mon, 10 Jun 2024 16:11:50 +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:287052 Archived-At: > From: Daniel Clemente > Date: Mon, 10 Jun 2024 16:11:50 +0000 > Cc: 71224@debbugs.gnu.org > > > Thanks, I could reproduce this and installed a fix. > > > > The result of the fix is that the daemon doesn't crash; the last > > client gets an error message and exits, but the terminal from which > > the last client connection was attempted is left in messed up state. > > The user will then need to reset the terminal somehow, e.g. with "tput > > reset" or somesuch. > > It seems more crash-resistant now, thanks. > > Leaving the terminal in a bad state doesn't seem a huge problem, since > Emacs is in a bad state too. Emacs is well enough to allow you to exit it in an orderly fashion. Which is enough when you brought it to its knees by infinite recursion. > In some cases it's possible to go back to the working frame, fix the > Lisp stack (e.g. by pressing q in the debug window to make all the > (recurse) calls finish), and then the new emacsclient connections will > work. Emacs is supposed to be able to overcome overflow if the C stack. But in this case, the overflow is in the Lisp nesting, not in the C stack. Try "M-x top-level RET" and see if it helps. > While testing this, the daemon kept crashing but at other points so I > filed separate bugs > - (I can't know the bug ID yet, but it may be #71473 or greater): delete_frame > - (I can't know the bug ID yet, but it may be #71474 or greater): > restore_kboard_configuration No need to mention other bugs here, that just increases confusion (of which we have more than enough already). > In addition, I saw the backtrace below, I think that even after your > patch („Avoid crashes in half-baked emacsclient frames“). I'm not 100% > sure which commit I was in, sorry. Is this situation still possible > after your patch? I can try to reproduce the crash but I'm seeing much > more often the previous 2 new bugs I mentioned. I don't know if it's the same scenario. If you show the recipe, I might be able to determine that. Is w->desired_matrix a NULL pointer again?