Strange crashes in @CRC32 and @MD5

dim

Dimitry Andric
May 31, 2008
205
1
Netherlands
Strange crashes in @CRC32 and @MD5

Hi,

I am experiencing some very strange crashes in the @CRC32 and @MD5
functions, using TCmd 11.00.39 (both x86 and x64 versions).

As it happens, I usually use the filename "f" for temporary files,
intermediate redirection output, and so on. However, when I try to run
either the @CRC32 or @MD5 function over such a file, TCC crashes. It
does not seem to matter whether the file "f" actually exists or not.

E.g. just run:

echo %@crc32[f]

in some empty directory, and it crashes. For the x86 version, the crash
stack is:
Code:
>    TakeCmd.dll!1004aeb5()     
     [Frames below may be incorrect and/or missing, no symbols loaded for TakeCmd.dll]    
     TakeCmd.dll!1004b051()     
     TakeCmd.dll!10013a1b()     
     TakeCmd.dll!10015428()     
     kernel32.dll!_BasepCreateActCtx@12()  + 0x6db bytes    
     kernel32.dll!_GetFileAttributesW@4()  + 0x68 bytes    
     05ffffff()
For the x64 version, it is:

Code:
>    TakeCmd.dll!0000000010056cf7()     
     [Frames below may be incorrect and/or missing, no symbols loaded for TakeCmd.dll]    
     TakeCmd.dll!0000000010056ee1()     
     TakeCmd.dll!000000001001dbe3()     
     TakeCmd.dll!000000001001f6f0()     
     TakeCmd.dll!0000000010029909()     
     TakeCmd.dll!000000001007fdfe()     
     TCC.exe!000000000040138e()     
     TCC.exe!0000000000403d3a()     
     kernel32.dll!BaseProcessStart()  + 0x2c bytes
Can anyone reproduce this?
 
May 20, 2008
603
0
Sammamish, WA
TCC 11.00.39 Windows Vista [Version 6.0.6002]
TCC Build 39 Windows Vista Build 6002 Service Pack 2

I can reproduce what you saw.

Also, using the filename s instead of f prints 0 for the CRC32
and D41D8CD98F00B204E9800998ECF8427E for the MD5. The SHA functions all seem
to behave.

On Fri, Feb 5, 2010 at 4:56 AM, dim <> wrote:


> Strange crashes in @CRC32 and @MD5
>
> Hi,
>
> I am experiencing some very strange crashes in the @CRC32 and @MD5
> functions, using TCmd 11.00.39 (both x86 and x64 versions).
>
> As it happens, I usually use the filename "f" for temporary files,
> intermediate redirection output, and so on. However, when I try to run
> either the @CRC32 or @MD5 function over such a file, TCC crashes. It
> does not seem to matter whether the file "f" actually exists or not.
>
> E.g. just run:
>
> echo %@crc32[f]
>
> in some empty directory, and it crashes. For the x86 version, the crash
> stack is:
>
> Code:
> ---------
> > TakeCmd.dll!1004aeb5()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> TakeCmd.dll]
> TakeCmd.dll!1004b051()
> TakeCmd.dll!10013a1b()
> TakeCmd.dll!10015428()
> kernel32.dll!_BasepCreateActCtx@12() + 0x6db bytes
> kernel32.dll!_GetFileAttributesW@4() + 0x68 bytes
> 05ffffff()
> ---------
> For the x64 version, it is:
>
>
> Code:
> ---------
> > TakeCmd.dll!0000000010056cf7()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> TakeCmd.dll]
> TakeCmd.dll!0000000010056ee1()
> TakeCmd.dll!000000001001dbe3()
> TakeCmd.dll!000000001001f6f0()
> TakeCmd.dll!0000000010029909()
> TakeCmd.dll!000000001007fdfe()
> TCC.exe!000000000040138e()
> TCC.exe!0000000000403d3a()
> kernel32.dll!BaseProcessStart() + 0x2c bytes
> ---------
> Can anyone reproduce this?
>
>
>
>
>



--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 

dim

Dimitry Andric
May 31, 2008
205
1
Netherlands
Also, using the filename s instead of f prints 0 for the CRC32
and D41D8CD98F00B204E9800998ECF8427E for the MD5.

Indeed, I had forgotten to mention this explicitly: the crash ONLY
occurs for the exact filename "f", not for any other filename that I
could determine. (I tried all 1-letter filenames).

Note the CRC32 and MD5 sums you mention are correct for an empty file,
so nothing is wrong with that.

The SHA functions all seem to behave.

Yes, same here.
 
May 20, 2008
603
0
Sammamish, WA
On Fri, Feb 5, 2010 at 6:14 AM, dim <> wrote:


> ---Quote (Originally by Jim Cook)---
> Also, using the filename s instead of f prints 0 for the CRC32
> and D41D8CD98F00B204E9800998ECF8427E for the MD5.
> ---End Quote---
> Indeed, I had forgotten to mention this explicitly: the crash ONLY
> occurs for the exact filename "f", not for any other filename that I
> could determine. (I tried all 1-letter filenames).
>
> Note the CRC32 and MD5 sums you mention are correct for an empty file,
> so nothing is wrong with that.
>

I did not have a filename s there, and it should have shown -1 as it did for
all other single letter filenames (except of course f). I had created an
empty test folder and changed into it.

All 2-letter filenames (AA-ZZ) behaved as expected. All 3-letter filenames
(AAA-ZZZ) also, with NUL showing CRC32 0. For completeness, I should mention
that CON, oddly showed "ECHO is OFF" instead of a number.

--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 

rconn

Administrator
Staff member
May 14, 2008
12,340
149
> I am experiencing some very strange crashes in the @CRC32 and @MD5
> functions, using TCmd 11.00.39 (both x86 and x64 versions).
>
> As it happens, I usually use the filename "f" for temporary files,
> intermediate redirection output, and so on. However, when I try to run
> either the @CRC32 or @MD5 function over such a file, TCC crashes. It
> does not seem to matter whether the file "f" actually exists or not.

@CRC32 and @MD5 use 's' and 'f' as "string" and "file" specifiers, and
expect a second argument if the first arg is 's' or 'f'. See the @MD5
documentation for details.

I've fixed the crash when you don't provide the (required) second argument
in build 40.

Rex Conn
JP Software
 
May 20, 2008
603
0
Sammamish, WA
On Fri, Feb 5, 2010 at 8:36 PM, rconn <> wrote:


> > As it happens, I usually use the filename "f" for temporary files,
>



> ---End Quote---
> @CRC32 and @MD5 use 's' and 'f' as "string" and "file" specifiers, and
> expect a second argument if the first arg is 's' or 'f'. See the @MD5
> documentation for details.
>
>
I didn't look at @MD5, but instead at @CRC32 which does not say the f or s
is allowed. It sounds like the help should be updated.

Topic "f_crc32.htm" last edited 2006-08-31

--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
rconn wrote:
| @CRC32 and @MD5 use 's' and 'f' as "string" and "file" specifiers,
| and expect a second argument if the first arg is 's' or 'f'. See
| the @MD5 documentation for details.
|
| I've fixed the crash when you don't provide the (required) second
| argument in build 40.

Which TCC version changed the syntax of @CRC32 from a single parameter, a
filename (the original syntax since V5) to requiring two parameters?
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
12,340
149
> rconn wrote:
> | @CRC32 and @MD5 use 's' and 'f' as "string" and "file" specifiers,
> | and expect a second argument if the first arg is 's' or 'f'. See
> | the @MD5 documentation for details.
> |
> | I've fixed the crash when you don't provide the (required) second
> | argument in build 40.
>
> Which TCC version changed the syntax of @CRC32 from a single parameter,
> a filename (the original syntax since V5) to requiring two parameters?

V5. And it doesn't require two parameters, unless you only have a single 'f'
or 's'. Otherwise, it assumes it's a filename.

Rex Conn
JP Software
 
May 20, 2008
3,515
4
Elkridge, MD, USA
rconn wrote:
|| Which TCC version changed the syntax of @CRC32 from a single
|| parameter, a filename (the original syntax since V5) to requiring
|| two parameters?

| V5. And it doesn't require two parameters, unless you only have a
| single 'f' or 's'. Otherwise, it assumes it's a filename.

Actually, I think it was V7. In my V5 and V6 the function %@CRC32[F]
operates on the file F correctly. I suspect the only reason I did not notice
the failures for files named F and S since the change in V7 that I don't
usually use those names, and when something occasionally failed I attributed
it to file system issues. Another reason for overlooking the undocumented
change is that I now typically use the "r" report code in PDIR, which, of
course, was not affected, and use @compare for file comparison, which is
always faster than comparing hash codes (and cannot be fooled, either).
--
Steve
 
Similar threads
Thread starter Title Forum Replies Date
R strange bug? Support 7
Jesse Heines Strange Line Wrapping Behavior Support 14
F strange results Support 9
M Strange error messages from TCC in FTP copy Support 7
M Another possibly strange remote registry issue Support 5
forbin Strange handling of [nonbright] magenta background (v22) Support 2
N Fixed Strange dir behavior Support 6
vefatica REGDIR, strange error message Support 7
T WAD Strange Unexpected "features" in the Debugger Support 2
P Strange mouse behavior with list Support 2
vefatica Strange tcc.exception.log Support 7
vefatica A strange one Support 0
D Strange DO behavior with /O Support 5
Glenn Bowes Strange text at startup Support 5
Steve Pitts WAD Strange output from DEL of a non-existent directory Support 7
vefatica Big numbers, strange errors Support 1
aedthuio Strange... lpksetup Support 4
CWBillow dir /4 strange Support 2
D Strange issue with FOR loop Support 15
MikeBaas Strange prob with %@replace.. Support 4
vefatica OT: strange files in %TEMP Support 10
Dan Glynhampton Documentation v15 help: Strange links in @INT topic Support 0
R WAD Strange output from "memory" command Support 1
M Yet another strange something re something called "@TCONVERT" Support 8
Roedy How to? Strange colours Support 9
M WAD Strange "Start" misbehavior... Support 10
vefatica Very strange console font corruption Support 3
Steve Pitts Strange problem with FREE Support 10
A strange error in alias Support 9
newgeekorder Debugger IDE - strange tab and parameter behaviour Support 1
Exolon Strange Prompt. Support 6
vefatica Strange folders Support 1
T Strange CPU value Support 3
J Strange error: unset /s Support 14
M Strange behavior... Support 2
CWBillow Strange happenings Support 2
B Strange handling of a .BAT file Support 5
vefatica Strange behavior reloading SHRALIAS sav files. Support 1
J ASSOC / FTYPE strange error message Support 3
Charles Dye Strange output, here-doc redirection, TYPE, //UnicodeOutput=Yes Support 6
S Strange CHKDSK behavior Support 6
vefatica Strange results with CP 1252 Support 12
S Strange REN problem - non-English characters Support 3
dcantor Strange status in ACTIVATE command Support 0
Jay Sage TCMD Crashes with "tctoolbar /c /r file" Support 5
S Take Command crashes for aliases with length > 1015 Support 1
C Fixed V25 crashes when adding and then removing in the tabbed toolbar Support 3
S tcc crashes Support 3
L FTYPE crashes TCC v23.00.30-34 Support 17
A Fixed [23.0.22]: TCMD crashes shortly after start, TCC keeps running in background Support 6

Similar threads