Re: Debugging Emacs with threads

[Ken Raeburn <raeburn@raeburn.org>]

On Dec 11, 2016, at 11:26, Eli Zaretskii <eliz@gnu.org> wrote:

> 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?

Perhaps a new thread-local variable which has the value of current_thread when the thread is the current Lisp thread.  Or we could invoke sys_thread_self() to compare against current_thread->thread_id; it’s not like xbacktrace works on a core file anyway.  (I’m assuming GDB will invoke a function or look at TLS in the context of the current OS thread, or the appropriate OS thread when invoked via something like “thread apply all bt”.)

Ken