3

Some developers work on code hardening.

(protecting against errors, you can build with a stack protector for example).

However, if you're trying to redo a strange someone else reports, or find possible problems with the code, the reverse could be useful.

Are there well known ways to increase the chance an error in the code will lead to a crash?

Examples could include...

  • Pack structs so accidental out-of-bounds access don't access padding bytes.
  • Initialize stack & heap memory to random bits.
  • Re-arrange executable in memory layout to expose errors.
    (For whatever reason or 'good luck', some bugs will only impact specific configurations).
  • Change thread scheduling to expose threading bugs.

So the question is:

Which existing methods of building software exist, that help expose errors in C/C++ applications?


Note, am aware of valgrind, address-sanitizer & rational-purify.

closed as too broad by user40980, BЈовић, user22815, gnat, Doc Brown Sep 10 '15 at 14:41

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Code "hardening" should not be intermixed with "masking errors". And the above suggestions are no techniques suitable for designing code. If one wants to design code for identifying more errors, one has to add run time checks, or implement design-by-contract in code. – Doc Brown Sep 10 '15 at 14:45
  • @Doc Brown, agree its not an exact opposite. However some aspects of code hardening regard being resilient to errors. Where I'm interested in failing fast WRT this question. – ParityLentil Sep 11 '15 at 5:42
  • recommended reading: Why do 'some examples' and 'list of things' questions get closed? – gnat Sep 11 '15 at 13:50
7

Actually I would say that what you want is still hardening. It will help you discover the bug - if it is there, it will manifest loudly and closer to the actual cause, rather than silently somewhere later.

If you are trying to reproduce a strange bug report, I would suggest to not alter the code at all. It's obviously best if you can get the same code, same build setup and run in the same environment as the reporter has. But if you can't or if the bug still doesn't happen:

  • valgrind is great, as you know, it has lot of attributes you can play with
    • this covers the initializing memory with random bits, valgrind knows that the data is unitialized and any read access will be reported
  • compiling and running the program on different architectures is easy way to make some bugs appear
  • on linux, compile with -fPIE and make sure ASLR is on
  • have automatic tests, units tests are great, but just a fuzzy test that will pump lot of random (valid) data in the program can help
1

I don't know if this is exactly what is requested, but once I received a system with a few thousands of pretty bad written lines of code. Among other bad practices, it was full of try{ ; } catch(...); so when an exception happened the system just kept going, sometimes erratically. What I've decided was to remove completely the "protection" exposing the system to a crash, often in production, so I could get the dump. That move helped a lot.

Not the answer you're looking for? Browse other questions tagged or ask your own question.