Svadev mailing list

[John Criswell <criswell AT illinois.edu>]

On 7/11/11 11:23 AM, Matthew Wala wrote:
> On Mon, Jul 11, 2011 at 11:10 AM, John 
> Criswell<criswell AT illinois.edu>
>   wrote:
> > On 7/11/11 11:06 AM, Matthew Wala wrote:
> >
> > Hello everyone:
> > When I compile the attached test case with SAFECode (tried on asha and
> > bach) I get a large number of Out of Bounds / Load Store errors. The
> > test calls gmtime() which returns static memory. These errors also
> > occur if the function that is called is replaced with localtime().
> >
> > Check to see if gmtime() and localtime() are recognized by DSA's StdLib
> > pass.  If so, then what is probably happening is that they are being marked
> > complete, but since the memory objects aren't registered, you get an error.
> I did check, and there are entries for those functions in StdLibPass.
> There's also entries for ctime() and asctime(). It looks like all four
> of those functions have the same flags in the StdLibPass table, but
> despite that the error still occurs. Perhaps the flags are wrong.

So, you have a couple of options for how to fix this:

1) Modify the StdLibPass to mark the DSNode of the static memory with 
the External flag.
2) Modify SAFECode to register the memory returned by these functions 
into a pool.
3) Modify SAFECode's CompleteChecks pass to not make these memory 
objects complete.

Option 2 is probably the best as it will provide the greatest safety.

It may also be worth enhancing the exactcheck optimization pass to treat 
these functions like allocators.  I'd be willing to bet that many of 
these memory objects are only accessed within the function in which they 
are called and would benefit from the exactcheck optimization.

-- John T.

> I tested ctime() once more, and it looks that reading the output from
> ctime() actually does cause a Load / Store error.
> (The reason my previous testing didn't recognize this is that I did a
> simple printf("%s\n", ctime(...)); call, and it looks like the C
> frontend lowers such calls to puts(), which SAFECode doesn't currently
> handle (I think I should probably add support for puts() in the
> CStdLib pass for this reason). So the read of the value of ctime() was
> being done in external code, which is why it didn't raise any errors.)
>
> Matt
>
> > If other functions aren't recognized by DSA's StdLib pass, then the pointer
> > is being marked External, which means that SAFECode won't raise an error if
> > the memory object isn't found in the pool.
> >
> > -- John T.
> >
> > However, other time-related functions that return static memory like
> > ctime() (as well as the reentrant versions of gmtime() and
> > localtime()) do not cause SAFECode to complain.
> > Before filing a bug I'd like to know if there is a reason for this
> > behavior or if this is already known.
> >
> > Thanks,
> > Matt
> >
> >
> > _______________________________________________
> > svadev mailing list
> > svadev AT cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/svadev