5 ms·

Considering that it happens only on Ryzen and with multiple GCC versions and that the first post in this Gentoo forum thread shows segfaults in bash (not gcc) i

by qb45 9y ago

Considering that it happens only on Ryzen and with multiple GCC versions and that the first post in this Gentoo forum thread shows segfaults in bash (not gcc) it looks rather like a CPU bug manifesting itself under load. Nobody talked about even trying clang, knowing Phoronix they just couldn't resist mentioning it for drama or SEO.

DannyBee 9y ago
"Considering that it happens only on Ryzen and with multiple GCC versions and that the first post in this Gentoo forum thread shows segfaults in bash (not gcc) it looks rather like a CPU bug manifesting itself under load. " Well, maybe. x86 is obviously a large target, and there are definitely weird corner cases and stuff that, while often not legal, just happen to work on intel and not amd (or vice versa) I'd still bet on that before i'd bet on hardware bug. Certainly the hardware bugs occur, but software tends to be buggier :)
- dom0 9y ago
  https://news.ycombinator.com/item?id=14480282 https://news.ycombinator.com/item?id=14480282 At least the part where a different process crashes sounds really more like a hardware problem, although it could of course also be a Kernel<->Hardware issue. There is also this: https://www.reddit.com/r/programming/comments/6f08mb/compiling_with_ryzen_cpus_on_linux_causing_random/dieuoad/ https://www.reddit.com/r/programming/comments/6f08mb/compili...
aidenn0 9y ago
Ryzen 1700 stock clock, lateset BIOS here. Recompiling bash with gcc-6.3 made it much less likely to happen. After recompiling my entire system with 6.3, I haven't seen it happen yet, despite doing 8 hours straight of building. Also recompiling my linux kernel with gcc-6.3 my ~72 hour kernel crashes seem to have gone away I had to reboot for an unrelated reason, after doing this, so only have two ~144 hour uptimes for my data.
- watt 9y ago
  Sounds like a CPU bug then. Recompiling made it so that certain instruction (or sequence of instructions) are not hit - avoiding hitting some kind of hardware problem. But the problem is still there.
  - qb45 9y ago
    Not really, it could equally well be a pre-6.3 GCC bug which resulted in outputting bad code. What makes me think it may be CPU rather than GCC is that the segfault seems to happen nondeterministicly in a single-threaded bash binary running the same shell script with the same arguments each time. Somebody also reported this oddity: Strangely enough, the machine can run mprime for days on end without any trouble. However, an average run of the Glasgow Haskell Compiler's testsuite exhibits a handful of failures (typically segmentation faults). Even stranger, if I run a few mprime threads alongside a run of GHC's testsuite, mprime will itself sometimes crash with a segmentation fault. So you have the same mprime binary which either crashes or not depending on whether GHC tests are running at the same time.

by qb45 9y ago

DannyBee 9y ago

"Considering that it happens only on Ryzen and with multiple GCC versions and that the first post in this Gentoo forum thread shows segfaults in bash (not gcc) it looks rather like a CPU bug manifesting itself under load. " Well, maybe. x86 is obviously a large target, and there are definitely weird corner cases and stuff that, while often not legal, just happen to work on intel and not amd (or vice versa) I'd still bet on that before i'd bet on hardware bug. Certainly the hardware bugs occur, but software tends to be buggier :)

dom0 9y ago
https://news.ycombinator.com/item?id=14480282 https://news.ycombinator.com/item?id=14480282 At least the part where a different process crashes sounds really more like a hardware problem, although it could of course also be a Kernel<->Hardware issue. There is also this: https://www.reddit.com/r/programming/comments/6f08mb/compiling_with_ryzen_cpus_on_linux_causing_random/dieuoad/ https://www.reddit.com/r/programming/comments/6f08mb/compili...

aidenn0 9y ago

Ryzen 1700 stock clock, lateset BIOS here. Recompiling bash with gcc-6.3 made it much less likely to happen. After recompiling my entire system with 6.3, I haven't seen it happen yet, despite doing 8 hours straight of building. Also recompiling my linux kernel with gcc-6.3 my ~72 hour kernel crashes seem to have gone away I had to reboot for an unrelated reason, after doing this, so only have two ~144 hour uptimes for my data.

watt 9y ago
Sounds like a CPU bug then. Recompiling made it so that certain instruction (or sequence of instructions) are not hit - avoiding hitting some kind of hardware problem. But the problem is still there.
- qb45 9y ago
  Not really, it could equally well be a pre-6.3 GCC bug which resulted in outputting bad code. What makes me think it may be CPU rather than GCC is that the segfault seems to happen nondeterministicly in a single-threaded bash binary running the same shell script with the same arguments each time. Somebody also reported this oddity: Strangely enough, the machine can run mprime for days on end without any trouble. However, an average run of the Glasgow Haskell Compiler's testsuite exhibits a handful of failures (typically segmentation faults). Even stranger, if I run a few mprime threads alongside a run of GHC's testsuite, mprime will itself sometimes crash with a segmentation fault. So you have the same mprime binary which either crashes or not depending on whether GHC tests are running at the same time.