32 bit golang Trace/Breakpoint trap: modify_ldt ENOSYS
Posted Aug 4 2015, 16:04 by William Shallum [updated Aug 4 2015, 16:06]
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.