all.bash gotest fails on line 164 segmentation fault on debian lenny on xen #386
Labels
Comments
It's hard to say for sure, but it looks like this is a Xen kernel bug. The stack trace you've shown: standcanada kernel: [<c0109941>] write_ldt+0x1a7/0x1c3 standcanada kernel: [<c0106d46>] syscall_call+0x7/0xb standcanada kernel: [<c0430000>] hrtimer_nanosleep_restart+0x28/0x51 is definitely a kernel stack trace. Perhaps the kernel is unable or unwilling to accommodate Go's writing to the LDT. I'll leave this as WaitingForReply because I'd like to know for sure what's going on, but we'll need someone on a Xen system to debug this. Maybe there is documentation somewhere about Xen disallowing such system calls. Another thing to try is to run the binary using: strace -f 8.out and see what system call strace thinks is running when the kernel gets upset. Labels changed: added helpwanted, os-linux. Owner changed to r...@golang.org. Status changed to WaitingForReply. |
here are results of strace
strace -f ./8.out
execve("./8.out", ["./8.out"], [/* 24 vars */]) = 0
brk(0) = 0x99008000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb8086000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb8085000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb8085690, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
modify_ldt(1, {entry_number:7, base_addr:0x805c474, limit:1048575, seg_32bit:1,
contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, 16) =
0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
|
I have attached two C programs. The first, x.c, calls modify_ldt. The second, xx.c, calls set_thread_area with the same arguments. Please try compiling and running each of them under Xen and see whether each works. When they succeed, they print "ok" and "ok - set_thread_area". If Xen kills off the modify_ldt version then that's probably a Xen bug. But if it lets the set_thread_area one through, maybe we can switch to using that. Attachments: |
I can reproduce this bug, but I got a different result when running "x" (it segfaults
sometimes).
Reproducing the bug:
~/go/src/pkg/archive/tar$ ./8.out
Segmentation fault
~/go/src/pkg/archive/tar$ strace -f ./8.out -s 100000
execve("./8.out", ["./8.out", "-s", "100000"], [/* 22 vars */]) = 0
brk(0) = 0x9905d000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8043000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8042000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb8042690, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
modify_ldt(1, {entry_number:7, base_addr:0x80b9134, limit:1048575, seg_32bit:1,
contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}, 16) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 13739 detached
== dmesg ==
kernel BUG at arch/x86/xen/enlighten.c:436!
invalid opcode: 0000 [#2] SMP
Pid: 13003, comm: 8.out Tainted: G D W (2.6.27.2-xenU #1)
EIP: 0061:[<c01034cb>] EFLAGS: 00210282 CPU: 0
EIP is at xen_write_ldt_entry+0x87/0x94
EAX: ffffffea EBX: c4a89038 ECX: 00000001 EDX: 9134ffff
ESI: 08eff20b EDI: 00000000 EBP: 00000008 ESP: c9b75f64
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
Process 8.out (pid: 13003, ti=c9b74000 task=c9a257f0 task.ti=c9b74000)
Stack: 08eff20b 00000000 09a69038 00000000 00000280 0000000f 00000001 c0109941
c62e8c18 c62e8ac0 00000007 080b9134 000fffff 00000051 9134ffff 08eff20b
00000001 bff6f77c 0806ea1a c9b74000 c0106d46 00000001 bff6f6c8 00000010
Call Trace:
[<c0109941>] write_ldt+0x1a7/0x1c3
[<c0106d46>] syscall_call+0x7/0xb
[<c0430000>] hrtimer_nanosleep_restart+0x28/0x51
Testing with x.c and xx.c:
~/go/src/pkg/archive/tar$ ./x
Segmentation fault
~/go/src/pkg/archive/tar$ ./xx
ok - set_thread_area
(again)
~/go/src/pkg/archive/tar$ ./x
ok
~/go/src/pkg/archive/tar$ ./x
Segmentation fault
In the end, x.c crashes only sometimes, while "gotest" in pkg/archives/tar crashes every
time.
|
I went back and tested again and can confirm that x.c does cause a seg fault for me too on about 50% of tests (I've run it about 50 times and it appears to be random when it seg faults). xx.c did not crash ever in about 50 executions. "gotest" in pkg/archives/tar crashes every time. |
> What's holding this up? We just have higher priority tasks, sorry. If you'd like to fix it, please go ahead and send us a patch. I think that Devon tried to help someone on IRC with this problem, and switching to set_thread_area didn't help, so the problem is deeper than that. Status changed to LongTerm. |
This is the person I was helping on IRC. I'll provide my patch here in case anybody else wants to try it, but it causes segfaults for me on standard amd64 hardware running i386. I reverted my tree because it didn't seem to work for anybody, but this is what I came up with. Perhaps it's a step in the right direction; perhaps setldt is a red herring. Attachments:
|
|
The issue also comes up here for various people: |
|
@djtm this issue was closed 5 years ago. Please open a new issue if this problem affects you. |
|
For the modify_ldt problem, filed #14795.
|
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by tntknight:
The text was updated successfully, but these errors were encountered: