Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

@SMWRITE invalid handle

Joe Caverly

Joe Caverly

Aug
2,293
111
Code: 
     _x64: 1
   _admin: 1
_elevated: 1

TCC  25.00.20 x64   Windows 10 [Version 10.0.18362.476]

I cannot get the @smwrite function to work unless it is called from a subroutine.

Rem out the Gosub GSLoop and quit, and it returns
Code: 
e:\utils>smtest
@smopen hnd: 3988
TCC: (Sys) E:\Utils\smtest.btm [10]  The handle is invalid.
 "%@smwrite[3988,0,a,Step    1]"
TCC: (Sys) E:\Utils\smtest.btm [10]  The handle is invalid.
 "%@smwrite[3988,10,a,Step    2]"
TCC: (Sys) E:\Utils\smtest.btm [10]  The handle is invalid.
 "%@smwrite[3988,20,a,Step    3]"

...for each iteration.

Can anyone else reproduce this, or have my tired eyes missed something?

Joe

Code: 
@setlocal
@echo off
Gosub GSLoop
quit

set hnd=%@smopen[10000,"Test"] > nul
echo @smopen hnd: %hnd
set ptr=0
Do kount=1 to 1000
  set theString=Step %@formatn[4.0,%kount]
  echo %@smwrite[%hnd,%ptr,a,%theString] > nul
  ::echo %@smread[%hnd,%ptr,a,%@len[%theString]]
  set ptr=%@eval[%ptr+10]
enddo
echo @smclose hnd: %@smclose[%hnd]

endlocal
quit

:GSLoop
set hnd=%@smopen[10000,"Test"] > nul
echo @smopen hnd: %hnd
set ptr=0
Do kount=1 to 1000
  set theString=Step %@formatn[4.0,%kount]
  echo %@smwrite[%hnd,%ptr,a,%theString] > nul
  ::echo %@smread[%hnd,%ptr,a,%@len[%theString]]
  set ptr=%@eval[%ptr+10]
enddo
echo @smclose hnd: %@smclose[%hnd]
Return
 
setlocal / endlocal?

@SMOPEN[ size, name ] - Open and return a handle to shared memory.

size - The size of shared memory (in bytes)

name - The name of the shared memory. The name can have a "Global\" or "Local\" prefix to create the object in the global or session namespace. If the name is "Global\", then only an elevated session can open the shared memory.
 
Hmmm! Joe, I put your code, unchanged, into a BTM. It worked. Then I REM'd the "gosub" and "quit" (near the top). It worked again.
 
Thanks @vefatica.

I quit out of TCMD, and launched a single TCC. I get the same error.

However, when I run the .BTM with TCC-RT, I get no error.

What's the difference? I start TCC-RT with the /I option.

So, I tried
Code: 
"%comspec" /i /c smtest.btm
where
Code: 
E:\utils>echo %comspec
C:\Program Files\JPSoft\TCMD25\TCC.EXE
with the /I option, and also, no error.

Thus, there has to be something in either my .INI file, library functions, plugins, TCSTART or TCEXIT that is causing problems with @smwrite.

Thanks again for testing.

Joe
 
Nope. I don't think it has anything to do with the .INI file, library functions, plugins, TCSTART or TCEXIT either.

From a TCC window in TCMD, I can run the .btm and get the error, but no error if I run, from the same TCC, prefixed with TCC.EXE;
Code: 
e:\utils>smtest.btm
Called from Subroutine
@smopen hnd: 2288
@smclose hnd: 0
Called from Main
@smopen hnd: 2696
TCC: (Sys) E:\Utils\smtest.btm [12]  The handle is invalid.
 "%@smwrite[2696,0,a,Step    1]"
TCC: (Sys) E:\Utils\smtest.btm [12]  The handle is invalid.
 "%@smwrite[2696,10,a,Step    2]"
TCC: (Sys) E:\Utils\smtest.btm [12]  The handle is invalid.
 "%@smwrite[2696,20,a,Step    3]"
TCC: (Sys) E:\Utils\smtest.btm [12]  The handle is invalid.
 "%@smwrite[2696,30,a,Step    4]"
TCC: (Sys) E:\Utils\smtest.btm [12]  The handle is invalid.
 "%@smwrite[2696,40,a,Step    5]"
@smclose hnd: 0

e:\utils>"C:\Program Files\JPSoft\TCMD25\TCC.EXE" /c smtest.btm
Called from Subroutine
@smopen hnd: 820
@smclose hnd: 0
Called from Main
@smopen hnd: 820
@smclose hnd: 0

e:\utils>

From a PowerShell 64 window in TCMD;
Code: 
PS E:\utils> & "C:\Program Files\JPSoft\TCMD25\TCC.EXE" /c smtest.btm
Called from Subroutine
@smopen hnd: 816
@smclose hnd: 0
Called from Main
@smopen hnd: 816
@smclose hnd: 0
PS E:\utils>

From a CMD 64 window in TCMD;
Code: 
e:\utils>"C:\Program Files\JPSoft\TCMD25\TCC.EXE" /c smtest.btm
Called from Subroutine
@smopen hnd: 832
@smclose hnd: 0
Called from Main
@smopen hnd: 880
@smclose hnd: 0

e:\utils>

Joe
 
vefatica said:
Joe, did you figure it out?
Click to expand...
Hey @vefatica, I think I found the problem. Hopefully you can duplicate it.

I stripped my TCSTART.BTM down to the following;
Code: 
@if %_pipe != 0 .or. %_transient != 0 .or. %_ide != 0 quit
rem   set _alias=%@sfn[%@path[%comspec]\alias.lst]
rem   set _function=%@sfn[%@path[%comspec]\function.lst]
echo %comspec
@if %_pipe ne 1 .and. %_transient ne 1 cd E:\utils

...and it produces no error;
Code: 
TCC  25.00.20 x64   Windows 10 [Version 10.0.18362.476]
Copyright 2019 JP Software Inc.  All Rights Reserved
Registered to DESKTOP-JOE

rem   set _alias=%@sfn[%@path[%comspec]\alias.lst]
rem   set _function=%@sfn[%@path[%comspec]\function.lst]
echo C:\Program Files\JPSoft\TCMD25\TCC.EXE
[e:\utils]smtest
Called from Subroutine
@smopen hnd: 824
@smclose hnd: 0
Called from Main
@smopen hnd: 824
@smclose hnd: 0

[e:\utils]

Un-REM either of those lines, and the error returns;
Code: 
TCC  25.00.20 x64   Windows 10 [Version 10.0.18362.476]
Copyright 2019 JP Software Inc.  All Rights Reserved
Registered to DESKTOP-JOE

set _alias=C:\PROGRA~1\JPSoft\TCMD25\alias.lst
rem   set _function=%@sfn[%@path[%comspec]\function.lst]
echo C:\Program Files\JPSoft\TCMD25\TCC.EXE
[e:\utils]smtest.btm
Called from Subroutine
@smopen hnd: 980
@smclose hnd: 0
Called from Main
@smopen hnd: 980
TCC: (Sys) E:\utils\smtest.btm [12]  The handle is invalid.
"%@smwrite[980,0,a,Step    1]"
TCC: (Sys) E:\utils\smtest.btm [12]  The handle is invalid.
"%@smwrite[980,10,a,Step    2]"
TCC: (Sys) E:\utils\smtest.btm [12]  The handle is invalid.
"%@smwrite[980,20,a,Step    3]"
TCC: (Sys) E:\utils\smtest.btm [12]  The handle is invalid.
"%@smwrite[980,30,a,Step    4]"
TCC: (Sys) E:\utils\smtest.btm [12]  The handle is invalid.
"%@smwrite[980,40,a,Step    5]"
@smclose hnd: 0

[e:\utils]

Joe
 
Last edited:
I have re-worked those two environment variables as;
Code: 
set _alias="%@path["%comspec"]alias.lst"
set _function="%@path["%comspec"]function.lst"

...in my TCSTART.BTM, and no more errors with @SMWRITE.

Joe
 
Last edited:
This doesn't actually have anything to do with TCSTART or environment variables, The real problem is a compiler bug that is failing (sometimes) to properly initialize a variable. Doing random things previously can result in the address of that variable on the stack either being cleared (when it works) or filled with random values (when it doesn't).

I've fixed it for build 25.
 
You must log in or register to reply here.
Back
Top