Is this a bug?

[George R Goffe]

Hi,

I apologize for bothering you with this question.

I have several directories on a system with > 300k files. When I use filename completion bash freezes for over a minute depending on the number of files. I'm pretty sure that bash has to read the directory to do the completion but the read appears to be uninterruptible. Is this a bug?

Again, I apologize for bothering you with this.

Best regards,

George...

[Dmitry Goncharov]

On Thu, Aug 6, 2020 at 1:54 PM George R Goffe <grg...@yahoo.com> wrote:
> I have several directories on a system with > 300k files. When I use filename completion bash freezes for over a minute depending on the number of files. I'm pretty sure that bash has to read the directory to do the completion but the read appears to be uninterruptible. Is this a bug?

Why don't you run strace (or truss or whatever you have on your
system) and see which syscall bash is blocked in?

regards, Dmitry

[Chet Ramey]

On 8/6/20 1:53 PM, George R Goffe wrote:
> Hi,
>
> I apologize for bothering you with this question.
>

> I have several directories on a system with > 300k files. When I use filename completion bash freezes for over a minute depending on the number of files. I'm pretty sure that bash has to read the directory to do the completion but the read appears to be uninterruptible. Is this a bug?

Can you tell what system call bash is executing? Some file systems make
the system call underlying readdir() uninterruptible.

In general, the readline filename completion function that calls readdir
only reads a single directory entry at a time, and returns it to a caller.
If the SIGINT causes readdir to return NULL, the function returns normally.
If readdir returns a valid entry, the caller (e.g., rl_completion_matches)
checks for receipt of a signal. That should be enough to terminate the
directory read.

> Again, I apologize for bothering you with this.

No bother.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU ch...@case.edu http://tiswww.cwru.edu/~chet/

[Valentin Bajrami]

Are you trying to run autocompletion on an nfs mount? Are you using ''ls''
to autocomplete and if so did you run \ls /path/to/dir .. ?

Maybe worth to mention the bash version you are using.


Op do 6 aug. 2020 19:53 schreef George R Goffe <grg...@yahoo.com>:

> Hi,
>
> I apologize for bothering you with this question.
>
> I have several directories on a system with > 300k files. When I use
> filename completion bash freezes for over a minute depending on the number
> of files. I'm pretty sure that bash has to read the directory to do the
> completion but the read appears to be uninterruptible. Is this a bug?
>

> Again, I apologize for bothering you with this.
>

> Best regards,
>
> George...
>
>

[George R Goffe]

Chet,


Please accept my apology for not responding to your email sooner.

I have the bash source from the(?) repository. I followed Dimitris suggestion and found bash hung in a system call named "pselect". I did a grep on the source and found the only two ".c" files using "pselect":

Does this help?

Best regards and thanks for your patience.

George...


lib/readline/input.c:#if defined (HAVE_PSELECT)
lib/readline/input.c:#if defined (HAVE_PSELECT)
lib/readline/input.c:#if defined (HAVE_PSELECT)
lib/readline/input.c:      result = pselect (fileno (stream) + 1, &readfds, NULL, NULL, NULL, &_rl_orig_sigset);
lib/readline/input.c:      result = pselect (fileno (stream) + 1, &readfds, NULL, NULL, NULL, &empty_set);
lib/sh/ufuncs.c:#if defined (HAVE_TIMEVAL) && (defined (HAVE_SELECT) || defined (HAVE_PSELECT))
lib/sh/ufuncs.c:#if defined (HAVE_PSELECT)
lib/sh/ufuncs.c:#if defined (HAVE_PSELECT)
lib/sh/ufuncs.c:#endif /* !HAVE_PSELECT */
lib/sh/ufuncs.c:#if defined (HAVE_PSELECT)
lib/sh/ufuncs.c:      r = pselect(0, (fd_set *)0, (fd_set *)0, (fd_set *)0, &ts, &blocked_sigs);Chet,

On Thursday, August 6, 2020, 1:10:42 PM PDT, Chet Ramey <chet....@case.edu> wrote:





On 8/6/20 1:53 PM, George R Goffe wrote:

> Hi,
>
> I apologize for bothering you with this question.
>
> I have several directories on a system with > 300k files. When I use filename completion bash freezes for over a minute depending on the number of files. I'm pretty sure that bash has to read the directory to do the completion but the read appears to be uninterruptible. Is this a bug?

Can you tell what system call bash is executing? Some file systems make
the system call underlying readdir() uninterruptible.

In general, the readline filename completion function that calls readdir
only reads a single directory entry at a time, and returns it to a caller.
If the SIGINT causes readdir to return NULL, the function returns normally.
If readdir returns a valid entry, the caller (e.g., rl_completion_matches)
checks for receipt of a signal. That should be enough to terminate the
directory read.

> Again, I apologize for bothering you with this.

[Chet Ramey]

On 8/18/20 5:14 PM, George R Goffe wrote:
> Chet,
>
>
> Please accept my apology for not responding to your email sooner.
>
> I have the bash source from the(?) repository. I followed Dimitris suggestion and found bash hung in a system call named "pselect". I did a grep on the source and found the only two ".c" files using "pselect":

If it's in pselect, it's waiting for input. It's probably not performing
completion at all. It may have read the directory, found no common prefix
for the files it found, `rang' the visible bell, and gone back to waiting
to read the next input character.

[George R Goffe]

Chet,

Thanks for your response.

I'm running konsoles (KDE). I have tried complettion but don't see any evidence of bell ringing. Not even a flash.

Do you think that bash have a problem with konsole? Maybe it's a konsole bug?


I'll look at konsole docs for anything that speaks of "alarm bells", visual or otherwise and report back here. Ok?

Regards,

George...

[Dmitry Goncharov]

On Tue, Aug 18, 2020 at 7:57 PM George R Goffe <grg...@yahoo.com> wrote:
>
> Chet,
>
> Thanks for your response.
>
> I'm running konsoles (KDE). I have tried complettion but don't see any evidence of bell ringing. Not even a flash.
>
> Do you think that bash have a problem with konsole? Maybe it's a konsole bug?
>
>
> I'll look at konsole docs for anything that speaks of "alarm bells", visual or otherwise and report back here. Ok?

You can use pstack to see the call stack.

regards, Dmitry

[George R Goffe]

Chet,

I've been thinking about what you've said below... that bash is waiting for input. If this were the case, ctrl-c would return to the bash prompt immediately. Yes? What I'm seeing is that with a partial filename entered followed by the tab key is hit which results in nothing due to an uninterriputible sleep. Ctrl-c does not stop the filename completion process.

Does this make any sense?

[Chet Ramey]

On 8/19/20 12:02 AM, George R Goffe wrote:
> Chet,
>

> I've been thinking about what you've said below... that bash is waiting for input. If this were the case, ctrl-c would return to the bash prompt immediately. Yes? What I'm seeing is that with a partial filename entered followed by the tab key is hit which results in nothing due to an uninterriputible sleep. Ctrl-c does not stop the filename completion process.
>
> Does this make any sense?

If that were the case, and it might be, the pselect is a red herring.
The filename completion process doesn't use pselect.

Chet

[George R Goffe]

Chet,

How can I help capture data about this problem?

When I run bash in one konsole and it hangs, I do an strace on that pid and the strace -xvfp <pid> always shows pselect. Eventually, the results come back but til then, the session is frozen.

I suppose I could run strace to a file on bash and make (or try) the failure appear. Your thoughts?

Regards,

George...


George...

[Chet Ramey]

On 8/19/20 1:14 PM, George R Goffe wrote:
> Chet,
>

> How can I help capture data about this problem?
>
> When I run bash in one konsole and it hangs, I do an strace on that pid and the strace -xvfp <pid> always shows pselect. Eventually, the results come back but til then, the session is frozen.

You can try running gdb on bash from another terminal, attaching to the
hanging bash process with `attach <pid>', and generating a backtrace from
gdb. That would at least give you the call stack.

Make sure to run the bash instance you're testing with `--noprofile --norc'
to get as vanilla an environment as possible.

[George R Goffe]

Chet,

I tried several times to create the problem. I think I succeeded. I did install the "debuginfo" files I could find but it looks like libnss_sss.so's debuginfo isn't built properly? It's supplied by sssd-client. I tried installing sssd-client-debuginfo but it is already installed. I don't remember doing that. Sigh... Somehow libnss_sss.so is referenced by bash? That's what gdb thinks.

Anyway, I tried causing the problem. ls -al zzz<tab-key> and then ctrl-c with seemingly no response. I'll have to try running gdb in another konsole so I can watch what happens when I <ctrl-c>... I'll do that now. Stand by.

...

I'm still not certain that I'm doing it right. When I entered ls -al zzz<tab key> bash froze. I went to the gdb konsole and typed in where but nothing happened. Tried several times. Tried ctrl-c on the gbb console. Got gdb's attention. Entered where. Here's the results:

Please let me know if this helps or if you need me to do something different.

Regards,

George...

gdb -p 233460
GNU gdb (GDB) Fedora 9.2-6.fc33
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
--Type <RET> for more, q to quit, c to continue without paging--c

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 233460
Reading symbols from /usr/bin/bash...
Reading symbols from /usr/lib/debug/usr/bin/bash-5.0.17-2.fc33.x86_64.debug...
Reading symbols from /usr/lib64/libtinfo.so.6...
Reading symbols from /usr/lib/debug/usr/lib64/libtinfo.so.6.2-6.2-3.20200222.fc33.x86_64.debug...
Reading symbols from /usr/lib64/libdl.so.2...
Reading symbols from /usr/lib/debug/usr/lib64/libdl-2.32.9000.so.debug...
Reading symbols from /usr/lib64/libc.so.6...
Reading symbols from /usr/lib/debug/usr/lib64/libc-2.32.9000.so.debug...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/usr/lib64/ld-2.32.9000.so.debug...
Reading symbols from /usr/lib64/libnss_sss.so.2...

Reading symbols from .gnu_debugdata for /usr/lib64/libnss_sss.so.2...
(No debugging symbols found in .gnu_debugdata for /usr/lib64/libnss_sss.so.2)

Reading symbols from /usr/lib64/libnss_files.so.2...
Reading symbols from /usr/lib/debug/usr/lib64/libnss_files-2.32.9000.so.debug...
0x00007f0c6a55528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffe53b570a0, writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>, timeout@entry=0x0, sigmask=0x7ffe53b57060, sigmask@entry=0x559c9c04a4e0 <_rl_orig_sigset>) at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,
(gdb)
(gdb)
(gdb) continue
Continuing.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
[Detaching after fork from child process 387754]



[Detaching after fork from child process 388057]

where
[Detaching after fork from child process 388297]
[Detaching after fork from child process 388339]

Program received signal SIGINT, Interrupt.
0x00007f0c6a55528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffe53b570a0,
    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,
    timeout@entry=0x0, sigmask=0x7ffe53b57060, sigmask@entry=0x559c9c04a4e0 <_rl_orig_sigset>)
    at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,
(gdb)
Continuing.

where
^C
Program received signal SIGINT, Interrupt.
0x00007f0c6a55528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffe53b570a0,
    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,
    timeout@entry=0x0, sigmask=0x7ffe53b57060, sigmask@entry=0x559c9c04a4e0 <_rl_orig_sigset>)
    at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,
(gdb) where
#0  0x00007f0c6a55528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffe53b570a0,
    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,
    timeout@entry=0x0, sigmask=0x7ffe53b57060, sigmask@entry=0x559c9c04a4e0 <_rl_orig_sigset>)
    at ../sysdeps/unix/sysv/linux/pselect.c:48
#1  0x0000559c9bfe78af in rl_getc (stream=0x7f0c6a621800 <_IO_2_1_stdin_>) at input.c:529
#2  0x0000559c9bfe6b7c in rl_read_key () at input.c:495
#3  0x0000559c9bfc7c4a in readline_internal_char () at readline.c:620
#4  0x0000559c9bfc87cd in readline_internal_charloop () at readline.c:706
#5  readline_internal () at readline.c:718
#6  readline (prompt=<optimized out>) at readline.c:424
#7  0x0000559c9bf30f1f in yy_readline_get () at ./parse.y:1487
#8  0x0000559c9bf32a29 in yy_getc () at ./parse.y:2345
--Type <RET> for more, q to quit, c to continue without paging--
#9  shell_getc (remove_quoted_newline=1) at ./parse.y:2345
#10 0x0000559c9bf3532a in read_token (command=<optimized out>) at ./parse.y:3252
#11 0x0000559c9bf38c52 in read_token (command=0) at ./parse.y:3202
#12 yylex () at ./parse.y:2761
#13 yyparse () at y.tab.c:1835
#14 0x0000559c9bf3c00b in parse_command () at eval.c:304
#15 0x0000559c9bf3c14d in read_command () at eval.c:348
#16 0x0000559c9bf3c415 in reader_loop () at eval.c:143
#17 0x0000559c9bf2e689 in main (argc=3, argv=0x7ffe53b58438, env=0x7ffe53b58458) at shell.c:815
(gdb)

[Chet Ramey]

On 8/19/20 4:55 PM, George R Goffe wrote:
> Chet,
>

> I tried several times to create the problem. I think I succeeded. I did install the "debuginfo" files I could find but it looks like libnss_sss.so's debuginfo isn't built properly? It's supplied by sssd-client. I tried installing sssd-client-debuginfo but it is already installed. I don't remember doing that. Sigh... Somehow libnss_sss.so is referenced by bash? That's what gdb thinks.

Yep, it needs it to get access to user and group data for things like tilde
expansion.

> Anyway, I tried causing the problem. ls -al zzz<tab-key> and then ctrl-c with seemingly no response. I'll have to try running gdb in another konsole so I can watch what happens when I <ctrl-c>... I'll do that now. Stand by.

The trace you sent shows readline waiting in pselect for user input, so it
must be after the directory read was interrupted.

The only thing I can suggest is to defer the attach in gdb until bash
appears frozen. That may not work, but it's better than what you got.

[Ángel]

On 2020-08-19 at 20:55 +0000, George R Goffe wrote:
> Chet,
>
> I tried several times to create the problem. I think I succeeded. I did install the "debuginfo" files I could find but it looks like libnss_sss.so's debuginfo isn't built properly? It's supplied by sssd-client. I tried installing sssd-client-debuginfo but it is already installed. I don't remember doing that. Sigh... Somehow libnss_sss.so is referenced by bash? That's what gdb thinks.
>

> Anyway, I tried causing the problem. ls -al zzz<tab-key> and then ctrl-c with seemingly no response. I'll have to try running gdb in another konsole so I can watch what happens when I <ctrl-c>... I'll do that now. Stand by.
>

> ....

>
> I'm still not certain that I'm doing it right. When I entered ls -al zzz<tab key> bash froze. I went to the gdb konsole and typed in where but nothing happened. Tried several times. Tried ctrl-c on the gbb console. Got gdb's attention. Entered where. Here's the results:
>
> Please let me know if this helps or if you need me to do something different.
>
> Regards,
>
> George...

Since you mention sssd, and it is apparently loaded by bash, are the
users and groups list from a remote server (such as LDAP)?

That could cause bash (or whatever program which tries to determine the
name of a user/group) to freeze if its cache expired and it needs to
refetch those from a remote server (e.g. it may be downloading the list
of all the users in the company).


Best regards

[George R Goffe]

Chet,

I'm really perplexed with this situation. I type in "ls -al 123456<tab>" with only 1 tab key. NO indication of what's happening. I hit enter and get a message that "ls: cannot access '123456': No such file or directory" I try the same command but with 2 tab keys... hit enter and get the same msg.

I tried the same with a partial filename that DOES exist in the directory. I can't seem to get the filename completion to ctrl-c out. gdb sees the ctrl-c but bash stays in the attempted filename completion. Enter doesn't work. Ctrl-c doesn't work. Ctrl-z doesn't work.

Shouldn't there be a message about no file found presented by bash? There appears to be NO indication that filename completion has failed to find a file.

I'm at a loss as to what to do at this point. What I would like to be able to ctrl-c out of filename completion.

Is this a konsole problem? I will try xterms.

What are your thoughts?

Are you able to create this situation on your system(s)?

Best regards,

George...


gdb -p 706812

GNU gdb (GDB) Fedora 9.2-6.fc33
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
--Type <RET> for more, q to quit, c to continue without paging--c

For help, type "help".
Type "apropos word" to search for commands related to "word".

Attaching to process 706812

Reading symbols from /usr/bin/bash...
Reading symbols from /usr/lib/debug/usr/bin/bash-5.0.17-2.fc33.x86_64.debug...
Reading symbols from /usr/lib64/libtinfo.so.6...
Reading symbols from /usr/lib/debug/usr/lib64/libtinfo.so.6.2-6.2-3.20200222.fc33.x86_64.debug...
Reading symbols from /usr/lib64/libdl.so.2...
Reading symbols from /usr/lib/debug/usr/lib64/libdl-2.32.9000.so.debug...
Reading symbols from /usr/lib64/libc.so.6...
Reading symbols from /usr/lib/debug/usr/lib64/libc-2.32.9000.so.debug...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/usr/lib64/ld-2.32.9000.so.debug...
Reading symbols from /usr/lib64/libnss_sss.so.2...

Reading symbols from /usr/lib/debug/usr/lib64/libnss_sss.so.2-2.3.1-4.fc33.x86_64.debug...

Reading symbols from /usr/lib64/libnss_files.so.2...
Reading symbols from /usr/lib/debug/usr/lib64/libnss_files-2.32.9000.so.debug...

0x00007f11222f528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffdafb3f020, writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>, timeout@entry=0x0, sigmask=0x7ffdafb3efe0, sigmask@entry=0x55f28c2904e0 <_rl_orig_sigset>) at ../sysdeps/unix/sysv/linux/pselect.c:48

48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,

(gdb) continue
Continuing.

(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.

0x00007f11222f528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffdafb3f020,

    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,

    timeout@entry=0x0, sigmask=0x7ffdafb3efe0, sigmask@entry=0x55f28c2904e0 <_rl_orig_sigset>)

    at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,

(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.

0x00007f11222f528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffdafb3f020,

    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,

    timeout@entry=0x0, sigmask=0x7ffdafb3efe0, sigmask@entry=0x55f28c2904e0 <_rl_orig_sigset>)

    at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,

(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.

0x00007f11222f528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffdafb3f020,

    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,

    timeout@entry=0x0, sigmask=0x7ffdafb3efe0, sigmask@entry=0x55f28c2904e0 <_rl_orig_sigset>)

    at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,

(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.

0x00007f11222f528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffdafb3f020,

    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,

    timeout@entry=0x0, sigmask=0x7ffdafb3efe0, sigmask@entry=0x55f28c2904e0 <_rl_orig_sigset>)

    at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,

(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.

0x00007f11222f528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffdafb3f020,

    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,

    timeout@entry=0x0, sigmask=0x7ffdafb3efe0, sigmask@entry=0x55f28c2904e0 <_rl_orig_sigset>)

    at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,

(gdb) continue
Continuing.
^[[A

Program received signal SIGINT, Interrupt.

0x00007f11222f528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffdafb3f020,

    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,

    timeout@entry=0x0, sigmask=0x7ffdafb3efe0, sigmask@entry=0x55f28c2904e0 <_rl_orig_sigset>)

    at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,

(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.

0x00007f11222f528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffdafb3f020,

    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,

    timeout@entry=0x0, sigmask=0x7ffdafb3efe0, sigmask@entry=0x55f28c2904e0 <_rl_orig_sigset>)

    at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,

(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.

0x00007f11222f528b in __pselect (nfds=1, readfds=readfds@entry=0x7ffdafb3f020,

    writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, timeout=<optimized out>,

    timeout@entry=0x0, sigmask=0x7ffdafb3efe0, sigmask@entry=0x55f28c2904e0 <_rl_orig_sigset>)

    at ../sysdeps/unix/sysv/linux/pselect.c:48
48        return SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds,
(gdb)

On Thursday, August 20, 2020, 7:29:38 AM PDT, Chet Ramey <chet....@case.edu> wrote:

On 8/19/20 4:55 PM, George R Goffe wrote:
> Chet,
>
> I tried several times to create the problem. I think I succeeded. I did install the "debuginfo" files I could find but it looks like libnss_sss.so's debuginfo isn't built properly? It's supplied by sssd-client. I tried installing sssd-client-debuginfo but it is already installed. I don't remember doing that. Sigh... Somehow libnss_sss.so is referenced by bash? That's what gdb thinks.

Yep, it needs it to get access to user and group data for things like tilde
expansion.

> Anyway, I tried causing the problem. ls -al zzz<tab-key> and then ctrl-c with seemingly no response. I'll have to try running gdb in another konsole so I can watch what happens when I <ctrl-c>... I'll do that now. Stand by.

[Dale R. Worley]

George R Goffe <grg...@yahoo.com> writes:
> Shouldn't there be a message about no file found presented by bash?
> There appears to be NO indication that filename completion has failed
> to find a file.

I'm not very experienced using filename completion, but my understanding
is that completion indicates "there is no file with this prefix" by
ringing the bell, and I assume that specifically means emitting a \007
character. bash depends on whatever "terminal program" it is running
under to give the user an indication that \007 has been emitted.

In the one system to hand, the terminal program is xterm, but it gives
no indication for \007. And my memory is that over the years, support
for "the bell" has been poor and inconsistent.

Now maybe there's a way to configure bash to indicate
no-completion-choices in a different way.

> I'm at a loss as to what to do at this point. What I would like to be
> able to ctrl-c out of filename completion.

Sorry, I've re-read your messages and I can't tell what your situation
really is. Can you describe a test case where you can't ctrl-c out of
filename cmopletion, including the facts about the files involved, the
exact sequence of what you type, and the behavior you observer?

Dale

[Chet Ramey]

On 8/22/20 5:25 PM, George R Goffe wrote:
>
> Chet,
>

> I'm really perplexed with this situation. I type in "ls -al 123456<tab>" with only 1 tab key. NO indication of what's happening. I hit enter and get a message that "ls: cannot access '123456': No such file or directory" I try the same command but with 2 tab keys... hit enter and get the same msg.

Readline defaults to a visual bell, using the terminal's `vb' capability.
You can set the readline `bell-style' variable to `audible' to change that.
If you do, make sure your terminal emulator does something reasonable with
the ^G character.

> I tried the same with a partial filename that DOES exist in the directory. I can't seem to get the filename completion to ctrl-c out. gdb sees the ctrl-c but bash stays in the attempted filename completion. Enter doesn't work. Ctrl-c doesn't work. Ctrl-z doesn't work.

I just can't reproduce this. (Though there's no reason to expect ^Z to have
any effect, since we're not running a separate job here.)

>
> Shouldn't there be a message about no file found presented by bash? There appears to be NO indication that filename completion has failed to find a file.

Why would a message be appropriate here? It seems to me that the visible or
audible bell is the right indicator.

[George R Goffe]

Chet,

I'm not seeing any visual "bells". The audio part of this computer is broken... NO sound...

George...

[Chet Ramey]

On 8/24/20 4:15 PM, George R Goffe wrote:
> Chet,
>

> I'm not seeing any visual "bells". The audio part of this computer is broken... NO sound...

I'm not sure what I can do about that. If the visual bell doesn't work and
the sound is broken, you're not going to get much of an indication no
matter what you do.

Chet

[George R Goffe]

Chet,

I appreciate your help with this.

Do "we" know that bash IS trying to generate an alarm?

I have gone searching for doc on how to set alarm behavior in konsole. I found none. I have written a bug about his at the KDE bug site. ARGH! They have been singularly unresponsive when it comes to bug reports. We'll see.

Best regards,

George...

[Lawrence Velázquez]

> On Aug 25, 2020, at 3:47 PM, George R Goffe <grg...@yahoo.com> wrote:
>
> I have gone searching for doc on how to set alarm behavior in
> konsole. I found none. I have written a bug about his at the KDE
> bug site. ARGH! They have been singularly unresponsive when it comes
> to bug reports. We'll see.

This suggests that Konsole does not support a typical visual bell,
although I can't vouch for its accuracy or continued relevance (it's
over three years old).

https://unix.stackexchange.com/q/371019

vq

[George R Goffe]

Chet,

I found how how to make konsole do a visual alarm and then tried my failure scenario.

I cd'd to a "big" directory and then entered "ls -al abc<tab key>", waited a few seconds then did a ctrl-c. As usual, a freeze happened. I waited a while and then saw the visual alarm followed by the ctr-c.

Somewhere between the request for filename completion and the recognition of ctrl-c appears to be where the "bug" is located.

I could try running strace during all of this. Would it help?

Best regards,

George.

[Dale R. Worley]

I was going to suggest this analysis, but George has gotten ahead of me,
so let me collate the two:

My understanding is that the details of how different programs read
directories differs, and how different operating systems implement those
operations differs, and how different file systems under an operating
system implement them differs. But overall, reading large directories
can take a long time, and often the operations involved are not
interruptable. (At root, that is because this is an uncommon scenario
in Unix and people don't work to optimize it.)

So I was going to recommend this calibration: Go to the directory in
question and execute "time ls -1 >/dev/null". That gives you the
maximum amount of time it will take to read that directory, and that
should be an upper bound on how long it will take bash to finish
whatever completion operation it is doing.

George R Goffe <grg...@yahoo.com> writes:

> I found how how to make konsole do a visual alarm and then tried my
> failure scenario.
>
> I cd'd to a "big" directory and then entered "ls -al abc<tab key>",
> waited a few seconds then did a ctrl-c. As usual, a freeze happened. I
> waited a while and then saw the visual alarm followed by the ctr-c.

OK, so it looks like there is some long, uniterruptable operation
happening as part of filename completion. How does the length of that
freeze compare to "ls -1", as described above?

> Somewhere between the request for filename completion and the
> recognition of ctrl-c appears to be where the "bug" is located.
>
> I could try running strace during all of this. Would it help?

My guess is that could reveal some particularly slow operating system
call that is involved in implementing filename completion, but it
would not indicate a way to improve it.

Dale

[Chet Ramey]

On 8/25/20 3:47 PM, George R Goffe wrote:
> Chet,
>

> I appreciate your help with this.
>
> Do "we" know that bash IS trying to generate an alarm?

Yes, we are fairly sure that bash is trying to `ring' the bell. When I
run

bind 'set bell-style audible'

and type the common prefix of a set of filenames in the current directory,
then hit TAB, bash rings the bell.

[Chet Ramey]

On 8/25/20 8:21 PM, George R Goffe wrote:

> I could try running strace during all of this. Would it help?

It might indicate the order in which things are happening.