digitalmars.D - sha1Of() crashing and incorrect result on win64
- knutaf (31/31) Mar 06 2014 Hello,
- John Colvin (2/33) Mar 06 2014 dmd version?
- Andrej Mitrovic (2/5) Mar 06 2014 It works fine for me using 2.064 and 2.065, both with and without -m64.
- dnewbie (3/9) Mar 06 2014 It doesn't work for me. Incorrect result & crash.
- Andrej Mitrovic (8/10) Mar 06 2014 Hmm, could it be VC-related? I'm using VS2010:
- knutaf (8/20) Mar 06 2014 Hi again, Andrej
- Peter Alexander (2/2) Mar 06 2014 Known issue
- knutaf (8/10) Mar 06 2014 Thanks. Is this suggesting that if I don't use toHexString, I
- Peter Alexander (3/15) Mar 06 2014 Hmm. Looks like it's actually a separate bug then as others are
- dnewbie (1/1) Mar 06 2014 It works with DMD/Phobos from GIT.
- Rainer Schuetze (7/33) Mar 06 2014 I can reproduce your results but the crashes don't happen all the time.
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
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 -knutafdmd version?
Mar 06 2014
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
On Thursday, 6 March 2014 at 15:56:07 UTC, Andrej Mitrovic wrote:On 3/6/14, knutaf <a b.com> wrote:It doesn't work for me. Incorrect result & crash. dmd2.065and 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
On 3/6/14, dnewbie <run3 myopera.com> wrote:It doesn't work for me. Incorrect result & crash. dmd2.065Hmm, 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
On Thursday, 6 March 2014 at 16:37:21 UTC, Andrej Mitrovic wrote:On 3/6/14, dnewbie <run3 myopera.com> wrote: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.It doesn't work for me. Incorrect result & crash. dmd2.065Hmm, 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 ----clMicrosoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64 -knutaf
Mar 06 2014
Known issue https://d.puremagic.com/issues/show_bug.cgi?id=9279
Mar 06 2014
On Thursday, 6 March 2014 at 16:58:00 UTC, Peter Alexander wrote:Known issue https://d.puremagic.com/issues/show_bug.cgi?id=9279Thanks. 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
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:Hmm. Looks like it's actually a separate bug then as others are suggesting. Sorry for the distraction.Known issue https://d.puremagic.com/issues/show_bug.cgi?id=9279Thanks. 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
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