[cfe-dev] -fsanitize=undefined and shared libraries

[Richard Smith]

On Thu, Jan 17, 2013 at 12:05 PM, Martin Martin
<martin at silverliningsystems.com> wrote:
> Hey Will,
>
> I'm using vanilla clang/compiler-rt, not the "always link in ubsan"
> workaround.
>
> It now compiles and runs my unit tests!  However, using std::fixed like
> this:
>
> #include <iostream>
>
> int main()
> {
>     std::cout << std::fixed;
>     return 0;
> }
>
> Gives this error message:
>
> $ clang++ -g -fsanitize=undefined foo.cpp && ./a.out
>
> ==15067== WARNING: Trying to symbolize code, but external symbolizer is not
> initialized!
>
> /home/martin/cache/lib/a.out:0x402918: runtime error: load of value
> 4294967035, which is not a valid value for type 'std::_Ios_Fmtflags'
> /home/martin/cache/lib/a.out:0x402b44: runtime error: load of value
> 4294967035, which is not a valid value for type 'std::_Ios_Fmtflags'
>
> Two questions:
>
> Should I ignore the warning, if not, how do I fix it?
>
> Is there a way to suppress messages from the standard library?  I'm guessing
> not, but I can write a quick script on my end to filter them out.

This is a bug in libstdc++. You will be able to work around it with a
sanitizer blacklist file, once Will's patch for that lands, but for
now, filtering them out manually is likely to be your best option.

Here's a patch to fix it; I'll be looking into pushing this to
libstdc++ upstream in the next few days.

--- bits/ios_base.h
+++ bits/ios_base.h
@@ -87,7 +87,7 @@

   inline _GLIBCXX_CONSTEXPR _Ios_Fmtflags
   operator~(_Ios_Fmtflags __a)
-  { return _Ios_Fmtflags(~static_cast<int>(__a)); }
+  { return _Ios_Fmtflags(static_cast<int>(__a) ^
static_cast<int>(_S_ios_fmtflags_end - 1)); }

   inline const _Ios_Fmtflags&
   operator|=(_Ios_Fmtflags& __a, _Ios_Fmtflags __b)
@@ -127,7 +127,7 @@

   inline _GLIBCXX_CONSTEXPR _Ios_Openmode
   operator~(_Ios_Openmode __a)
-  { return _Ios_Openmode(~static_cast<int>(__a)); }
+  { return _Ios_Openmode(static_cast<int>(__a) ^
static_cast<int>(_S_ios_openmode_end - 1)); }

   inline const _Ios_Openmode&
   operator|=(_Ios_Openmode& __a, _Ios_Openmode __b)
@@ -165,7 +165,7 @@

   inline _GLIBCXX_CONSTEXPR _Ios_Iostate
   operator~(_Ios_Iostate __a)
-  { return _Ios_Iostate(~static_cast<int>(__a)); }
+  { return _Ios_Iostate(static_cast<int>(__a) ^
static_cast<int>(_S_ios_iostate_end - 1)); }

   inline const _Ios_Iostate&
   operator|=(_Ios_Iostate& __a, _Ios_Iostate __b)


> On Thu, Jan 17, 2013 at 12:19 PM, Will Dietz <willdtz at gmail.com> wrote:
>>
>> Bah, missed one! :).  Thanks Alexey, fixed in r172730.
>>
>> Martin, can you update and try now?  Let me know if you have any
>> further linking issues.
>>
>> As an aside, are you using vanilla clang/compiler-rt, or did you need
>> to apply the "always link in ubsan" workaround discussed in this
>> thread?
>>
>> Thanks, happy code checking! :)
>>
>> ~Will
>>
>> On Thu, Jan 17, 2013 at 9:21 AM, Alexey Samsonov <samsonov at google.com>
>> wrote:
>> >
>> > On Thu, Jan 17, 2013 at 7:02 PM, Martin Martin
>> > <martin at silverliningsystems.com> wrote:
>> >>
>> >> Any word on this linking error?  Would a test case help?
>> >>
>> >> Thanks,
>> >> Martin
>> >>
>> >>
>> >>
>> >> On Sat, Jan 12, 2013 at 4:40 PM, Martin Martin
>> >> <martin at silverliningsystems.com> wrote:
>> >>>
>> >>> Great, that works!  The next linking error I get is:
>> >>>
>> >>>  hidden symbol `__ubsan_vptr_type_cache' in
>> >>>
>> >>> /home/martin/clang/build/bin/../lib/clang/3.3/lib/linux/libclang_rt.ubsan-x86_64.a(ubsan_type_hash.cc.o)
>> >>> is referenced by DSO
>> >
>> >
>> > Just a random guess - would adding SANITIZER_INTERFACE_ATTRIBUTE to
>> > __ubsan_vptr_type_cache definition help? Like this:
>> > extern "C" SANITIZER_INTERFACE_ATTRIBUTE HashValue
>> > __ubsan_vptr_type_cache[VptrTypeCacheSize];
>> >
>> >
>> >>>
>> >>>
>> >>> It's a little trouble for me to narrow down the test case, but I'm
>> >>> happy
>> >>> to do it if it helps.
>> >>>
>> >>> Thanks,
>> >>> Martin
>> >>>
>> >>
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> cfe-dev at cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >>
>> >
>> >
>> >
>> > --
>> > Alexey Samsonov, MSK
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >
>
>