5

Is there a way to check for buffer overflows in VLA's ? I used -fstack-protector-all -Wstack-protector but get these warnings:

warning: not protecting local variables: variable length buffer

Is there a library for achieving this ? (-lefence is for heap memory)

I'm currently using Valgrind and gdb.

osgx
  • 90,338
  • 53
  • 357
  • 513
Jan Chou
  • 51
  • 1

3 Answers3

1

You can use -fmudflap instead of -fstack-protector-all

Update: Some documentation and options are here http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging

osgx
  • 90,338
  • 53
  • 357
  • 513
Ting Chang
  • 11
  • 1
0

Perhaps using alloca() will help. That's annoying, because c99 should save you from having to use it, but the GCC man page seems to say that the stack protection code will be turned on if you use alloca().

Of course the real solution is to write perfect, bug free code that never tries to corrupt the stack.

Adrian Ratnapala
  • 5,485
  • 2
  • 29
  • 39
0

I don't see how a library could do this for you; with a variable-length array, you're not calling any functions to do the indexing, so there's no place to "hook in" a library. With malloc(), the allocation is explicit in a function and you can track it.

Of course, you could go through the code and use preprocessor trickery to add some macro to each indexing point, and have the macro expand to code that checks the boundaries. But that is very intrusive.

I'm thinking something like changing:

void work(int n)
{
  int data[n];   /* Our variable-length array. */

  data[0] = 0;
}

into something like:

#include "vla-tracking.h"

void work(int n)
{
  VLA_NEW(int, data, n);  /* Our variable-length array. */

  VLA_SET(data, 0, 0);
}

Then come up with suitable macro definitions (and auxiliary code) to track the accesses. As I said, it won't be pretty. Of course, the idea is that the macros would be able to "compile out" to just the plain definitions, controlled by some build-time setting (debug/release mode, or whatever).

unwind
  • 391,730
  • 64
  • 469
  • 606