bitcoin generation broken in 0.3.8? (64-bit)
I was starting to wonder when my systems seemed to quit generating coins if there was something going on. They went from about 1 block / day to none in a week.
ArtForz in irc suggested I run a test isolated net with two nodes only connected to each other with empty wallet dir. I took a couple of quad core systems and set them up. they have produced no blocks in about 90 minutes now while hashing at a combined rate of over 8000 khash/sec. Is this evidence of a problem yet or is it more bad luck?
The systems are Linux 64 bit one Intel quad q6600 and one AMD quad phenom II 940.
Just had a “fun” gdb session with the official 0.3.8 linux 64 bit binary on debian sid. Same bug, output state on return from SHA256Transform always == initial state. So… did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)? Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6. Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.
Quote from: ArtForz on August 09, 2010, 12:31:45 AM
Just had a “fun” gdb session with the official 0.3.8 linux 64 bit binary on debian sid. Same bug, output state on return from SHA256Transform always == initial state. So… did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)? Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6. Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.
Nice work mate! Time to PM Satoshi.
Sent you 5.01 for your troubles.
The 32 bit Linux build seems ok for those who don’t care to try to build it themselves. It’s only a few percent slower than the 64 when built right.
I guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing.
Quote from: lfm on August 09, 2010, 10:04:43 AM
I guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing.
Yet another argument for cmake or similar.
I found that SSE2 only added a slight 2% speedup, which didn’t seem worth the incompatibility. I was trying to take the safer option.
It doesn’t look to me like Crypto++ could be deciding whether to use SSE2 at runtime. There’s one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can’t see how that would switch at runtime. Maybe I’m not looking in the right place.
Should we enable SSE2 in all the makefiles? It seems like we must in case someone compiles with 64-bit.
I will recompile the 64-bit part of the Linux 0.3.8 release.
Quote from: satoshi on August 09, 2010, 06:50:41 PM
I found that SSE2 only added a slight speedup, about 2%, which didn’t seem worth the incompatibility.
I do the see point because a non-SSE2 machine, the client would crash? Depends on which is easier really. If you enable something that is going to break compatibility, the only people who will feel the pain are the non-technical users of the client. From their perspective, it just doesn’t work for some reason.
I think some builds notes would be better, example (If compiling on a 64bit system, be sure to do this part).
Have one branch of source that cross-compiles across multiple operating systems is always tricky business. Grin
Quote from: lachesis on August 09, 2010, 03:45:39 PM
Yet another argument for cmake or similar.
It’s a fact.
I intend to eventually sort out all building hassles and have a reliable build procedure across all win/unix 32/64-bit platform combinations.
On that note, I’m currently tackling x64 build for windows and notice that for 64-bit MSVC, the X86_SHA256_HashBlocks function is deferred to an external definition that is not present in the project. In the original CryptoPP library it seems to be in a separate asm module. I wonder how are people building x64 on windows, are they setting defines to use the C-source sha version?
I uploaded 0.3.8.1 for Linux with re-built 64-bit. I ran a difficulty 1 test with it and it has generated blocks.