SIGABRT in `stream-of-directory-files'

SIGABRT in `stream-of-directory-files'

[Michael Heerdegen]

Hello,

sorry if I'm missing something obvious.

When I traverse a stream created with `stream-of-directory-files', and
that stream recursively traverses a huge directory hierarchy, like in

#+begin_src emacs-lisp
(seq-doseq (_file (stream-of-directory-files
                   "/home/micha" t nil t nil
                   (lambda (file) (and (file-readable-p file) (file-regular-p file)))))
  nil)
#+end_src

emacs crashes with SIGABRT (after quite some time).

Is it possible that doing something like this hits some internal limit?
My half-baked trials to debug with gdb were not very enlightening:

| (gdb) run
| Starting program: /home/micha/software/emacs/src/emacs 
| During startup program terminated with signal SIGABRT, Aborted.
| (gdb) xbacktrace
| You can't do that without a process to debug.
| (gdb) bt
| No stack.

Hints appreciated.


Thanks,

Michael.

Re: SIGABRT in `stream-of-directory-files'

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Mon, 26 Feb 2018 13:09:06 +0100
> 
> When I traverse a stream created with `stream-of-directory-files', and
> that stream recursively traverses a huge directory hierarchy, like in
> 
> #+begin_src emacs-lisp
> (seq-doseq (_file (stream-of-directory-files
>                    "/home/micha" t nil t nil
>                    (lambda (file) (and (file-readable-p file) (file-regular-p file)))))
>   nil)
> #+end_src
> 
> emacs crashes with SIGABRT (after quite some time).
> 
> Is it possible that doing something like this hits some internal limit?
> My half-baked trials to debug with gdb were not very enlightening:
> 
> | (gdb) run
> | Starting program: /home/micha/software/emacs/src/emacs 
> | During startup program terminated with signal SIGABRT, Aborted.

Is your Emacs stripped or something?  Why doesn't GDB get control when
Emacs hits SIGABRT?

I also don't understand the "run" thing -- this will start Emacs
"normally", loading your init files etc., it won't run the above
code.  Can you start by showing how you start Emacs to run the above
code, without the debugger?

> | (gdb) xbacktrace
> | You can't do that without a process to debug.
> | (gdb) bt
> | No stack.

Yes, if Emacs terminated, those commands will not work, because they
need a live process.

Re: SIGABRT in `stream-of-directory-files'

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Is your Emacs stripped or something?  Why doesn't GDB get control when
> Emacs hits SIGABRT?

That's exactly my question ;-)

Oh, I had forgotten to compile Emacs with debugging info.  I've now
rebuild Emacs from scratch using

| > CFLAGS='-O0 -g3' ./configure

but it didn't make a difference.  I also tried to build with

| > CFLAGS='-O0 -g3' ./configure --enable-check-lisp-object-type\
|   --enable-checking=all

but that would take the whole rest of the day, at least - it's horribly
slow.

> I also don't understand the "run" thing -- this will start Emacs
> "normally", loading your init files etc., it won't run the above
> code.

Yes - this was just for testing, I have evaluated the problematic code
manually in that Emacs session.

> Can you start by showing how you start Emacs to run the above code,
> without the debugger?

I've just created bug#30626 including a recipe.


Thanks,

Michael.

Re: SIGABRT in `stream-of-directory-files'

[Andreas Schwab]

On Feb 27 2018, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Is your Emacs stripped or something?  Why doesn't GDB get control when
>> Emacs hits SIGABRT?
>
> That's exactly my question ;-)

Do you have enabled some settings that disallow tracing processes?  Does
strace work?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: SIGABRT in `stream-of-directory-files'

[Michael Heerdegen]

Andreas Schwab <schwab@suse.de> writes:

> Do you have enabled some settings that disallow tracing processes?

Not that I knew, no.

> Does strace work?

Yes, strace works well.


Here is an example session from xterm - am I doing something wrong?

micha> cd software/emacs/src
src> gdb ./emacs
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 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-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/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./emacs...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0
TERM = xterm-256color
Breakpoint 1 at 0x55980d: file emacs.c, line 364.
Temporary breakpoint 2 at 0x57de7e: file sysdep.c, line 1077.
(gdb) run
Starting program: /home/micha/software/emacs/src/emacs 
Fatal error 11: Segmentation fault
Backtrace:
/home/micha/software/emacs/src/emacs[0x57f469]
/home/micha/software/emacs/src/emacs[0x5598a1]
/home/micha/software/emacs/src/emacs[0x57ec89]
/home/micha/software/emacs/src/emacs[0x57ec5a]
/home/micha/software/emacs/src/emacs[0x57ecc4]
/home/micha/software/emacs/src/emacs[0x57ee80]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12180)[0x7ffff12ca180]
/home/micha/software/emacs/src/emacs[0x555543]
/home/micha/software/emacs/src/emacs[0x555561]
/home/micha/software/emacs/src/emacs[0x61618f]
/home/micha/software/emacs/src/emacs[0x61621b]
/home/micha/software/emacs/src/emacs[0x61644b]
/home/micha/software/emacs/src/emacs[0x6034d0]
/home/micha/software/emacs/src/emacs[0x5ff74f]
/home/micha/software/emacs/src/emacs[0x603025]
/home/micha/software/emacs/src/emacs[0x5ff74f]
/home/micha/software/emacs/src/emacs[0x603025]
/home/micha/software/emacs/src/emacs[0x602aca]
/home/micha/software/emacs/src/emacs[0x604c80]
/home/micha/software/emacs/src/emacs[0x604890]
/home/micha/software/emacs/src/emacs[0x64cc41]
/home/micha/software/emacs/src/emacs[0x60529c]
/home/micha/software/emacs/src/emacs[0x6048d4]
/home/micha/software/emacs/src/emacs[0x64cc41]
/home/micha/software/emacs/src/emacs[0x60529c]
/home/micha/software/emacs/src/emacs[0x6048d4]
/home/micha/software/emacs/src/emacs[0x5fc8f7]
/home/micha/software/emacs/src/emacs[0x604b87]
/home/micha/software/emacs/src/emacs[0x604890]
/home/micha/software/emacs/src/emacs[0x603cdb]
/home/micha/software/emacs/src/emacs[0x5fcd7d]
/home/micha/software/emacs/src/emacs[0x604cac]
/home/micha/software/emacs/src/emacs[0x604890]
/home/micha/software/emacs/src/emacs[0x64cc41]
/home/micha/software/emacs/src/emacs[0x60529c]
/home/micha/software/emacs/src/emacs[0x6048d4]
/home/micha/software/emacs/src/emacs[0x6042a0]
/home/micha/software/emacs/src/emacs[0x55ec02]
/home/micha/software/emacs/src/emacs[0x6013b2]
/home/micha/software/emacs/src/emacs[0x55e151]
/home/micha/software/emacs/src/emacs[0x600c94]
...
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt
No stack.
(gdb) xbacktrace
You can't do that without a process to debug.
(gdb) 


Thanks,

Michael.

Re: SIGABRT in `stream-of-directory-files'

[Andreas Schwab]

On Feb 27 2018, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> (gdb) run
> Starting program: /home/micha/software/emacs/src/emacs 
> Fatal error 11: Segmentation fault

Does it work if you do "set startup-with-shell off" before run?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: SIGABRT in `stream-of-directory-files'

[Michael Heerdegen]

Andreas Schwab <schwab@suse.de> writes:

> Does it work if you do "set startup-with-shell off" before run?

Wow - yes!

What does that mean?  Could the problem be that my default shell is the
(non-standard) elvish shell?  I didn't know that gdb uses a shell to
start the program.


Thanks,

Michael.

Re: SIGABRT in `stream-of-directory-files'

[Andreas Schwab]

On Feb 27 2018, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Andreas Schwab <schwab@suse.de> writes:
>
>> Does it work if you do "set startup-with-shell off" before run?
>
> Wow - yes!
>
> What does that mean?

Your shell is doing something bad.

Try "strace -c -eexecve -f $SHELL -c /bin/true".  There should be
exactly two execve calls.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: SIGABRT in `stream-of-directory-files'

[Michael Heerdegen]

Andreas Schwab <schwab@suse.de> writes:

> Your shell is doing something bad.
>
> Try "strace -c -eexecve -f $SHELL -c /bin/true".  There should be
> exactly two execve calls.

The output is

| bash-4.4:micha:~$ strace -c -eexecve -f /usr/bin/elvish -c /bin/true
| strace: Process 24467 attached
| strace: Process 24468 attached
| strace: Process 24469 attached
| strace: Process 24470 attached
| strace: Process 24471 attached
| strace: Process 24472 attached
| strace: Process 24473 attached
| strace: Process 24474 attached
| strace: Process 24475 attached
| strace: Process 24476 attached
| [pid 24469] ????( <detached ...>
| % time     seconds  usecs/call     calls    errors syscall
| ------ ----------- ----------- --------- --------- ----------------
|   0.00    0.000000           0         2           execve
| ------ ----------- ----------- --------- --------- ----------------
| 100.00    0.000000                     2           total


Michael.

Re: SIGABRT in `stream-of-directory-files'

[Andreas Schwab]

On Feb 27 2018, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> | bash-4.4:micha:~$ strace -c -eexecve -f /usr/bin/elvish -c /bin/true
> | strace: Process 24467 attached
> | strace: Process 24468 attached
> | strace: Process 24469 attached
> | strace: Process 24470 attached
> | strace: Process 24471 attached
> | strace: Process 24472 attached
> | strace: Process 24473 attached
> | strace: Process 24474 attached
> | strace: Process 24475 attached
> | strace: Process 24476 attached

That's bad already.  Your shell should not spawn any processes in -c
mode.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."