Crash in bitcoin 0.1.0

Normally I would keep the symbols in, but they increased the size of the EXE from 6.5MB to 50MB so I just couldn’t justify not stripping them.  I guess I made the wrong decision, at least for this early version.  I’m kind of surprised there was a crash, I’ve tested heavily and haven’t had an outright exception for a while.  Come to think of it, there isn’t even an exception print at the end of debug.log.  I’ve been testing on XP SP2, maybe SP3 is something. I’ve attached bitcoin.exe with symbols.  (gcc symbols for gdb, if you’re using MSVC I can send you an MSVC build with symbols) Thanks for your help! Hi Satoshi - I tried running bitcoin.exe from the 0.1.0 package, and it crashed. I am running on an up to date version of XP, SP3. The debug.log output is attached. There was also a file db.log but it was empty. The crash allowed me to start up a debugger, but there were no symbols. The exception was at address 00930AF7. The displayed call stack was 942316 called by 508936. When I have a chance, I’ll try building it, although it looks like it would take me a while to acquire all the dependencies. Hal

I was temporarily able to reproduce the bug and narrowed it down to the “mapAddresses.count” in the following code.  It was absolutely the last piece of code to go in and mainly only got tested with the MSVC build.  It’s not essential and I’m inclined to turn off optimization and delete the section of code until I figure out what’s going on. I’m attaching a dbg exe you can try that deletes the line of code and turns off optimization.  I’m not able to reproduce it anymore at the moment. irc.cpp: if (pszName[0] == ‘u’) {     CAddress addr;     if (DecodeAddress(pszName, addr))     {         CAddrDB addrdb;         if (AddAddress(addrdb, addr))             printf("new ");         else         {             // make it try connecting sooner             CRITICAL_BLOCK(cs_mapAddresses)                 if (mapAddresses.count(addr.GetKey()))                     mapAddresses[addr.GetKey()].nLastFailed = 0;         }         addr.print();     }     else     {         printf(“decode failed\n”);     } } Yes, actually the version with MSVC symbols would be better, that is the one I am using. I found that if I launched this one from a cygwin shell, it does not crash. But if I launch it from Windows, double-clicking on the file, it does crash similarly to the previous version. However, I am pretty sure that the previous version did crash even when I launched it from cygwin. I have to go out but I’ll leave this version running for a while. Hal

I isolated the problem.  If I spawn a thread and do mapAddresses.count, even as the very first thing in the program, it segfaults.  The workaround is to needlessly call mapAddresses.count in the main thread once and it’s fine from then on.  I hate to blame the compiler, and I’ve never had a GCC compiler bug before, but this feels like one.  Maybe some bit of init code it tries to optimize out if it’s not called at least once in the same thread, or some STL optimization that’s not thread friendly.  I’m really dismayed to have this botch up the release after all that stress testing. The attached file: bitcoin-0.1.1.rar (filesize 2,132,686) is the version where I deleted the mapAddresses.count line, and that should be the safest version.  (that was the only use of mapAddresses.count)  If you could try this version and confirm that the crash is fixed, I’d appreciate it. Thanks, Satoshi

OK, thanks.  The one in bitcoin-0.1.1-exe-dbg.rar is the same build as in bitcoin-0.1.1.rar.  I forgot, when you build debug on MSVC, it uses the debug versions of the runtime DLLs, which aren’t included with Windows distributions.  Actually, MSVC 6.0’s runtime (MSVC60.DLL) is the last version that shipped preinstalled on Windows, which is why the continued interest in that ancient version of the compiler.  Later Visual C versions can’t create a standalone EXE that doesn’t require additional runtime packages installed. I can’t use MSVC 6.0 for the release because its optimization of the SHA-256 routines is too slow. I’ve attached a copy of the debug runtime DLLs.  (They’re redistributable) Hi Satoshi - The version with the .pdb file did not run for me, I got an error about MSVCP60D.DLL not being found. I imagine this is due to the version incompatibility you were worried about. The next version, that deleted the questionable line of code and turned off optimization, seems to run fine for me. So the problem may be related to that bit. Hal