Your message dated Mon, 23 Mar 2020 18:09:04 -0400
with message-id <87pnd2wwov....@posteo.net>
and subject line Re: Bug#942227: fish: "unreachable" state reached when 
redirecting to/from an unopenable file with `exec'
has caused the Debian Bug report #942227,
regarding fish: "unreachable" state reached when redirecting to/from an 
unopenable file with `exec'
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
942227: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942227
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: fish
Version: 3.0.2-2
Severity: normal
Tags: upstream

Dear Maintainer,

I was running a program under GDB, and I needed to have it read from a
file which it is not permitted to read. So I typed

  (gdb) run < /dev/mem

GDB ran fish (since that is my $SHELL) to execute my program. But fish
was terminated by SIGABRT with the following stacktrace:

An error occurred while redirecting file '/dev/mem'
open: Permission denied
<E> fish: src/exec.cpp:1032: failed assertion: this should be unreachable
<E> fish: Backtrace:
<E> fish: 0   /usr/bin/fish(+0xb16e7) [0x5555556056e7]
<E> fish: 1   parse_execution_context_t::run_1_job(tnode_t<grammar::job>, 
block_t const*) + 2101
<E> fish: 2   
parse_execution_context_t::run_job_conjunction(tnode_t<grammar::job_conjunction>,
 block_t const*) + 196
<E> fish: 3   parse_execution_result_t 
parse_execution_context_t::run_job_list<grammar::job_list>(tnode_t<grammar::job_list>,
 block_t const*) + 281
<E> fish: 4   parse_execution_context_t::eval_node(tnode_t<grammar::job_list>, 
block_t const*, io_chain_t const&) + 1380
<E> fish: 5   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>) + 777
<E> fish: 6   parser_t::eval(std::shared_ptr<parsed_source_t const>, io_chain_t 
const&, block_type_t) + 176
<E> fish: 7   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) + 225
<E> fish: 8   run_command_list(std::vector<std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> >, 
std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> > > >*, io_chain_t const&) + 147
<E> fish: 9   main + 2200
<E> fish: 10  __libc_start_main + 235
<E> fish: 11  _start + 42

The first two lines are expected, but it then aborts because it reached
an "unreachable" state (how embarrassing!)

At first I thought that the problem was being run by GDB, but it is
actually `exec' that is the problem. For example:

  $ fish -c 'exec cat < /dev/mem'
  An error occurred while redirecting file '/dev/mem'
  open: Permission denied
  <E> fish: src/exec.cpp:1032: failed assertion: this should be unreachable
  <E> fish: Backtrace:
  [...]

Note the `exec' and the `<'. Without the `<', `cat' tries to open
/dev/mem, not `fish', so the bug does not appear.

This is not only specific to /dev/mem or special files. It can be any
unreadable file, for example /etc/shadow. It can even be a file that
does not exist. (Just remember to look for a file that does not exist
outside of your home directory, since you are sure to have created every
possible filename in your home directory if you are anything like me
(actually, I usually just shove it under ~/misc these days).)

Each time, it aborts in src/exec.cpp:1032. Fish should of course exit
with an error, but it should not reach an "unreachable" state.

This also happens if you redirect *to* an unwritable file even if it is
readable (such as /etc/passwd).

Also note that without the `exec', the bug does not appear:

  $ fish -c 'cat < /dev/mem'
  An error occurred while redirecting file '/dev/mem'
  open: Permission denied

This looks like an upstream bug (hence the "upstream" tag), but I'm not
sure because I haven't tried it with upstream fish yet. I'll send
another message with my findings if I do get around to trying it with
upstream.

Thanks,
Asher

-- 
A witty saying proves nothing, but saying something pointless gets
people's attention.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fish depends on:
ii  bc                              1.07.1-2+b2
ii  dpkg                            1.19.7
ii  elinks [www-browser]            0.13~20190125-4
ii  epiphany-browser [www-browser]  3.32.1.2-3
ii  firefox-esr [www-browser]       60.8.0esr-1
ii  fish-common                     3.0.2-2
ii  libc6                           2.29-2
ii  libgcc1                         1:9.2.1-8
ii  libncurses6                     6.1+20190803-1
ii  libpcre2-32-0                   10.32-5+b1
ii  libstdc++6                      9.2.1-8
ii  libtinfo6                       6.1+20190803-1
ii  links2 [www-browser]            2.20.2-1
ii  lynx [www-browser]              2.9.0dev.4-1
ii  man-db                          2.8.7-3
ii  netrik [www-browser]            1.16.1-2+b2
ii  python3                         3.7.5-1
ii  w3m [www-browser]               0.5.3-37+b1

Versions of packages fish recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages fish suggests:
pn  doc-base  <none>

-- no debconf information

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message ---
Version: 3.1.0-1

Hello,

David Adam <zanc...@ucc.gu.uwa.edu.au> writes:

> I am pleased to report that this problem is fixed in the upcoming
> 3.1.0 release:

Now that this release is in Debian, I am closing the bug. Hope no one
minds!

Thanks,
Asher

-- 
He was part of my dream, of course -- but then I was part of his dream too.
                -- Lewis Carroll
                               --------
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68

Attachment: signature.asc
Description: PGP signature


--- End Message ---

Reply via email to