Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation fault with 3.0 on RHEL 7.4 #5550

Closed
dniku opened this issue Jan 18, 2019 · 35 comments
Closed

Segmentation fault with 3.0 on RHEL 7.4 #5550

dniku opened this issue Jan 18, 2019 · 35 comments
Labels
bug Something that's not working as intended
Milestone

Comments

@dniku
Copy link

dniku commented Jan 18, 2019

$ fish --version
fish, version 3.0.0
$ uname -a
Linux airulsf01 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
$ echo $TERM
xterm-256color
$ sh -c 'env HOME=$(mktemp -d) fish'
Segmentation fault

Segfault is also produced just by running fish.

I don't have an easy way to test the issue with 2.7.1 as I am running on a server without root, where I installed fish using nix, itself installed via proot in ~/.nix.

This gist contains outputs of the following commands:

  • nix log nixpkgs.fish
  • fish -d 5
  • gdb fish
  • strace fish

Note that the output of gdb fish is most likely unhelpful as it seems that fish detects that it is launched in a non-interactive environment (probably due to gdb) and does something weird.

Also note that I have also tried to install fish on the same machine using Linuxbrew, and it also failed with a segfault.

@faho
Copy link
Member

faho commented Jan 18, 2019

Specifically, this crashes on fish installed on RHEL 7 via nix.

Can you try building it manually to rule out any nix changes (I know there are a few), or at least try a log from one of those builds to remove all the nix paths?

There's a few things here that look weird, one is that the last message of fish -d 5 is one about doing a universal variable sync, another is the "access: Bad address" (that's an EFAULT), which is supposed to mean:

 EFAULT pathname points outside your accessible address space.

(http://man7.org/linux/man-pages/man2/access.2.html)

Which could be down to some kind of sandboxing or some such.

@ridiculousfish's knowledge would be appreciated here.

@faho faho added bug Something that's not working as intended needs more info labels Jan 18, 2019
@dniku
Copy link
Author

dniku commented Jan 18, 2019

I am a novice nix user and unfortunately it will take me time to research how to populate all fish dependencies using nix. For now, I can only mention that on the same machine, I am also getting a segfault with fish build by Linuxbrew.

@faho
Copy link
Member

faho commented Jan 18, 2019

how to populate all fish dependencies using nix

What I mean is building without nix.

For now, I can only mention that on the same machine, I am also getting a segfault with fish build by Linuxbrew.

Can you upload the output for a fish built using linuxbrew instead of nix?

It's both that nix does special stuff, and that the nix output is quite noisy (these ugly /nix/store/buesfhaeiodfhiosjd paths).

Also you might get an actual backtrace here, which would be great.

@dniku
Copy link
Author

dniku commented Jan 18, 2019

What I mean is building without nix.

I still need to get the curses dependency on that machine somehow (it is not currently installed), and the easiest way to do that seems to be by using nix for that. Or are you suggesting that ncurses built by nix may be the culprit here?

@faho
Copy link
Member

faho commented Jan 18, 2019

Or are you suggesting that ncurses built by nix may be the culprit here?

No.

What I'm suggesting is simply that I feel like running fish outside of nix would result in nicer output.

It's probably alright to get the dependencies via nix (I'm assuming you don't have root, because otherwise this'd be a simple sudo yum install ncurses-devel).

@kirelagin
Copy link

kirelagin commented Jan 19, 2019

Hey, I’d like to add my 2 cents. I would guess that the problem is in the weird combination of nix and proot. The output with exactly the same hash as in OP’s log files is available straight in the official nixpkgs cache, and I have no problems running it:

$ sudo nix copy --from https://cache.nixos.org/ /nix/store/rfvad85vjz26bcwb55fhaiq0k4mzh63f-fish-3.0.0
[3 copied (12.6 MiB), 2.1 MiB DL]

$ /nix/store/rfvad85vjz26bcwb55fhaiq0k4mzh63f-fish-3.0.0/bin/fish
Welcome to fish, the friendly interactive shell
kirelagin@deployer ~>

@ridiculousfish
Copy link
Member

This is a null dereference; gdb should be able to tell us where if we can catch it. But the access() failures are showing EFAULT which means it's probably there but I don't know why.

Can you please try repeating the gdb command with set follow-fork-mode parent instead?

@horta
Copy link

horta commented Jan 21, 2019

https://pastebin.com/raw/Sq0rPqjf

Fish installed via linuxbrew.

@horta
Copy link

horta commented Jan 21, 2019

Compiling from source, manually, also produces segmentation fault. During the compilation I get the following warnings:

/nfs/software/stegle/system/.linuxbrew/bin/ld: libfishlib.a(wutil.cpp.o): in function `safe_strerror(int)':
/homes/horta/code/fish-shell/src/wutil.cpp:334: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead
/nfs/software/stegle/system/.linuxbrew/bin/ld: /homes/horta/code/fish-shell/src/wutil.cpp:334: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead
[ 94%] Built target fish_key_reader
Scanning dependencies of target fish
[ 95%] Building CXX object CMakeFiles/fish.dir/src/fish.cpp.o
[ 95%] Linking CXX executable fish
/nfs/software/stegle/system/.linuxbrew/bin/ld: libfishlib.a(wutil.cpp.o): in function `safe_strerror(int)':
/homes/horta/code/fish-shell/src/wutil.cpp:334: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead
/nfs/software/stegle/system/.linuxbrew/bin/ld: /homes/horta/code/fish-shell/src/wutil.cpp:334: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead
[ 95%] Built target fish
Scanning dependencies of target pofiles_3
[ 96%] Generating fr.gmo
[ 96%] Built target pofiles_3
Scanning dependencies of target fish_indent
[ 97%] Building CXX object CMakeFiles/fish_indent.dir/src/fish_indent.cpp.o
[ 98%] Building CXX object CMakeFiles/fish_indent.dir/src/print_help.cpp.o
[100%] Linking CXX executable fish_indent
/nfs/software/stegle/system/.linuxbrew/bin/ld: libfishlib.a(wutil.cpp.o): in function `safe_strerror(int)':
/homes/horta/code/fish-shell/src/wutil.cpp:334: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead
/nfs/software/stegle/system/.linuxbrew/bin/ld: /homes/horta/code/fish-shell/src/wutil.cpp:334: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead

@floam
Copy link
Member

floam commented Jan 21, 2019

follow-fork-mode is something you want to set in gdb, not fish.

@dniku
Copy link
Author

dniku commented Jan 21, 2019

follow-fork-mode parent is the default setting in gdb, so @horta's log is still relevant.
(Also, I assume that the log from fish installed by Linuxbrew on my machine is no longer needed.)

@faho
Copy link
Member

faho commented Jan 21, 2019

During the compilation I get the following warnings:

Yeah, glibc deprecated some stuff without easy replacement. Not to worry.

Your log shows that it crashes in

0x000000000048aa4c in env_get_runtime_pathabi:cxx11 ()

Which has an access() and also a possible NULL dereference:

    const char *dir = getenv("XDG_RUNTIME_DIR");
    if (dir != NULL && access(dir, mode) == 0 && check_runtime_path(dir) == 0) {
        result = str2wcstring(dir);
    } else {
        const char *uname = getpwuid(geteuid())->pw_name;
        // /tmp/fish.user
        std::string tmpdir = "/tmp/fish.";
        tmpdir.append(uname);

So, I am assuming the following:

  • $XDG_RUNTIME_DIR is set but not accessible to fish, because of some sandboxy stuff (it could also be unset, which would still get to the crash, just without the EFAULT)

  • getpwuid() fails, so getting its pw_name field is a NULL dereference, so we get a crash

@horta
Copy link

horta commented Jan 21, 2019

I'm trying to use fish on a cluster, btw.

@horta
Copy link

horta commented Jan 21, 2019

Workaround when starting fish from bash:

# ~/.bashrc
export XDG_RUNTIME_DIR=/run/user/$(id -u)

@dniku
Copy link
Author

dniku commented Jan 21, 2019

@horta doesn't work for me.

$ echo $XDG_RUNTIME_DIR

$ XDG_RUNTIME_DIR=/run/user/$(id -u) fish
Segmentation fault

@horta
Copy link

horta commented Jan 21, 2019

Yeah, it still gives me segmentation fault randomly.

@ridiculousfish
Copy link
Member

@horta that's great, can you please try this in gdb:

$ gdb fish
...
Program received signal SIGSEGV, Segmentation fault.
0x000000000048aa4c in env_get_runtime_pathabi:cxx11 ()
(gdb) <---- START HERE

From within gdb, before quitting, it would be good to get a backtrace bt, a thread list via info threads, and a register dump via info registers

@horta
Copy link

horta commented Jan 22, 2019

[horta@hh-yoda-08-06 ~]$ gdb fish
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1
Copyright (C) 2013 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".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /nfs/software/stegle/system/.linuxbrew/Cellar/fish/3.0.0/bin/fish...(no debugging symbols found)...done.
(gdb) r
Starting program: /nfs/software/stegle/system/.linuxbrew/bin/fish 
warning: File "/nfs/software/stegle/system/.linuxbrew/Cellar/gcc/5.5.0_4/lib/libstdc++.so.6.0.21-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
To enable execution of this file add
	add-auto-load-safe-path /nfs/software/stegle/system/.linuxbrew/Cellar/gcc/5.5.0_4/lib/libstdc++.so.6.0.21-gdb.py
line to your configuration file "/homes/horta/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/homes/horta/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
warning: File "/nfs/software/stegle/system/.linuxbrew/Cellar/glibc/2.23/lib/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Detaching after fork from child process 25664.
Detaching after fork from child process 25665.
Detaching after fork from child process 25667.
Detaching after fork from child process 25668.
Welcome to fish, the friendly interactive shell
Detaching after fork from child process 25669.
Detaching after fork from child process 25670.
Detaching after fork from child process 25671.
Detaching after fork from child process 25672.
hh-yoda-08-06 ~>                                                                                                    (base) 
Program received signal SIGSEGV, Segmentation fault.
0x000000000048aa4c in env_get_runtime_path[abi:cxx11]() ()
(gdb) bt
#0  0x000000000048aa4c in env_get_runtime_path[abi:cxx11]() ()
#1  0x0000000000496f9b in universal_notifier_named_pipe_t::make_pipe(wchar_t const*) ()
#2  0x0000000000497085 in universal_notifier_t::new_notifier_for_strategy(universal_notifier_t::notifier_strategy_t, wchar_t const*) ()
#3  0x000000000049714f in universal_notifier_t::default_notifier() ()
#4  0x00000000004cba68 in input_common_readch(int) ()
#5  0x00000000004c4a87 in input_readch(bool) ()
#6  0x00000000004f019a in reader_readline(int) ()
#7  0x00000000004f31de in reader_read(int, io_chain_t const&) ()
#8  0x000000000043b06a in main ()
(gdb) info threads
  Id   Target Id         Frame 
* 1    process 25660 "fish" 0x000000000048aa4c in env_get_runtime_path[abi:cxx11]() ()
(gdb) info registers
rax            0x0	0
rbx            0x7fffffffc700	140737488340736
rcx            0x7369662f706d742f	8316290540852048943
rdx            0x0	0
rsi            0xffffffff	4294967295
rdi            0x0	0
rbp            0x7fffffffee89	0x7fffffffee89
rsp            0x7fffffffc690	0x7fffffffc690
r8             0x7fffffffc300	140737488339712
r9             0x7d5a30	8215088
r10            0x6c00656c69662074	7782331672395391092
r11            0x206	518
r12            0x835dd0	8609232
r13            0x7	7
r14            0x7	7
r15            0x7fffffffc800	140737488340992
rip            0x48aa4c	0x48aa4c <env_get_runtime_path[abi:cxx11]()+108>
eflags         0x10202	[ IF RF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0

faho added a commit to faho/fish-shell that referenced this issue Jan 22, 2019
@faho
Copy link
Member

faho commented Jan 22, 2019

@horta: That still looks like the crash I described.

Can you try b8efd89?

Also, can you clarify this for me:

Yeah, it still gives me segmentation fault randomly.

Does fish, without setting $XDG_RUNTIME_DIR in bash outside, crash randomly or always?

If it crashes always if you don't do that and only randomly if you do, then that's a change in behavior that probably means we'd got a few different crashes here.

Which could possibly all be down to the same root cause - us not expecting that getting passwd info fails.

The other crash then might not be "random" at all, but e.g. triggered by tilde-expansion (because that gets $HOME for the mentioned user).

(or it's down to /run/user/$(id -u) not always existing, or getting the user info failing sometimes with a network timeout....)

@horta
Copy link

horta commented Jan 22, 2019

I'm working on a cluster. In the login machine:

  • fish fails
  • XDG_RUNTIME_DIR="/run/user/$(id -u)" fish works

But once I log into a worker node:

  • fish fails
  • XDG_RUNTIME_DIR="/run/user/$(id -u)" fish fails

I will try that commit in a moment/

@faho
Copy link
Member

faho commented Jan 22, 2019

XDG_RUNTIME_DIR="/run/user/$(id -u)" fish fails

@horta: Is that directory accessible? If it isn't, that still means the else-branch is taken, which still leads to the crash.

@horta
Copy link

horta commented Jan 22, 2019

It works @faho , but with a "warning":

Master node:

  • tmp2/fish-shell/build/fish works with warning
  • XDG_RUNTIME_DIR="/run/user/$(id -u)" tmp2/fish-shell/build/fish works without warning

Worker node:

  • tmp2/fish-shell/build/fish works with warning
  • XDG_RUNTIME_DIR="/run/user/$(id -u)" tmp2/fish-shell/build/fish works with warning

Warning:

<E> fish: Runtime path not available.
<E> fish: Try deleting the directory /tmp/fish. and restarting fish.

@horta
Copy link

horta commented Jan 22, 2019

XDG_RUNTIME_DIR="/run/user/$(id -u)" fish fails

@horta: Is that directory accessible? If it isn't, that still means the else-branch is taken, which still leads to the crash.

That folder exists (and accessible) in the master node. That folder does not exist and cannot be created on a worker node.

@faho
Copy link
Member

faho commented Jan 22, 2019

That folder does not exist and cannot be created on a worker node.

Which means we won't get our runtime dir, which is why we correctly try other ways to get one.

Note that this is against the XDG Base Directory Specification ("The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700. "), so you can expect more things to fail.

It works @faho , but with a "warning":

And that warning is also correct. We can't get our runtime path, so we warn about it, because you are now running fish with reduced functionality. In particular universal variables won't actually be shared across instances.

Set $XDG_RUNTIME_DIR to a path that is accessible to that fish, or make it so getpwuid works and gives us an accessible $HOME.

@horta
Copy link

horta commented Jan 22, 2019

Thanks, I didnt know that. I will change my shell files accordingly...

@horta
Copy link

horta commented Jan 22, 2019

That is great. It works now with fish 3.0.0.

I don't manage the cluster but I manage a group of people that uses it, so I need to sometimes fix those issues. Here it is what I come up with for those interested:

if [ -z "$XDG_RUNTIME_DIR" ];
then
    export XDG_RUNTIME_DIR=/run/user/$(id -u)
fi

if ! touch $XDG_RUNTIME_DIR/.can_i_write 2>/dev/null;
then
    export XDG_RUNTIME_DIR=~/.run/user/$(id -u)
    mkdir -p $XDG_RUNTIME_DIR
    chmod 700 $XDG_RUNTIME_DIR
fi

@faho faho closed this as completed in 82b4d72 Jan 22, 2019
faho added a commit that referenced this issue Jan 22, 2019
Otherwise this is a NULL dereference and then crash.

Fixes #5550.
@faho faho added this to the fish 3.0.1 milestone Jan 22, 2019
@faho
Copy link
Member

faho commented Jan 22, 2019

This should now hopefully be fixed in master and the upcoming 3.0.1.

@dniku dniku changed the title Segmentation fault with 3.0 on RHEL Segmentation fault with 3.0 on RHEL 7.4 Jan 25, 2019
@ridiculousfish
Copy link
Member

Looks like 963e321 is the pick, thanks faho!

@dniku
Copy link
Author

dniku commented Jan 26, 2019

With @horta's workaround, I am still seeing frequent crashes, both during startup and during autocompletion. I don't see any pattern to them (the sequence of actions that triggers the crash usually, but not always, ceases to work after a restart), but rm -r ~/.run and a relogin seem to mitigate the problem. Is this expected?

@faho
Copy link
Member

faho commented Jan 26, 2019

Is this expected?

@Pastafarianist: Crashes are not expected behavior, no.

Can you try to build 963e321, i.e. the "Integration_3.0.1" branch (which will become the 3.0.1 release shortly)? That should make the workaround unnecessary.

If you can still reproduce the crashes with that, I'd really love to have a stack trace.

@mqudsi
Copy link
Contributor

mqudsi commented Jan 27, 2019

@Pastafarianist you can also enable core dumps to automatically generate a fish.core in /tmp or CWD

@dniku
Copy link
Author

dniku commented Jan 29, 2019

I have enabled core dumps and will upload them as soon as I get a crash. As for building from source, unfortunately, as a novice Nix user, I do not know how to specify that I want to download a specific commit.

@dniku
Copy link
Author

dniku commented Jan 29, 2019

$ gdb fish core.49466
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 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-unknown-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 fish...(no debugging symbols found)...done.
[New LWP 49466]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/fivq0nbggp4y8mhy3ixprqd7qyn1hy2j-glibc-2.27/lib/libthread_db.so.1".
Core was generated by `fish'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f217184bf5c in sysmalloc () from /nix/store/fivq0nbggp4y8mhy3ixprqd7qyn1hy2j-glibc-2.27/lib/libc.so.6
warning: File "/nix/store/sf0wnp30savqz9ljn6fsrn8f63w5v0za-gcc-7.4.0-lib/lib/libstdc++.so.6.0.24-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /nix/store/sf0wnp30savqz9ljn6fsrn8f63w5v0za-gcc-7.4.0-lib/lib/libstdc++.so.6.0.24-gdb.py
line to your configuration file "/path/to/home/user/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/path/to/home/user/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
(gdb) bt
#0  0x00007f217184bf5c in sysmalloc () from /nix/store/fivq0nbggp4y8mhy3ixprqd7qyn1hy2j-glibc-2.27/lib/libc.so.6
#1  0x00007f217184cf4f in _int_malloc () from /nix/store/fivq0nbggp4y8mhy3ixprqd7qyn1hy2j-glibc-2.27/lib/libc.so.6
#2  0x00007f217184ecca in malloc () from /nix/store/fivq0nbggp4y8mhy3ixprqd7qyn1hy2j-glibc-2.27/lib/libc.so.6
#3  0x00007f21723e59b8 in operator new(unsigned long) () from /nix/store/sf0wnp30savqz9ljn6fsrn8f63w5v0za-gcc-7.4.0-lib/lib/libstdc++.so.6
#4  0x00000000004e4084 in void std::vector<parse_node_t, std::allocator<parse_node_t> >::_M_realloc_insert<parse_node_t const&>(__gnu_cxx::__normal_iterator<parse_node_t*, std::vector<parse_node_t, std::allocator<parse_node_t> > >, parse_node_t const&) ()
#5  0x00000000004e30a9 in parse_ll_t::accept_tokens(parse_token_t, parse_token_t) ()
#6  0x00000000004e381c in parse_tree_from_string(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, unsigned int, parse_node_tree_t*, std::vector<parse_error_t, std::allocator<parse_error_t> >*, parse_token_type_t) ()
#7  0x00000000004e72bd in parse_util_detect_errors(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, std::vector<parse_error_t, std::allocator<parse_error_t> >*, bool, std::shared_ptr<parsed_source_t const>*) ()
#8  0x00000000004f9ca9 in read_ni(int, io_chain_t const&) ()
#9  0x0000000000502f82 in reader_read(int, io_chain_t const&) ()
#10 0x0000000000464af7 in builtin_source(parser_t&, io_streams_t&, wchar_t**) ()
#11 0x000000000043d7ba in builtin_run(parser_t&, int, wchar_t**, io_streams_t&) ()
#12 0x00000000004ab511 in exec_job(parser_t&, std::shared_ptr<job_t>) ()
#13 0x0000000000528f68 in parse_execution_context_t::run_1_job(tnode_t<grammar::job>, block_t const*) ()
#14 0x0000000000529703 in parse_execution_context_t::run_job_conjunction(tnode_t<grammar::job_conjunction>, block_t const*) ()
#15 0x000000000052cbc2 in parse_execution_result_t parse_execution_context_t::run_job_list<grammar::job_list>(tnode_t<grammar::job_list>, block_t const*) ()
#16 0x000000000052aaa3 in parse_execution_context_t::eval_node(tnode_t<grammar::job_list>, block_t const*, io_chain_t const&) ()
#17 0x00000000004ed8f7 in int parser_t::eval_node<grammar::job_list>(std::shared_ptr<parsed_source_t const>, tnode_t<grammar::job_list>, io_chain_t const&, block_type_t, std::shared_ptr<job_t>) ()
#18 0x00000000004eaf5f in parser_t::eval(std::shared_ptr<parsed_source_t const>, io_chain_t const&, block_type_t) ()
#19 0x00000000004ecc2a in parser_t::eval(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, io_chain_t const&, block_type_t) ()
#20 0x00000000004ae03a in exec_subshell_internal(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, std::vector<std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::allocator<std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > >*, bool, bool) ()
#21 0x000000000051c8ae in autoload_t::locate_file_and_maybe_load_it(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, bool, bool, std::vector<std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::allocator<std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > > const&) ()
#22 0x000000000051d53b in autoload_t::load(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, bool) ()
#23 0x00000000004b7d40 in load(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) ()
#24 0x00000000004b7df4 in function_exists(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) ()
#25 0x000000000052378f in parse_execution_context_t::process_type_for_command(tnode_t<grammar::plain_statement>, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) const ()
#26 0x00000000005269f0 in parse_execution_context_t::populate_plain_process(job_t*, process_t*, tnode_t<grammar::plain_statement>) ()
#27 0x0000000000527694 in parse_execution_context_t::populate_job_process(job_t*, process_t*, tnode_t<grammar::statement>) ()
#28 0x000000000052789e in parse_execution_context_t::populate_job_process(job_t*, process_t*, tnode_t<grammar::statement>) ()
#29 0x0000000000527fbd in parse_execution_context_t::populate_job_from_job_node(job_t*, tnode_t<grammar::job>, block_t const*) ()
#30 0x0000000000528e7c in parse_execution_context_t::run_1_job(tnode_t<grammar::job>, block_t const*) ()
#31 0x0000000000529703 in parse_execution_context_t::run_job_conjunction(tnode_t<grammar::job_conjunction>, block_t const*) ()
#32 0x000000000052ac22 in parse_execution_context_t::run_if_statement(tnode_t<grammar::if_statement>, block_t const*) ()
#33 0x000000000052919b in parse_execution_context_t::run_1_job(tnode_t<grammar::job>, block_t const*) ()
#34 0x0000000000529703 in parse_execution_context_t::run_job_conjunction(tnode_t<grammar::job_conjunction>, block_t const*) ()
#35 0x000000000052cbc2 in parse_execution_result_t parse_execution_context_t::run_job_list<grammar::job_list>(tnode_t<grammar::job_list>, block_t const*) ()
#36 0x000000000052aaa3 in parse_execution_context_t::eval_node(tnode_t<grammar::job_list>, block_t const*, io_chain_t const&) ()
#37 0x00000000004ed8f7 in int parser_t::eval_node<grammar::job_list>(std::shared_ptr<parsed_source_t const>, tnode_t<grammar::job_list>, io_chain_t const&, block_type_t, std::shared_ptr<job_t>) ()
#38 0x00000000004af006 in void internal_exec_helper<grammar::job_list>(parser_t&, std::shared_ptr<parsed_source_t const>, tnode_t<grammar::job_list>, io_chain_t const&, std::shared_ptr<job_t>) ()
#39 0x00000000004ac844 in exec_job(parser_t&, std::shared_ptr<job_t>) ()
#40 0x0000000000528f68 in parse_execution_context_t::run_1_job(tnode_t<grammar::job>, block_t const*) ()
#41 0x0000000000529703 in parse_execution_context_t::run_job_conjunction(tnode_t<grammar::job_conjunction>, block_t const*) ()
#42 0x000000000052cbc2 in parse_execution_result_t parse_execution_context_t::run_job_list<grammar::job_list>(tnode_t<grammar::job_list>, block_t const*) ()
#43 0x000000000052aaa3 in parse_execution_context_t::eval_node(tnode_t<grammar::job_list>, block_t const*, io_chain_t const&) ()
#44 0x00000000004ed8f7 in int parser_t::eval_node<grammar::job_list>(std::shared_ptr<parsed_source_t const>, tnode_t<grammar::job_list>, io_chain_t const&, block_type_t, std::shared_ptr<job_t>) ()
#45 0x00000000004af006 in void internal_exec_helper<grammar::job_list>(parser_t&, std::shared_ptr<parsed_source_t const>, tnode_t<grammar::job_list>, io_chain_t const&, std::shared_ptr<job_t>) ()
#46 0x00000000004ac844 in exec_job(parser_t&, std::shared_ptr<job_t>) ()
#47 0x0000000000528f68 in parse_execution_context_t::run_1_job(tnode_t<grammar::job>, block_t const*) ()
#48 0x0000000000529703 in parse_execution_context_t::run_job_conjunction(tnode_t<grammar::job_conjunction>, block_t const*) ()
#49 0x000000000052cbc2 in parse_execution_result_t parse_execution_context_t::run_job_list<grammar::job_list>(tnode_t<grammar::job_list>, block_t const*) ()
#50 0x000000000052aaa3 in parse_execution_context_t::eval_node(tnode_t<grammar::job_list>, block_t const*, io_chain_t const&) ()
#51 0x00000000004ed8f7 in int parser_t::eval_node<grammar::job_list>(std::shared_ptr<parsed_source_t const>, tnode_t<grammar::job_list>, io_chain_t const&, block_type_t, std::shared_ptr<job_t>) ()
#52 0x00000000004eaf5f in parser_t::eval(std::shared_ptr<parsed_source_t const>, io_chain_t const&, block_type_t) ()
#53 0x00000000004ecc2a in parser_t::eval(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, io_chain_t const&, block_type_t) ()
#54 0x00000000004a80f8 in event_fire_internal(event_t const&) ()
#55 0x00000000004a8a74 in event_fire(event_t const*) ()
#56 0x00000000004a8bfa in event_fire_generic(wchar_t const*, std::vector<std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::allocator<std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > >*) ()
#57 0x0000000000502bd0 in reader_read(int, io_chain_t const&) ()
#58 0x000000000043970f in main ()
(gdb) info threads
  Id   Target Id                         Frame 
* 1    Thread 0x7f21717cd0c0 (LWP 49466) 0x00007f217184bf5c in sysmalloc () from /nix/store/fivq0nbggp4y8mhy3ixprqd7qyn1hy2j-glibc-2.27/lib/libc.so.6
(gdb) info registers
rax            0x28000             163840
rbx            0x7f2171b7caa0      139781618518688
rcx            0xffffffffffffffff  -1
rdx            0x7fcfc1e74000      140530288115712
rsi            0xae4f0dd000        748650614784
rdi            0x0                 0
rbp            0xa010              0xa010
rsp            0x7ffd90f0eb00      0x7ffd90f0eb00
r8             0x2b001             176129
r9             0x0                 0
r10            0xfff               4095
r11            0x246               582
r12            0x2a70              10864
r13            0x7f2172ec6590      139781638743440
r14            0x3000              12288
r15            0x3000              12288
rip            0x7f217184bf5c      0x7f217184bf5c <sysmalloc+1612>
eflags         0x10202             [ IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

This looks like a different issue. Do you want me to file a new bug report?

@faho
Copy link
Member

faho commented Jan 30, 2019

This looks like a different issue. Do you want me to file a new bug report?

Yes, and yes!

@faho
Copy link
Member

faho commented Jan 30, 2019

On second thought, #5605.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something that's not working as intended
Projects
None yet
Development

No branches or pull requests

7 participants