GNU bug report logs - #21528
25.0.50; gud tries to guess what file we're debugging, which can take a long time

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21528 in the body.
You can then email your comments to 21528 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50;
 gud tries to guess what file we're debugging, which can take a long
 time
Date: Sun, 20 Sep 2015 19:50:21 -0700

Hi. Currently when the user invokes any gud-based mode ('M-x pdb' for
instance) the minibuffer pops up with a suggested command. This command
tries to guess what you're trying to debug based on some pretty
arbitrary heuristics. This is in 'gud-query-cmdline' in gud.el

These heuristics include looking at each file in the current directory
to find the most recent executable file. In my experience this almost
never is what I want. If I'm doing remote debugging with tramp and the
current directory has many files in it, then emacs can sit there for a
very long time before opening the minibuffer, while it looks at all the
files in the remote directory. I think this delay changes this behavior
from not-useful to harmful, and I think it should be removed. Thoughts?

Message #8 received at 21528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 21528 <at> debbugs.gnu.org
Subject: Re: bug#21528: 25.0.50;
 gud tries to guess what file we're debugging, which can take a
 long	time
Date: Mon, 21 Sep 2015 10:04:28 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Sun, 20 Sep 2015 19:50:21 -0700
> 
> Hi. Currently when the user invokes any gud-based mode ('M-x pdb' for
> instance) the minibuffer pops up with a suggested command. This command
> tries to guess what you're trying to debug based on some pretty
> arbitrary heuristics. This is in 'gud-query-cmdline' in gud.el
> 
> These heuristics include looking at each file in the current directory
> to find the most recent executable file. In my experience this almost
> never is what I want. If I'm doing remote debugging with tramp and the
> current directory has many files in it, then emacs can sit there for a
> very long time before opening the minibuffer, while it looks at all the
> files in the remote directory. I think this delay changes this behavior
> from not-useful to harmful, and I think it should be removed. Thoughts?

Removing it altogether, based on your personal and very specific use
case, would be too drastic, IMO.  Can you propose some less drastic
measure?  If nothing smarter could be done automatically, a defcustom
to control this should be a stopgap, I think.

And while at that: the search for executables could bypass certain
files, like shell scripts, for example.

Message #11 received at 21528 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21528 <at> debbugs.gnu.org
Subject: Re: bug#21528: 25.0.50;
 gud tries to guess what file we're debugging, which can take a long
 time
Date: Mon, 21 Sep 2015 00:39:13 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> If I'm doing remote debugging with tramp and the current directory
>> has many files in it, then emacs can sit there for a very long time
>> before opening the minibuffer, while it looks at all the files in the
>> remote directory. I think this delay changes this behavior from
>> not-useful to harmful, and I think it should be removed. Thoughts?
>
> Removing it altogether, based on your personal and very specific use
> case, would be too drastic, IMO.

Completely agree that my opinion should play only a small role. Let me
push that argument a tiny bit more, and I'll leave it alone.

The current heuristic assumes that both

1. The program we're debugging lives in the current directory
2. The program is executable

Both of those could be true, but probably not all that often. Especially
the "program is executable part" easily fails for interpreted languages.



OK. Now for better solutions. The current logic is:

  (dolist (f (directory-files default-directory) file)
    (if (and (file-executable-p f)
             (not (file-directory-p f))
             (or (not file)
                 (file-newer-than-file-p f file)))
        (setq file f)))

With tramp each of the file system calls above are a separate tramp
call, and the overhead becomes very significant. I don't know enough
about tramp to know if consolidating these would be possible.

The heuristic could be more useful be filtering on file extensions. So
for instance looking at only .py files for pdb could be good, but this
could be wrong, and wouldn't really speed up the above code.

Finally as currently written, perldb doesn't run that code at all, but
simply tries to debug the script in the current buffer. This could easly
apply to python too, if we decide.

Message #14 received at 21528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 21528 <at> debbugs.gnu.org
Subject: Re: bug#21528: 25.0.50;
 gud tries to guess what file we're debugging, which can take a long
 time
Date: Mon, 21 Sep 2015 10:59:16 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: 21528 <at> debbugs.gnu.org
> Date: Mon, 21 Sep 2015 00:39:13 -0700
> 
> The current heuristic assumes that both
> 
> 1. The program we're debugging lives in the current directory
> 2. The program is executable
> 
> Both of those could be true, but probably not all that often. Especially
> the "program is executable part" easily fails for interpreted languages.

How about bypassing this search in 2 situations:

 . the debuggee is on a remote system
 . the debugger being invoked is for an interpreted language

Would that be "good enough"?

Message #17 received at 21528 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21528 <at> debbugs.gnu.org
Subject: Re: bug#21528: 25.0.50;
 gud tries to guess what file we're debugging, which can take a long
 time
Date: Mon, 21 Sep 2015 02:03:53 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> How about bypassing this search in 2 situations:
>
>  . the debuggee is on a remote system
>  . the debugger being invoked is for an interpreted language
>
> Would that be "good enough"?

That would be fine by me. What do you want to do with perldb? Currently
it always bypasses this search.

Message #20 received at 21528 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 21528 <at> debbugs.gnu.org
Subject: Re: bug#21528: 25.0.50;
 gud tries to guess what file we're debugging, which can take a long
 time
Date: Mon, 21 Sep 2015 12:43:11 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: 21528 <at> debbugs.gnu.org
> Date: Mon, 21 Sep 2015 02:03:53 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > How about bypassing this search in 2 situations:
> >
> >  . the debuggee is on a remote system
> >  . the debugger being invoked is for an interpreted language
> >
> > Would that be "good enough"?
> 
> That would be fine by me. What do you want to do with perldb? Currently
> it always bypasses this search.

Perldb is of the "interpreted language" type, isn't it?

Message #23 received at 21528 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21528 <at> debbugs.gnu.org
Subject: Re: bug#21528: 25.0.50;
 gud tries to guess what file we're debugging, which can take a long
 time
Date: Mon, 21 Sep 2015 11:24:50 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > How about bypassing this search in 2 situations:
>> >
>> >  . the debuggee is on a remote system
>> >  . the debugger being invoked is for an interpreted language
>> >
>> > Would that be "good enough"?
>> 
>> That would be fine by me. What do you want to do with perldb? Currently
>> it always bypasses this search.
>
> Perldb is of the "interpreted language" type, isn't it?

Yep. Just making sure that you're proposing touching that too. Works for
me. Thanks.

Message #26 received at 21528 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21528 <at> debbugs.gnu.org, Dima Kogan <dima <at> secretsauce.net>
Subject: Re: bug#21528: 25.0.50; gud tries to guess what file we're
 debugging, which can take a long time
Date: Mon, 24 Jan 2022 14:56:59 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Both of those could be true, but probably not all that often. Especially
>> the "program is executable part" easily fails for interpreted languages.
>
> How about bypassing this search in 2 situations:
>
>  . the debuggee is on a remote system
>  . the debugger being invoked is for an interpreted language
>
> Would that be "good enough"?

I don't think it's all that useful to separate interpreted vs compiled
here -- it'll be slow (or not) in any case (and interpreted files are
normally executable).

So I've just made it not do the loop if it's on a remote system, and
there's a lot of files there in Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.