CODEWITHSUNDEEP
c
user2371524
user2371524

Reputation:

How to force a crash in C, is dereferencing a null pointer a (fairly) portable way?

I'm writing my own test-runner for my current project. One feature (that's probably quite common with test-runners) is that every testcase is executed in a child process, so the test-runner can properly detect and report a crashing testcase.

I want to also test the test-runner itself, therefore one testcase has to force a crash. I know "crashing" is not covered by the C standard and just might happen as a result of undefined behavior. So this question is more about the behavior of real-world implementations.

My first attempt was to just dereference a null-pointer:

int c = *((int *)0);

This worked in a debug build on GNU/Linux and Windows, but failed to crash in a release build because the unused variable c was optimized out, so I added

printf("%d", c); // to prevent optimizing away the crash

and thought I was settled. However, trying my code with clang instead of gcc revealed a surprise during compilation:

   [CC]   obj/x86_64-pc-linux-gnu/release/src/test/test/test_s.o
src/test/test/test.c:34:13: warning: indirection of non-volatile null pointer
      will be deleted, not trap [-Wnull-dereference]
    int c = *((int *)0);
            ^~~~~~~~~~~
src/test/test/test.c:34:13: note: consider using __builtin_trap() or qualifying
  pointer with 'volatile'
1 warning generated.

And indeed, the clang-compiled testcase didn't crash.

So, I followed the advice of the warning and now my testcase looks like this:

PT_TESTMETHOD(test_expected_crash)
{
    PT_Test_expectCrash();

    // crash intentionally
    int *volatile nptr = 0;
    int c = *nptr;
    printf("%d", c); // to prevent optimizing away the crash
}

This solved my immediate problem, the testcase "works" (aka crashes) with both gcc and clang.

I guess because dereferencing the null pointer is undefined behavior, clang is free to compile my first code into something that doesn't crash. The volatile qualifier removes the ability to be sure at compile time that this really will dereference null.

Now my questions are:

Upvotes: 12

Views: 4584

Answers (5)

dgnuff
dgnuff

Reputation: 3557

No, dereferencing a NULL pointer is not a portable way of crashing a program. It is undefined behavior, which means just that, you have no guarantees what will happen.

As it happen, for the most part under any of the three main OS's used today on desktop computers, that being MacOS, Linux and Windows NT (*) dereferencing a NULL pointer will immediately crash your program.

That said: "The worst possible result of undefined behavior is for it to do what you were expecting."

I purposely put a star beside Windows NT, because under Windows 95/98/ME, I can craft a program that has the following source:

int main()
{
    int *pointer = NULL;
    int i = *pointer;
    return 0;
}

that will run without crashing. Compile it as a TINY mode .COM files under 16 bit DOS, and you'll be just fine.

Ditto running the same source with just about any C compiler under CP/M.

Ditto running that on some embedded systems. I've not tested it on an Arduino, but I would not want to bet either way on the outcome. I do know for certain that were a C compiler available for the 8051 systems I cut my teeth on, that program would run fine on those.

Upvotes: 2

joop
joop

Reputation: 4523

The program below should work. It might cause some collateral damage, though.

#include <string.h>

void crashme( char *str)
{
char *omg;

for(omg=strtok(str, "" ); omg ; omg=strtok(NULL, "") ) {
        strcat(omg , "wtf");
        }
*omg =0; // always NUL-terminate a NULL string !!!
}

int main(void)
{
char buff[20];
// crashme( "WTF" );    // works!
// crashme( NULL );     // works, too
crashme( buff );        // Maybe a bit too slow ...
return 0;
}

Upvotes: 0

user2371524
user2371524

Reputation:

The answer refering to abort() was great, I really didn't think of that and it's indeed a perfectly portable way of forcing an abnormal program termination.

Trying it with my code, I came across msvcrt (Microsoft's C runtime) implements abort() in a special chatty way, it outputs the following to stderr:

This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

That's not so nice, at least it unnecessarily clutters the output of a complete test run. So I had a look at __builtin_trap() that's also referenced in clang's warning. It turns out this gives me exactly what I was looking for:

LLVM code generator translates __builtin_trap() to a trap instruction if it is supported by the target ISA. Otherwise, the builtin is translated into a call to abort.

It's also available in gcc starting with version 4.2.4:

This function causes the program to exit abnormally. GCC implements this function by using a target-dependent mechanism (such as intentionally executing an illegal instruction) or by calling abort.

As this does something similar to a real crash, I prefer it over a simple abort(). For the fallback, it's still an option trying to do your own illegal operation like the null pointer dereference, but just add a call to abort() in case the program somehow makes it there without crashing.

So, all in all, the solution looks like this, testing for a minimum GCC version and using the much more handy __has_builtin() macro provided by clang:

#undef HAVE_BUILTIN_TRAP
#ifdef __GNUC__
#  define GCC_VERSION (__GNUC__ * 10000 \
    + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
#  if GCC_VERSION > 40203
#    define HAVE_BUILTIN_TRAP
#  endif
#else
#  ifdef __has_builtin
#    if __has_builtin(__builtin_trap)
#      define HAVE_BUILTIN_TRAP
#    endif
#  endif
#endif

#ifdef HAVE_BUILTIN_TRAP
#  define crashMe() __builtin_trap()
#else
#  include <stdio.h>
#  define crashMe() do { \
    int *volatile iptr = 0; \
    int i = *iptr; \
    printf("%d", i); \
    abort(); } while (0)
#endif

// [...]

PT_TESTMETHOD(test_expected_crash)
{
    PT_Test_expectCrash();

    // crash intentionally
    crashMe();
}

Upvotes: 5

valdo
valdo

Reputation: 12943

you can write memory instead of reading it.

*((int *)0) = 0;

Upvotes: 4

Bathsheba
Bathsheba

Reputation: 234795

I wouldn't rely on that method as being robust if I were you.

Can't you use abort(), which is part of the C standard and is guaranteed to cause an abnormal program termination event?

Upvotes: 18

Related Questions