llvm dev - May 2012 - [LLVMdev] 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 at localhost ~]# clang --version
clang version 3.2 (trunk)
Target: i386-pc-linux-gnu
Thread model: posix


On OS

Centos -6
[root at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120525/ab350f78/attachment.html>

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

On Fri, May 25, 2012 at 3:57 PM, Umesh Kalappa <umesh.kalappa0 at
gmail.com>wrote:
> 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 at localhost ~]# clang --version
> clang version 3.2 (trunk)
> Target: i386-pc-linux-gnu
> Thread model: posix
>
>
> On OS
>
> Centos -6
> [root at 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
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120525/b6b6c8d2/attachment.html>

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

On 5/25/12 6:57 AM, Umesh Kalappa wrote:
> 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.
>
> For you reference
> I'm using the clang version as
>
>     [root at localhost ~]# clang --version
>     clang version 3.2 (trunk)
>     Target: i386-pc-linux-gnu
>     Thread model: posix
>
>
> On OS
>
>     Centos -6
>     [root at 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
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120525/0ff08cdb/attachment.html>

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
On May 25, 2012 7:54 PM, "John Criswell" <criswell at
illinois.edu> wrote:
>  On 5/25/12 6:57 AM, Umesh Kalappa wrote:
>
> 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.
>
>
>  For you reference
> I'm using the clang version as
>
>  [root at localhost ~]# clang --version
>  clang version 3.2 (trunk)
>   Target: i386-pc-linux-gnu
>  Thread model: posix
>
>
>  On OS
>
> Centos -6
>  [root at 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
>
>
>
>
> _______________________________________________
> cfe-dev mailing listcfe-dev at
cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120528/dd51fd3c/attachment.html>