Unit testing for failed malloc()

Question

What is the best way for unit testing code paths involving a failed malloc()? In most instances, it probably doesn't matter because you're doing something like

thingy *my_thingy = malloc(sizeof(thingy));
if (my_thingy == NULL) {
  fprintf(stderr, "We're so screwed!\n");
  exit(EXIT_FAILURE);
}

but in some instances you have choices other than dying, because you've allocated some extra stuff for caching or whatever, and you can reclaim that memory.

However, in those instances where you can try to recover from a failed malloc() that you're doing something tricky and error prone in a code path that's pretty unusual, making testing especially important. How do you actually go about doing this?

Answer 1

In FreeBSD I once simply overloaded C library malloc.o module (symbols there were weak) and replaced malloc() implementation with one which had controlled probability to fail. So I linked statically and started to perform testing. srandom() finished the picture with controlled pseudo-random sequence.

Also look here for a set of good tools that you seems to need by my opinion. At least they overload malloc() / free() to track leaks so it seems as usable point to add anything you want.

Answer 2

This is a kinda gross, but if you really want unit testing, you could do it with #ifdefs:

thingy *my_thingy = malloc(sizeof(thingy));
#ifdef MALLOC_UNIT_TEST_1
my_thingy = NULL;
#endif
if (my_thingy == NULL) {
  fprintf(stderr, "We're so screwed!\n");
  exit(EXIT_FAILURE);
}

Unfortunately, you'd have to recompile a lot with this solution.

If you're using linux, you could also consider running your code under memory pressure by using ulimit, but be careful.

Answer 3

I saw a cool solution to this problem which was presented to me by S. Paavolainen. The idea is to override the standard malloc(), which you can do just in the linker, by a custom allocator which

1. reads the current execution stack of the thread calling malloc()
2. checks if the stack exists in a database that is stored on hard disk
   1. if the stack does not exist, adds the stack to the database and returns NULL
   2. if the stack did exist already, allocates memory normally and returns

Then you just run your unit test many times---this system automatically enumerates through different control paths to malloc() failure and is much more efficient and reliable than e.g. random testing.

Answer 4

I suggest creating a specific function for your special malloc code that you expect could fail and you could handle gracefully. For example:

void* special_malloc(size_t bytes) {
  void* ptr = malloc(bytes);
  if(ptr == NULL) {
    /* Do something crafty */
  } else {
    return ptr;
  }
}

Then you could unit-test this crafty business in here by passing in some bad values for bytes. You could put this in a separate library and make a mock-library that does behaves special for your testing of the functions which call this one.

Answer 5

write your own library that implements malloc by randomly failing or calling the real malloc (either staticly linked or explicitly dlopened)

then LD_PRELOAD it

Answer 6

You could hijack malloc by using some defines and global parameter to control it... It's a bit hackish but seems to work.

#include <stdio.h>
#include <stdlib.h>

#define malloc(x) fake_malloc(x)

struct {
  size_t last_request;
  int should_fail;
  void *(*real_malloc)(size_t);
} fake_malloc_params;

void *fake_malloc(size_t size) {
  fake_malloc_params.last_request = size;
  if (fake_malloc_params.should_fail) {
    return NULL;
  }
  return (fake_malloc_params.real_malloc)(size);;
}

int main(void) {
  fake_malloc_params.real_malloc = malloc;
  void *ptr = NULL;
  ptr = malloc(1);
  printf("last: %d\n", (int) fake_malloc_params.last_request);
  printf("ptr: 0x%p\n", ptr);
  return 0;
}