I am getting random "Illegal instruction (core dumped)" on various programs in my Arch Linux system, since I ran some system updates.

The crashes are quite random. E.g. sometimes "git status" crashes the first two times, but then the next time it works ok.

Programs that crash:

  • ruby (using it for compass, to compile SASS files) (SEGV)
  • git (on simple commands like git status) (ILL)
  • gdb (for analysing the core dumps) (ILL)
  • SpotifyHelper (ILL)
  • xfce4-panel (ILL)
  • /usr/lib/networkmanager/nm-dispatcher (ILL)
  • /usr/bin/httpd (ILL)
  • /usr/bin/plymouthd (ILL)

I don't know what all of these have in common, that makes them crash. Maybe my system is just corrupt since the last update.

I had a look at some of the stack traces, following the instructions on https://wiki.archlinux.org/index.php/Core_dump. They all had the frame #0 in /usr/lib/libpthread.so.0, mostly __lll_lock_elision (). Otherwise, the stack trace does not seem very informative, it has a lot of ??? () and is different per application.

The update that may have caused this got stuck in the middle, in a way that I had to restart the system. This may have caused the problem. Currently the system reports that everything is up-to-date. Not sure if this helps.

This included a Kernel update. Currently uname -a says #1 SMP PREEMPT Fri Jun 12 17:50:53 UTC 2015 x86_64 GNU/Linux. But I don't remember the previous Kernel.

One thing that went wrong during the update was related to grub and memtest86: Syntax error in grub.cfg on update-grub (Grub 2) (memtest86+) But I don't think it is related.

UPDATE (2015-06-18):

It appears this is related to the initramfs boot option in grub, and suspend.

  • If I attempt to boot without initramfs, it gets stuck in the Manjaro loading screen.
  • If I boot with initramfs, boot is successful, and I get no issues with "Illegal instruction (core dumped)".
  • If I suspend (to RAM) from the session with initramfs, and then wake up, the problems with "Illegal instruction (core dumped)" appear.
  • I have to reboot again (with initramfs) to get a "clean" session.

CPU version: (4 cores)

model name      : Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
microcode       : 0x1c
fpu             : yes
fpu_exception   : yes
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse 
sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc ap
erfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic
 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid

Some questions for a start:

  • What is __lll_lock_elision(), and how it can crash?
  • What is the "illegal instruction"? How could I find out? Could this be something that used to be a valid instruction before the update, but no longer is now?
  • What's your CPU? What microcode revision do you have? (Check /proc/cpuinfo for both pieces of information.) This could be related to TSX on Haswell. – Stephen Kitt Jun 17 '15 at 8:07
  • I added some information from /proc/cpuinfo. Not sure what else of this is relevant. – donquixote Jun 17 '15 at 8:34
  • @StephenKitt What is it with the TSX? – donquixote Jun 17 '15 at 14:09
  • Just a quick update, dunno if relevant: system froze while in screensaver mode, had to reboot, reboot failed, had to choose "initramfs" option in grub. Not sure what this even means. I guess this means there could be issues with my HD or filesystems. Info about this is in the linked issue, if relevant. – donquixote Jun 17 '15 at 16:03
  • Illegal instructions involving ___lll_lock_elision() reminds me of bugs like bugs.debian.org/cgi-bin/bugreport.cgi?bug=754392 where glibc attempts to use TSX instructions even though they're unsupported or disabled... – Stephen Kitt Jun 17 '15 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.