From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#57751: 29.0.50; crash in GC Date: Thu, 15 Sep 2022 07:28:17 +0200 Message-ID: References: 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="8715"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) Cc: 57751@debbugs.gnu.org To: Sam Steingold Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 15 07:29:21 2022 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 1oYhRA-000286-V3 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 07:29:21 +0200 Original-Received: from localhost ([::1]:49426 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYhR9-0003fX-UI for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 01:29:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50988) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYhQt-0003bP-CQ for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 01:29:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39804) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYhQt-0007bQ-2P for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 01:29:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oYhQr-00076X-SW for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 01:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Sep 2022 05:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57751 X-GNU-PR-Package: emacs Original-Received: via spool by 57751-submit@debbugs.gnu.org id=B57751.166321970827267 (code B ref 57751); Thu, 15 Sep 2022 05:29:01 +0000 Original-Received: (at 57751) by debbugs.gnu.org; 15 Sep 2022 05:28:28 +0000 Original-Received: from localhost ([127.0.0.1]:56736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYhQK-00075h-1a for submit@debbugs.gnu.org; Thu, 15 Sep 2022 01:28:28 -0400 Original-Received: from mail-ej1-f53.google.com ([209.85.218.53]:33580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYhQI-00075T-5o for 57751@debbugs.gnu.org; Thu, 15 Sep 2022 01:28:26 -0400 Original-Received: by mail-ej1-f53.google.com with SMTP id lc7so39598725ejb.0 for <57751@debbugs.gnu.org>; Wed, 14 Sep 2022 22:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=kj6btwaV2VbcTwVZWzGECvkmdxilGGwczJkrq0iSeZw=; b=bpjb6ft4QaowEnMAQzrO+zllvHxnm1lRAlxf0ar5oyjpgL0RrjzvfzCpkvI2QmTJjy 5a61j9xsR5+3i3BEh/ic6ZYhBWxVprTL/IemkRsdX0bSQYv0qifCj8XKeLus4mJJR73d PoBngF7pInVHrGzCyiIgTX177m0XtCXaH5s+wwP22u4MpDFhdePh+VUfBxp9PKekXTty gZ2mQpXbsXi4L+0gDaQuSFDJb/6vYyqUZ5SlE8g+sSEhnuszNEmNGXP3kBWrt7iI2nEx 6m9r2UcYnGr+GKJPiJ0eq/BD8m5QM0cu6phUYgq6I/jzqx0SP7yFoKcVPxNtp7MahCOE QxnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date; bh=kj6btwaV2VbcTwVZWzGECvkmdxilGGwczJkrq0iSeZw=; b=qPw4fqQVEDD6KzW7WTwV1B+dXKoZLt+dUO1R7i6kk2EhEl42OUHL36rkYqw4AIU+05 zXkimrCw7NP8yixpheqo3X9Rm88wKxyjX57gJwpjO+K/wg6V1M0HXDPv6tSwINABCVD0 Qwt4P+01/KlpOaISWlqULMLXAao67v+he7NyrMKmp1N4sae611URFhaoVa1IHFsvfd+x 3QhhpgRIF+Sf7sUeDpfg+urRDRrf5dhwVUSOjiAJoMSKrY/M0Offtby8O58ompbm+VcP tL7JoFPaIKSId4VTDsyat+RcXSDVLzvAsVOLQbf9u/bNUheIhATQKgQaNvZ0zx3khZms YjPA== X-Gm-Message-State: ACgBeo24QREPZK3+87fsWprQtOPEXDAZfDErrycyK+mR0oZmPW0XNgxb jgPt3xgOP/yfEqnu+J34OSdsFmG7wdM= X-Google-Smtp-Source: AA6agR5XwFsGIr+oxnAFd0sblOBclvKaEJPwvplzXBjhztRkU3Ze6sCD+CF6Sdwpjou3FtyHrnyKtg== X-Received: by 2002:a17:907:7607:b0:770:7ec4:fb41 with SMTP id jx7-20020a170907760700b007707ec4fb41mr26231380ejc.685.1663219699601; Wed, 14 Sep 2022 22:28:19 -0700 (PDT) Original-Received: from Mini.fritz.box (pd9e368e8.dip0.t-ipconnect.de. [217.227.104.232]) by smtp.gmail.com with ESMTPSA id x24-20020a50d618000000b0044e01e2533asm11259542edi.43.2022.09.14.22.28.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 22:28:18 -0700 (PDT) In-Reply-To: (Sam Steingold's message of "Wed, 14 Sep 2022 14:36:30 -0400") 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" Xref: news.gmane.io gmane.emacs.bugs:242554 Archived-At: Sam Steingold writes: > I _think_ that Tramp does something with a BAD FD and corrupts the > memory (see my previous message: tramp appears to be broken recently). Hm. There have been a number of Tramp commits/fixes recently, so it could be that something broke. I'd report that as a bug, maybe after updating to the ltest master. I can't exclude that as a possibility, of course, but I think it's unlikely that using Tramp can lead to a corruption of the C heap somehow. > >> - Does it also crash when you run emacs on a terminal (-nw)? If not, it >> could be a hint that the cu=C3=B6prit is in the NS GUI code. > > (lldb) run -nw > There is a running process, kill it and restart?: [Y/n] y > Process 18589 exited with status =3D 9 (0x00000009)=20 > Process 53208 launched: '/Users/sdsg/src/emacs/trunk/src/emacs' (x86_64) > emacs(53208,0x101748600) malloc: nano zone abandoned due to inability to = preallocate reserved vm space. > Process 53208 stopped > * thread #1, queue =3D 'com.apple.main-thread', stop reason =3D signal SI= GTTOU > frame #0: 0x00007ff81575bec6 libsystem_kernel.dylib`__ioctl + 10 > libsystem_kernel.dylib`__ioctl: > -> 0x7ff81575bec6 <+10>: jae 0x7ff81575bed0 ; <+20> > 0x7ff81575bec8 <+12>: movq %rax, %rdi > 0x7ff81575becb <+15>: jmp 0x7ff815759db9 ; cerror > 0x7ff81575bed0 <+20>: retq=20=20=20 > Target 0: (emacs) stopped. Oh, another thing I forgot to mention: LLDB requires a magic spell for running terminal apps, instead of "run": process launch --tty -- -nw \o/ :-). >> - Could you please see if it crashes consistently in different runs? >> What I mean is that is crashes in the same function with the same >> backtrace and the same pointer value of the symbol in frame#0? I >> guess I would quit LLDB between between runs, for no good reason >> :-), just to make sure it's reproducible that way. > > I restarted lldb and run Emacs. > This time I let it finish restoring desktop _completely_ before moving > the frame - it did __NOT__ crash. I moved the frame around, no crash. Ok. So we have a workaround, at least. > Then I quit it and restarted and moved the frame while it was in the > process of re-creating *vc-dir* buffers. Ok. Moving means grabbing the titlebar? I'm asking because of the "part =3D scroll_bar_nowhere" in the event. I wonder if one has to grab the frame at a certain location? And, are you using scroll bars or are they off? > Process 53726 stopped > * thread #1, queue =3D 'com.apple.main-thread', stop reason =3D EXC_BAD_A= CCESS (code=3D1, address=3D0x7ff8c11d2f50) > frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=3D0x00007ff8c11d= 2f50) at alloc.c:4020:14 > 4017 { > 4018 return pdumper_object_p (s) > 4019 ? pdumper_marked_p (s) > -> 4020 : s->u.s.gcmarkbit; > 4021 } > (lldb) p *event > (buffered_input_event) $0 =3D { > kind =3D MOVE_FRAME_EVENT > ie =3D { > kind =3D MOVE_FRAME_EVENT > > looks consistent with the previous crash. That's nice! I feel we're on the trail of the killer. I have no idea what's behind this, but maybe I can get something that I can reproduce now. > >> - I think you mentioned that the crashes started not so long ago? Do >> you perhaps know a commit which is still "good"? Or maybe a time, >> like 4 weeks ago, or so? We would need a good commit for git bisect >> anyway. > > I am "pretty sure" that 2 weeks ago it was good. Ok.=20=20 I think I'll try next to reproduce this desktop loading/moving frame crash here. When I get something, I'll bisect, and then let's see further. I'll report back when I have something. > >> (If I'm trying the be too "helpful", please just tekk ne. I Know that >> I'm sometimes doing that. No problem.) > > You are very helpful, and I appreciate your attention! > > Thank you very much! Thanks, good to know! Helps.