[LLVMdev] [cfe-dev] About Address San...

[John Criswell]

On 5/28/12 3:27 AM, Umesh Kalappa wrote:
>
> 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.


>
> Thanks Again.
>
> ~Umesh
>
> On May 25, 2012 7:54 PM, "John Criswell" <criswell at illinois.edu 
> <mailto: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 list
>>     cfe-dev at cs.uiuc.edu  <mailto: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/20120528/2c8146e2/attachment.html>