tcc.exe crash with long command line

Jun 28, 2011
1
0
#1
tcc.exe crash

I am having some problem with long command lines for TCC. I have read
the help documentation and believe I am nowhere near the internal TCC
limitations.

I run "TCC 12.11.69 Windows 7 [Version 6.1.7601]" (32 bit)

The following command line causes a crash. The quotes are intentional
(added by cygwin make). I have isolated the TCC command lines which
do not work, so that the fact that the problem was discovered in make
is not an issue here. Copy and paste of the commands in this report
will demonstrate the problem; the quotes are significant and my path to tcc.exe (E:\opt\JPSoft\TCMD12\) needs to be replicated for an exact match.

E:\opt\JPSoft\TCMD12\tcc.exe -c "e:\opt\Borland\BDS\3.0\Bin\dcc32.exe Sys\APCLI.pas -Ue:\opt\madshi\madCollection\madExcept\Delphi2005;e:\opt\madshi\madCollection\madBasic\Delphi2005;e:\opt\madshi\madCollection\madDisAsm\Delphi2005;Sys;Math;Graph;Tide;FPLoT;netcdf;.;.;e:/opt/Raize/RC4/Lib/Delphi2005;e:/opt/HiComponents/ImageEn/Delphi2005;e:/opt/Borland/BDS/3.0/Lib"

TCC reports the following error

TCC: (Sys) The system cannot find the path specified.
"\\?\E:\opt\Borland\BDS\3.0\Bin\dcc32.exe Sys\APCLI.pas -Ue"

The \\?\ prefix is interesting, as is the truncation at the first colon
of the -U option.

The corresponding Win7 error box problem details are as follows:

Problem signature:
Problem Event Name: BEX
Application Name: tcc.exe
Application Version: 12.1.1.69
Application Timestamp: 4df6bee6
Fault Module Name: StackHash_6a0c
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 00440042
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 3081
Additional Information 1: 6a0c
Additional Information 2: 6a0c2613e92241025843a173afe0a554
Additional Information 3: 4d4a
Additional Information 4: 4d4ac4ec642fc711bb32837b4c0df0fe

If I now modify the command line to be the following, TCC does not report
an error but still crashes with a Win7 error.

E:\opt\JPSoft\TCMD12\tcc.exe -c "e:\opt\Borland\BDS\3.0\Bin\dcc32.exe Sys\APCLI.pas -Ue:\opt\madshi\madCollection\madExcept\Delphi2005;e:\opt\madshi\madCollection\madBasic\Delphi2005;e:\opt\madshi\madCollection\madDisAsm\Delphi2005;Math;Graph;Tide;FPLoT;netcd;e:/opt/Raize/RC4/Lib/Delphi2005;e:/opt/HiComponents/ImageEn/Delphi2005;e:/opt/Borland/BDS/3.0"

Problem signature:
Problem Event Name: BEX
Application Name: tcc.exe
Application Version: 12.1.1.69
Application Timestamp: 4df6bee6
Fault Module Name: StackHash_2264
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 00000000
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 3081
Additional Information 1: 2264
Additional Information 2: 2264db07e74365624c50317d7b856ae9
Additional Information 3: 875f
Additional Information 4: 875fa2ef9d2bdca96466e8af55d1ae6e

If I delete just one random character from the second command line, the
command completes successfully.

This problem also exists under WinXP SP3.

This problem does *not* exist for 4NT 7.01.370, under either WinXP or Win7.

Regards, Arnstein.
 
#2
On Wed, 06 Jul 2011 05:22:47 -0400, quack <> wrote:


|E:\opt\JPSoft\TCMD12\tcc.exe -c "e:\opt\Borland\BDS\3.0\Bin\dcc32.exe Sys\APCLI.pas -Ue:\opt\madshi\madCollection\madExcept\Delphi2005;e:\opt\madshi\madCollection\madBasic\Delphi2005;e:\opt\madshi\madCollection\madDisAsm\Delphi2005;Sys;Math;Graph;Tide;FPLoT;netcdf;.;.;e:/opt/Raize/RC4/Lib/Delphi2005;e:/opt/HiComponents/ImageEn/Delphi2005;e:/opt/Borland/BDS/3.0/Lib"

I don't know about the Win7 messages, but you have quoted the entire pair
"program arguments" that TCC is supposed to run. TCC sees that one string as
the program name and that name is longer than the OS's MAX_PATH constant (260).
TCC adds the "\\?\" to try to get around the MAX_PATH limitation. The
well-formed command would look like this:

Code:
E:\opt\JPSoft\TCMD12\tcc.exe -c "e:\opt\Borland\BDS\3.0\Bin\dcc32.exe"
Sys\APCLI.pas ... BDS/3.0
clearly delineating the name of the program TCC is to run. I don't think the
tail of the command line (the arguments to dcc32.exe) needs to be quoted. Since
the program name, "e:\opt\Borland\BDS\3.0\Bin\dcc32.exe", contains no spaces you
could do without the quotes altogether.
 

rconn

Administrator
Staff member
May 14, 2008
10,588
97
#3
tcc.exe crash

I am having some problem with long command lines for TCC. I have read
the help documentation and believe I am nowhere near the internal TCC
limitations.

I run "TCC 12.11.69 Windows 7 [Version 6.1.7601]" (32 bit)
I'm not able to reproduce your problem here. Do you have a TCSTART that might be interfering?

There are several bad things going on in your example, though at least some of them don't appear to be TCC-related.

First, the Windows error reporting is completely useless. If you're crashing in TCC, it will generate a "TCC.GPF" file (usually in the same directory as your TCMD.INI) that actually has useful information (like a stack trace).

Second, there are no modules named "StackHash_*" in TCC, nor is there anything loaded at that address. You may have plugins or another process injecting a DLL into TCC's address space; the stack trace in TCC.GPF should clarify this.

Third, the "-c" is technically invalid syntax, though TCC recognizes it as equivalent to "/C".

Fourth, the quoting of the command line is wrong. I don't know if you can tell Cygwin make not to do that, but there's no reason at all to be doing it.

After TCC removes the "-C", it assumes the remaining (quoted) string is a command to execute. TCC will remove the enclosing quotes to get around problem #4 above, and then pass it off to the parser. On my system, I then get the expected error :

TCC: Unknown command "e:\opt\Borland\BDS\3.0\Bin\dcc32.exe"

For some as-yet undetermined reason on your system (TCSTART? Plugins? PRE_EXEC alias?), TCC is first looking at the whole quoted string and interpreting it as a filename. Since the argument is > than the normal max number of filename characters (260), TCC prefixes "\\?\" and looks to see if the filename exists, which is where your system goes off the rails.

If you are running plugins, try it without them. If you have a TCSTART, try disabling it (i.e., with something like "if %_transient == 1 quit").
 
#4
On Wed, 06 Jul 2011 10:11:55 -0400, rconn <> wrote:

|For some as-yet undetermined reason on your system (TCSTART? Plugins? PRE_EXEC alias?), TCC is first looking at the whole quoted string and interpreting it as a filename.

I see different behaviors, a colon triggering the behavior reported by the OP.

Code:
v:\> d:\tc12\tcc.exe /c "cmq.exe f\foo;%@repeat[x,400]"
TCC: Unknown command "cmq.exe"

v:\> d:\tc12\tcc.exe /c "cmq.exe f:\foo;%@repeat[x,400]"
TCC: (Sys) The system cannot find the file specified.
 "\\?\V:\cmq.exe f"
 
#6
On Wed, 06 Jul 2011 11:10:08 -0400, rconn <> wrote:

|---Quote---
|> I see different behaviors, a colon triggering the behavior
|> reported by the OP.
|---End Quote---
|Not reproducible here. Did you try it without TCSTART and plugins?

Here it again with the current (and future) TCC started with /IIPSX.

Code:
v:\> d:\tc12\tcc.exe /iipsx /c "cmq.exe
f\foo;%@repeat[x,100];%@repeat[x,100];%@repeat[x,100];%@repeat[x,100]"
TCC: Unknown command "cmq.exe"

v:\> d:\tc12\tcc.exe /iipsx /c "cmq.exe
f:\foo;%@repeat[x,100];%@repeat[x,100];%@repeat[x,100];%@repeat[x,100]"
TCC: (Sys) The system cannot find the file specified.
 "\\?\V:\cmq.exe f"
 

rconn

Administrator
Staff member
May 14, 2008
10,588
97
#7
> v:\> d:\tc12\tcc.exe /iipsx /c "cmq.exe
> f:\foo;%@repeat[x,100];%@repeat[x,100];%@repeat[x,100];%@repeat[x,10
> 0]"
> TCC: (Sys) The system cannot find the file specified.
> "\\?\V:\cmq.exe f"
You're telling TCC to look in the file "cmq.exe f" for a stream named
"\foo;%@repeat[x,100];%@repeat[x,100];%@repeat[x,100];%@repeat[x,10

If you want to pass gibberish and have TCC automagically correct it for you,
you should invoke the startup switch for the DWIM parser. :-)

Rex Conn
JP Software
 
#8
On Wed, 06 Jul 2011 13:26:18 -0400, rconn <> wrote:

|---Quote---
|> v:\> d:\tc12\tcc.exe /iipsx /c "cmq.exe
|> f:\foo;%@repeat[x,100];%@repeat[x,100];%@repeat[x,100];%@repeat[x,10
|> 0]"
|> TCC: (Sys) The system cannot find the file specified.
|> "\\?\V:\cmq.exe f"
|---End Quote---
|You're telling TCC to look in the file "cmq.exe f" for a stream named
|"\foo;%@repeat[x,100];%@repeat[x,100];%@repeat[x,100];%@repeat[x,10
|
|
|---Quote---
|> 0]".
|---End Quote---
|If you want to pass gibberish and have TCC automagically correct it for you,
|you should invoke the startup switch for the DWIM parser. :-)

**I** don't want to do that , but someone might. TCC tolerates (umm ...)
unfortunate quoting in other situations.
 
#10
On Wed, 06 Jul 2011 14:27:34 -0400, rconn <> wrote:

|---Quote---
|> **I** don't want to do that , but someone might. TCC tolerates (umm ...)
|> unfortunate quoting in other situations.
|---End Quote---
|And it could do it in this situation too -- if I removed support for NTFS
|streams.
|
|Which is preferable - stream support or support for badly quoted commands?

Stream support, of course. Is such quoting (TCC "program args") ever necessary?
I was suggesting you not tolerate it at all? But now I see that CMD does.
[Sigh!]