2

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 ()
  • 1
    I'd use strace zsh to see what's going on. – slm Jul 03 '14 at 01: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.. –  Jul 03 '14 at 02:22

1 Answers1

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.

  • 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. – Stéphane Chazelas Jul 03 '14 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. –  Jul 03 '14 at 18:52