> > I created 2 tickets [1] for the merge, [2] for the fix, I attached it the fixed FDB. Main thread with the target file is not paused > Switching workers when VM is paused after new worker creation seems to > work now, that' great! > Setting a breakpoint to the file that is not loaded yet and will be > loaded later by a new worker also seems to work, that's even more cool!
Yep :-) > I still see the issue with setting a breakpoint in incorrect file when > all workers are loaded but the file belongs to non active one. See [1] > > Next steps: > > 1- Fix the bad message when a file is not found > What do you mean? It seems I meant just what you said: > I still see the issue with setting a breakpoint in incorrect file when > all workers are loaded but the file belongs to non active one. See [1] But I reduced my sentence to the message: > Breakpoint 1: file MP3Worker.as, line 30 // WRONG FILE > > BTW IntelliJ uses only breakpoints, no watches and displays. I will still need to apply the same logic to each potential command that could have the same issue. > - 'break' command may be called with file name or with file id. If it is > called with file id then probably the right thing is to apply the > command to the current worker only Good point, I keep that ! > - the same file may belong to several workers. So probably fdb should > iterate all suspended workers and try to set the breakpoint for all that > contain this file. I would have suspended all workers instead and place a BP in each if it belongs to. Why to put some BP in on the suspended ones ? > - new workers that contain this file may appear later. And each existing > worker that doesn't contain the file may get new bytecode loaded with > this file. So despite of the result of the previous attempts fdb should > remember the breakpoint location and try to set it for all new workers > that appear later. Also each time when new code is loaded fdb should try > to set breakpoint again for each existing worker that didn't contain the > file before. Yep, was my goal too. Frédéric THOMAS > Date: Wed, 30 Apr 2014 15:37:38 +0400 > From: alexander.doros...@jetbrains.com > To: dev@flex.apache.org > Subject: Re: [FDB] Integration > > On 30.04.2014 14:14, Frédéric THOMAS wrote: > > I created 2 tickets [1] for the merge, [2] for the fix, I attached it the > > fixed FDB. Main thread with the target file is not paused > Switching workers when VM is paused after new worker creation seems to > work now, that' great! > Setting a breakpoint to the file that is not loaded yet and will be > loaded later by a new worker also seems to work, that's even more cool! > I still see the issue with setting a breakpoint in incorrect file when > all workers are loaded but the file belongs to non active one. See [1] > > Next steps: > > 1- Fix the bad message when a file is not found > What do you mean? > > 2- New feature: Automaticaly set back the breakpoints, watches and displays > > when another instance of the worker is created and the "-ide" argument is > > passed to FDB > The feature needs to be thoroughly thought over. There are too many > cases to keep in mind: > - 'break' command may be called with file name or with file id. If it is > called with file id then probably the right thing is to apply the > command to the current worker only > - if 'break' command is followed by the file name then still there are a > lot of cases: > - definitely fdb should try to find this file in the current worker and > set breakpoint if found > - the same file may belong to several workers. So probably fdb should > iterate all suspended workers and try to set the breakpoint for all that > contain this file. > - new workers that contain this file may appear later. And each existing > worker that doesn't contain the file may get new bytecode loaded with > this file. So despite of the result of the previous attempts fdb should > remember the breakpoint location and try to set it for all new workers > that appear later. Also each time when new code is loaded fdb should try > to set breakpoint again for each existing worker that didn't contain the > file before. > > BTW IntelliJ uses only breakpoints, no watches and displays. > > > 3- In the Falcon repo, merge FDB with its classes using the Falcon AST > > > > Any comments are welcome. > > > > Frédéric THOMAS > > > > [1] https://issues.apache.org/jira/browse/FLEX-34291 > > [2] https://issues.apache.org/jira/browse/FLEX-34292 > [1] > Apache fdb (Flash Player Debugger) [build 20140430] > Copyright 2013 The Apache Software Foundation. All rights reserved. > (fdb) run > Waiting for Player to connect > Player connected; session starting. > Set breakpoints and then type 'continue' to resume the session. > (fdb) c > [SWF] C:\work\flex_projects\MP3Worker\bin-debug\MP3Worker.swf - 175а169 > bytes after decompression > [WorkerCreate] 1 > Additional ActionScript code has been loaded from a SWF or a frame. > To see all currently loaded files, type 'info files'. > Active worker has changed to worker 1 > > Set additional breakpoints as desired, and then type 'continue'. > (fdb) c > [SWF] C:\work\flex_projects\MP3Worker\bin-debug\MP3Worker.swf - 493а264 > bytes after decompression > halt > Do you want to attempt to halt execution? (y or n) y > Attempting to halt. > To help out, try nudging the Player (e.g. press a button) > Execution halted at 0x00009aeb (39659) > (fdb) worker 0 > Active worker has changed to worker Main Thread > (fdb) halt > Attempting to suspend Player execution... > Player stopped > (fdb) info workers > Main Thread 0 - Suspended (Active) > Worker 1 - Suspended > (fdb) break BackWorker.as:30 > Breakpoint 1: file MP3Worker.as, line 30 // WRONG FILE >
