[PATCH] [UBsan] Dumping call stacks when reporting bad-cast (-fsanitize=vptr)

[Alexey Samsonov]

So, in short, we need to call UBSan initialization early enough. I believe
that even if we find a workaround for this today, we will still require it
some day tomorrow.
We may replace lazy initialization with a single call to __ubsan::Init()
and run it from .preinit_array (on Linux) or from a dynamic initializer (on
Mac).


On Thu, Jul 24, 2014 at 9:50 AM, Byoungyoung Lee <byoungyoung at google.com>
wrote:

> This is quite strange, but UBSAN_OPTIONS are not visible (i.e.,
> getEnv("UBSAN_OPTIONS") returns null) even when all Chrome sandboxes are
> disabled. So I suppose this is related to the Chrome's multi-process
> running model involving Zygote (i.e., UBsan init has to be executed from
> the Zygote process, not one of Zygote's child processes. However, all of
> rendering processes are running as a child process of the Zygote process
> while the Zygote process may wipe out all environment variables.). If the
> initialization is done at the very early running phase, UBsan can read
> UBSAN_OPTIONS though.
>
>
>
>
> On Thu, Jul 24, 2014 at 12:29 AM, Byoungyoung Lee <byoungyoung at google.com>
> wrote:
>
>> Thanks Alexey for turning my sloppy patch into way better one!
>>
>> Yes, I was calling the InitializeSanitizerCommon() in the early phase to
>> initialize UBSan before the Chrome sandbox kick in. As I tried Clang ToT
>> today, I found another issue that UBSAN_OPTIONS was not visible in
>> InitializeSanitizerCommon() for Chrome (I suspect this is also related to
>> the Chrome sandboxing, but haven't verified yet). Please let me try more
>> tomorrow.
>>
>> Thanks,
>> Byoungyoung
>>
>>
>>
>>
>> On Wed, Jul 23, 2014 at 12:01 PM, Alexey Samsonov <vonosmas at gmail.com>
>> wrote:
>>
>>> I've incorporated your patch into r213783. Now if you want to see stack
>>> traces in vptr checker, but don't want to run online symbolization you can
>>> provide UBSAN_OPTIONS="symbolize=0 print_stacktrace=1". Let me know if
>>> you're OK with this change. One thing that wasn't submitted is call to
>>> InitializeSanitizerCommon() early in __ubsan_handle_dynamic_type_cache_miss
>>> (before we even check for duplicated report or for cache miss). It would be
>>> really costly and weird to add initialization at this place. I assume that
>>> you're trying to initialize UBSan as early as possible in presence of
>>> Chromium sandbox. Is that right?
>>>
>>>
>>> On Wed, Jul 23, 2014 at 8:53 AM, Byoungyoung Lee <byoungyoung at google.com
>>> > wrote:
>>>
>>>> Thank you Alexey!
>>>>
>>>>
>>>> On Tue, Jul 22, 2014 at 6:24 PM, Alexey Samsonov <vonosmas at gmail.com>
>>>> wrote:
>>>>
>>>>> FYI I'm working on a slightly modified version of this patch. Will
>>>>> update this thread tomorrow.
>>>>>
>>>>> http://reviews.llvm.org/D4410
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Alexey Samsonov
>>> vonosmas at gmail.com
>>>
>>
>>
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140724/16eca25a/attachment.html>