Random Notes‎ > ‎

32 bit golang Trace/Breakpoint trap: modify_ldt ENOSYS

posted Aug 4, 2015, 9:04 AM by William Shallum   [ updated Aug 4, 2015, 9:06 AM ]
If you're like me: a bit too cheap to get a large VPS and too miserly to waste limited RAM by using a 64 bit OS you may run into something like this:

vm:~$ gdrive
Trace/breakpoint trap


Where gdrive is https://github.com/prasmussen/gdrive - it is written in the Go programming language, which would explain the rather interesting behavior below.

It worked before, so something must be wrong. A short strace later showed:

vm:~$ strace /usr/local/bin/gdrive
execve("/usr/local/bin/gdrive", ["/usr/local/bin/gdrive"], [/* 11 vars */]) = 0
modify_ldt(1, {entry_number:7, base_addr:0x84d8548, limit:1048575, seg_32bit:1,
contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, 1
6) = -1 ENOSYS (Function not implemented)
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
+++ killed by SIGTRAP +++
Trace/breakpoint trap


Some searching around led to this LKML discussion: https://lkml.org/lkml/2015/7/23/243

It seems on this kernel:

vm:~$ uname -a
Linux vm 3.18.19-0-virtgrsec #1-Alpine SMP Fri Jul 31 11:09:05 GMT 2015 i686 Linux


The patch mentioned was applied. Luckily the syscall can still be reenabled by

# echo 1 > /proc/sys/kernel/modify_ldt


After re-enabling the syscall, the program works fine.


Comments