Turns out that in the case of -fsanitize=null and a virtual call,
the type check was generated *after* reading from vtable, which
causes a non-interpretable segfault. The check has been moved up
in https://reviews.llvm.org/D26559 and this CL adds a test for this case.
Details
Diff Detail
- Build Status
Buildable 1189 Build 1189: arc lint + arc unit
Event Timeline
sync & address the comments.
test/ubsan/TestCases/TypeCheck/null.cpp | ||
---|---|---|
1–10 | It's a debug left over. Thank you for the catch. | |
10 | Debug leftover. Removed. Thank you for spotting this. | |
35 | Actually, the real reason for adding these is that break_optimization didn't really fool the compiler, and I had to add some more logic to avoid letting it know that the pointer is always null => it's undefined behavior. In my case, I saw my return being ignored and two switch statements executed together. I can't currently reproduce it now, most likely, because the fix has eliminated the virtual call on a pointer that is guaranteed to be null. So, I have removed these as well as break_optimization calls. |
Is this #include needed?