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