Segfaulting VIM. What?

I got quite the surprise today while opening a file for editing using vim.

fx@teikapi2:~ sudo vim /etc/hosts  
Segmentation fault  

Say what? Vim, segfaulting? Okay.

There was an automatic apt-get upgrade on this machine today, so that is the explanation.
Still quite weird and most definitely not expected.

Quick backtrace under gdb showed:

#0  _dl_lookup_symbol_x (undef_name=0x40a93987 <error: Cannot access memory at address 0x40a93987>, undef_map=undef_map@entry=0x76fff958, ref=ref@entry=0x7efff3ec,
    symbol_scope=symbol_scope@entry=0x76fffb10, version=0x76d1e500, type_class=1, flags=flags@entry=1, skip_map=skip_map@entry=0x0) at dl-lookup.c:715
#1  0x76fdb31c in elf_machine_rel (reloc=0x54abe014, skip_ifunc=<optimized out>, reloc_addr_arg=0x54c7f4a0, version=<optimized out>, sym=0x54b2c384, map=0x76fff958)
    at ../ports/sysdeps/arm/dl-machine.h:377
#2  elf_dynamic_do_Rel (skip_ifunc=<optimized out>, lazy=0, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x76fff958) at do-rel.h:137
#3  _dl_relocate_object (scope=<optimized out>, reloc_mode=<optimized out>, consider_profiling=<optimized out>, consider_profiling@entry=0) at dl-reloc.c:264
#4  0x76fd23a4 in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2201
#5  0x76fe5b30 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7efff800, dl_main=0x0) at ../elf/dl-sysdep.c:249
#6  0x76fd3c78 in _dl_start_final (arg=0x7efff800, arg@entry=0x0, info=info@entry=0x7efff580) at rtld.c:330
#7  0x76fd3f08 in _dl_start (arg=0x0) at rtld.c:558
#8  0x76fcfd50 in _start () from /lib/

So looks like a fail whilst doing ELF dynamic relocation.

Somewhat regretfully, I reinstalled vim and this fixed the problem.

Now, in retrospect, should have saved the binary.
The more I think about it the more interesting this seems.

System testing after upgrades seems like a good idea at this point, ofc that would be an overkill for my poor raspberry Pi that servers mainly as a Samba server at home 🙂

More digging next time, eh?

Systemtap on Debian Jessie

So I wanted to play a bit with Systemtap on Debian Jessie.

I installed it:

sudo apt-get install systemtap  

Afterwards I wanted to run a quick one-liner:

fx@cloudhawk:~$ stap -L 'nd_syscall.*'  
Checking "/lib/modules/3.16.0-4-amd64/build/.config" failed with error: No such file or directory  
Tip: /usr/share/doc/systemtap/README.Debian should help you get started.  

It failed, but hey, at least it provided a clue – the README.Debian file.
So I looked at the provided doc in /usr/share/doc/systemtap/README.Debian.

I mean, you would imagine that this would be the best place to look for tips on how to get it running.

To quote it:

To use systemtap you need to  
manually install the linux-image-*-dbg and linux-header-* packages  
that match your running kernel. To simplify this task you can use the  
stap-prep command. Please always run this before reporting a bug.  

Then it goes on talking about using vim-addon-manager which makes no sense to me.
But ok, so far so good, the doc suggests to run stap-prep.

fx@cloudhawk:~$ sudo stap-prep  
/usr/bin/stap-prep: line 30: rpm: command not found

What the hell? RPM??? Crazy.

And if you look at the script, what it wants to do is to use yum to install the dependencies.
Looks as if someone @Debian just blindly took this from RedHat/Centos.

But all you actually need to get Systemtap going on Debian is to do:

sudo apt-get install systemtap linux-image-`uname -r`-dbg linux-headers-`uname -r`  

As simple as that.
Now it works:

fx@cloudhawk:~$ sudo  stap -L 'nd_syscall.*'|head -n 5  
nd_syscall.accept sockfd:long addr_uaddr:long addrlen_uaddr:long name:string argstr:string  
nd_syscall.accept4 sockfd:long addr_uaddr:long addrlen_uaddr:long flags:long name:string flags_str:string argstr:string  
nd_syscall.access name:string pathname:string mode:long mode_str:string argstr:string  
nd_syscall.acct name:string filename:string argstr:string  
nd_syscall.add_key name:string type_uaddr:long description_uaddr:long payload_uaddr:long plen:long ringid:long argstr:string