Hi Ben,
In sample example I shared, I was trying to simulate a behaviour similar to
what my application(based on top of V8) saw - sleep calls were added to somehow
make this example artificially simulate the app. I’ve modified the gist, hoping
now it doesn’t create confusion.
Here is sample output from it, I’ll explain below what they mean(annotating by
line no to make it easy to explain, otherwise would need ascii drawing :)):
line# Output Message
====================================
1 debugger.ccTestBreakPoints179
2 debugger.ccTestBreakPoints181
3 debugger.ccSendDebugUserRequest146
4 2016-08-16.21:33:16 DebugSetBreakpointHandler
{"seq":0,"request_seq":1,"type":"response","command":"setbreakpoint","success":true,"body":{"type":"scriptId","breakpoint":1,"script_id":33,"line":1,"column":0,"actual_locations”:
[{"line":1,"column":4,"script_id":33}]},"refs":[],"running":true}
5 2016-08-16.21:33:18 DebugListBreakpointHandler
{"seq":1,"request_seq":3,"type":"response","command":"listbreakpoints","success":true,"body":{"breakpoints":[{"number":1,"line":1,"column":0,"groupId":null,"active":true,"condition":null,"actual_locations":[{"line":1,"column":4,"script_id":33}],"type":"scriptId","script_id":33}],"breakOnExceptions":false,"breakOnUncaughtExceptions":false},"refs":[],"running":true}
6 debugger.ccSendDebugUserRequest148
7 2016-08-16.21:33:18SendDebugUserRequest{"type": "json",
"client": "Chrome Canary", "counter":0}
8 debugger.ccSendDebugUserRequest162
9 2016-08-16.21:33:18 DebugListBreakpointHandler
{"seq":2,"type":"event","event":"break","body":{"invocationText":"DebugUserRequest(doc=#<Object>)","sourceLine":1,"sourceColumn":4,"sourceLineText":"
if (doc.type === \"json\")
{","script":{"id":33,"name":null,"lineOffset":0,"columnOffset":0,"lineCount":6},"breakpoints":[1]}}
10 debugger.ccTestClearBreakPoints208
<Execution stuck beyond this point>
Line 1-2,4, 5 - basically setup breakpoint and lists them
Line 3,6,7-9 - trying to call the user supplied JS code but it doesn’t proceed
to finish execution because it’s waiting at the breakpoint set earlier - hoping
someone would fire continue/clearbreakpoint
Line 10 - Attempt to clear breakpoint but this guy can’t proceed further
because the user supplied code(currently stuck at breakpoint) is holding the
lock to the isolate
So my question is, how can the user supplied code execution could proceed
further in this case?
> On 16-Aug-2016, at 7:20 PM, Ben Noordhuis <[email protected]> wrote:
>
> On Tue, Aug 16, 2016 at 1:10 PM, Abhishek Singh
> <[email protected]> wrote:
>> Hi,
>>
>> I’m using V8 Debugger, but facing an issue.
>>
>> https://gist.github.com/abhi-bit/20b8569bc5d655659b51d425564eb49d - this is
>> link to standalone code simulating the same problem. In short, what this
>> code does is:
>>
>> * Main thread i.e. the calling JS code with required params periodically.
>> Given it’s Local<Function> Call, I’m using V8::Locker(without it handlescope
>> errors out asking me to use locking api)
>> * Debug thread, that basically sets breakpoint -> list breakpoints and
>> finally clears the breakpoints in that order(with some sleep pause in
>> between the call), this too is using Locker and hence leading to the problem
>> I’m facing.
>>
>> In the given test case, main thread keeps running for first 10 secs and
>> doesn’t let Debug thread to proceed(because main thread has a lock for the
>> isolate) - so essentially I can’t do debug operations from another thread.
>> How can I avoid using locker in either main and debug threads or both and
>> debug user supplied JS code at runtime? Looking at v8 debug unit tests, I
>> don’t see it using locker anywhere in there.
>>
>> Thanks,
>> Abhishek
>
> Your threads should not sleep while holding the Locker. Let it go out
> of scope before calling this_thread::sleep_for().
>
> You could create a v8::Unlocker instance but you need to exit the
> Context scope first so letting the Locker go out of scope is probably
> just as easy.
>
> --
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" 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-users mailing list
[email protected]
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" 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.
