svadev AT lists.siebelschool.illinois.edu
Subject: Svadev mailing list
List archive
- From: Matthew Wala <wala1 AT illinois.edu>
- To: David Keaton <dmk AT dmk.com>
- Cc: "svadev AT cs.uiuc.edu" <svadev AT cs.uiuc.edu>
- Subject: Re: [svadev] question about SAFECode output
- Date: Thu, 19 Jan 2012 19:45:10 -0600
- List-archive: <http://lists.cs.uiuc.edu/pipermail/svadev>
- List-id: <svadev.cs.uiuc.edu>
Hi David,
On Thu, Jan 19, 2012 at 1:22 PM, David Keaton
<dmk AT dmk.com>
wrote:
> Matt,
>
> Thanks for your help.
>
>
> On 01/18/2012 06:35 PM, Matthew Wala wrote:
>>
>> I'm pretty sure this is why the long error sequence occurs:
>>
>> http://lists.cs.uiuc.edu/pipermail/svadev/2011-August/000104.html
>
>
> That explains a lot, thanks.
>
>
>> If you want to output only the first error message and then exit, use
>> the '-fmemsafety-terminate' option along with '-fmemsafety' when
>> compiling your code.
>
>
> Actually, I am looking for just the opposite. I would like to run a
> program to completion, and then afterward look at the list of buffer
> overflows that occurred.
>
> Many programs work in spite of their buffer overflows. For example,
> they may allocate 15 bytes, but use 16, and they get away with it because 16
> bytes were reserved by the compiler or library for alignment purposes.
>
> Benchmarks are another category where run-to-completion is important.
>
> There are a couple of ways to implement this in a memory safety
> compiler/runtime system. One is to report the error and then let the
> program go on and do what it does. Another is to have the memory safety
> runtime system fake-extend each object to the maximum size that is actually
> accessed, as described in some of the papers on the subject.
>
> I thought SAFECode did the latter. Is it a special option that needs to
> be turned on explicitly, or is it not implemented?
>
To my knowledge, none of the SAFECode runtimes attempt to do any sort
of object extension when a memory safety error occurs.
>
>> As to why the program counter is printed as 0x8, it looks like the
>> runtime was accessing the wrong register value on x86-64 Linux. This
>> should be fixed in revision 148458.
>
>
> Thanks for fixing this! The sample program from the SAFECode Users
> Guide now shows a reasonable-looking program counter for these faults. It
> also now terminates after 20 faults, rather than continuing to fault
> indefinitely. Is this a newly designed limit? If so, can it be turned off
> to achieve run-to-completion?
>
The 20 error limit has been in place for a while. Which version of
SAFECode were you using prior to updating to the one in which the
program counter bug was fixed?
To get the infinite fault behavior that you saw previously, comment
out lines 132-134 of runtime/DebugRuntime/Report.cpp. However that's
probably not what you want, because you will not get any progress
since the program just keeps segfaulting at the same instruction. I'm
not sure how you could avoid that.
Matt
>
> I've appended the new output from the Users Guide sample program below.
>
> David
>
- [svadev] question about SAFECode output, David Keaton, 01/18/2012
- Re: [svadev] question about SAFECode output, Matthew Wala, 01/18/2012
- Re: [svadev] question about SAFECode output, David Keaton, 01/19/2012
- Re: [svadev] question about SAFECode output, Matthew Wala, 01/19/2012
- Re: [svadev] question about SAFECode output, David Keaton, 01/20/2012
- Re: [svadev] question about SAFECode output, John Criswell, 01/23/2012
- Re: [svadev] question about SAFECode output, Matthew Wala, 01/19/2012
- Re: [svadev] question about SAFECode output, David Keaton, 01/19/2012
- Re: [svadev] question about SAFECode output, Matthew Wala, 01/18/2012
Archive powered by MHonArc 2.6.16.