Simulating malloc failures

Is there something like valgrind that can make certain calls to malloc (also system calls could be interesting) fail?  My poor error paths never get tested.

Using a Python compiler would achieve your goal.

>>2
I don't think Python is Touring-complete, but thanks for the suggestion.

Well, I'm too lazy to dig into Valgrind and write my own module for this.  Would something like this work, perhaps?

char* malloc_break_file;
unsigned int malloc_break_line;

#define MALLOC(x) \
        ((__LINE__ == malloc_break_line && \
          strcmp(__FILE__, malloc_break_file) == 0) ? \
              NULL : \
              malloc(x))

I'll have to work a little with the preprocessor so I don't have to change anything in the code first.

http://goog-perftools.sourceforge.net/

I don't think it does what you want, but have a look anyway.

#define randomly_fail_malloc(x) ((rand()&1)?malloc(x):0)

http://www.ibm.com/developerworks/linux/library/l-glibc.html

To call malloc from your wrapper you'll have to grab the original malloc function via dlopen/dlsym. Easy!

>>6
http://c-faq.com/lib/notveryrand.html

just use linux. malloc never fails! the kernel just kills random processes when it runs out of memory!

Here he comes, here comes speedracer,
HE'S A DEMON ON WHEELS

>>7
That seems like a bit of an overkill, and I can't think of a way to control exactly which malloc will fail.

>>9
I'm not expecting malloc to fail, I just want to test my error paths as well.  Sure, it doesn't matter if memory leaks there, but what the hell, I might as well do it.

This is what I have now:

#define MALLOC(x) \
    ((getenv("MALLOC_FAIL_LINE_") && \
      getenv("MALLOC_FAIL_FILE_") && \
      (__LINE__ == strtol(getenv("MALLOC_FAIL_LINE_"), NULL, 10) && \
      strcmp(__FILE__, getenv("MALLOC_FAIL_FILE_")) == 0)) \
     ? NULL : malloc(x))

It seems both strtol and strcmp crash for NULL pointers.  I didn't figure out a nice way of replacing the internal malloc yet (I could just overwrite it and use realloc if I was lazy).

>>8
That was written a couple of decades ago. *Modern* systems are not braindead.

>>12
Except for the fact that most implementations of the standard rand use the same algorithm as they did decades ago for backward compatibility reasons, including glibc. There's a reason people tell you to use /dev/urandom instead.

There's a reason people tell you to use /dev/urandom instead.
To be slower and less portable?

>>14
POTENT POTABLES

>>13
Why the hell are ``rand" and ``backward compatibility" in the same sentence? rand() IS SUPPOSED TO BE RANDOM, ERGO ONE CANNOT RELY ON ITS RESULTS!

If you mean that, given the same seed, rand() should return the same sequence of numbers, then I'd agree; however, any application that relies on that sequence being the same across different platforms and not just different runs on the same platform is DOING IT WRONG

>>16
POTENT TROLL

>>15,17
TROLLENT TROLLABLES