Strange crashes in @CRC32 and @MD5

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

dim

Dimitry Andric
May 31, 2008
203
0
Netherlands
#1
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?
 
#2
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
203
0
Netherlands
#3
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.
 
#4
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
10,210
86
#6
> 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
 
#7
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.
 
#8
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
10,210
86
#9
> 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
 
#10
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