How to debug "Test case crashed" for users using C ?

[M0hanrajp]

Hello All,

Just wanted to know how can we proceed to debug Test case crashed with signal X type of issues.

• When writing code, when all sample tests passed, I observe some of my random test fail with memory
  exception errors.
• Do you guys follow any practices in order to avoid these kind of issues ?

Thanks.

[BobtheLantern]

Just print the input and flush stdout so it will print before the crash. This way, you can see the input causing your code to crash and proceed from there.

[hobovsky]

When I face a crash in a C or C++ solution, my procedure usually is:

1. I look at the signal. Knowing what signal caused your crash can help with debugging: SIGFPE usually means division by 0, modulo by 0, or domain error (like a negative argument to sqrt or logarithm). Signal 6 usually means invalid call to free: calling it on a string literal, or on a moved pointer. There is a chance you returned an invalid pointer which cannot be freed. SIGSEGV is the most problematic because it can mean anything related to invalid handling of memory, but the first thing to check is usually an out-of-bounds access to arrays or strings.
2. Use printf or std::cout to print out the input causing my crash. It is important to explicitly flush it with fflush or std::endl. However, printing does not always work. Sometimes the program crashes without printing, sometimes the crash goes away because new code masks the corrupted state.
3. I copy my code to my local Visual Studio and add main and call my solution with the arguments I printed. If I do not know the input, I try a couple of guessed/deduced/suspicious values. I run it in two ways: once in DEBUG configuration, so the problem can be caught by runtime checks. If it does not crash in DEBUG mode, I try with RELEASE configuration, to neutralize all possible "padding" for the error conditions. Usually, either DEBUG or RELEASE version crashes and I have a starting point for debugging.
4. If I cannot force the crash locally, I step through my program in debugger and check suspicious places, usually array accesses, and check if my index is never geq to the size of the accessed array. You can try some additional tools like valgrind to find issues with the code.

If all above fails, this is where the fun begins :)