From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Simen =?UTF-8?Q?Endsj=C3=B8?= Newsgroups: gmane.emacs.bugs Subject: bug#70914: 29.3; Crashes often on Windows Date: Mon, 20 May 2024 19:54:38 +0200 Message-ID: References: <86msouxamh.fsf@gnu.org> <86h6f0wsbv.fsf@gnu.org> <86seyjtgvd.fsf@gnu.org> <86ttizjdwm.fsf@gnu.org> <86h6eykiuk.fsf@gnu.org> <86cypmji2l.fsf@gnu.org> <865xvadhsg.fsf@gnu.org> <861q5ycpv1.fsf@gnu.org> <86ed9yb2cg.fsf@gnu.org> <86y185ac0w.fsf@gnu.org> <86bk50a938.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="14605"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70914@debbugs.gnu.org, corwin@bru.st To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 20 19:57:07 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 1s97Fz-0003a2-9e for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 May 2024 19:57:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s97Fr-0008R7-Fh; Mon, 20 May 2024 13:56:59 -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 1s97Fp-0008Qt-SB for bug-gnu-emacs@gnu.org; Mon, 20 May 2024 13:56:57 -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 1s97Fp-0005GE-KH for bug-gnu-emacs@gnu.org; Mon, 20 May 2024 13:56:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s97Ft-00055Q-Od for bug-gnu-emacs@gnu.org; Mon, 20 May 2024 13:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Simen =?UTF-8?Q?Endsj=C3=B8?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 May 2024 17:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70914 X-GNU-PR-Package: emacs Original-Received: via spool by 70914-submit@debbugs.gnu.org id=B70914.171622776919541 (code B ref 70914); Mon, 20 May 2024 17:57:01 +0000 Original-Received: (at 70914) by debbugs.gnu.org; 20 May 2024 17:56:09 +0000 Original-Received: from localhost ([127.0.0.1]:43934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s97Et-00054o-Os for submit@debbugs.gnu.org; Mon, 20 May 2024 13:56:09 -0400 Original-Received: from mail-lj1-f177.google.com ([209.85.208.177]:59863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s97Er-00054i-MP for 70914@debbugs.gnu.org; Mon, 20 May 2024 13:55:58 -0400 Original-Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-2e724bc466fso17614231fa.3 for <70914@debbugs.gnu.org>; Mon, 20 May 2024 10:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716227687; x=1716832487; 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=YNp1GyufbIrAv1GgzcjwCKWZ1s/IEyopieg4vBigbwU=; b=anc54Is2urWrnvmUeRToLYj05E2kGVewQII3ZEvMrJTpLZRnPtI3leGN0Qcd2fz2Ya BG2ZmitHE+IrsL80tsH2ikkYlSFwzlX4Gfr1nsLRCjNDG8IEgENPIp7nVM4ku64S3go7 WgdIMppqytY2KHA2JkHVYaj4ELIWLJ2d2BCJob3WOCCJQF6pQ1NVZRgOLj8veEI+x5cm gT4ud0L+/iDvffKLrxfoXQQXRfPM+EiIY5IZUMe1i5O27HUNIhqiW+5Hk2V9lwSySMwn 5qctL5Evz6F2qixiEZnntWATHNdIablTTUcIJJ0KzF4I0CWhgP1h4wgp7RaUnD8AHQkH 4L1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716227687; x=1716832487; 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=YNp1GyufbIrAv1GgzcjwCKWZ1s/IEyopieg4vBigbwU=; b=jUcPLWTOpk9tw02poVUaHqArsGOLmLTURNZD0LMrVBJ0D/K2fgRyqJDDNlacEMUNjG NVrUq4AYFqkHxZRMAg7t/H5e0Dd2j1MABvuXDtTRDjSFOkiJcnCWs1kGznGCE4hB5b4D 2Sexp2f8pxkZWVQMJMbOiIzN/REiH/Pi/pCnMctJC9s3Rqb0ylji3SYbezaaXmfpuOL8 lRV8L8b8sk3gbg0cHosSlxklmsyzNRcmCL5KNwXCrFaVa+0J2djFfp/bDaeZWXfGrrUQ /+K6iodKwOpemW8HVnYiUP+P13bOV4CCY2FwjUF06X/aZdRH57Ud6sW6WiYIHlWJhNBb PVQw== X-Gm-Message-State: AOJu0YzQ1UbtQIGlAh1E31aIFFCU+imfa0X9DAvw4JHdy9K0Hz4xaF1P nInbYmZUP9ILr0diRF7FLBDPha08bbL4Gfvx0Wm0mRgTi54SxClqyrihCTigYEJ1bTfQGegBPj5 6Ji23AeVw/reYlljf04cSvcfq+OU= X-Google-Smtp-Source: AGHT+IFWDRr48UEy7TiAs+chjkYDqS7vLoKkEPuLCY4j1a/9YgDLI/Y8Te0LkDzSs86elr328qzAwpFZeaYSxigOn+k= X-Received: by 2002:a19:f007:0:b0:518:9823:601a with SMTP id 2adb3069b0e04-5220fd7bd32mr26488780e87.39.1716227686615; Mon, 20 May 2024 10:54:46 -0700 (PDT) In-Reply-To: <86bk50a938.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:285488 Archived-At: > Please try this with a healthy Emacs process before you do it after > the crash, to make sure this procedure works. Here's my attempt to > validate this technique: Looks like I needed a binary with debugging symbols, so I used my previous build. It's as good as any other. But looks like there are two stack frames= with zero pointers, so the technique doesn't work? Thread 1 received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) thread 1 [Switching to thread 1 (Thread 19884.0x7bf8)] #0 0x0000000000000000 in ?? () (gdb) p/x *(uintptr_t *)$sp $1 =3D 0x0 (gdb) list *$ (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000000000000000 in ?? () (gdb) On Mon, May 20, 2024 at 3:47=E2=80=AFPM Eli Zaretskii wrote: > > > From: Simen Endsj=C3=B8 > > Date: Sun, 19 May 2024 20:38:24 +0200 > > Cc: 70914@debbugs.gnu.org, corwin@bru.st > > > > *****************************| System Information |********************= ********* > > Thanks. I think, given that every other avenue of approach has > failed, we should try the direct one: try to determine which code > called the zero PC address. I think the following should work for > you, after Emacs crashes due to zero address: > > (gdb) thread 1 > (gdb) p/x *(uintptr_t *)$sp > $1 =3D 0x1234567887654321 > (gdb) list *$ > > The "0x1234567887654321" stands for some 64-bit address that GDB will > show in your case, which is the address pointed by the stack pointer > register. AFAIU, that address should hold the return address of the > function which called the "zero address", and the "list" command > should show its source code (assuming it's some Emacs code). > > Please try this with a healthy Emacs process before you do it after > the crash, to make sure this procedure works. Here's my attempt to > validate this technique: > > gdb ./emacs.exe > ... > (gdb) break Frecursive_edit > Breakpoint 2 at 0x115dc2f: file emacs.c, line 2621. > (gdb) run -Q > Thread 1 hit Breakpoint 2, main (argc=3D2, argv=3D0x7ab2570) at emacs.c= :2621 > 2621 Frecursive_edit (); > (gdb) si > Frecursive_edit () at keyboard.c:808 > 808 { > (gdb) p/x *(uintptr_t *)$sp > $4 =3D 0x76dc34 > (gdb) list *$ > 0x76dc34 is in main (emacs.c:2622). > 2617 #endif > 2618 > 2619 /* Enter editor command loop. This never returns. */ > 2620 set_initial_minibuffer_mode (); > 2621 Frecursive_edit (); > 2622 eassume (false); > 2623 } > 2624 ^L > 2625 /* Sort the args so we can find the most important ones > 2626 at the beginning of argv. */ > (gdb) > > The above is in a 32-bit build of Emacs, not 64-bit build as in your > case. The above tells us that Frecursive_edit was called from a line > before 2622 (since the return address on the stack is the address of > the first function _after_ Frecursive_edit). > > Note that I used the "si" command (stepi) to step 1 machine > instruction inside Frecursive_edit and stop immediately after the > call, before the function's preamble pushes local variables onto the > stack, so as to ensure that the stack pointer points to the return > address. > > I hope using this technique we will be able to find the immediate > caller of the "zero address". Fingers crossed.