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

successive CDPATH CD's followed by ".." cause Backtrace SIGABRT termination #6220

Closed
sdothum opened this issue Oct 17, 2019 · 1 comment · Fixed by #6221
Closed

successive CDPATH CD's followed by ".." cause Backtrace SIGABRT termination #6220

sdothum opened this issue Oct 17, 2019 · 1 comment · Fixed by #6221
Labels
bug Something that's not working as intended
Milestone

Comments

@sdothum
Copy link

sdothum commented Oct 17, 2019

fish, version 3.0.2

sh -c 'env HOME=$(mktemp -d) fish'
mkdir .config
cd .config
cd .config
..<E> fish: /builddir/fish-3.0.2/src/wutil.cpp:464: failed assertion: !wd.empty() && wd.front() == sep && wd.ba
ck() == sep && "Invalid working directory, it must start and end with /"
<E> fish: Backtrace:
<E> fish: 0   path_normalize_for_cd(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) + 1263
<E> fish: 1   fish(+0xee8c4) [0x55b0b92f48c4]
<E> fish: 2   path_can_be_implicit_cd(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >*, env_vars_snapshot_t const&) + 130
<E> fish: 3   fish(+0xbc5eb) [0x55b0b92c25eb]
<E> fish: 4   highlight_shell(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, std::vector<unsigned int, std::allocator<unsigned int> >&, unsigned long, 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> > > >*, env_vars_snapshot_t const&) + 425
<E> fish: 5   fish(+0xf96f0) [0x55b0b92ff6f0]
<E> fish: 6   std::_Function_handler<void (), _iothread_trampoline<highlight_result_t>::perform<std::function<highlight_result_t ()>, void (*)(highlight_result_t)>(std::function<highlight_result_t ()> const&, void (* const&)(highlight_result_t))::{lambda()#1}>::_M_invoke(std::_Any_data const&) + 49
<E> fish: 7   fish(+0xdb5e4) [0x55b0b92e15e4]
<E> fish: 8   /usr/lib/libpthread.so.0(+0x8f27) [0x7f15a07aff27]
<E> fish: 9   clone + 63
fish: Job 2, “bash -norc $argv” terminated by signal SIGABRT (Abort)

Typing ".." after the second "cd .config" causes the immediate backtrace. Appears only to occur with path changes using the CDPATH spec e.g. explicit pathnames "cd ~/.config; cd ~/.config; .." does not cause a backtrace. Directory names do not need to be the same to cause the backtrace.

Occurs on..

Voidlinux: Linux lumen 5.2.21_1 #1 SMP PREEMPT Fri Oct 11 18:24:40 UTC 2019 x86_64 GNU/Linux

Archlinux: Linux luna 5.3.5-arch1-1-ARCH #1 SMP PREEMPT Mon Oct 7 19:03:08 UTC 2019 x86_64 GNU/Linux

Terminals alacritty and xterm: xterm-256color

CDPATH set as..

set -x CDPATH . .. ../..

Not a hugely serious workflow issue, as successive relative CD's followed by ".." would be rare! but the backtrace would be annoying.

@krobelus krobelus added the bug Something that's not working as intended label Oct 17, 2019
krobelus added a commit to krobelus/fish-shell that referenced this issue Oct 17, 2019
@krobelus krobelus added this to the fish 3.1.0 milestone Oct 17, 2019
@krobelus
Copy link
Member

Thanks for the report, the fix should be ready soon!

krobelus added a commit to krobelus/fish-shell that referenced this issue Oct 17, 2019
krobelus added a commit to krobelus/fish-shell that referenced this issue Oct 19, 2019
krobelus added a commit that referenced this issue Oct 19, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 16, 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

Successfully merging a pull request may close this issue.

2 participants