Received: (at 80000) by debbugs.gnu.org; 13 Dec 2025 17:21:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 13 12:21:54 2025 Received: from localhost ([127.0.0.1]:41717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vUTJZ-0007sD-S6 for submit <at> debbugs.gnu.org; Sat, 13 Dec 2025 12:21:54 -0500 Received: from strange.networkguild.org ([2600:3c02:e000:dd::1]:35969) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <mgrant@HIDDEN>) id 1vUTJV-0007ro-EK for 80000 <at> debbugs.gnu.org; Sat, 13 Dec 2025 12:21:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=grant.org; s=strange; t=1765646502; bh=wCh1SwlTJ2mYGqCO3olVVUWh8GoAYOYY8BMDv3X2KvQ=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To:From; b=ijl16gYNaquluVy4RRuuC8XQ7h3BuxQROPM50vQ8kE4qtqntwAjw9aHPZKUH0EHXH IfMh2G6Bewpvr87j9N5C3Y9wYRNs7JIhYlO3GtH2BWhhMOxeXUlkA8zWwkcXahAlBt iWYHIfPZJG7qGSAzWUPhQkWACAzLmgKrzKL/MrCM6p1LcnTzHPfAIgN/Zsmz8plX+S aw1YbphpRWXAj7JM1sPI3PrKW61R993mzJ40xjGYsX11kEtC9zc+UjiIZRVFQkYwDP wSosUQaZYgBx2tPdVbFWs9cReJmJ6Px8Foni9vEHaMaAQqLu5Bp1dOPCzzd5f9kisn g4EX2JyfYPAjQ== Received: from auth (localhost [127.0.0.1]) (authenticated bits=0) by strange.networkguild.org (8.17.1.9/8.17.1.9/Debian-2+deb12u2) with ESMTPSA id 5BDHLVEu769548 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 13 Dec 2025 12:21:38 -0500 From: "Michael Grant" <mgrant@HIDDEN> To: "Eli Zaretskii" <eliz@HIDDEN> Subject: Re[2]: bug#80000: gdb issues Date: Sat, 13 Dec 2025 17:21:30 +0000 Message-Id: <em6cfe2497-e666-4a10-87c6-c1392c3974e3@HIDDEN> In-Reply-To: <86ecoy8hu5.fsf@HIDDEN> References: <em3224d3c5-caa3-446f-908d-8c4efcdbbd36@HIDDEN> <86fr9e8kmu.fsf@HIDDEN> <emd76acf3a-ec93-42dd-99ec-a2bfd8821fb1@HIDDEN> <86ecoy8hu5.fsf@HIDDEN> User-Agent: eM_Client/10.4.4195.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 1.0.9 at strange.networkguild.org X-Virus-Status: Clean X-BitDefender-Scanner: Clean, Agent: BitDefender Milter 3.1.7 on strange.networkguild.org, sigver: 7.99969 X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: Build: [Engines: 2.19.8.1610, Dats: 871106, Stamp: 3], Multi: [Enabled, t: (0.000004,0.006165)], BW: [Enabled, t: (0.000003), whitelisted: mgrant@HIDDEN], APM: [Enabled, Score: 500, t: (0.002780,0.000086), Flags: BA7B0291; NN_F_GRANT; NN_EXEC_H_MAIL_HAS_NO_LINK; NN_HAS_NAME_REPLY_TO; NN_LEGIT_VALID_REPLY; NN_LEGIT_SUMM_400_WORDS; NN_LEGIT_ORIGINAL_M_ADN], RTDA: [Disabled], total: 0(775) X-BitDefender-CF-Stamp: none X-Spam-Status: No, score=-99.0 required=5.0 autolearn=disabled X-Spam-Report: * -99 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on strange.networkguild.org X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80000 Cc: 80000 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Reply-To: Michael Grant <mgrant@HIDDEN> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) $ gdb --version #GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git (this was in my original message as well). I would say it's likely a gdb issue as well but wasn't sure to be honest=20 if it wasn't something known or some option mismatch that emacs needed=20 to update calling/starting gdb. No, I never saw gdb ever ask me a question like that. The only question=20 I saw was when starting gdb mode as m-x gdb: Enable querying debuginfod servers for this session? (y or n) I have tried yes and no here. No difference and i only started seeing=20 this question the other day. debuginfod is installed. I don't see this=20 running when I am in gdb, so not even sure it's working or using it, or=20 even if this is related to the issue at hand. I never ran gud-gdb. I just tried it. I can't seem to get it to do the=20 "gdb-many-windows" setup like m-x gdb. hmm, I ran m-x gdb first, then=20 quit it, then ran m-x gud-gdb and then m-x gdb-many-windows twice, now I=20 have many windows, but it does not seem to play nicely with gdb. It=20 doesn't really manage the many windows properly. However, when running m-x gdb, I do see a buffer "*gud-tmux*" so maybe=20 it is running properly? Thanks for the help. ------ Original Message ------ From "Eli Zaretskii" <eliz@HIDDEN> To "Michael Grant" <mgrant@HIDDEN> Cc 80000 <at> debbugs.gnu.org Date 13/12/2025 16:30:42 Subject Re: bug#80000: gdb issues >> From: "Michael Grant" <mgrant@HIDDEN> >> Cc: 80000 <at> debbugs.gnu.org >> Date: Sat, 13 Dec 2025 15:44:33 +0000 >> >> Nah not a cockpit error. I've been doing this for decades and never ha= d >> to do a "file tmux" after recompiling. I can confirm this does help >> though. This was working a couple days ago, so definitely not a cockpi= t >> error. Why did that start now? Is it an emacs bug? Perhaps it's a gd= b >> mode bug? Perhaps gdb mode should notice the underlying file changed >> and run this "file" command? Is it a gdb bug or is there maybe some >> additional/new option to gdb that emacs gdb mode should be using to >> cause it to run the file command? By the way, this does not happen all >> the time, sometimes after recompile attach works just fine. Why? I do >> see the error coming from gdb, but it is not at all clear to me that >> this isn't something that could have been avoided by some option or arg >> from the emacs controlling process. > >Maybe you have updated your GDB or Binutils? This exec-file-mismatch >warning needs build-ID to work, so if your previous development >environment didn't generate build-IDs, you wouldn't have seen this. > >In any case, the underlying issue is in GDB, IMO, so I think you >should take this up with the GDB developers first. There's a setting >in GDB called "set exec-file-mismatch", but I don't see any way of >setting it to a value that would force GDB to re-load the executable. >The default is to ask, but when GDB runs under some front-end, such as >the Emacs gdb-mi package, it doesn't seem to let the user the >possibility to answer YES. > >When you say you never had to do that, does it mean you didn't see the >warning and the confirmation prompt, or did you see that, but were >able to answer YES? If the latter, perhaps you should use "M-x gud-gdb" >instead of "M-x gdb". > >> I don't know if it's possible to redefine the 'attach' command via emac= s >> to check if the exec changed and run this file command? Or maybe >> there's some (perhaps new) option to gdb that does this? > >I don't know about any such GDB options (and you haven''t even told >which version of GDB do you have installed). > >As for redefining the 'attach' command, you could define a command >named "hook-attach", and then GDB will run that when you invoke >'attach', before it runs the _real_ 'attach' command. You can read >about this in the GDB's Info manual in the node "Hooks". >
bug-gnu-emacs@HIDDEN:bug#80000; Package emacs.
Full text available.Received: (at 80000) by debbugs.gnu.org; 13 Dec 2025 16:30:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 13 11:30:56 2025 Received: from localhost ([127.0.0.1]:41329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vUSWF-0001tx-Qp for submit <at> debbugs.gnu.org; Sat, 13 Dec 2025 11:30:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48852) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vUSWB-0001tf-QY for 80000 <at> debbugs.gnu.org; Sat, 13 Dec 2025 11:30:54 -0500 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 <eliz@HIDDEN>) id 1vUSW5-0002GB-M1; Sat, 13 Dec 2025 11:30:45 -0500 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=vjg1y3akapp8WLClDKVU2DAX2yPGfeqc8VzUNYJBMfU=; b=F2TR9FVkGCys nJ+nHQaX8CkK1ON3fH8xwhJNqX7UPYuHYUEWC00kePwlH6tGqdj2fj2zndOIex444tfJ7jOMvxfU4 FfTLTDbcTQSPjG242FawPxdfU6sdMkSjLjwJoEpvR2UCMPFpgho78o2yrlrp3agtTF1MRLm6qNgeM a+UaPAGLV8yjiI6ulzPT441aKdFXpl5VR0oRNOA/hOwAp+DR/+IZXr1lJ2KQotzxC0I6Js0Kpzo9N eEGkYX/67RtKc/Jr/d5LExrAb/OpEDtkniK//eur/5pj6FfRT/BcuBJYoM7R+tLXgGnV792dYuDAJ 1+dfRFqq4Ae7w2HtSxMEkg==; Date: Sat, 13 Dec 2025 18:30:42 +0200 Message-Id: <86ecoy8hu5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: "Michael Grant" <mgrant@HIDDEN> In-Reply-To: <emd76acf3a-ec93-42dd-99ec-a2bfd8821fb1@HIDDEN> (mgrant@HIDDEN) Subject: Re: bug#80000: gdb issues References: <em3224d3c5-caa3-446f-908d-8c4efcdbbd36@HIDDEN> <86fr9e8kmu.fsf@HIDDEN> <emd76acf3a-ec93-42dd-99ec-a2bfd8821fb1@HIDDEN> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 80000 Cc: 80000 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: "Michael Grant" <mgrant@HIDDEN> > Cc: 80000 <at> debbugs.gnu.org > Date: Sat, 13 Dec 2025 15:44:33 +0000 > > Nah not a cockpit error. I've been doing this for decades and never had > to do a "file tmux" after recompiling. I can confirm this does help > though. This was working a couple days ago, so definitely not a cockpit > error. Why did that start now? Is it an emacs bug? Perhaps it's a gdb > mode bug? Perhaps gdb mode should notice the underlying file changed > and run this "file" command? Is it a gdb bug or is there maybe some > additional/new option to gdb that emacs gdb mode should be using to > cause it to run the file command? By the way, this does not happen all > the time, sometimes after recompile attach works just fine. Why? I do > see the error coming from gdb, but it is not at all clear to me that > this isn't something that could have been avoided by some option or arg > from the emacs controlling process. Maybe you have updated your GDB or Binutils? This exec-file-mismatch warning needs build-ID to work, so if your previous development environment didn't generate build-IDs, you wouldn't have seen this. In any case, the underlying issue is in GDB, IMO, so I think you should take this up with the GDB developers first. There's a setting in GDB called "set exec-file-mismatch", but I don't see any way of setting it to a value that would force GDB to re-load the executable. The default is to ask, but when GDB runs under some front-end, such as the Emacs gdb-mi package, it doesn't seem to let the user the possibility to answer YES. When you say you never had to do that, does it mean you didn't see the warning and the confirmation prompt, or did you see that, but were able to answer YES? If the latter, perhaps you should use "M-x gud-gdb" instead of "M-x gdb". > I don't know if it's possible to redefine the 'attach' command via emacs > to check if the exec changed and run this file command? Or maybe > there's some (perhaps new) option to gdb that does this? I don't know about any such GDB options (and you haven''t even told which version of GDB do you have installed). As for redefining the 'attach' command, you could define a command named "hook-attach", and then GDB will run that when you invoke 'attach', before it runs the _real_ 'attach' command. You can read about this in the GDB's Info manual in the node "Hooks".
bug-gnu-emacs@HIDDEN:bug#80000; Package emacs.
Full text available.Received: (at 80000) by debbugs.gnu.org; 13 Dec 2025 15:44:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 13 10:44:53 2025 Received: from localhost ([127.0.0.1]:40919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vURng-000766-No for submit <at> debbugs.gnu.org; Sat, 13 Dec 2025 10:44:53 -0500 Received: from strange.networkguild.org ([2600:3c02:e000:dd::1]:36587) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <mgrant@HIDDEN>) id 1vURne-00075q-2Z for 80000 <at> debbugs.gnu.org; Sat, 13 Dec 2025 10:44:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=grant.org; s=strange; t=1765640681; bh=e80auhyngJOFi8YfJwNZZCSvHK90iR3EZI5ZrDNfYUE=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To:From; b=Rqhb8C/3tnSVrh8f3finPMwLLMityeJ0fkR/Cs1qynP9jYjgPGQn2JSc2PkKmYIfu 7R0w3Vrti60IDD3nirUKqp4Zf1Cbi7kWhT0HDWALVXVejEa7wYDKskIKTnGSRQ7oHa MO0UuXaBgx/L/e8LTva0hUGyyHN34N+DoUvkt/l08zWRo+BTl/PFof1kycNM09DpN1 xAKOe6mXnujxZ++MTm0rAfqsKRPeW9fTcxT15xFNpqgwsVqAl19ckYzDSdECwm8Syv kll3HV8KAs0azJT7r7YdPHPKYffWbax+kHZKa7CP8LOMFQt6jlXTCvmbO1u9A3uAH7 QG7MggNAmq+qg== Received: from auth (localhost [127.0.0.1]) (authenticated bits=0) by strange.networkguild.org (8.17.1.9/8.17.1.9/Debian-2+deb12u2) with ESMTPSA id 5BDFiXTU765441 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 13 Dec 2025 10:44:40 -0500 From: "Michael Grant" <mgrant@HIDDEN> To: "Eli Zaretskii" <eliz@HIDDEN> Subject: Re[2]: bug#80000: gdb issues Date: Sat, 13 Dec 2025 15:44:33 +0000 Message-Id: <emd76acf3a-ec93-42dd-99ec-a2bfd8821fb1@HIDDEN> In-Reply-To: <86fr9e8kmu.fsf@HIDDEN> References: <em3224d3c5-caa3-446f-908d-8c4efcdbbd36@HIDDEN> <86fr9e8kmu.fsf@HIDDEN> User-Agent: eM_Client/10.4.4195.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 1.0.9 at strange.networkguild.org X-Virus-Status: Clean X-BitDefender-Scanner: Clean, Agent: BitDefender Milter 3.1.7 on strange.networkguild.org, sigver: 7.99968 X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: Build: [Engines: 2.19.8.1610, Dats: 871106, Stamp: 3], Multi: [Enabled, t: (0.000004,0.006347)], BW: [Enabled, t: (0.000003), whitelisted: mgrant@HIDDEN], APM: [Enabled, Score: 500, t: (0.004076,0.000105), Flags: BA7B0291; NN_F_GRANT; NN_SWISS; NN_EXEC_H_MAIL_HAS_NO_LINK; NN_HAS_NAME_REPLY_TO; NN_LEGIT_VALID_REPLY; NN_LEGIT_SUMM_400_WORDS; NN_LEGIT_ORIGINAL_M_ADN], RTDA: [Disabled], total: 0(775) X-BitDefender-CF-Stamp: none X-Spam-Status: No, score=-99.0 required=5.0 autolearn=disabled X-Spam-Report: * -99 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on strange.networkguild.org X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80000 Cc: 80000 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Reply-To: Michael Grant <mgrant@HIDDEN> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Nah not a cockpit error. I've been doing this for decades and never had=20 to do a "file tmux" after recompiling. I can confirm this does help=20 though. This was working a couple days ago, so definitely not a cockpit=20 error. Why did that start now? Is it an emacs bug? Perhaps it's a gdb=20 mode bug? Perhaps gdb mode should notice the underlying file changed=20 and run this "file" command? Is it a gdb bug or is there maybe some=20 additional/new option to gdb that emacs gdb mode should be using to=20 cause it to run the file command? By the way, this does not happen all=20 the time, sometimes after recompile attach works just fine. Why? I do=20 see the error coming from gdb, but it is not at all clear to me that=20 this isn't something that could have been avoided by some option or arg=20 from the emacs controlling process. I don't know if it's possible to redefine the 'attach' command via emacs=20 to check if the exec changed and run this file command? Or maybe=20 there's some (perhaps new) option to gdb that does this? ------ Original Message ------ From "Eli Zaretskii" <eliz@HIDDEN> To "Michael Grant" <mgrant@HIDDEN> Cc 80000 <at> debbugs.gnu.org Date 13/12/2025 15:30:17 Subject Re: bug#80000: gdb issues >> Date: Sat, 13 Dec 2025 14:42:23 +0000 >> From: "Michael Grant" via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> I'm debugging a c program in emacs using gdb mode. I was running a sli= ghtly older version of emacs but >> recently updated ubuntu and now the version appears to be: >> >> (emacs-version) >> "GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, ca= iro version 1.18.0) of >> 2024-04-01, modified by Debian" >> >> $ gdb --version >> #GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git >> >> I run a program in a shell in another window (in this case, I am debugg= ing "tmux"), so I run tmux in another >> window, it comes up. >> >> I then find it's pid and in the emacs gdb window attach <pid> and it wo= rks fine. >> >> Then, I change something in the source window, recompile, exit tmux and = restart it, find it's new pid and >> attach <newpid> and this is what I see: >> >> (gdb) at 18848 >> Attaching to program: /home/mgrant/tmux/tmux, process 18848 >> warning: Build ID mismatch between current exec-file /home/mgrant/tmux/= tmux >> and automatically determined exec-file /home/mgrant/tmux/tmux >> exec-file-mismatch handling is currently "ask" >> Reading symbols from /home/mgrant/tmux/tmux... >> warning: loading /home/mgrant/tmux/tmux Warning: >> Cannot insert breakpoint 2. >> Cannot access memory at address 0x3ff58 >> Cannot insert breakpoint 1. >> Cannot access memory at address 0x40090 >> (gdb) Reading symbols from /lib64/ld-linux-x86-64.so.2... >> Reading symbols from /usr/lib/debug/.build-id/52/0e05878220fb2fc6d28ff4= 6b63b3fd5d48e763.debug... >> 0x000079858a31b4c4 in ?? () >> >> I have tried deleting and recreating break point 1, but no matter what, = I can't get it to work. The only way I >> can get it to work is to quit gdb and restart it (losing my breakpoints= ). >> >> I notice that when this happens, the addresses in the breakpoint window = change to something like >> 0x0000000000040090. The first time I run it and set a break point, the = addresses are much higher in >> memory like 0x0000601be62e50b4. I don't know if that's a clue to what'= s going on. >> >> This used to work fine. I would recompile, re-run, and attach again ov= er and over and never had a problem >> until this update. It's mega annoying to have to start gdb over each t= ime and put back in all my breakpoints. >> >> >> What other info can I give to help solve this? > >Thanks, but why do you think this is an Emacs problem? The warning >message you cite: > > (gdb) at 18848 > Attaching to program: /home/mgrant/tmux/tmux, process 18848 > warning: Build ID mismatch between current exec-file /home/mgrant/tmux/= tmux > and automatically determined exec-file /home/mgrant/tmux/tmux > exec-file-mismatch handling is currently "ask" > >comes from GDB. The fact that it says 'exec-file-mismatch handling is >currently "ask"' tells me that all you need to do is this: > > (gdb) file /home/mgrant/tmux/tmux > >after you rebuild the program, to tell GDB to re-read the exec-file. >Or just quit GDB by typing "q RET" at the "(gdb)" prompt, then restart >it. Because the problem is that the executable file GDB has read >originally is no longer pertinent. > >IOW, I think this is a cockpit error on your part. >
bug-gnu-emacs@HIDDEN:bug#80000; Package emacs.
Full text available.Received: (at 80000) by debbugs.gnu.org; 13 Dec 2025 15:30:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 13 10:30:32 2025 Received: from localhost ([127.0.0.1]:40838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vURZn-0006QO-MY for submit <at> debbugs.gnu.org; Sat, 13 Dec 2025 10:30:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50258) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vURZl-0006QA-4u for 80000 <at> debbugs.gnu.org; Sat, 13 Dec 2025 10:30:29 -0500 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 <eliz@HIDDEN>) id 1vURZc-0001yw-4E; Sat, 13 Dec 2025 10:30:21 -0500 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=DCDbTVgnxFupPrj3vblPlq4gV4JbmvfjQOGSk9fQlqk=; b=O6ZqCXmuzLqo 8B4w4FZZkg1AKZM0oUeL/V0e0l4+WTMAYgaVlNsbpNw7BG4qS4huQwDcRa/Cre5BwLLxVQMg7cbA2 pu57ha1JZaRuIN1zmY8ePvPk56taZchOa+LA7EnvbQ77kY9o1PvCcWMHDAj4qL+aK0gHUQoumjGuc i56V3+UkksQ6RZqhJ6ncrItm8cloGEhcDfeukf8v3sbFcMwd1qOvCx4ceVaEB8gYTTOF2KOxBiP8g bWkBh8bSwLtEHvhmKGwEXdRyOP5U4vXQcyFKIqombhCEZLpZutdEl2n0ujc39i7AOqYYwl/uNHPbc +1w7A0YoBxl4nEkzPyBpYA==; Date: Sat, 13 Dec 2025 17:30:17 +0200 Message-Id: <86fr9e8kmu.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Michael Grant <mgrant@HIDDEN> In-Reply-To: <em3224d3c5-caa3-446f-908d-8c4efcdbbd36@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#80000: gdb issues References: <em3224d3c5-caa3-446f-908d-8c4efcdbbd36@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80000 Cc: 80000 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 13 Dec 2025 14:42:23 +0000 > From: "Michael Grant" via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > I'm debugging a c program in emacs using gdb mode. I was running a slightly older version of emacs but > recently updated ubuntu and now the version appears to be: > > (emacs-version) > "GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of > 2024-04-01, modified by Debian" > > $ gdb --version > #GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git > > I run a program in a shell in another window (in this case, I am debugging "tmux"), so I run tmux in another > window, it comes up. > > I then find it's pid and in the emacs gdb window attach <pid> and it works fine. > > Then, I change something in the source window, recompile, exit tmux and restart it, find it's new pid and > attach <newpid> and this is what I see: > > (gdb) at 18848 > Attaching to program: /home/mgrant/tmux/tmux, process 18848 > warning: Build ID mismatch between current exec-file /home/mgrant/tmux/tmux > and automatically determined exec-file /home/mgrant/tmux/tmux > exec-file-mismatch handling is currently "ask" > Reading symbols from /home/mgrant/tmux/tmux... > warning: loading /home/mgrant/tmux/tmux Warning: > Cannot insert breakpoint 2. > Cannot access memory at address 0x3ff58 > Cannot insert breakpoint 1. > Cannot access memory at address 0x40090 > (gdb) Reading symbols from /lib64/ld-linux-x86-64.so.2... > Reading symbols from /usr/lib/debug/.build-id/52/0e05878220fb2fc6d28ff46b63b3fd5d48e763.debug... > 0x000079858a31b4c4 in ?? () > > I have tried deleting and recreating break point 1, but no matter what, I can't get it to work. The only way I > can get it to work is to quit gdb and restart it (losing my breakpoints). > > I notice that when this happens, the addresses in the breakpoint window change to something like > 0x0000000000040090. The first time I run it and set a break point, the addresses are much higher in > memory like 0x0000601be62e50b4. I don't know if that's a clue to what's going on. > > This used to work fine. I would recompile, re-run, and attach again over and over and never had a problem > until this update. It's mega annoying to have to start gdb over each time and put back in all my breakpoints. > > > What other info can I give to help solve this? Thanks, but why do you think this is an Emacs problem? The warning message you cite: (gdb) at 18848 Attaching to program: /home/mgrant/tmux/tmux, process 18848 warning: Build ID mismatch between current exec-file /home/mgrant/tmux/tmux and automatically determined exec-file /home/mgrant/tmux/tmux exec-file-mismatch handling is currently "ask" comes from GDB. The fact that it says 'exec-file-mismatch handling is currently "ask"' tells me that all you need to do is this: (gdb) file /home/mgrant/tmux/tmux after you rebuild the program, to tell GDB to re-read the exec-file. Or just quit GDB by typing "q RET" at the "(gdb)" prompt, then restart it. Because the problem is that the executable file GDB has read originally is no longer pertinent. IOW, I think this is a cockpit error on your part.
bug-gnu-emacs@HIDDEN:bug#80000; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 13 Dec 2025 14:42:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 13 09:42:45 2025
Received: from localhost ([127.0.0.1]:39547 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vUQpZ-0003OR-BV
for submit <at> debbugs.gnu.org; Sat, 13 Dec 2025 09:42:45 -0500
Received: from lists.gnu.org ([2001:470:142::17]:48402)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <mgrant@HIDDEN>) id 1vUQpX-0003O1-NT
for submit <at> debbugs.gnu.org; Sat, 13 Dec 2025 09:42:44 -0500
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 <mgrant@HIDDEN>) id 1vUQpR-0008B1-HF
for bug-gnu-emacs@HIDDEN; Sat, 13 Dec 2025 09:42:37 -0500
Received: from strange.networkguild.org ([2600:3c02:e000:dd::1])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <mgrant@HIDDEN>) id 1vUQpP-0005hO-MM
for bug-gnu-emacs@HIDDEN; Sat, 13 Dec 2025 09:42:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=grant.org; s=strange;
t=1765636952; bh=dyrE5yeEmcpz6tNhIFP3krdQvGbvG+4ZnOGOENykSTw=;
h=From:To:Subject:Date:Reply-To:From;
b=sawtCPjHvVa3rrde8HoB3EsL4E1jOr6uNIh+6Gv7bbgDwVDNwiKSqtEmTG9k7Rccf
hcuk+b11EDWfLuDr3l1Blh5x8V5dPVBbzsmepKwp9OsQqlaXjxO4R73A87swb7DLZ6
uxvNeuxFB/hJ41FmeV4m05KPoZIxhbQuk3yKoNVpSTPkN+adsX60cs4EVmmwjTAmgR
HenGGanTLe8q2hU2n7/wqLBjMXLTVJGsjciFhrPIj1vFazMEp5s24AaHnBXNTw1YWx
D6hAQLm7HwoZLF7/irRDdd1WVugY3SVEfzjxkSaMHtmQaGMVQKCPgnzIzEM5PuqER1
AEqOLzDH3qn5A==
Received: from auth (localhost [127.0.0.1]) (authenticated bits=0)
by strange.networkguild.org (8.17.1.9/8.17.1.9/Debian-2+deb12u2) with ESMTPSA
id 5BDEgNE2761368
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
for <bug-gnu-emacs@HIDDEN>; Sat, 13 Dec 2025 09:42:31 -0500
From: "Michael Grant" <mgrant@HIDDEN>
To: "bug-gnu-emacs@HIDDEN" <bug-gnu-emacs@HIDDEN>
Subject: gdb issues
Date: Sat, 13 Dec 2025 14:42:23 +0000
Message-Id: <em3224d3c5-caa3-446f-908d-8c4efcdbbd36@HIDDEN>
User-Agent: eM_Client/10.4.4195.0
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="------=_MB8D2A022C-D0F0-41BF-B8B2-5668778AE5F4"
X-Virus-Scanned: clamav-milter 1.0.9 at strange.networkguild.org
X-Virus-Status: Clean
X-BitDefender-Scanner: Clean, Agent: BitDefender Milter 3.1.7 on
strange.networkguild.org, sigver: 7.99968
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.19.8.1610, Dats: 871106, Stamp:
3], Multi: [Enabled, t: (0.000012,0.007153)], BW: [Enabled, t:
(0.000006,0.000001), whitelisted: mgrant@HIDDEN], APM: [Enabled, Score:
500, t: (0.007744,0.000096), Flags: BA7B0291; NN_F_GRANT;
NN_S_TWO_WORDS_LOWERCASE_NMD; NN_EXEC_H_MAIL_HAS_NO_LINK;
NN_HAS_NAME_REPLY_TO], RTDA: [Disabled], total: 0(775)
X-BitDefender-CF-Stamp: none
X-Spam-Status: No, score=-99.0 required=5.0 autolearn=disabled
X-Spam-Report: * -99 ALL_TRUSTED Passed through trusted hosts only via SMTP
* 0.0 HTML_MESSAGE BODY: HTML included in message
X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on
strange.networkguild.org
Received-SPF: pass client-ip=2600:3c02:e000:dd::1;
envelope-from=mgrant@HIDDEN; helo=strange.networkguild.org
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Michael Grant <mgrant@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)
--------=_MB8D2A022C-D0F0-41BF-B8B2-5668778AE5F4
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
I'm debugging a c program in emacs using gdb mode. I was running a=20
slightly older version of emacs but recently updated ubuntu and now the=20
version appears to be:
(emacs-version)
"GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,=20
cairo version 1.18.0) of 2024-04-01, modified by Debian"
$ gdb --version
#GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
I run a program in a shell in another window (in this case, I am=20
debugging "tmux"), so I run tmux in another window, it comes up.
I then find it's pid and in the emacs gdb window attach <pid> and it=20
works fine.
Then, I change something in the source window, recompile, exit tmux and=20
restart it, find it's new pid and attach <newpid> and this is what I=20
see:
(gdb) at 18848
Attaching to program: /home/mgrant/tmux/tmux, process 18848
warning: Build ID mismatch between current exec-file=20
/home/mgrant/tmux/tmux
and automatically determined exec-file /home/mgrant/tmux/tmux
exec-file-mismatch handling is currently "ask"
Reading symbols from /home/mgrant/tmux/tmux...
warning: loading /home/mgrant/tmux/tmux Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x3ff58
Cannot insert breakpoint 1.
Cannot access memory at address 0x40090
(gdb) Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from=20
/usr/lib/debug/.build-id/52/0e05878220fb2fc6d28ff46b63b3fd5d48e763.debug...
0x000079858a31b4c4 in ?? ()
I have tried deleting and recreating break point 1, but no matter what,=20
I can't get it to work. The only way I can get it to work is to quit=20
gdb and restart it (losing my breakpoints).
I notice that when this happens, the addresses in the breakpoint window=20
change to something like 0x0000000000040090. The first time I run it=20
and set a break point, the addresses are much higher in memory like=20
0x0000601be62e50b4. I don't know if that's a clue to what's going on.
This used to work fine. I would recompile, re-run, and attach again=20
over and over and never had a problem until this update. It's mega=20
annoying to have to start gdb over each time and put back in all my=20
breakpoints.
What other info can I give to help solve this?
Michael Grant
--------=_MB8D2A022C-D0F0-41BF-B8B2-5668778AE5F4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head>
<style id=3D"css_styles">=20
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px;=
padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px;=
padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding=
-top: 0px; }
a img { border: 0px; }
li[style=3D'text-align: center;'], li[style=3D'text-align: center; '], li[s=
tyle=3D'text-align: right;'], li[style=3D'text-align: right; '] { list-sty=
le-position: inside;}
body { font-family: 'Segoe UI'; font-size: 12pt; }
.quote { margin-left: 1em; margin-right: 1em; border-left: 5px #ebebeb soli=
d; padding-left: 0.3em; }
a.em-mention[href] { text-decoration: none; color: inherit; border-radius:=
3px; padding-left: 2px; padding-right: 2px; background-color: #e2e2e2; }
._em_placeholder {color: gray; border-bottom: 1px dotted lightblue;} ._em_p=
laceholder:before{color:gray; content: '{{ ';} ._em_placeholder:after{color=
:gray; content: ' }}';}
</style>
</head>
<body style=3D"">I'm debugging a c program in emacs using gdb mode.=C2=A0 I =
was running a slightly older version of emacs but recently updated ubuntu=
and now the version appears to be:<div><br /></div><div>(emacs-version)</di=
v><div>"GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, =
cairo version 1.18.0)=C2=A0of 2024-04-01, modified by Debian"</div><div><b=
r /></div><div>$ gdb --version
</div><div>#GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git=
</div><div><br /></div><div>I run a program in a shell in another window (i=
n this case, I am debugging "tmux"), so I run tmux in another window, it co=
mes up.</div><div><br /></div><div>I then find it's pid and in the emacs gd=
b window attach <pid> and it works fine.</div><div><br /></div><div>T=
hen, I change something in the source window, recompile, exit tmux and rest=
art it, find it's new pid and attach <newpid> and this is what I see:=
</div><div><br /></div><div>(gdb) at 18848
</div><div>Attaching to program: /home/mgrant/tmux/tmux, process 18848
</div><div>warning: Build ID mismatch between current exec-file /home/mgran=
t/tmux/tmux
</div><div>and automatically determined exec-file /home/mgrant/tmux/tmux
</div><div>exec-file-mismatch handling is currently "ask"
</div><div>Reading symbols from /home/mgrant/tmux/tmux...
</div><div>warning: loading /home/mgrant/tmux/tmux Warning:
</div><div>Cannot insert breakpoint 2.
</div><div>Cannot access memory at address 0x3ff58
</div><div>Cannot insert breakpoint 1.
</div><div>Cannot access memory at address 0x40090
</div><div>(gdb) Reading symbols from /lib64/ld-linux-x86-64.so.2...
</div><div>Reading symbols from /usr/lib/debug/.build-id/52/0e05878220fb2fc=
6d28ff46b63b3fd5d48e763.debug...
</div><div>0x000079858a31b4c4 in ?? ()</div><div><br /></div><div>I have tr=
ied deleting and recreating break point 1, but no matter what, I can't get=
it to work.=C2=A0 The only way I can get it to work is to quit gdb and rest=
art it (losing my breakpoints).</div><div><br /></div><div>I notice that wh=
en this happens, the addresses in the breakpoint window change to something =
like 0x0000000000040090.=C2=A0 The first time I run it and set a break poi=
nt, the addresses are much higher in memory like 0x0000601be62e50b4.=C2=A0=
I don't know if that's a clue to what's going on.</div><div><br /></div><di=
v style=3D"">This used to work fine.=C2=A0 I would recompile, re-run, and a=
ttach again over and over and never had a problem until this update.=C2=A0=
It's mega annoying to have to start gdb over each time and put back in all=
my breakpoints.=C2=A0=C2=A0</div><div style=3D""><br /></div><div style=3D"=
">What other info can I give to help solve this?</div><div style=3D""><br /=
></div><div style=3D"">Michael Grant</div></body></html>
--------=_MB8D2A022C-D0F0-41BF-B8B2-5668778AE5F4--
Michael Grant <mgrant@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#80000; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.