About Address San...

Hi All ,

I’m not sure the question is relevant to the forum,My apologies if not

We are trying to instrument our code with ASan(Clang) to find the memory errors and we see that the application execution halts when the Asan check finds the memory issue at the being. Which mean we need to fix the issue then compile and execute the instrumented code again to find the next issue and so on .Which is fine.

We would like to know that there is any option to clang or llvm ,Where we can say to Asan to log output to the file and continue to execute the instrumented application instead of halting the same.Like Valgrind memcheck has.So we can whole or almost issues in the log .

For you reference
I’m using the clang version as

[root@localhost ~]# clang --version

clang version 3.2 (trunk)

Target: i386-pc-linux-gnu

Thread model: posix

On OS

Centos -6

[root@localhost ~]# uname -a

Linux localhost.localdomain 2.6.32-220.el6.i686 #1 SMP Tue Dec 6 16:15:40 GMT 2011 i686 i686 i386 GNU/Linux

Thanks
~Umesh

Hi Umesh,

Yes, asan dies on the first detected error.
This is our design choice and there is no flag to override this.

If curious, these are the reasons behind such choice:

  1. The call to the error reporting routine inserted by asan is marked as noreturn, which makes the tool ~6-7% faster.
  2. Bugs detectable by asan are almost always very serious, whereas Valgrind/memcheck can report not-that-serious bugs (e.g. leaks)

Hope this helps,
–kcc

Hi Umesh,

We are trying to instrument our code with ASan(Clang) to find the memory
errors and we see that the application execution halts when the Asan check
finds the memory issue at the being. Which mean we need to fix the issue
then compile and execute the instrumented code again to find the next issue
and so on .Which is fine.

We would like to know that there is any option to clang or llvm ,Where we
can say to Asan to log output to the file and continue to execute the
instrumented application instead of halting the same.Like Valgrind memcheck
has.So we can whole or almost issues in the log .

This is not currently supported.
Once you've read the data from a wild pointer you may get into trouble
if any sensitive code is using it.
Wild writes are even more dangerous, because they may corrupt the
stack, the heap or other data structures.
Because it is generally hard to recover from such situations, ASan
just terminates the program.

You can try to instrument only the writes (pass "-mllvm
-asan-instrument-reads=false" to the compiler) to skip the less
interesting error reports, but you can't print all of them at once.

HTH,
Alexander

Hi All ,

I’m not sure the question is relevant to the forum,My apologies if not

We are trying to instrument our code with ASan(Clang) to find the memory errors and we see that the application execution halts when the Asan check finds the memory issue at the being. Which mean we need to fix the issue then compile and execute the instrumented code again to find the next issue and so on .Which is fine.

We would like to know that there is any option to clang or llvm ,Where we can say to Asan to log output to the file and continue to execute the instrumented application instead of halting the same.Like Valgrind memcheck has.So we can whole or almost issues in the log .

SAFECode’s clang supports this feature in its debug mode; I think the number of failures before termination is configurable via a command-line option. The price that it pays is extra performance overhead and an inability to detect the dereference of out-of-bounds pointers in external library code.

SAFECode also supports a feature to log error reports to a separate file instead of on stderr.

If you find the continued execution feature useful, please let all of us know. Since these features make design tradeoffs, it’s useful to learn what is useful and what isn’t.

That said, if ASan is finding a genuine memory safety error, you should fix that bug.

– John T.

Hi John and All,
Thank you for the your inputs,we tried running Safecode with Liblto on our code base few weeks back,I’m very sorry to say this that we feel that safecode is not so stable and output is not so informative ,Please correct us if i’m wrong here.

Thanks Again.

~Umesh

Hi John and All,
Thank you for the your inputs,we tried running Safecode with Liblto on our code base few weeks back,I’m very sorry to say this that we feel that safecode is not so stable and output is not so informative ,Please correct us if i’m wrong here.

Can you be more specific about how SAFECode was not stable or its output was not informative? Even though you’ve decided not to use it, we’d like to know details on what you think is wrong so that we can determine if it can be improved.

Also, may I ask what program you were compiling with SAFECode? If it’s open source, we might give SAFECode a spin on it ourselves.

Two other things that might influence your decision:

  1. Did you compile programs with the -g option? If not, then SAFECode’s error reports will not provide any useful debugging output.

  2. Will Dietz recently made some extraordinary memory consumption improvements to the code used in the libLTO module. If memory consumption was the problem you were having with SAFECode’s libLTO, that is fixed now.

– John T.