Thanks, SudoKid, but I’m not really interested in troubleshooting this 
faster, I simply took this issue (for which I already have a solution) as a 
case to finally start digging into debugging with v8 a bit more.

On Thursday, October 4, 2018 at 7:08:38 PM UTC+2, SudoKid wrote:
>
> It sounds like you would likely be able to troubleshoot the issue faster 
> by reaching out to the React community.
>
> If you are not planning on referencing the variable you could always use a 
> const and that way it shouldn't be able to be set to `null` without 
> throwing an error.
>
> If you are using React/Redux I would suggest looking at your reducers. I 
> experienced slimier issues in the past.
>
> On Thursday, October 4, 2018 at 5:33:28 AM UTC-7, [email protected] 
> wrote:
>>
>> Hmm, that makes sense. Is there an internal object reference I can use 
>> that does stay stable?
>>
>> And sorry if this wasn't clear from my message, but as I know nothing yet 
>> of v8 do you have any pointers to the source where assignment occurs?
>>
>> On Thursday, October 4, 2018 at 2:28:42 PM UTC+2, Yang Guo wrote:
>>>
>>> Unfortunately this won't work 100% of the time. V8's GC may move 
>>> objects, so the address you would need to watch is not fixed.
>>>
>>> Yang
>>>
>>> On Thu, Oct 4, 2018 at 2:25 PM <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I’m completely new to v8, so bare with me. Because the node debugging 
>>>> facility lacks the ability to define watchpoints (i.e. break when a 
>>>> variable changes), I was thinking that maybe I could do so at the VM level 
>>>> using lldb/gdb.
>>>>
>>>> The code I’m trying to debug tries to access a global variable, which 
>>>> somewhere during execution gets set to `null`. A pseudo example looks like:
>>>>
>>>> ```
>>>> var doc = document
>>>> debugger // <- here the object is a non-null value as expected
>>>> // Enzyme (a React testing utility) renders an async React tree and 
>>>> somewhere during that period `document` gets set to `null`
>>>> mount(<SomeComponentThatDoesAsyncRendering />) // <- an exception is 
>>>> raised because `document` is `null`
>>>> ```
>>>>
>>>> My thinking is:
>>>>
>>>> 1. I use node/v8’s JS debugger to hit a breakpoint where I know the 
>>>> variable is what I expect it to be
>>>> 2. break using lldb/gdb, find the JS variable
>>>> 3. set a native watchpoint or a conditional breakpoint on the VM code 
>>>> that assigns variables for the address of the JS variable
>>>> 4. when the native breakpoint hits, get a JS execution stack trace to 
>>>> find the location that is assigning the new (`null`) value
>>>>
>>>> Does this make any sense?
>>>>
>>>> Cheers,
>>>> Eloy
>>>>
>>>> -- 
>>>> -- 
>>>> v8-dev mailing list
>>>> [email protected]
>>>> http://groups.google.com/group/v8-dev
>>>> --- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "v8-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>

-- 
-- 
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
--- 
You received this message because you are subscribed to the Google Groups 
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to