You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a simple script that sets UBSAN_OPTIONS, TSAN_OPTIONS, etc. all at once to specify log_path for each sanitizer.
On Linux/gcc everything is as expected but when I compile with TSAN using AppleClang on MacOSX it appears that TSAN takes the log_path from UBSAN_OPTIONS instead of TSAN_OPTIONS if both are set. If only TSAN_OPTIONS are set then everything works as expected. This leads to ThreadSanitizer output land in TestName.ubsan.log.[PID].
The text was updated successfully, but these errors were encountered:
So my assumption from glancing at the code you pointed me to is that on AppleClang TSAN is built with support for UBSAN but on my Linux it happens to be not, hence the difference. Is that what you mean @Enna1 ?
One thing I don't understand is why the implementation overrides my TSAN options with UBSAN options. It would make more sense if UBSAN options are parsed first and then overridden by TSAN options if they are available. Then further refined by command line options if needed. Would you say this is still a bug?
I'm ok to ignore this since in my use case I will never have the code built nor ran with more than one sanitiser at a time but I feel like the logic is backwards in the current implementation.
I have a simple script that sets
UBSAN_OPTIONS
,TSAN_OPTIONS
, etc. all at once to specifylog_path
for each sanitizer.On Linux/gcc everything is as expected but when I compile with TSAN using AppleClang on MacOSX it appears that TSAN takes the
log_path
fromUBSAN_OPTIONS
instead ofTSAN_OPTIONS
if both are set. If onlyTSAN_OPTIONS
are set then everything works as expected. This leads to ThreadSanitizer output land inTestName.ubsan.log.[PID]
.The text was updated successfully, but these errors were encountered: