nvm, solved it. Thanks for help thus far. > On 22-Aug-2016, at 11:23 AM, Abhishek Singh <[email protected]> > wrote: > > Modified the test program, link > https://gist.github.com/abhi-bit/20b8569bc5d655659b51d425564eb49d - debug > calls are now executing without grabbing Locker. > > Problem I see right now, is with following flow of events: > > User JS code running -> BreakPoint set -> ListBreakPoint call -> > ClearBreakPoint Call -> User JS code execution resume - In above test code > User JS code execution doesn’t resume. It appears for calling > Debug::ProcessDebugMessages(), Locker is required hence calling it while > executing JS code with required arguments - I think that’s a problem leading > to user code execution being stuck at breakpoint. Suggestions please? > > >> On 17-Aug-2016, at 11:09 PM, Ben Noordhuis <[email protected]> wrote: >> >> On Wed, Aug 17, 2016 at 4:51 PM, Abhishek Singh >> <[email protected]> wrote: >>> Hi Ben, >>> >>>> On 17-Aug-2016, at 5:43 PM, Ben Noordhuis <[email protected]> wrote: >>>> >>>> On Tue, Aug 16, 2016 at 6:22 PM, Abhishek Singh >>>> <[email protected]> wrote: >>>>> 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? >>>> >>>> I think I understand what you mean. It sounds like you should be >>>> using v8::Debug::SendCommand() from the second thread, >>> >>> Basically I’m trying to provide an IDE support for JS in the bundled >>> product, so IDE would never know when “clearbreakpoint" or “continue” >>> request is going to come. So when a “setbreakpoint” command is fired, I >>> need to point the MessageHandler, SendCommand and ProcessDebugMessage & >>> finally give up the Locker. I can’t hold up Locker from second thread(which >>> I assume you referred to set_break_point thread). Please correct me if my >>> assumption is wrong. >>> >>> >>>> without >>>> grabbing the Locker or changing the debug listener first. >>> >>> Till now, I’ve been doing hit and trail for different combinations to avoid >>> Locker - but I’ve never been able to run various debug command request >>> handler without grabbing Locker. But I see v8 test-debug.cc in all places >>> is testing debug apis without using Locker at all. Sorry I don’t know how >>> to run handler code without grabbing Locker, when you’ve some time could >>> you please comment on gist on what possibly I’m missing? >>> >>> About “changing the debug listener first” - I didn’t get what you mean. >>> Could you give hints on what specific changes you meant? >>> >>> Given you mentioned 3 different approaches that could help solve my current >>> issue(based on whatever explanation I was able to relay), I’m hoping one of >>> them would apply to my use case. >> >> In your gist, you call v8::Debug::SetMessageHandler() in a couple of >> places. I'd change that to once at start-up so you don't need to grab >> the Locker when you want to send a message - you don't need it for >> v8::Debug::SendCommand(). >> >> -- >> -- >> 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.
