syncthing exits with Trace/Breakpoint Trap, due to missing modify_ldt system call in 386 systems

Support
1

Continuing the discussion from “Trace/breakpoint trap” while start on Debian 6 32bit: (Sorry for the late reply, I don’t get the notifications somehow)

calmh: No, echo 1 > /proc/sys/kernel/modify_ldt doesn’t work for me. I don’t have that file. The last working -version is: syncthing v0.10.6 (go1.3.3 linux-386 default) jenkins@build.syncthing.net 2014-11-18 12:24:42 UTC The next, run on another system, because of the issue: syncthing v0.10.7 (go1.3.3 linux-386 default) unknown-user@syncthing-builder 2014-11-24 10:57:31 UTC

This seems to be a golang issue:

I can’t even build a binary which worked even with old go and the old version (extracted from git):

  • compiling a new version with an old go compiler (docker google/golang:1.3) does not work
  • building an old version with a new compiler does not work.
  • not even building the old version with the old compiler works (resulting image: docker run -it djtm/syncthing:0.10.6_go1.3 bash), Dockerfile attached (syncthing v0.10.6 (go1.3 linux-386 default) unknown-user@ece227541990 2014-11-18 12:24:42 UTC) Dockerfile (719 Bytes)

Does the build script pull the old dependencies or new dependencies? As I’m building from git with checkout.

It appears some fix within the build environment might be possible. I wonder what change in the environment caused go to use the modify_ldt function since v0.10.6, though…

2

With all likelihood this has nothing to do with our code and is just an effect of the compiler changing. We track the latest; v0.10 was probably built with Go 1.2 or 1.3 or thereabouts, currently we’re at Go 1.6.

Edit: 0.10.7 looks like when we changed to a Docker based build environment, so for sure some things changed in how the compiler was set up and the cross compilation was done. Exactly how, though, is unknown.

3

For reference: there is now an official bug report in the golang tracker:

It might even be ported to 1.4.x.

1 Like
4

Solved! It turns out for some odd reason ksplice changs the name of the file: All this time all I needed to do was:

echo 1 /proc/sys/ksplice_modify_ldt

The ksplice is added to the filename in my instance. Sorry for all the trouble. Still a bug in go, which uses a syscall it really should not.

2 Likes
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.