[jsc-dev] Tracking down GC issue

[Geoffrey Garen]

…You could also try JSC_useZombieMode=1 along with JSC_useImmortalObjects=1.

Geoff

> On Jan 17, 2017, at 12:15 PM, Geoffrey Garen <ggaren at apple.com> wrote:
> 
> You can look at the Apple iOS builders (https://build.webkit.org/console?category=iOS <https://build.webkit.org/console?category=iOS>) to see what they do.
> 
> Geoff
> 
>> On Jan 17, 2017, at 12:14 PM, Dan Zimmerman <daniel.zimmerman at me.com <mailto:daniel.zimmerman at me.com>> wrote:
>> 
>> Thanks for the tips. Do you have any tips on compiling for iOS (this is an iOS app that I've been working with)? The main issues I've ran into are that the JSCLLIntOffsetExtractor won't get the proper offsets for arm/arm64 and then when trying to just compile for simulator I got linking issues.
>> 
>> (Sorry Geoff for duplicating the email to you - forgot to CC the email list at first).
>> 
>> Dan
>> 
>>> On Jan 17, 2017, at 2:11 PM, Geoffrey Garen <ggaren at apple.com <mailto:ggaren at apple.com>> wrote:
>>> 
>>> One debugging technique I like is to modify the GC to run all destructors eagerly and scribble all objects with zeros. That can make the bug easier to reproduce.
>>> 
>>> Your hypothesis is that you’ve called JSValueProtect on all objects that need it. Could also be valuable to add logging to JSValueProtect and JSValueUnprotect to verify that hypothesis.
>>> 
>>> Geoff
>>> 
>>>> On Jan 17, 2017, at 11:52 AM, Dan Zimmerman <daniel.zimmerman at me.com <mailto:daniel.zimmerman at me.com>> wrote:
>>>> 
>>>> Are there any tools to debug when objects are destructed? Since this happens within a CodeBlock it must be either a captured variable or a previous argument right? All functions that I store on the heap I'm sure to JSValueProtect, so I'm unsure how to go about looking into the lifetime of those captured objects.
>>>> 
>>>> Dan
>>>> 
>>>>> On Jan 17, 2017, at 1:45 PM, Geoffrey Garen <ggaren at apple.com <mailto:ggaren at apple.com>> wrote:
>>>>> 
>>>>> The GC often nulls out the first word of an object after running its destructor.
>>>>> 
>>>>> The most likely cause of your bug is an object lifetime issue.
>>>>> 
>>>>> Geoff
>>>>> 
>>>>>> On Jan 16, 2017, at 7:04 PM, Dan Zimmerman <daniel.zimmerman at me.com <mailto:daniel.zimmerman at me.com>> wrote:
>>>>>> 
>>>>>> Hey,
>>>>>> 
>>>>>> I apologize in advanced if this mailing list is inappropriate for this content.
>>>>>> 
>>>>>> I've ran into the bug that appears to be the root issue for both https://bugs.webkit.org/show_bug.cgi?id=160027 <https://bugs.webkit.org/show_bug.cgi?id=160027> and https://bugs.webkit.org/show_bug.cgi?id=149957 <https://bugs.webkit.org/show_bug.cgi?id=149957>. I'd like to try and figure out if I'm misusing the C API/if there's anything I can do to prevent the crash (as it seems like there are plenty of clients of JSC that don't run into this issue, it makes me believe either I'm doing something wrong or there's something that I can change). Unfortunately the codebase is under an NDA so I cannot share snippets here. It appears that the JSCell that are referenced in certain code blocks are being nulled out, as the JSCell at crash looks like this:
>>>>>> 
>>>>>> m_structureID: 0
>>>>>> m_indexingType: 0
>>>>>> m_type: UnspecifiedType (0)
>>>>>> m_flags: 0
>>>>>> m_cellState: AnthraciteOrBlack (0)
>>>>>> 
>>>>>> If I set the environment variable JSC_useZombieMode=1 then the crash doesn't occur (and no unexpected behavior occurs - the application actually works as desired). It feels wrong to ship anything with useZombieMode enabled so I was wondering if there's any guidance to figuring out the source of the issue.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Dan
>>>>>> _______________________________________________
>>>>>> jsc-dev mailing list
>>>>>> jsc-dev at lists.webkit.org <mailto:jsc-dev at lists.webkit.org>
>>>>>> https://lists.webkit.org/mailman/listinfo/jsc-dev <https://lists.webkit.org/mailman/listinfo/jsc-dev>
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/jsc-dev/attachments/20170117/21904ac1/attachment.html>