Is one of the win32 versions compiled in debug mode #2953

Saw this report:

http://bitcoin.stackexchange.com/questions/12997/assertion-failed-when-i-try-to-open-bitcoin-wallet

I could be wrong because I'm not that well versed in makefiles but unless this is overridden by something else, it looks like in makefile.mingw has starting at line 47:

DEBUGFLAGS=-g CFLAGS=-mthreads -O2 -w -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter $(DEBUGFLAGS) $(DEFS) $(INCLUDEPATHS)

Doesn't the -g enable assertions? I think it shouldn't be enabled for the prod release.

No, assert is just a function. It's always "enabled".

-g tells the compiler to generate debugging symbols.

It's a macro, actually, and compiling with -DNDEBUG disables them. We only have cheap assertions and leave them enabled all the time. Frequently crashing is preferrable to ending up in an unknown state.

Also, the Windows release binaries are built using makefile.linux-mingw.

OK, I understand. Would it make more sense to, er, "crash gracefully" rather than presenting an assert message to the end-user though? @luke-jr the "assert.h" file (gnu for example) has code like this: #ifdef NDEBUG #define assert(EX) #else #define assert(EX) (void)((EX) || (assert (#EX, __FILE, LINE),0)) #endif

so if you #define NDEBUG somewhere in your code it basically makes the assert macro do nothing. It's meant to disable debugging mode. I was unclear on whether the -g option also did this but it does not.

Yes, a crash handler that sent the data to the developers would be more useful. The problem is that bitcoin is kind of sensitive in this regard and we can't just send a memory dump etc as it may contain private keys or other sensitive data. See also #2551.