< September 2006 >
      1 2
3 4 5 6 7 8 9
Wed, 20 Sep 2006:

Currently, I am totally struggling with APC's shm memory. Usually with most memory issues, the system cleanly segfaults. But when the memory is part of a 128 MB mmap() area, a couple of bytes here or there show up way too late in the debug operations to detect and fix.

Now, a lot of the allocator code has things which allocate n bytes + sizeof(header) and return the allocated area - sizeof(header). The problem is that my previous watchpoints code cannot differentiate between these two, unless I put an explicit watchpoint on the location. Not to mention, it has no concept of free operation in conjuction with the original block.

Digging around in valgrind code, I found an elegant answer to the problem - VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_MAKE_NOACCESS. Here's a mocked up version of my code, which seems to work out.

#include <valgrind/valgrind.h>
#include <valgrind/memcheck.h>

void *  alloc(size_t n) 
	void* x = malloc(n + 42);
	x = (unsigned char *)x + 42;
	return x;
void dealloc(void * ptr)
	free(ptr - 42);
int main() 
	size_t n = 200;
	char * a = alloc(n);
	a[0] = '1';
	a[-1] = 'x';

Now, the valgrind has red-zones, which are like canaries or sentinels for memory over-writes. I haven't figured out quite how to use them, but this should be enough right now, I think.

==28706== Invalid write of size 1
==28706==    at 0x80484ED: main (x.c:23)
==28706==  Address 0x4025051 is 41 bytes inside a block of size 242 alloc'd

And the line 23 is the a[-1]. Valgrind is just amazing. Ever since I've hit up on this tool, I've found that my debugging life is a lot easier. Now, to reproduce original bug and nail that son of a b*tch :)

They separate the right from the left, the man from the woman, the plant from the animal,
the sun from the moon. They only want to count to two.
                -- Emma Bull, "Bone Dance

posted at: 15:44 | path: /hacks | permalink | Tags: ,