for BIT in $(seq 0 31); do make clean && rm -f objs.txt && BIT=$BIT make -j9 && cp arch/x86/boot/bzImage kernel_${BIT}.bzimg && mv objs.txt objs_${BIT}.txt ; donehttps://twitter.com/marcan42/status/928571175210323968 …
Show this thread
-
I expect 16/32 crashes on average; I'm at 8 so far after running through all kernels twice at 20 seconds per test. That narrows it down to 4 object files. The time to crash is nondeterministic, so let's go for a third run...
Show this thread
DING DING
$ grep '^[0246][012389ab][0189][014589cd][028a][012389ab][014589cd]' objs_0.txt
6b9cab4f arch/x86/entry/vdso/vclock_gettime.o #yes, grep for bitops
Who'd have thought a *userspace* crash would depend on a difference in vdso code... which is userspace code!
-
-
Surprise, it's Go's fault. Turns out 104 bytes of stack space is not enough when GCC decides to do a 4K stack probe. And stack probes are *exactly* what would cause nondeterministic corruption if another thread races that address!https://github.com/golang/go/issues/20427#issuecomment-343255844 …
Show this thread -
So my second time stumbling upon and debugging a Go runtime bug *again* winds up being a problem with Go->C interop. Still not a fan of Go.
Show this thread
End of conversation
New conversation -
-
-
gratulations! a bug in one of the obscurest parts of linux
-
I don't know yet that this is a bug in Linux. All I know is this *difference* in Linux triggers a crash in the Go runtime. It could be Go's fault. In fact I've been betting it's Go's fault, and this makes me bet even harder :-)
- Show replies
New conversation -
-
-
Make sure you add a test case when you figure this all out. :) Too bad Linux doesn't have a proper CI.
-
It's not a Linux bug. It's Go making assumptions about the syscall/vdso interface that are not guaranteed.
End of conversation
New conversation -
-
-
.. or vdso failing by making assumptions about rest of userland that're not guaranteed.. :) always_inline + some commentary about expected stack sounds the right thing for these two vdso calls, they're so simple; a go patch to help it work with unusual krnls and gcc is needed too
-
The spec doesn't guarantee stack usage, so Go is wrong here :-). Of course, that would be a worthwhile addition to the spec. But given the current documentation, this is squarely a Go bug (the source even acknowledges it currently makes an assumption).
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.