From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Debugging Emacs with threads Date: Sun, 11 Dec 2016 18:26:12 +0200 Message-ID: <83inqqe8kb.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1481473553 20052 195.159.176.226 (11 Dec 2016 16:25:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Dec 2016 16:25:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 11 17:25:50 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cG6we-00047O-1Q for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 17:25:48 +0100 Original-Received: from localhost ([::1]:56192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG6wi-0003Ld-4A for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 11:25:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG6wX-0003L3-Kr for emacs-devel@gnu.org; Sun, 11 Dec 2016 11:25:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cG6wT-0003HF-N0 for emacs-devel@gnu.org; Sun, 11 Dec 2016 11:25:41 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44319) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG6wT-0003HA-EX; Sun, 11 Dec 2016 11:25:37 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3147 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cG6wS-0000BB-Oc; Sun, 11 Dec 2016 11:25:37 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:210282 Archived-At: There's a nasty issue that people who debug Emacs with threads need to be aware of. When Emacs stops due to a breakpoint, the thread that is the current one is in sync between GDB and Emacs. IOW, the current_thread variable describes the same thread on which GDB commands will act. But as soon as you say something like "thread 1" at the GDB prompt, this synchronization is lost: GDB acts on the thread you specified, while current_thread is still pointing at the thread which was the current one when Emacs stopped. The result of this is that invoking functions in Emacs will likely crash, because thread-specific variables used by Emacs are incorrect for the thread whose stack GDB will use to create the call-stack frame for the function it calls. In particular, xbacktrace will definitely crash. And since src/.gdbinit automatically invokes xbacktrace when you type "bt", any "bt" issued when the threads mismatch will ruin the debugging session. It would be good to protect xbacktrace from this, and avoid calling functions in Emacs in this situation. Unfortunately, I couldn't find any way of gleaning the OS thread ID from the GDB thread number. Maybe Tom, who knows a lot about GDB, could help, or someone else might have an idea that we then could implement in .gdbinit? TIA