5 ms·

UBSan ␇ Runtime

22 points by gok 7y ago

xg15 7y ago
Question to people with more knowledge in the matter: This runtime will emit sound, most traditionally the terminal's bell sound, when undefined behavior occurs. I'm surprised this is possible. My understanding was that compilers don't consciously check for UB and then decide to make the dev's life hell if they find some. It's more that compilers pretend that certain assumptions are true even though this cannot actually be verified. If they happen to not be true (but the compiler still behaves as if they were), undefined behaviour occurs. So if you can explicitly check for code that causes UB, why permit it at all? Why not abort compilation or at least emit a warning?
- comex 7y ago
  UBSan detects (certain types of) undefined behavior at runtime, not compile time. The compiler is involved, as UBSan works by adding checks to the generated assembly code: for example, whenever the original code adds two signed integers, the compiler adds code that checks whether overflow occurred, and triggers an error report if so. (Or with this patch, a bell sound!) But the compiler doesn't know ahead of time what the inputs to the addition will be.
- ithkuil 7y ago
  Indeed the ubsan sanitizer is designed to catch undefined behavior while compiling and is designed to emit an error when it founds code that hits undefined behaviour, statically. Yet, this patch is fun answer to those people who are annoyed by the number of errors that running their codebase through ubsan will produce and might think "that's just for edge cases, I'm pretty sure in practice I'll never hit effects of those at runtime". Compile with ubsan_bel and listen in horror how often it actually happens.... > Yes, this is April 1st and the patch isn't particularly serious.
  - comex 7y ago
    Pretty sure that's not true. Clang has a static analyzer, but UBSan is not part of that; it's a purely dynamic analysis that detects issues at runtime.
- imtringued 7y ago
  >I'm surprised this is possible. Yeah, I'm surprised that the terminal bell still exists in 2020. >My understanding was that compilers don't consciously check for UB and then decide to make the dev's life hell if they find some. That was the case during the 20th century. In the 20 years compilers have gotten far more aggressive. They do actively check for UB. >It's more that compilers pretend that certain assumptions are true even though this cannot actually be verified. What often happens is that UB gets detected and information that is clearly available in the source code gets erased in the compiler to follow the letter of the standard. There is a lot of UB code that can run without problems if the compiler didn't interfere. >So if you can explicitly check for code that causes UB, why permit it at all? Why not abort compilation or at least emit a warning? A lot of UB can only be detected at runtime. The most sensible interpretation of UB would be to simply skip these checks in production builds but keep them in debug builds so that developers can avoid UB in their code. Example: Bitshifting can result in UB but if both operands are variables the UB can be detected at runtime.
  - aw1621107 7y ago
    > What often happens is that UB gets detected and information that is clearly available in the source code gets erased in the compiler to follow the letter of the standard. I'm not sure how much I agree with this. I agree that compilers have gotten a lot better about deriving information from UB analysis in the past decade or two, but I think a lot of the time it gains information from the additional analysis rather than ignoring existing information. The main example I can think of for a compiler ignoring information from the source code is strict aliasing, where the compiler can ignore the fact that two addresses can be statically proven to point to the same memory location [0] (although to be fair that's from 2009; I'm not sure whether GCC still does this). For stuff like null pointer dereferences, signed overflow, or OOB dereferences, though, the compiler can (sometimes?) derive stricter bounds, which means the compiler is gleaning more information from the source code than it has previously. [0]: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg01647.html https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg...
  - dTal 7y ago
    >I'm surprised that the terminal bell still exists in 2020. Why? Given that terminals still exist in 2020, it's just as useful today as when it was conceived - if anything moreso, since we often have dozens of terminals to monitor. On many systems a terminal bell will even result in a desktop notification - lovely!
tyilo 7y ago
Off-topic: I get the same weird font display on this site as on microsoft's login page. It seems like the font is specified as: font: 13px 'Segoe UI','Segoe UI Emoji','Segoe UI Symbol','Lato','Helvetica Neue',Helvetica,Arial,sans-serif; and the first font I have avaiable seems to be Segoe UI Emoji and Segoe UI Symbol, which looks horrible: https://i.imgur.com/KS19dRA.png https://i.imgur.com/KS19dRA.png Removing them both from the list gives the following result: https://i.imgur.com/ReI0W4Z.png https://i.imgur.com/ReI0W4Z.png I guess I have the emoji and symbol font installed for Segoe UI and not the main font.
- tyilo 7y ago
  Hmm, I fixed it by uncommenting the lines for matching Segoe UI Emoji and Segoe UI Symbol. /etc/fonts/conf.avail/75-joypixels.conf
trelliscoded 7y ago
On the mac it opens a youtube video if you hit over 9000 undefined behaviors...

22 points by gok 7y ago

xg15 7y ago

Question to people with more knowledge in the matter: This runtime will emit sound, most traditionally the terminal's bell sound, when undefined behavior occurs. I'm surprised this is possible. My understanding was that compilers don't consciously check for UB and then decide to make the dev's life hell if they find some. It's more that compilers pretend that certain assumptions are true even though this cannot actually be verified. If they happen to not be true (but the compiler still behaves as if they were), undefined behaviour occurs. So if you can explicitly check for code that causes UB, why permit it at all? Why not abort compilation or at least emit a warning?

comex 7y ago
UBSan detects (certain types of) undefined behavior at runtime, not compile time. The compiler is involved, as UBSan works by adding checks to the generated assembly code: for example, whenever the original code adds two signed integers, the compiler adds code that checks whether overflow occurred, and triggers an error report if so. (Or with this patch, a bell sound!) But the compiler doesn't know ahead of time what the inputs to the addition will be.
ithkuil 7y ago
Indeed the ubsan sanitizer is designed to catch undefined behavior while compiling and is designed to emit an error when it founds code that hits undefined behaviour, statically. Yet, this patch is fun answer to those people who are annoyed by the number of errors that running their codebase through ubsan will produce and might think "that's just for edge cases, I'm pretty sure in practice I'll never hit effects of those at runtime". Compile with ubsan_bel and listen in horror how often it actually happens.... > Yes, this is April 1st and the patch isn't particularly serious.
- comex 7y ago
  Pretty sure that's not true. Clang has a static analyzer, but UBSan is not part of that; it's a purely dynamic analysis that detects issues at runtime.
imtringued 7y ago
>I'm surprised this is possible. Yeah, I'm surprised that the terminal bell still exists in 2020. >My understanding was that compilers don't consciously check for UB and then decide to make the dev's life hell if they find some. That was the case during the 20th century. In the 20 years compilers have gotten far more aggressive. They do actively check for UB. >It's more that compilers pretend that certain assumptions are true even though this cannot actually be verified. What often happens is that UB gets detected and information that is clearly available in the source code gets erased in the compiler to follow the letter of the standard. There is a lot of UB code that can run without problems if the compiler didn't interfere. >So if you can explicitly check for code that causes UB, why permit it at all? Why not abort compilation or at least emit a warning? A lot of UB can only be detected at runtime. The most sensible interpretation of UB would be to simply skip these checks in production builds but keep them in debug builds so that developers can avoid UB in their code. Example: Bitshifting can result in UB but if both operands are variables the UB can be detected at runtime.
- aw1621107 7y ago
  > What often happens is that UB gets detected and information that is clearly available in the source code gets erased in the compiler to follow the letter of the standard. I'm not sure how much I agree with this. I agree that compilers have gotten a lot better about deriving information from UB analysis in the past decade or two, but I think a lot of the time it gains information from the additional analysis rather than ignoring existing information. The main example I can think of for a compiler ignoring information from the source code is strict aliasing, where the compiler can ignore the fact that two addresses can be statically proven to point to the same memory location [0] (although to be fair that's from 2009; I'm not sure whether GCC still does this). For stuff like null pointer dereferences, signed overflow, or OOB dereferences, though, the compiler can (sometimes?) derive stricter bounds, which means the compiler is gleaning more information from the source code than it has previously. [0]: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg01647.html https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg...
- dTal 7y ago
  >I'm surprised that the terminal bell still exists in 2020. Why? Given that terminals still exist in 2020, it's just as useful today as when it was conceived - if anything moreso, since we often have dozens of terminals to monitor. On many systems a terminal bell will even result in a desktop notification - lovely!

tyilo 7y ago

Off-topic: I get the same weird font display on this site as on microsoft's login page. It seems like the font is specified as: font: 13px 'Segoe UI','Segoe UI Emoji','Segoe UI Symbol','Lato','Helvetica Neue',Helvetica,Arial,sans-serif; and the first font I have avaiable seems to be Segoe UI Emoji and Segoe UI Symbol, which looks horrible: https://i.imgur.com/KS19dRA.png https://i.imgur.com/KS19dRA.png Removing them both from the list gives the following result: https://i.imgur.com/ReI0W4Z.png https://i.imgur.com/ReI0W4Z.png I guess I have the emoji and symbol font installed for Segoe UI and not the main font.

tyilo 7y ago
Hmm, I fixed it by uncommenting the lines for matching Segoe UI Emoji and Segoe UI Symbol. /etc/fonts/conf.avail/75-joypixels.conf

trelliscoded 7y ago

On the mac it opens a youtube video if you hit over 9000 undefined behaviors...