www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - sha1Of() crashing and incorrect result on win64

reply "knutaf" <a b.com> writes:
Hello,

Apologies if I have missed some rule or convention in posting 
this. I'm new to this site and to D as a whole. I do all of my 
development on Windows and in general try to keep my programs as 
64-bit unless I have a reason not to.

I tried the following simple program, but it seems to not only be 
producing the wrong answer but also crashing (as in, my 
postmortem debugger comes up when I run it).

import std.stdio;
import std.digest.sha;

void main()
{
     writefln("%s", toHexString(sha1Of("abc")));
}

Produces:
67452301EFCDAB8998BADCFE10325476C3D2E1F0

and then crashes. If I build without -m64, I get 
A9993E364706816ABA3E25717850C26C9CD0D89D, which is what I was 
expecting.

I'm also not sure how to produce the right kind of callstack or 
crash dump. I do most of my debugging with windbg, and the stack 
has a lot of scary looking mangled names that don't seem terribly 
helpful.

I found a recent changelist where the version(Win64) has SSE3 
disabled. I tried to incorporate that change locally, and it 
seems to have stopped it from crashing, but it still produces the 
wrong result.

Can anyone else reproduce this? Hopefully it is just a matter of 
me messing up something simple.

Thanks
-knutaf
Mar 06 2014
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 6 March 2014 at 08:15:55 UTC, knutaf wrote:
 Hello,

 Apologies if I have missed some rule or convention in posting 
 this. I'm new to this site and to D as a whole. I do all of my 
 development on Windows and in general try to keep my programs 
 as 64-bit unless I have a reason not to.

 I tried the following simple program, but it seems to not only 
 be producing the wrong answer but also crashing (as in, my 
 postmortem debugger comes up when I run it).

 import std.stdio;
 import std.digest.sha;

 void main()
 {
     writefln("%s", toHexString(sha1Of("abc")));
 }

 Produces:
 67452301EFCDAB8998BADCFE10325476C3D2E1F0

 and then crashes. If I build without -m64, I get 
 A9993E364706816ABA3E25717850C26C9CD0D89D, which is what I was 
 expecting.

 I'm also not sure how to produce the right kind of callstack or 
 crash dump. I do most of my debugging with windbg, and the 
 stack has a lot of scary looking mangled names that don't seem 
 terribly helpful.

 I found a recent changelist where the version(Win64) has SSE3 
 disabled. I tried to incorporate that change locally, and it 
 seems to have stopped it from crashing, but it still produces 
 the wrong result.

 Can anyone else reproduce this? Hopefully it is just a matter 
 of me messing up something simple.

 Thanks
 -knutaf

dmd version?
Mar 06 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/6/14, knutaf <a b.com> wrote:
 and then crashes. If I build without -m64, I get
 A9993E364706816ABA3E25717850C26C9CD0D89D, which is what I was
 expecting.

It works fine for me using 2.064 and 2.065, both with and without -m64.
Mar 06 2014
prev sibling next sibling parent "dnewbie" <run3 myopera.com> writes:
On Thursday, 6 March 2014 at 15:56:07 UTC, Andrej Mitrovic wrote:
 On 3/6/14, knutaf <a b.com> wrote:
 and then crashes. If I build without -m64, I get
 A9993E364706816ABA3E25717850C26C9CD0D89D, which is what I was
 expecting.

It works fine for me using 2.064 and 2.065, both with and without -m64.

It doesn't work for me. Incorrect result & crash. dmd2.065
Mar 06 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/6/14, dnewbie <run3 myopera.com> wrote:
 It doesn't work for me. Incorrect result & crash.
 dmd2.065

Hmm, could it be VC-related? I'm using VS2010: ---- C:\dev\code\d_code>vcvars Setting environment for using Microsoft Visual Studio 2010 x86 tools. C:\dev\code\d_code>dmd -m64 -run test.d A9993E364706816ABA3E25717850C26C9CD0D89D ----
Mar 06 2014
prev sibling next sibling parent "knutaf" <a b.com> writes:
On Thursday, 6 March 2014 at 16:37:21 UTC, Andrej Mitrovic wrote:
 On 3/6/14, dnewbie <run3 myopera.com> wrote:
 It doesn't work for me. Incorrect result & crash.
 dmd2.065

Hmm, could it be VC-related? I'm using VS2010: ---- C:\dev\code\d_code>vcvars Setting environment for using Microsoft Visual Studio 2010 x86 tools. C:\dev\code\d_code>dmd -m64 -run test.d A9993E364706816ABA3E25717850C26C9CD0D89D ----

Hi again, Andrej I managed to forget to put the dmd version, sorry. I followed your suggestion from Twitter and upgraded to 2.065, but didn't see any difference from 2.064.2. I'm using VC 2013.
cl

x64 -knutaf
Mar 06 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
Known issue

https://d.puremagic.com/issues/show_bug.cgi?id=9279
Mar 06 2014
prev sibling next sibling parent "knutaf" <a b.com> writes:
On Thursday, 6 March 2014 at 16:58:00 UTC, Peter Alexander wrote:
 Known issue

 https://d.puremagic.com/issues/show_bug.cgi?id=9279

Thanks. Is this suggesting that if I don't use toHexString, I won't see the problem? Because if I do: auto result = sha1Of("abc"); writefln("%s", result[0]); I still see it's showing the wrong answer (and crashes). Or is this problematic cast/construction used in other parts of the SHA1 implementation's guts?
Mar 06 2014
prev sibling next sibling parent "dnewbie" <run3 myopera.com> writes:
It works with DMD/Phobos from GIT.
Mar 06 2014
prev sibling next sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 06.03.2014 09:15, knutaf wrote:
 Hello,

 Apologies if I have missed some rule or convention in posting this. I'm
 new to this site and to D as a whole. I do all of my development on
 Windows and in general try to keep my programs as 64-bit unless I have a
 reason not to.

 I tried the following simple program, but it seems to not only be
 producing the wrong answer but also crashing (as in, my postmortem
 debugger comes up when I run it).

 import std.stdio;
 import std.digest.sha;

 void main()
 {
      writefln("%s", toHexString(sha1Of("abc")));
 }

 Produces:
 67452301EFCDAB8998BADCFE10325476C3D2E1F0

 and then crashes. If I build without -m64, I get
 A9993E364706816ABA3E25717850C26C9CD0D89D, which is what I was expecting.

 I'm also not sure how to produce the right kind of callstack or crash
 dump. I do most of my debugging with windbg, and the stack has a lot of
 scary looking mangled names that don't seem terribly helpful.

 I found a recent changelist where the version(Win64) has SSE3 disabled.
 I tried to incorporate that change locally, and it seems to have stopped
 it from crashing, but it still produces the wrong result.

 Can anyone else reproduce this? Hopefully it is just a matter of me
 messing up something simple.

I can reproduce your results but the crashes don't happen all the time. I think it is fixed in git head (the unittest there tests the "abc" sequence, too). The problem is that the SSE3 optimized version does not use the correct calling convention for Win64, so it is disabled for now. It is not enough to just patch the phobos sources, you'll have to recompile phobos to get it fixed.
Mar 06 2014
prev sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 6 March 2014 at 17:16:39 UTC, knutaf wrote:
 On Thursday, 6 March 2014 at 16:58:00 UTC, Peter Alexander 
 wrote:
 Known issue

 https://d.puremagic.com/issues/show_bug.cgi?id=9279

Thanks. Is this suggesting that if I don't use toHexString, I won't see the problem? Because if I do: auto result = sha1Of("abc"); writefln("%s", result[0]); I still see it's showing the wrong answer (and crashes). Or is this problematic cast/construction used in other parts of the SHA1 implementation's guts?

Hmm. Looks like it's actually a separate bug then as others are suggesting. Sorry for the distraction.
Mar 06 2014