Emacs without threads

Emacs without threads

[Manuel Giraud via Emacs development discussions.]

Hi,

I know I can build Emacs without Lisp threads support with
'--without-threads' but how can I build Emacs without thread support at
all?

Best regards,
-- 
Manuel Giraud

Re: Emacs without threads

[Eli Zaretskii]

> Date: Thu, 14 Dec 2023 11:36:09 +0100
> From:  Manuel Giraud via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> I know I can build Emacs without Lisp threads support with
> '--without-threads' but how can I build Emacs without thread support at
> all?

What do you mean by "without thread support at all", and how is it
different from what you get with --without-threads?

Re: Emacs without threads

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 14 Dec 2023 11:36:09 +0100
>> From:  Manuel Giraud via "Emacs development discussions." <emacs-devel@gnu.org>
>> 
>> I know I can build Emacs without Lisp threads support with
>> '--without-threads' but how can I build Emacs without thread support at
>> all?
>
> What do you mean by "without thread support at all", and how is it
> different from what you get with --without-threads?

I mean that Emacs won't be able to start any thread (for example via
pthread_* functions).  I thought that --without-threads only removed the
Lisp support for threads because, from a debugging session, Emacs does
seem to continue to start threads.

(FWIW, I want this to simplify debugging because on my machine I cannot
make GDB to switch to the correct thread or to continue running other
threads)
-- 
Manuel Giraud

Re: Emacs without threads

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: emacs-devel@gnu.org
> Date: Thu, 14 Dec 2023 13:43:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What do you mean by "without thread support at all", and how is it
> > different from what you get with --without-threads?
> 
> I mean that Emacs won't be able to start any thread (for example via
> pthread_* functions).

That's what --without-threads does.

> I thought that --without-threads only removed the Lisp support for
> threads because, from a debugging session, Emacs does seem to
> continue to start threads.

The threads you see under a debugger are not Lisp threads, they are
threads started by GTK and other libraries we link against.  You
cannot disable them, except by building Emacs without those libraries
(I think just without GTK should do, if you are on GNU/Linux).

> (FWIW, I want this to simplify debugging because on my machine I cannot
> make GDB to switch to the correct thread

How come?

> or to continue running other threads)

Why would you need to do that?

Re: Emacs without threads

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 14 Dec 2023 13:43:09 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > What do you mean by "without thread support at all", and how is it
>> > different from what you get with --without-threads?
>> 
>> I mean that Emacs won't be able to start any thread (for example via
>> pthread_* functions).
>
> That's what --without-threads does.

Ok, good.

>> I thought that --without-threads only removed the Lisp support for
>> threads because, from a debugging session, Emacs does seem to
>> continue to start threads.
>
> The threads you see under a debugger are not Lisp threads, they are
> threads started by GTK and other libraries we link against.  You
> cannot disable them, except by building Emacs without those libraries
> (I think just without GTK should do, if you are on GNU/Linux).

I'm not using GTK so maybe it is another library (maybe librsvg-2).

>> (FWIW, I want this to simplify debugging because on my machine I cannot
>> make GDB to switch to the correct thread
>
> How come?

I don't know so I will just describe the symptoms: when I "run" Emacs
into a 'M-x gdb' session at one point the *gud* buffer will output [New
thread ...] and then the Emacs process is stuck and so is the process of
the *gud* buffer.  So I have to kill and close everything.

(FWIW, GDB on OpenBSD does not seem to support non-stop mode.  Maybe it
is what is required.)
-- 
Manuel Giraud

Re: Emacs without threads

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: emacs-devel@gnu.org
> Date: Thu, 14 Dec 2023 15:12:31 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The threads you see under a debugger are not Lisp threads, they are
> > threads started by GTK and other libraries we link against.  You
> > cannot disable them, except by building Emacs without those libraries
> > (I think just without GTK should do, if you are on GNU/Linux).
> 
> I'm not using GTK so maybe it is another library (maybe librsvg-2).

Look at the code those threads run (e.g., with "thread apply all bt"),
and you will know which library does that.

> >> (FWIW, I want this to simplify debugging because on my machine I cannot
> >> make GDB to switch to the correct thread
> >
> > How come?
> 
> I don't know so I will just describe the symptoms: when I "run" Emacs
> into a 'M-x gdb' session at one point the *gud* buffer will output [New
> thread ...] and then the Emacs process is stuck and so is the process of
> the *gud* buffer.  So I have to kill and close everything.

Never seen anything like that.  Any chance of describing under what
conditions this happens?  Is this 100% reproducible on your system?

> (FWIW, GDB on OpenBSD does not seem to support non-stop mode.  Maybe it
> is what is required.)

No, you don't need the non-stop mode to debug Emacs.  You need the
all-stop mode, which is supposed to be the default.

What version of GDB do you have there?

Re: Emacs without threads

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 14 Dec 2023 15:12:31 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > The threads you see under a debugger are not Lisp threads, they are
>> > threads started by GTK and other libraries we link against.  You
>> > cannot disable them, except by building Emacs without those libraries
>> > (I think just without GTK should do, if you are on GNU/Linux).
>> 
>> I'm not using GTK so maybe it is another library (maybe librsvg-2).
>
> Look at the code those threads run (e.g., with "thread apply all bt"),
> and you will know which library does that.
>
>> >> (FWIW, I want this to simplify debugging because on my machine I cannot
>> >> make GDB to switch to the correct thread
>> >
>> > How come?
>> 
>> I don't know so I will just describe the symptoms: when I "run" Emacs
>> into a 'M-x gdb' session at one point the *gud* buffer will output [New
>> thread ...] and then the Emacs process is stuck and so is the process of
>> the *gud* buffer.  So I have to kill and close everything.
>
> Never seen anything like that.  Any chance of describing under what
> conditions this happens?  Is this 100% reproducible on your system?

This is not 100% reproducible but it eventually happens most of the time
😅.  For example, if I put a breakpoint on 'show_mouse_face' and run
with -Q in gdb, I finally stuck like this at some point.

>> (FWIW, GDB on OpenBSD does not seem to support non-stop mode.  Maybe it
>> is what is required.)
>
> No, you don't need the non-stop mode to debug Emacs.  You need the
> all-stop mode, which is supposed to be the default.

Ok.  FWIW, I cannot set the scheduler-locking setting.  Here is what I
get when I try:

(gdb) set scheduler-locking replay
Target 'exec' cannot support this command.
(gdb) show scheduler-locking
Mode for locking scheduler during execution is "off".

> What version of GDB do you have there?

Version 9.2 that comes with OpenBSD packages.
-- 
Manuel Giraud

Re: Emacs without threads

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: emacs-devel@gnu.org
> Date: Fri, 15 Dec 2023 12:08:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Manuel Giraud <manuel@ledu-giraud.fr>
> >> Cc: emacs-devel@gnu.org
> >> Date: Thu, 14 Dec 2023 15:12:31 +0100
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > The threads you see under a debugger are not Lisp threads, they are
> >> > threads started by GTK and other libraries we link against.  You
> >> > cannot disable them, except by building Emacs without those libraries
> >> > (I think just without GTK should do, if you are on GNU/Linux).
> >> 
> >> I'm not using GTK so maybe it is another library (maybe librsvg-2).
> >
> > Look at the code those threads run (e.g., with "thread apply all bt"),
> > and you will know which library does that.
> >
> >> >> (FWIW, I want this to simplify debugging because on my machine I cannot
> >> >> make GDB to switch to the correct thread
> >> >
> >> > How come?
> >> 
> >> I don't know so I will just describe the symptoms: when I "run" Emacs
> >> into a 'M-x gdb' session at one point the *gud* buffer will output [New
> >> thread ...] and then the Emacs process is stuck and so is the process of
> >> the *gud* buffer.  So I have to kill and close everything.
> >
> > Never seen anything like that.  Any chance of describing under what
> > conditions this happens?  Is this 100% reproducible on your system?
> 
> This is not 100% reproducible but it eventually happens most of the time
> 😅.  For example, if I put a breakpoint on 'show_mouse_face' and run
> with -Q in gdb, I finally stuck like this at some point.

Unless someone who uses GDB on X can confirm this problem, I'd say
this is something to report to the GDB developers and/or the OpenBSD's
GDB distro maintainers.

Do you have any idea what code is run by those "New thread"s?

If you start GDB from the shell prompt, not from Emacs, does this
happen then as well?  If not, this could be some bug in gdb-mi.el.

> FWIW, I cannot set the scheduler-locking setting.  Here is what I
> get when I try:
> 
> (gdb) set scheduler-locking replay
> Target 'exec' cannot support this command.
> (gdb) show scheduler-locking
> Mode for locking scheduler during execution is "off".

OFF is OK for debugging Emacs, but why do you think scheduler-locking
is relevant to this issue?

Re: Emacs without threads

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Unless someone who uses GDB on X can confirm this problem, I'd say
> this is something to report to the GDB developers and/or the OpenBSD's
> GDB distro maintainers.
>
> Do you have any idea what code is run by those "New thread"s?

No I don't but…

> If you start GDB from the shell prompt, not from Emacs, does this
> happen then as well?  If not, this could be some bug in gdb-mi.el.

… Thank you for suggesting it because I have tried with "gdb ./emacs"
from a xterm and I am not able to reproduce this lock.  I have also
tried with 'M-x gud-gdb' and I also ended up stuck.  So there might be
something at play in gdb-mi.el.

FWIW, I have also noticed that even though I have closed the stuck Emacs
and delete the *gud* Emacs process.  The system process for GDB and
Emacs are still there and in weird states.  ps gives me the following
STAT:

      - GDB is DlL which means: in uninterruptible wait, ld.so has
        syscall pinning, libc.so has syscall pinning
        
      - Emacs is TXlL which means: stopped process, being traced or
        debugged, ld.so has syscall pinning, libc.so has syscall pinning
-- 
Manuel Giraud

Re: Emacs without threads

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: emacs-devel@gnu.org
> Date: Fri, 15 Dec 2023 14:58:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If you start GDB from the shell prompt, not from Emacs, does this
> > happen then as well?  If not, this could be some bug in gdb-mi.el.
> 
> … Thank you for suggesting it because I have tried with "gdb ./emacs"
> from a xterm and I am not able to reproduce this lock.  I have also
> tried with 'M-x gud-gdb' and I also ended up stuck.  So there might be
> something at play in gdb-mi.el.

Strange, gdb-mi.el is not supposed to cause any threads anywhere.

Does anyone see something like that on GNU/Linux?

> FWIW, I have also noticed that even though I have closed the stuck Emacs
> and delete the *gud* Emacs process.  The system process for GDB and
> Emacs are still there and in weird states.  ps gives me the following
> STAT:
> 
>       - GDB is DlL which means: in uninterruptible wait, ld.so has
>         syscall pinning, libc.so has syscall pinning
>         
>       - Emacs is TXlL which means: stopped process, being traced or
>         debugged, ld.so has syscall pinning, libc.so has syscall pinning

Attaching a GDB to each one of those and posting a backtrace might
give us some ideas.

Re: Emacs without threads

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 15 Dec 2023 14:58:57 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > If you start GDB from the shell prompt, not from Emacs, does this
>> > happen then as well?  If not, this could be some bug in gdb-mi.el.
>> 
>> … Thank you for suggesting it because I have tried with "gdb ./emacs"
>> from a xterm and I am not able to reproduce this lock.  I have also
>> tried with 'M-x gud-gdb' and I also ended up stuck.  So there might be
>> something at play in gdb-mi.el.
>
> Strange, gdb-mi.el is not supposed to cause any threads anywhere.

Yes it is indeed.  I had GDB session for debugging Emacs: it had run for
hours and never created any threads and never froze.

> Does anyone see something like that on GNU/Linux?
>
>> FWIW, I have also noticed that even though I have closed the stuck Emacs
>> and delete the *gud* Emacs process.  The system process for GDB and
>> Emacs are still there and in weird states.  ps gives me the following
>> STAT:
>> 
>>       - GDB is DlL which means: in uninterruptible wait, ld.so has
>>         syscall pinning, libc.so has syscall pinning
>>         
>>       - Emacs is TXlL which means: stopped process, being traced or
>>         debugged, ld.so has syscall pinning, libc.so has syscall pinning
>
> Attaching a GDB to each one of those and posting a backtrace might
> give us some ideas.

I don't know what you mean here but anyway I'll try to look into this
issue when I have some time.
-- 
Manuel Giraud

Re: Emacs without threads

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: emacs-devel@gnu.org
> Date: Sat, 16 Dec 2023 20:13:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> FWIW, I have also noticed that even though I have closed the stuck Emacs
> >> and delete the *gud* Emacs process.  The system process for GDB and
> >> Emacs are still there and in weird states.  ps gives me the following
> >> STAT:
> >> 
> >>       - GDB is DlL which means: in uninterruptible wait, ld.so has
> >>         syscall pinning, libc.so has syscall pinning
> >>         
> >>       - Emacs is TXlL which means: stopped process, being traced or
> >>         debugged, ld.so has syscall pinning, libc.so has syscall pinning
> >
> > Attaching a GDB to each one of those and posting a backtrace might
> > give us some ideas.
> 
> I don't know what you mean here but anyway I'll try to look into this
> issue when I have some time.

What I mean is:

  . find out the process ID of the GDB process that is DlL
  . attach another GDB to it, like this:

      $ gdb -p PID

    where PID is the process ID of that DlL GDB
  . produce backtrace (thread apply all bt") from the GDB attached to
    the DlL GDB

This will only help of your GDB is installed with symbols, otherwise
the backtrace will not be interesting.

Re: Emacs without threads

[Manuel Giraud via Emacs development discussions.]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>>> Cc: emacs-devel@gnu.org
>>> Date: Fri, 15 Dec 2023 14:58:57 +0100
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> > If you start GDB from the shell prompt, not from Emacs, does this
>>> > happen then as well?  If not, this could be some bug in gdb-mi.el.
>>> 
>>> … Thank you for suggesting it because I have tried with "gdb ./emacs"
>>> from a xterm and I am not able to reproduce this lock.  I have also
>>> tried with 'M-x gud-gdb' and I also ended up stuck.  So there might be
>>> something at play in gdb-mi.el.
>>
>> Strange, gdb-mi.el is not supposed to cause any threads anywhere.
>
> Yes it is indeed.  I had GDB session for debugging Emacs: it had run for
> hours and never created any threads and never froze.

Ok, so it is something in my config.  emacs -Q is not affected and won't
freeze into a debugging session.  I do not have much customization on
GDB so I wonder what it could be though.
-- 
Manuel Giraud

Re: Emacs without threads

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: emacs-devel@gnu.org
> Date: Sun, 17 Dec 2023 19:43:12 +0100
> 
> Ok, so it is something in my config.  emacs -Q is not affected and won't
> freeze into a debugging session.  I do not have much customization on
> GDB so I wonder what it could be though.

Do you have something in your customizations that loads packages
written in languages other than Lisp?  Or features that launch other
programs?  Or maybe something that does try to start Lisp threads via
make-thread?

Re: Emacs without threads

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 17 Dec 2023 19:43:12 +0100
>> 
>> Ok, so it is something in my config.  emacs -Q is not affected and won't
>> freeze into a debugging session.  I do not have much customization on
>> GDB so I wonder what it could be though.
>
> Do you have something in your customizations that loads packages
> written in languages other than Lisp?  Or features that launch other
> programs?  Or maybe something that does try to start Lisp threads via
> make-thread?

Thanks for your ideas (and patience).  I think I have found the guilty
program.

I'm using EXWM and start emacs last from my .xsession.  But, as for
other wm, I start it with a dbus-launch like this:

   dbus-launch --sh-syntax --exit-with-x11 emacs
   
If I replace this line with just "emacs", I do not experience the freeze
of GDB sessions.  Thanks.
-- 
Manuel Giraud

Re: Emacs without threads

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: emacs-devel@gnu.org
> Date: Mon, 18 Dec 2023 07:53:00 +0100
> 
> I'm using EXWM and start emacs last from my .xsession.  But, as for
> other wm, I start it with a dbus-launch like this:
> 
>    dbus-launch --sh-syntax --exit-with-x11 emacs
>    
> If I replace this line with just "emacs", I do not experience the freeze
> of GDB sessions.  Thanks.

Glad I could help you.

I don't what dbus-launch does.  Michael, can you help us understand
why it interferes with debugging via gdb-mi.el?

Re: Emacs without threads

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> I'm using EXWM and start emacs last from my .xsession.  But, as for
>> other wm, I start it with a dbus-launch like this:
>>
>>    dbus-launch --sh-syntax --exit-with-x11 emacs
>>
>> If I replace this line with just "emacs", I do not experience the freeze
>> of GDB sessions.  Thanks.
>
> Glad I could help you.
>
> I don't what dbus-launch does.  Michael, can you help us understand
> why it interferes with debugging via gdb-mi.el?

dbus-launch with its above arguments starts the D-Bus session bus as
daemon. It sets the respective environment variables and starts the
given program (emacs in this case) with the new environment.

The backside of this approach is, that this D-Bus environment is known
only to the started Emacs instance and its derived programs. The cannot
communicate with other programs via D-Bus, if these programs are started
outside the dbus-launch invocation.

I don't know, whether this is relevant for gdb-mi.el.

Best regards, Michael.

Re: Emacs without threads

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Manuel Giraud <manuel@ledu-giraud.fr>,  emacs-devel@gnu.org
> Date: Fri, 22 Dec 2023 10:20:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> Hi Eli,
> 
> >> I'm using EXWM and start emacs last from my .xsession.  But, as for
> >> other wm, I start it with a dbus-launch like this:
> >>
> >>    dbus-launch --sh-syntax --exit-with-x11 emacs
> >>
> >> If I replace this line with just "emacs", I do not experience the freeze
> >> of GDB sessions.  Thanks.
> >
> > Glad I could help you.
> >
> > I don't what dbus-launch does.  Michael, can you help us understand
> > why it interferes with debugging via gdb-mi.el?
> 
> dbus-launch with its above arguments starts the D-Bus session bus as
> daemon. It sets the respective environment variables and starts the
> given program (emacs in this case) with the new environment.
> 
> The backside of this approach is, that this D-Bus environment is known
> only to the started Emacs instance and its derived programs. The cannot
> communicate with other programs via D-Bus, if these programs are started
> outside the dbus-launch invocation.
> 
> I don't know, whether this is relevant for gdb-mi.el.

Thanks.  Do you have an idea what could be those threads that Manuel
saw when debugging such an Emacs?

Manuel, would you please describe in detail how you debug such an
Emacs?  That is, how you start GDB in gdb-mi, and how you "connect"
GDB to the Emacs session launched as above?

Re: Emacs without threads

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,
>> dbus-launch with its above arguments starts the D-Bus session bus as
>> daemon. It sets the respective environment variables and starts the
>> given program (emacs in this case) with the new environment.
>>
>> The backside of this approach is, that this D-Bus environment is known
>> only to the started Emacs instance and its derived programs. The cannot
>> communicate with other programs via D-Bus, if these programs are started
>> outside the dbus-launch invocation.
>>
>> I don't know, whether this is relevant for gdb-mi.el.
>
> Thanks.  Do you have an idea what could be those threads that Manuel
> saw when debugging such an Emacs?

No idea, sorry.

Best regards, Michael.

Re: Emacs without threads

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Manuel, would you please describe in detail how you debug such an
> Emacs?  That is, how you start GDB in gdb-mi, and how you "connect"
> GDB to the Emacs session launched as above?

Hi,

Nothing special here.  I just do 'M-x gdb' from the Emacs src directory
so it automatically propose to lauch "egdb -i=mi emacs" and I hit enter.
(don't mind the 'e' in "egdb" it is the name of binary for recent GDB on
OpenBSD)

FWIW, I have stopped to load DBUS at session startup and I still don't
know what am I missing without it.
-- 
Manuel Giraud

Re: Emacs without threads

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Michael Albinus <michael.albinus@gmx.de>,  emacs-devel@gnu.org
> Date: Fri, 22 Dec 2023 14:55:32 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Manuel, would you please describe in detail how you debug such an
> > Emacs?  That is, how you start GDB in gdb-mi, and how you "connect"
> > GDB to the Emacs session launched as above?
> 
> Nothing special here.  I just do 'M-x gdb' from the Emacs src directory
> so it automatically propose to lauch "egdb -i=mi emacs" and I hit enter.
> (don't mind the 'e' in "egdb" it is the name of binary for recent GDB on
> OpenBSD)

And "emacs" in the above "M-x gdb" command is a shell script that
starts Emacs via dbus-launch?  If not, i.e. if "emacs" is the Emacs
binary itself, then how is dbus-launch involved in this?

Re: Emacs without threads

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: Michael Albinus <michael.albinus@gmx.de>,  emacs-devel@gnu.org
>> Date: Fri, 22 Dec 2023 14:55:32 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Manuel, would you please describe in detail how you debug such an
>> > Emacs?  That is, how you start GDB in gdb-mi, and how you "connect"
>> > GDB to the Emacs session launched as above?
>> 
>> Nothing special here.  I just do 'M-x gdb' from the Emacs src directory
>> so it automatically propose to lauch "egdb -i=mi emacs" and I hit enter.
>> (don't mind the 'e' in "egdb" it is the name of binary for recent GDB on
>> OpenBSD)
>
> And "emacs" in the above "M-x gdb" command is a shell script that
> starts Emacs via dbus-launch?  If not, i.e. if "emacs" is the Emacs
> binary itself, then how is dbus-launch involved in this?

No it is not the sub emacs (into GDB) that calls dbus-launch, it's the
top level Emacs:

          - my .xsession launches "exec dbus-launch --sh-syntax
            --exit-with-x11 emacs"
            
          - Now I am in Emacs, I go to Emacs src directory and I do 'M-x
            gdb'

          - This gdb session launches another sub emacs to be debugged
-- 
Manuel Giraud

Re: Emacs without threads

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Manuel, would you please describe in detail how you debug such an
>> > Emacs?  That is, how you start GDB in gdb-mi, and how you "connect"
>> > GDB to the Emacs session launched as above?
>>
>> Nothing special here.  I just do 'M-x gdb' from the Emacs src directory
>> so it automatically propose to lauch "egdb -i=mi emacs" and I hit enter.
>> (don't mind the 'e' in "egdb" it is the name of binary for recent GDB on
>> OpenBSD)
>
> And "emacs" in the above "M-x gdb" command is a shell script that
> starts Emacs via dbus-launch?  If not, i.e. if "emacs" is the Emacs
> binary itself, then how is dbus-launch involved in this?

dbus-launch starts another session bus, which is different from the
default one:

--8<---------------cut here---------------start------------->8---
# env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
# dbus-launch env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-t1LP7XjmxF,guid=9672c32358416ef3dfccdb4465859e93
--8<---------------cut here---------------end--------------->8---

Everything which is started inside the dbus-launch umbrella uses this
private bus, and not the default one. So it could be already a problem,
when a process tries to communicate with another process, and these
processes are started from inside and from outside the umbrella,
respectively. No second dbus-launch is needed.

Same for two process under different dbus-launch umbrellas.

Best regards, Michael.

Re: Emacs without threads

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: michael.albinus@gmx.de,  emacs-devel@gnu.org
> Date: Fri, 22 Dec 2023 15:44:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And "emacs" in the above "M-x gdb" command is a shell script that
> > starts Emacs via dbus-launch?  If not, i.e. if "emacs" is the Emacs
> > binary itself, then how is dbus-launch involved in this?
> 
> No it is not the sub emacs (into GDB) that calls dbus-launch, it's the
> top level Emacs:
> 
>           - my .xsession launches "exec dbus-launch --sh-syntax
>             --exit-with-x11 emacs"
>             
>           - Now I am in Emacs, I go to Emacs src directory and I do 'M-x
>             gdb'
> 
>           - This gdb session launches another sub emacs to be debugged

So only the Emacs which runs "M-x gdb" us launched from dbus-launch,
and the Emacs being debugged is run directly by GDB?  Then I don't
understand why you see any threads during debugging: GDB only shows
threads of the program being debugged.