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

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?

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.

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

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
----

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
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64

-knutaf

Known issue

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

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?

It works with DMD/Phobos from GIT.

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.