Fixed GPF in SETLOCAL

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,555
46
Albuquerque, NM
prospero.unm.edu
#1
Okay, so this one is super-obscure! TCC crashes, extremely infrequently, on a SETLOCAL.

It happens only very rarely, but I can reproduce it. This only seems to happen when the entire environment -- including the current directories for all drives and the current value of CMDLINE -- is some specific size. So whether or not the crash occurs depends on exactly how the last command was invoked (e.g. TEST.BTM versus plain TEST), the current directory on all drives, whether or not TCC is running in a Take Command tab window (the TCMD and TCMDVER variables), and God knows what all else. I'm not certain exactly what the lethal size is, but it's somewhere close to 2048 bytes.

If I do a SET > ENVIRONMENT.OUT immediately before the offending SETLOCAL, I get a file 2,062 bytes long (//UnicodeOutput=No).

I honestly don't know whether this is something new in 13.04.55, or whether it's lain dormant for decades and I've only now stumbled across it.
 

Attachments

rconn

Administrator
Staff member
May 14, 2008
10,417
95
#3
Not reproducible here. (Note that you have more things in your environment than are visible, or that will be written with a "set >" command.)

I created a batch file that started with a 1K environment and then added one character to a variable every time through a loop:

Code:
do i=1 to 5000
set ralph=%ralph%a
Setlocal
echo %i
endlocal
enddo
This ran 25 times on my system without a hitch. Can you try running it on your system and see if you can reproduce the crash at a particular point?
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,555
46
Albuquerque, NM
prospero.unm.edu
#4
I created a batch file that started with a 1K environment and then added one character to a variable every time through a loop:

Code:
do i=1 to 5000
set ralph=%ralph%a
Setlocal
echo %i
endlocal
enddo
This ran 25 times on my system without a hitch. Can you try running it on your system and see if you can reproduce the crash at a particular point?
Yes, that crashes consistently on my system. If I start a fresh copy of TCC.EXE with the /I startup option, and empty the environment with UNSET *, it crashes around i=2000 approximately. If I don't empty the environment it crashes quicker.

I don't get a .GPF file when I start TCC.EXE with /I. WAD? If I don't use /I, the .GPF file is almost the same as the one I posted earlier (same addresses, same stack; a few registers differ slightly.)
 
#9
I just tested with V7, V8 and V12, as well as V13.04.55. When the size of the environment exceeds 8100 by a version-dependent amount, they all fail. V8 triggered the MS "sorry" message. V12 and V13 created GPFs. Uploaded.
 

Attachments

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,555
46
Albuquerque, NM
prospero.unm.edu
#10
I just tested with V7, V8 and V12, as well as V13.04.55. When the size of the environment exceeds 8100 by a version-dependent amount, they all fail. V8 triggered the MS "sorry" message. V12 and V13 created GPFs. Uploaded.
I suspect that it actually gorks only when the environment is equal to some magic value, not when it exceeds it. At any rate, my repeatable crash can be prevented by adding a semicolon to the end of my PATH; or by typing UNLOAD.BTM instead of just UNLOAD.
 
#11
I agree about specific size; including some overhead (not explicitly part of the environment) that size seems likely to be 8192. Both V12 and V13 are consistent - whether using my normal environment or "unset *" - it was when total environment was approaching 8192 that TCC crashed (btw, my tests were always stand-alone, 32b, under WinXP SP3 home). When redirecting the batch file output to a file I am not sure how much may have been lost due to buffering, probably no more than one line.

Note that the command you use becomes part of the environment so expanding its size by the explicit addition of .BTM or by appending a harmless semicolon to PATH both get you past that magic size causing crash.
 

rconn

Administrator
Staff member
May 14, 2008
10,417
95
#12
I ran a number of tests in various environments, and was eventually able to reproduce it (only) in XP sp3 32-bit. More investigation revealed an XP API bug, which has probably been there for years. The critical size isn't 2K or 8K, it's (any?) multiples of 4K.

It doesn't appear thus far that there's anything I can do to fix it, so I'll have to hack up #6,177 in a looooonnnngg list of "ugly kludges for Windows bugs" ...
 
#14
Thanks from here, too! It probably explains some otherwise unexplainable (and unreported) old crashes going back to 4nt5. It certainly affects 4nt7 and everything since - but the likelihood is so low that most of us probably attributed it to other causes (including user error). But I hope you won't ditch XP support in V14 because of a single problem, for which you will have a correction anyway.