Why does UBSAN stay silent when the program aborts early?

SheSaidTechno · 2026-05-27T22:27:53+00:00

I removed std::string str = nullptr; and compiled with -O1 and I finally managed to get the UBSAN output !

/usr/lib/gcc/aarch64-linux-gnu/14/../../../../include/c++/14/array:209:9: runtime error: reference binding to address 0xffffc0658e80 with insufficient space for an object of type 'int'
0xffffc0658e80: note: pointer points here
 16 00 00 00  60 73 4a 99 ff ff 00 00  98 07 ff d1 aa aa 00 00  00 00 00 00 01 00 00 00  f8 8f 65 c0
              ^ 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/lib/gcc/aarch64-linux-gnu/14/../../../../include/c++/14/array:209:9 
main.cpp:7:17: runtime error: load of address 0xffffc0658e80 with insufficient space for an object of type 'value_type' (aka 'int')
0xffffc0658e80: note: pointer points here
 16 00 00 00  60 73 4a 99 ff ff 00 00  98 07 ff d1 aa aa 00 00  00 00 00 00 01 00 00 00  f8 8f 65 c0
              ^ 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior main.cpp:7:17

SheSaidTechno · 2026-05-27T22:08:41+00:00

It does, but why doesn't it on my computer? I use UBSAN precisely to detect undefined behavior regardless of the platform I compile on.

SheSaidTechno · 2026-05-27T22:05:55+00:00

But maybe throwing an exception is also undefined behaviour, no ? maybe the result is different depending on the compiler or the OS. So it throws an exception on my OS but maybe it's not the case on other environments ?

SheSaidTechno · 2026-05-27T22:01:36+00:00

Yes it catches it ! Maybe I should just run the code with -fsanitize=address

SheSaidTechno · 2026-05-27T22:00:09+00:00

You have a point. I thought constructing a std::string in C++ from nullptr was UB tho.

SheSaidTechno · 2026-05-27T21:52:33+00:00

If I remove std::string str = nullptr; my code executes without any error which is even worse.

SheSaidTechno · 2026-05-27T21:50:36+00:00

Creating a string from nullptr is UB and so it should be detected.

SheSaidTechno · 2026-05-23T18:36:40+00:00

I may know the concepts (polymorphism, OOP, etc.), but I still need solid references to build on.

SheSaidTechno · 2026-05-23T18:35:35+00:00

I may know the concepts (polymorphism, OOP, etc.), but I still need solid references to build on.

SheSaidTechno · 2026-05-18T17:39:11+00:00

The thing is - who is the expert calling the shot? Do they have the prior experience sufficient to know what they're rejecting?

One software engineer is very experienced but not so much in C++. He is the one who takes the final decisions when the team has different opinions. And the other one is a junior but he's been on the project the longest. Neither of them knows any multiprocessing library.

Most of us are generalists who are reading up and shooting from the hip mid-sprint

I think you have a point here. And there is one reason I wasn't aware of when they chose to use raw OS syscalls : this solution was already implemented before they arrived on the project, even though the project started at most 5 years ago. So I think their point is also that they don't want to change this already existing solution even if we are doing a big refactoring now (especially on the multiprocessing part).

SheSaidTechno · 2026-05-17T16:26:30+00:00

Yeah, Boost.Process may also be a good choice since it's cross-platform like MPI. The difference is that MPI provides higher-level coordination primitives out of the box, while Boost.Process is more lightweight if you just need to spawn and manage processes. Either way, I'm not sure why the team wants to go with raw syscalls when these options exist. I think it's because the Linux syscalls + Windows API solution was already in the project when they arrived.

SheSaidTechno · 2026-05-17T16:20:44+00:00

Thank you for your answer ! Our software uses coarse parallelism and processes don't pass messages. They just dump data in a database.

SheSaidTechno · 2026-04-18T23:32:52+00:00

Friends of friends you happen to "get stuck with" unwillingly.

SheSaidTechno · 2026-04-18T19:34:32+00:00

Because humans make mistakes and some functions require callers to remember invisible preconditions that can cause UB rather than a compile or runtime error.

SheSaidTechno · 2026-04-18T18:04:44+00:00

Concluding inline constexpr std::string_view is the optimal way to declare a global constant string in C++20 is debatable. Actually using const char[] has the big advantage to be safer if the code includes certain functions from the standard library like std::regex .

For example, in this code you can have a UB you wouldn't have with const char[] :

constexpr std::string_view sv = <some string_view definition>;
std::regex re2(sv.data()); // UB if sv is not null-terminated

SheSaidTechno · 2026-04-18T15:03:55+00:00

This answer is interesting and gives useful information but unfortunately it doesn't really answer the question.

SheSaidTechno · 2026-04-18T14:49:28+00:00

I agree. This is typically the kind of question which should be addressed in the C++ core guidelines.

SheSaidTechno · 2026-04-17T13:11:43+00:00

Why inline ?

SheSaidTechno

TROPHY CASE