Thank you, Andreas, for getting to the bottom of this.

Hemang.
Andreas Kupries wrote:
>  I finally managed to repro it here, overcoming a different bug in Komodo
>  itself too.
> 
>  It is a bug in the spawn handling of dbgp_tcldebug ...
> 
>  *	Using Tcl 8.5, and snit 2 the command resolution changed subtly.
> 
>  *	This caused an [eval] in the spawn processing to not be the
>  	core ::eval, but an app internal command.
> 
>  *	This is turn caused the port number for the new session to be
>  	some Tcl command string instead of a number, and appLaunch.tcl
>  	then threw an error on that, exiting silently.
> 
>  I will rebuild the dbgp_tcldebug(.exe).
> 
>  --
>  	Andreas Kupries <andreask@[...].com>
>  	Developer @ http://www.ActiveState.com
>  	Tel: +1 778-786-1122
> 
> 
>    
> > -----Original Message-----
> > From: tdk-bounces@[...].com
> > [mailto:tdk-bounces@[...].com]On Behalf Of Andreas
> > Kupries
> > Sent: Wednesday, November 19, 2008 12:19 PM
> > To: Hemang Lavana; Alex Panchenko
> > Cc: Jeff Hobbs; dbgp@listserv.activestate.com;
> > komodo-discuss@listserv.ActiveState.com; tdk@[...].com
> > Subject: Re: [TDK] [Komodo-discuss] Tcl remote debugger and spawnpoints
> >
> >
> >
> >     
> >> -----Original Message-----
> >> From: tdk-bounces@[...].com
> >> [mailto:tdk-bounces@[...].com]On Behalf Of Hemang Lavana
> >> Sent: Tuesday, November 18, 2008 1:53 PM
> >> To: Alex Panchenko
> >> Cc: Jeff Hobbs; dbgp@listserv.activestate.com;
> >> komodo-discuss@listserv.ActiveState.com; tdk@[...].com
> >> Subject: Re: [TDK] [Komodo-discuss] Tcl remote debugger and spawnpoints
> >>
> >>
> >> Hi all,
> >>
> >> Any updates on whether this issue has been resolved or not?
> >>
> >> Thanks,
> >> Hemang.
> >> Alex Panchenko wrote:
> >>       
> >>> Hi,
> >>>
> >>> Here is the detailed information.
> >>>         
> > Reading closely
> >
> >     
> >>> There are to files: parent.tcl and child.tcl
> >>>
> >>> === parent.tcl ===
> >>> proc spawn {cmd args} {
> >>>     puts [exec [info nameofexecutable] $cmd $args]
> >>> }
> >>>
> >>> puts "PARENT STARTED"
> >>> spawn child.tcl
> >>> puts "PARENT FINISHED"
> >>> === child.tcl ====
> >>> puts "CHILD STARTED"
> >>> puts "CHILD FINISHED"
> >>> ==================
> >>>         
> > Looking ok.
> >
> >     
> >>> The contents of the files is based on the
> >>> http://docs.activestate.com/tdk/5.0/Debugger.html#mult_processes
> >>>         
> >>> The command line used to start debugger is (all on the same line):
> >>> C:\TCL-Debug\5\dbgp_tcldebug.exe
> >>>  -dbgp 192.168.3.135:10000
> >>>  -app-shell C:\Tcl85\bin\tclsh85.exe
> >>>  -ide-key dbgp_1225872443074
> >>>  -log -logfile C:\TCL-Debug\log
> >>>  -app-file C:\home\tcl-spawnpoints\parent.tcl --
> >>>         
> > Looks ok as well, knows where to find Komodo, or rather your frontend app.
> >
> >     
> >>> DBGP request:
> >>> spawnpoint_set -s enabled -n 6 -i 68 -f
> >>> file:///C:/home/tcl-spawnpoints/parent.tcl
> >>>         
> > Looks ok as well
> >
> >     
> >>> DBGP response:
> >>> <?xml version="1.0" encoding="UTF-8" ?>
> >>> <response xmlns="urn:debugger_protocol" command="spawnpoint_set"
> >>> transaction_id="68" state="enabled" id="0" />
> >>>         
> > And is accepted. So, dbgp_tcldebug, and the application under debug agree
> > that this is a spawnpoint.
> >
> >
> >     
> >>> After that:
> >>> run -i 70
> >>>
> >>> response:
> >>> - a few stream/OUTPUT packets, followed by
> >>> <?xml version="1.0" encoding="UTF-8" ?>
> >>> <response xmlns="urn:debugger_protocol" command="run"
> >>> transaction_id="70" status="stopping" reason="ok" />
> >>>
> >>> Debuggger log:
> >>> The whole log file size is about 200kb, the spawnpoint
> >>>         
> > handling part is:
> >     
> >>> ...
> >>> LOG(timing,3271527680): HandleNubEvent ENTER
> >>> LOG(message,3271527680): reading 105 bytes
> >>> LOG(message,3271527680): got (105): 'SPAWN_RQ {{0 {} global} {0
> >>>         
> >> {1 6 {97
> >>       
> >>> 16}} source C:/home/tcl-spawnpoints/parent.tcl}} {} {spawn child.tcl}'
> >>> LOG(timing,3271527680): HandleNubEvent SPAWN_RQ
> >>> debug     | appState = stopped (traced, sync'd)
> >>> LOG(timing,3271527680): DeliverEvent stdin ()
> >>> debug     | appState = running (traced, sync'd)
> >>>         
> > The application under debug recognizes the spawnpoint, has invoked the
> > internal replacement for 'spawn' and asks dbgp_tcldebug for the relevant
> > info (SPAWN_RQ).
> >
> >
> >     
> >>> LOG(message,3271527680): sent: len=117 'SPAWN_ACK alex
> >>> {::dbgp::client::Spawn request {spawn child.tcl} ::client}
> >>>         
> > The debugged application has received the spawn info from dbgp_tcldebug
> > (SPAWN_ACK)
> > Per the attached spawn.pdx is will run the child process, except
> > if no port
> > was specified (= denied). I do not see that.
> >
> >
> >     
> >>> C:/TCL-Debug/5/appLaunch.tcl {} tcldbgp2472'
> >>> LOG(timing,3271542680): HandleNubEvent ENTER
> >>> ...
> >>>
> >>> Output:
> >>> PARENT STARTED
> >>> PARENT FINISHED
> >>>
> >>> Output if there is no spanwpoint or if spawnpoint is disabled:
> >>> PARENT STARTED
> >>> CHILD STARTED
> >>> CHILD FINISHED
> >>> PARENT FINISHED
> >>>
> >>> So it looks like the new process is not started if there is a
> >>>         
> >> spawnpoint.
> >>       
> > Which, according to the spawn.pdx code  can happen only if there is a Tcl
> > error before the exec.
> >
> > The other possibility is that the child process is launched, but something
> > in its initialization fails before the user code is reached, and then it
> > silently exits. Like for example, does
> >
> >  	C:/TCL-Debug/5/appLaunch.tcl
> >
> > exist ? That is the actual entrypoint for the child, to initialize the
> > debugger nub in the child, before child.tcl is run.
> >
> > One thing which could be done would be to add 'puts' statements to the
> > appLaunch file which writes to a fixed log file on the box. After the
> > failing run check how much of that file is executed per these puts. If
> > something happens there before child.tcl is run ... Well, as said above,
> > that would be a very silent exit.
> >
> >
> >
> >
> >     
> >>> Also, it should made subsequent DBGP connection from the
> >>>         
> > child process,
> >     
> >>> but it also does not happen.
> >>>         
> > If something goes wrong with the child process startup the dbgp_tcldebug
> > will not open a connection, as it has no new session to open it for. I.e.
> > this is likely a follow-on behaviour to the original problem.
> >
> >
> >     
> >>> It should be enough information to reproduce the issue. If you
> >>>         
> >> need more
> >>       
> >>> information - please let me know.
> >>>
> >>> Thanks,
> >>> Alex
> >>>
> >>>
> >>> Jeff Hobbs wrote:
> >>>
> >>>         
> >>>> Alex Panchenko wrote:
> >>>>
> >>>>           
> >>>>> I am not sure what mailing list should be used for my question, so I
> >>>>> will post to all related ones.
> >>>>>
> >>>>> I am interested in the DBGP support of the spawnpoints. Does tcl
> >>>>> remote debugger support spawnpoints?
> >>>>>
> >>>>> At the moment Komodo IDE does not allow me even to setup spawnpoints
> >>>>> when remote debugger is attached.
> >>>>> I can debug the same code with spawnpoint using Tcl Dev Kit
> >>>>>             
> > Debugger,
> >     
> >>>>> but it looks like it uses proprietary protocol to communicate with
> >>>>> the launched process.
> >>>>>
> >>>>>             
> >>>> Yes, the TDK Debugger uses a different Tcl-oriented protocol as it
> >>>> preceded dbgp and was designed just for Tcl.  The debugger backends
> >>>> between TDK and Komodo use the same debugging core for Tcl though.
> >>>> There handling of spawnpoints will vary as the protocol
> >>>>           
> > allows, but as
> >     
> >>>> it is the debugging core with the support, it should be "the same".
> >>>>
> >>>>
> >>>>           
> >>>>> Back to the DBGP: I can send spawnpoint_set command (and verify the
> >>>>> result with spawnpoint_list), but when the process reaches the
> >>>>> specified line nothing happens. Should I use some undocumented
> >>>>> commands to make it work, is it a bug or a missing feature?
> >>>>>
> >>>>> My configuration is
> >>>>> - Windows XP
> >>>>> - Tcl 8.4
> >>>>> - latest tcl remote debugger
> >>>>>
> >>>>>             
> >>>> In my testing, one obvious variation that I noted was that TDK will
> >>>> report invalid spawnpoint lines (lines not recognized by the debugger
> >>>> as allowable spawn points).  In TDK, a dialog will show to indicate
> >>>> this, but I received no such feedback from Komodo.
> >>>>
> >>>> Currently only [exec], [spawn] and [thread::create] are recognized
> >>>> spawn point generators.  This is a hardcoded core list (unless you
> >>>> extend with .pdx files), and I noticed one quirk about this ...
> >>>> exp_spawn was not recognized, whereas spawn was.  This is
> >>>>           
> > something we
> >     
> >>>> need to correct.
> >>>>
> >>>> In any case, that may be what you hit.  You are using the
> >>>>           
> > correct dbgp
> >     
> >>>> commands though.  Can you describe in more detail the tests you are
> >>>> using?  Have you tried running dbgp_tcldebug with -log (activate
> >>>> logging) and -logfile myfile.txt (redirect log from stdout to file)?
> >>>> That should provide more detailed information.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Jeff
> >>>>
> >>>>           
> >>> _______________________________________________
> >>> TDK mailing list
> >>> TDK@[...].com
> >>> http://listserv.ActiveState.com/mailman/listinfo/tdk
> >>>
> >>>         
> >> _______________________________________________
> >> TDK mailing list
> >> TDK@[...].com
> >> http://listserv.ActiveState.com/mailman/listinfo/tdk
> >>       
> > --
> > 	Andreas Kupries <andreask@[...].com>
> > 	Developer @ http://www.ActiveState.com
> > 	Tel: +1 778-786-1122
> >
> >
> >     
> 
>  _______________________________________________
>  TDK mailing list
>  TDK@[...].com
>  http://listserv.ActiveState.com/mailman/listinfo/tdk
>    

_______________________________________________
TDK mailing list
TDK@[...].com
http://listserv.ActiveState.com/mailman/listinfo/tdk