3 ms·
The most insidious version of this I experienced was when a library changed the FPU settings. Fortunately, it was sufficient to reset the FPU settings after in
by c-linkage 1y ago
The most insidious version of this I experienced was when a library changed the FPU settings.
Fortunately, it was sufficient to reset the FPU settings after initializing the library. But it sure took a long time to figure out what happened!
- DavidVoid 1y agoThere's a great Random ASCII blog post about an obscure FPU issue like this [1]. - The crash was in a FPU that Chrome barely uses - The instruction that crashed Chrome was thousands of instructions away from the one that triggered the exception - The instruction that triggered the exception was not at fault - The crash only happened because of third-party code running inside of Chrome - The crash was ultimately found to be caused by a code-gen bug in Visual Studio 2015 I've run into this kind of thing once myself (sharing a process with other companies is fun!). It was real confusing to get a stack trace showing our code suddenly crashing on a line of code that was doing the exact same thing with the exact same values as it had always done before. [1]: https://randomascii.wordpress.com/2016/09/16/everything-old-is-new-again-and-a-compiler-bug/ https://randomascii.wordpress.com/2016/09/16/everything-old-...
- minetest2048 1y agoThis also happened in python ecosystem where gevent were messing with numpy because gevent was compiled with -ffast-math, which disables subnormal numbers Blog post: https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html https://moyix.blogspot.com/2022/09/someones-been-messing-wit... HN discussion: https://news.ycombinator.com/item?id=41212072 https://news.ycombinator.com/item?id=41212072