Groups | Search | Server Info | Login | Register

Groups > comp.lang.tcl > #55516

Very hard to debug issue

Show all headers | View raw

I have a rather complicated process involving threads, channels and 
system processes. And it fails on one single computer until now.
The environment is Windows 11.

The errors I get are pretty random and I don't think they have much 
relevance. I have a hunch, that the errors are older catched errors, 
unrelated to the actual issue.

So the process is:

1. From the main thread, send a command on a parallel thread. The body 
of that command is seen below.
2. In the the parallel thread, that command opens some communication 
pipes and starts a new system process (an Tcl executable) with some 
command line parameters (variable $cmdline below)
3. I waits for the system process to end and returns the result.

Like I said, the above steps are failing, but only on one single PC 
until now. Many other PC are in use with no issues.

The user on that PC got full admin rights, and the problem is still 
there. Firewall and Anti Virus was checked and according to the IT, it 
blocks nothing.

In order to provide an workarround, I changed the first step so that 
that command is executed directly in the main thread instead in a 
parallel thread. This works!

But why?

This is very hard to debug, because changing things means changing the 
Tcl excutable app. I might come with another solution for this though.

But still, any ideas, why the command below fails only on one PC and 
only when executed in a parallel thread?

Is there something wrong about the chan pipes?

Could it still be a OS problem, something blocking the executation of an 
executable but only when the executable is started from the main app?

Many thanks
Alex


# Open different channels for read and write
lassign [chan pipe] processStdin writeChanId
lassign [chan pipe] readChanId processStdoutErr
# React when the read channel becomes readable (meaning, a new line was 
written to the channel)
chan event $readChanId readable "::meshparts::GeneratePartBatchRead 
$readChanId $processStdoutErr"
# Start the part generation process
set res [::twapi::create_process "" -cmdline $cmdline -returnhandles 1 
-inherithandles 1 -stdchannels [list $processStdin $processStdoutErr 
$processStdoutErr]]
# Store the process handles
lassign $res pid tid hproc hthread
# Wait for the process to end
set ::meshparts::twapi_pid($pid) ""
::twapi::wait_on_handle $hproc -executeonce 1 -async [list 
::meshparts::GlobalVarSetFromTwapiCallback ::meshparts::twapi_pid($pid) ""]
vwait ::meshparts::twapi_pid($pid)
::twapi::close_handle $hproc
# Get the last line written which is normally the path of the generated 
model file
if {[info exists lastline($readChanId)]} {
   set result $lastline($readChanId)
} else {
   set result ""
}
catch {close $readChanId}
catch {close $writeChanId}
catch {close $processStdin}
catch {close $processStdoutErr}
array unset lastline $readChanId
return $result

Back to comp.lang.tcl | Previous | Next — Next in thread | Find similar

Thread

Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-04 09:03 +0100
  Re: Very hard to debug issue undroidwish <undroidwish@googlemail.com> - 2026-03-04 10:12 +0100
    Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-04 12:35 +0100
    Re: Very hard to debug issue Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-11 17:12 +0000
  Re: Very hard to debug issue Ralf Fassel <ralfixx@gmx.de> - 2026-03-04 12:09 +0100
    Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-04 12:37 +0100
      Re: Very hard to debug issue Christian Gollwitzer <auriocus@gmx.de> - 2026-03-04 21:26 +0100
        Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-05 07:25 +0100
    Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-04 12:40 +0100
    Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-04 12:41 +0100
    Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-04 12:42 +0100
  Re: Very hard to debug issue Rich <rich@example.invalid> - 2026-03-04 13:05 +0000
    Re: Very hard to debug issue et99 <et99@rocketship1.me> - 2026-03-04 17:09 -0800
      Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-05 07:19 +0100
    Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-05 07:20 +0100
      Re: Very hard to debug issue Rich <rich@example.invalid> - 2026-03-05 13:29 +0000
        Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-05 16:43 +0100
          Re: Very hard to debug issue Rich <rich@example.invalid> - 2026-03-05 17:02 +0000
        Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-05 16:45 +0100
          Re: Very hard to debug issue et99 <et99@rocketship1.me> - 2026-03-05 11:49 -0800
            Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-06 08:32 +0100
              Re: Very hard to debug issue Rich <rich@example.invalid> - 2026-03-06 14:51 +0000
                Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-06 18:39 +0100
                Re: Very hard to debug issue Ralf Fassel <ralfixx@gmx.de> - 2026-03-16 12:12 +0100
                Re: Very hard to debug issue meshparts <alexandru.dadalau@meshparts.de> - 2026-03-18 21:28 +0100

csiph-web