Svadev mailing list

[Matthew Wala <wala1 AT illinois.edu>]

On Thu, Sep 22, 2011 at 9:47 AM, John Criswell 
<criswell AT illinois.edu>
 wrote:
> On 9/21/11 5:47 PM, Matthew Wala wrote:
>>
>> Hi everyone:
>>
>> I think I may know why my code was triggering memory safety bugs in
>> the LLVM test suite program MultiSource/Applications/d. It turns out
>> that d uses strdup() as an allocator. In
>> lib/Support/AllocatorInfo.cpp, the
>> StringAllocatorInfo:getOrCreateAllocSize uses a call to strlen() to
>> determine the size of the allocation. The problem is that the real
>> size of strdup(s) is strlen(s) + 1, but the current code just does
>> strlen(s). So I believe it was registering the item in the pool with
>> the wrong object size, which is why my checks were giving an off by
>> one error.
>
> Can you easily verify that, in fact, the pool_register() call is using
> strlen(s) and not strlen(s) + 1 as the object registration size?  If you can
> verify it, then you know that's the problem, and you can fix it.
>

Yes. For instance SAFECode took the following instruction sequence

char *c = strdup("string");

and the resulting code was:

  %call = call noalias i8* @strdup(i8* getelementptr inbounds ([7 x
i8]* @.str, i32 0, i32 0)) nounwind
  %1 = call i64 @strlen(i8* getelementptr inbounds ([7 x i8]* @.str,
i32 0, i32 0))
  %2 = trunc i64 %1 to i32
  call void @pool_register_debug(i8* null, i8* %call, i32 %2, i32 0,
i8* getelementptr inbounds ([5 x i8]* @sourcefile, i32 0, i32 0), i32
1)

I fixed it in revision 140351.

Matt

>
> -- John T.
>
>>  I don't know if that makes sense though, since it seems
>> like an issue that should have been caught before.
>>
>> Matt
>> _______________________________________________
>> svadev mailing list
>> svadev AT cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/svadev
>
>