3

I'm using Linux arch 3.15.2-1-ARCH x86_64. I don't use zsh (zsh-5.0.5-1) every day, otherwise I would have noticed it segfaults, when I launch it from the bash cli:

arch kernel: zsh[2187]: segfault at 8 ip 00007f3b49853083 sp 00007fff2ad39198 error 4 in libc-2.19.so[7f3b497d2000+1a4000] arch systemd-coredump[2188]: Process 2187 (zsh) dumped core.

Now I remember running it at some point and going through the configuration script(zsh /usr/share/zsh/functions/Newuser/zsh-newuser-install -f segfaults too now). So I have done the following:

  • Reboot
  • The behavior is the same in X or the console
  • Remove with configuration and clear package cache, then reinstall: pacman -Rns zsh; paccache -r; paccache -ruk0; pacman -S zsh.
  • Try to compile using the recipe for 5.0.5-1 and 5.0.4-1: compiles, then goes on to check the binary by executing it, which segfaults in both cases, so this aborts.
  • Made sure to have no .zsh* file in my home directory - made sure to have the basic .zsh* files in my home dir.
  • Renamed /etc/profile
  • Renamed /etc/zsh/zprofile
  • zsh-completions is/is not installed

Ironically, zsh --version or --help work and echo the relevant info.

So what could be the issue with my setup/environment here?

Note: ran quick gdb if that brings any insight into what is happening:

(gdb) run Starting program: /usr/bin/zsh warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? Program received signal SIGSEGV, Segmentation fault. 0x00007ffff713e083 in __strchr_sse2 () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff713e083 in __strchr_sse2 () from /usr/lib/libc.so.6 #1 0x000000000044f2e3 in ?? () #2 0x000000000044f7d4 in op () #3 0x000000000045003b in ?? () #4 0x00000000004505cd in ?? () #5 0x00000000004507dc in matheval () #6 0x0000000000450829 in mathevali () #7 0x00000000004602b0 in ?? () #8 0x00000000004624ab in assignsparam () #9 0x0000000000463636 in createparamtable () #10 0x000000000043f2b5 in setupvals () #11 0x0000000000440e14 in zsh_main () #12 0x00007ffff70dd000 in __libc_start_main () from /usr/lib/libc.so.6 #13 0x000000000040f7be in _start ()
Improve this question
2
  • 1
    I'd use strace zsh to see what's going on. Commented Jul 3, 2014 at 1:35
  • @slm Thank you for the suggestion. I put that there. I see a few errors like an illegal lseek and some files not found but I'm afraid I can't see anything meaningful at my level.. Commented Jul 3, 2014 at 2:22

1 Answer 1

Reset to default
1

The behavior can be reproduced with:

export HISTSIZE=V=

For some reason I had that in my .bashrc file. Most likely I didn't have focus in the window I thought I had, ended up adding V= without noticing it and was careless saving the file; maybe it was open in the editor - those are set to enable unlimited history. But zsh uses the parameter too. So bash didn't complain about the error but zsh did... A quick look at the output of envfor anything unusual has to be on the debug checklist.

Improve this answer
2
  • 2
    Since that's a setting for interactive bash shells with a syntax specific to bash shells, it should be put in ~/.bashrc and not exported as opposed to exported in ~/.profile. Same as for PS1 where the syntax is shell specific but the variable is shared by different shells. Commented Jul 3, 2014 at 10:38
  • @StéphaneChazelas Thank you, I will remember this lesson about the environment for sure! That's one for my books. Although I must say even without exporting here, just having that typo in the parameter value triggers the segfault. Commented Jul 3, 2014 at 18:52

You must log in to answer this question.