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
-
Finished building 32 kernels in 29 minutes. Time to test.
2 replies 2 retweets 8 likesShow 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...
2 replies 1 retweet 4 likesShow 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!4 replies 5 retweets 12 likesShow this thread -
Replying to @marcan42
gratulations! a bug in one of the obscurest parts of linux
1 reply 0 retweets 0 likes -
Replying to @Max_Krueger
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 :-)
1 reply 0 retweets 1 like
Yeah it was Go's fault. Making assumptions about vDSO stack usage that are not documented and don't always hold.
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.