<div dir="ltr">It's called by strtol (there's a strtol@plt in the assembly code). It seems to be a problem just with this function.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 10, 2015 at 5:59 AM, Evgeniy Stepanov <span dir="ltr"><<a href="mailto:eugeni.stepanov@gmail.com" target="_blank">eugeni.stepanov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Apr 10, 2015 at 5:22 AM, Keno Fischer<br>
<<a href="mailto:kfischer@college.harvard.edu">kfischer@college.harvard.edu</a>> wrote:<br>
> Thanks! I'll try that.<br>
><br>
> In order to avoid starting a new thread, let me ask you the next question.<br>
> One of the shared libraries I load calls strtol and msan fails to intercept<br>
> it. Why would this be? The library seems to be otherwise implemented. One of<br>
> the potential culprits I saw is that strtol is marked as strong in libc. Is<br>
> there any workaround?<br>
<br>
</span>Strong symbol should not be a problem. What name is it called by?<br>
There are a number of __strtol_internal, __strtol_l and other variants<br>
that we intercept.<br>
It is a problem with all calls from that library, or just this one function?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> Keno<br>
><br>
> On Thu, Apr 9, 2015 at 3:00 PM, Evgeniy Stepanov <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Thu, Apr 9, 2015 at 9:24 PM, Keno Fischer<br>
>> <<a href="mailto:kfischer@college.harvard.edu">kfischer@college.harvard.edu</a>> wrote:<br>
>> > Hi everyone,<br>
>> ><br>
>> > I ran into a false positive with memory sanitizer due to it not<br>
>> > intercepting<br>
>> > dlinfo. I tried to get started on writing such an interceptor, but<br>
>> > dlinfo<br>
>> > seems like an extraordinarily difficult function to intercept. The three<br>
>> > considerations that I would like somebody to look at are:<br>
>> ><br>
>> > 1) How do we get the enum values to decide what kind of pointer dlinfo<br>
>> > is<br>
>> > getting. Ideally we'd include dlfcn.h, but the interceptor file doesn't<br>
>> > generally include system headers. What's the right thing to do here?<br>
>><br>
>> We generally redefine system constants and types in<br>
>> sanitizer_platform_limits_posix.h and verify correctness with<br>
>> assertions in .cc.<br>
>><br>
>> > 2) The structures pointed to contain linked lists, etc. of dynamic<br>
>> > linker<br>
>> > state. In order to avoid spurious failures, it seems like we should<br>
>> > iterate<br>
>> > the linked lists and unpoison all of them, but that seems expensive. Do<br>
>> > you<br>
>> > see a better solution?<br>
>><br>
>> Nope, sounds like that's want you need to do.<br>
>><br>
>> > 3) The return values include pointers into the object files. It seems<br>
>> > perfectly reasonable for a user to want to read these object files based<br>
>> > on<br>
>> > information from dlinfo. That probably means we should unpoison them as<br>
>> > well? Do we need to do something here or are these already unpoisoned by<br>
>> > some other mechanism (e.g. because msan realizes they are part of a<br>
>> > loaded<br>
>> > object file or unposions them on load - does this happen?).<br>
>><br>
>> They are unpoisoned. All memory defaults to unpoisoned (shadow == 0),<br>
>> and we take care of unpoisoning all memory we return to the OS.<br>
>><br>
>> ><br>
>> > Thanks,<br>
>> > Keno<br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>