Re: [Bitcoin-development] # error Bitcoin cannot be compiled without assertions. NOT
On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese s9jaf...@stud.uni-saarland.de wrote: I think most concerns about the current use of asserts would be resolved if the currently used asserts would be changed to a nicer definition which is independent of NDEBUG, and a second class of debugging asserts would be introduced, which is exclusively for expensive, redundant checks and is disabled by NDEBUG. Also, most assertion errors that happen to people running Bitcoin Core are not caused by software bugs but database corruption errors (usually due to unclean shutdown). For example in case we detect missing/truncated block files or UTXO db consistency we should, instead of raising an assertion error, propose a -reindex - see also https://github.com/bitcoin/bitcoin/issues/2202 . So instead of using assertions we need a fatal error function for those problems which are probably recoverable in a certain specific way. In principle starting a reindex wouldn't even need to take down the entire process (though that's easier for implementation due to cleanup and assumptions made). Wladimir -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] # error Bitcoin cannot be compiled without assertions. NOT
Hi Ron, FYI your mail is being spamfoldered due to Yahoo's DMARC policy and the brokenness of the SF.net mailing list software. I would not expect to get replies reliably whilst this is the case. I think we should move away from SF.net for hosting mailing lists personally, because it's this list that's at fault not Yahoo, but until then you may wish to send to the list with a different email address. As to your question, assert() should have *no* side effects, that is the problem. See http://books.google.com/books?id=L5ZbzVnpkXACpg=PA72lpg=PA72dq=Gotcha+%2328+Side+Effectssource=blots=Rn15TlPmjesig=tymHqta0aSANwaM2GaXC-1Di_tkhl=ensa=Xei=uVKNU47fCcvTsAT6goHIBAved=0CCAQ6AEwAA#v=onepageq=Gotcha%20%2328%20Side%20Effectsf=false a great book, BTW. Everyone who thinks they know what they are doing when they write C++ should read this book! They will realize that they don't know Jack [image: Roll Eyes] Why weren't these and all the other examples of amateur, i.e., non-professional, software fixed way back in version 0.3.0 in 2010, before any more releases were done? And why were these and other sub-standard coding practices continued and expanded in later releases, right up until the present? Back in 2010 most code was still being written by Satoshi so perhaps you should ask him. Regardless, it's very common for professional codebases to require assertions be enabled. For example the entire Google C++ codebase uses always-on assertions that have side effects liberally: it's convenient and safe, when you have the guarantee the code will always run, and the performance benefits of compiling out assertions are usually non-existent. So for this reason I think Bitcoin Core currently will fail to build if assertions are disabled, and that seems OK to me. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] # error Bitcoin cannot be compiled without assertions. NOT
assert() should have *no* side effects, that is the problem. I'm pretty sure that all the side effects of assertions have been removed before 0.9.0. However, the assertion checks are extremely important to the proper sanity of the client and network, so IMHO it's fair to still require building with them enabled. Wladimir -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] # error Bitcoin cannot be compiled without assertions. NOT
On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese s9jaf...@stud.uni-saarland.de wrote: I think most concerns about the current use of asserts would be resolved if the currently used asserts would be changed to a nicer definition which is independent of NDEBUG, and a second class of debugging asserts would be introduced, which is exclusively for expensive, redundant checks and is disabled by NDEBUG. Sounds good to me. Wladimir -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] error Bitcoin cannot be compiled without assertions. NOT
Message: 2 Date: Wed, 4 Jun 2014 08:15:08 -0400 From: Jeff Garzik jgar...@bitpay.com Subject: Re: [Bitcoin-development] # error Bitcoin cannot be compiled without assertions. NOT To: Mike Hearn m...@plan99.net Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net, Ron rd...@yahoo.com Message-ID: cajhla0ptthfvd-1br5s2k-4uw6v6qleyabf2ysrxoosjth9...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Yes, check macros like that can be useful. I like the kernel's policy, which parallels our direction: 1) Enable and use lightweight assertions for most users. 2) No assertions with side effects If you want to compile them out, that's fine, but they should always be present in production software. _ I don't think many of you actually read what I said, and you went off on your own tangents. I said: this commit and code with all side effects removed from the assertions. in Vol 37, Issue 4 I intentionally left the gcc code alone. Only the MSC code is assert fixed. I would have hoped that someone would have noticed and incorporated these changes into the gcc code. Simply by removing the #ifdef _MSC_VER ... #else ... #endif etc. etc. Did I say I compiled them out? No! Did anyone bother to look at my code or what I said? Here is an example from main.cpp CTransaction::UpdateCoins(... -// add outputs +// add outputs sure looks like an assert with side effects here!? +#ifdef _MSC_VER +bool +fTest = inputs.SetCoins(txhash, CCoins(*this, nHeight)); +#ifdef _DEBUG +assert(fTest); +#else +if( !fTest ) +releaseModeAssertionfailure( __FILE__, __LINE__, __PRETTY_FUNCTION__ ); +#endif +#else assert(inputs.SetCoins(txhash, CCoins(*this, nHeight))); +#endif Note that I do the test, and if debugging, I let it abort() the program if it fails. Note that in release mode it calls a new function on failure, that I leave you to discover what it does. I see that this assert has been fixed in 0.9.x, but I think my fix is better, since it allows release mode code to run better, if not identically. I changed every assert() in the bitcoind 086 sources to behave this way. Since C++ is perniciously baroque, it is not clear if a side effect can or has occurred in the most innocuous of C++ statements. Is the example above side-effect free? Here is a piece of what I made my decision on: http://www.gnu.org/software/libc/manual/html_node/Consistency-Checking.html and the link to the book previously given. Also, no one answered the question about bitcoin-qt, to whit, can or should it be compiled in RELEASE mode because of this? Should it have always been compiled in DEBUG mode in the past too? Ron -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
