[cfe-dev] i386 -faddress-sanitizer

[Carsten Mattner]

On Thu, Oct 18, 2012 at 11:55 PM, Anna Zaks <ganna at apple.com> wrote:
>
> On Oct 18, 2012, at 2:43 PM, Carsten Mattner <carstenmattner at gmail.com> wrote:
>
>> On Thu, Oct 18, 2012 at 10:50 PM, Carsten Mattner
>> <carstenmattner at gmail.com> wrote:
>>> On Thu, Oct 18, 2012 at 6:27 PM, Kostya Serebryany <kcc at google.com> wrote:
>>>>
>>>>
>>>> On Thu, Oct 18, 2012 at 8:19 PM, Carsten Mattner <carstenmattner at gmail.com>
>>>> wrote:
>>>>>
>>>>> On Thu, Oct 18, 2012 at 5:41 PM, Alexander Potapenko <glider at google.com>
>>>>> wrote:
>>>>>> You have two issues here then.
>>>>>> First, for some reason the linker doesn't like the unresolved calls to
>>>>>> ASan runtime in your shared object. Can you please attach the full
>>>>>> command line used to invoke the linker (feel free to obfuscate the
>>>>>> file names if needed, but please keep the flags).
>>>>>
>>>>> clang c_src/<PROJECT>.o -lstdc++ -v -faddress-sanitizer
>>>>>  -shared
>>>>>  -L/usr/local/lib/erlang/lib/erl_interface-3.7.8/lib
>>>>>  -lerl_interface -lei -o priv/<PROJECT>.so
>>>>> clang version 3.2 (http://llvm.org/git/clang.git
>>>>> 278eafa2cd8296f8128d13c6466a0ace3d03a872)
>>>>> (http://llvm.org/git/llvm.git
>>>>> 2360b7ad99eedecaae512373e7be49c2143550cf)
>>>>> Target: i386-pc-linux-gnu
>>>>> Thread model: posix
>>>>> "/usr/bin/ld" --eh-frame-hdr -m elf_i386 -shared -o priv/<PROJECT>.so
>>>>> /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../crti.o
>>>>> /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtbeginS.o
>>>>> -L/usr/local/lib/erlang/lib/erl_interface-3.7.8/lib
>>>>> -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2
>>>>> -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../.. -L/lib -L/usr/lib
>>>>> c_src/<PROJECT>.o -lstdc++
>>>>> -lerl_interface -lei -lgcc --as-needed -lgcc_s
>>>>> --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
>>>>> /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtendS.o
>>>>> /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../crtn.o
>>>>
>>>>
>>>> Hm. I don't see any reason for the failure here... Anyone?
>>>
>>> Is the probably special handling for .so files that automatically
>>> prevents linking in asan.a?
>>>
>>>>>> Second, you're going to have problems with unresolved symbols once you
>>>>>> load your shared object into a non-instrumented executable.
>>>>>> The only way to detect any errors in a shared library so far is to
>>>>>> rebuild the executable loading that library with ASan.
>>>>>> Please don't link libasan.a with the .so anyway, because you're likely
>>>>>> to have problems with the initialization order. ASan runtime needs to
>>>>>> be initialized at program startup.
>>>>>
>>>>> This makes sense and I'll build an instrumented Erlang runtime
>>>>> as a next step. With that in place do I still have to enable asan
>>>>> in CFLAGS when building the object file? I would say yes.
>>>>
>>>> You need to use -faddress-sanitizer while building the objects you
>>>> want to test. You don't need to instrument Erlang sources (but most
>>>> likely it won't hurt), just make sure that -faddress-sanitizer is
>>>> passed to the link command.
>>>
>>> That's good to know if all I want to check are faults in my
>>> shared object only.
>>>
>>>> BTW, we have the same problem with python.
>>>> In our private setting we solved it with "LD_PRELOAD=asan.so python x.py",
>>>> but I would not recommend this as a generally good approach.
>>>>
>>>>>
>>>>>
>>>>> Is this detail documented?
>>>>
>>>>
>>>> Probably no. I think we explain *how* asan works in detail, from which you
>>>> can deduct these limitations,
>>>> but that's not trivial.
>>>>
>>>>>
>>>>> If not maybe it should
>>>>
>>>>
>>>> Mmm. Perhaps.
>>
>> I can confirm it basically works now with the rebuilt
>> Erlang runtime. Thanks everybody!
>>
>> Speaking of finding errors, I never was able to find
>> errors in one or two projects I tried the clang static
>> analyzer on. Is there really nothings else to than
>> running the project's build wrapped with the scanner?
>
> That should have worked. Make sure that your project is
> clean before analyzing. You can also try inserting an error
> and checking if it is caught (something like:
> int foo() {int x = 0; return 5/x;}).

Thanks Anna that confirmed scan-build and scan-view work.
How did I not think of inserting buggy code. I must have assumed
my code is buggy enough.