[C]Memory errors in my memory manager

Questions about programming languages and debugging
Post Reply
User avatar
Lundis
Distorter of Reality
Distorter of Reality
Posts: 543
Joined: 22 Aug 2008, 16:00
15
Location: Deadlock of Awesome
Contact:

[C]Memory errors in my memory manager

Post by Lundis »

Excuse me for not having a good test-case, or any at all for that matter. Just a huge bunch of code, you can find some basic documentation in the headers.

I've been writing a game engine on and off for a while, and now I'm debugging the memory manager (keeps track of pointer usage and with a bit of luck it also reuses memory that isn't used anymore, without doing any slow syscalls).

My problem is that the usage count variable is distorted after I set it to 1, at some point, or that the compiler fails to read from the right memory address, or maybe something else. It's easiest explained with a bit of my code and the output:

http://code.suck-o.com/41144

Output: (OP pointer: usage_count)

Code: Select all

new 143951408: 1
new 143951096: 1
new 143952408: 1
new 143984408: 1
new 143984520: 1
new 143984632: 1
new 143984776: 1
new 143984920: 1
new 143984984: 1
new 143985048: 1
new 143985192: 1
new 143985240: 1
dec 143985240: 143985256
new 143985304: 1
inc 143984920: 143984952
dec 143985304: 143985320
new 143985368: 1
inc 143984984: 143985016
dec 143985368: 143985384
new 143985432: 1
new 143985488: 1
inc 143985432: 143985456
dec 143985488: 143985504
dec 143951096: 143951112
dec 143952408: 143952440
dec 143951408: 143964512
dec 143985192: 143985208
dec 143985048: 143985160
dec 143984408: 141620192
dec 143984520: 143991624
dec 143984632: 143984744
dec 143984776: 143984888
As you can see, the usage_count member of ptr_info is changed into a value that's clearly related to the ptr member. ptr + 16 seems to be common. The ptr_info structs aren't modifed anywhere but in the above code, so the only thing I can think of is that the CPU reads part of the pointer and part of the usage_count instead of just the usage_count.

Valgrind errors, they are probably related, although I don't see how the first could modify any values, and the second seems very suspicious, but I have no idea how such an error would arise (besides abusing pointer arithmetic):

Code: Select all

==6049== Invalid read of size 4
==6049==    at 0x804A965: ptr_info_equals_ptr (mem_mngr.c:20)
==6049==    by 0x804B3ED: check (containers.c:11)
==6049==    by 0x804B427: both_linked_list_find (containers.c:21)
==6049==    by 0x804B641: hashmap_find (containers.c:116)
==6049==    by 0x804AB83: _remove (mem_mngr.c:86)
==6049==    by 0x804AC2F: trash (mem_mngr.c:112)
==6049==    by 0x8049F53: destroy_func_holder (game_object.c:166)
==6049==    by 0x8049A75: destroy_game_object (game_object.c:48)
==6049==    by 0x80497FD: mainloop (main.c:163)
==6049==    by 0x8049848: main (main.c:179)
==6049==  Address 0x494ad8f is 1 bytes before a block of size 12 alloc'd
==6049==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==6049==    by 0x804AAA0: _add (mem_mngr.c:56)
==6049==    by 0x804AB56: cached_alloc (mem_mngr.c:72)
==6049==    by 0x8049F00: create_func_holder (game_object.c:157)
==6049==    by 0x8049F6D: add_function (game_object.c:171)
==6049==    by 0x80493F6: init_game_objects (main.c:80)
==6049==    by 0x8049843: main (main.c:178)
The first error is caused by the following code:

Code: Select all

typedef struct {
	void *ptr;
	int usage_count;
	size_t size;
} ptr_info;

int ptr_info_equals_ptr(const void *pi, const void *ptr) {
	void *stored = ((ptr_info*)pi)->ptr; // mem_mngr.c:20
	return stored == ptr;
}
www.lundis-haven.org/pub/dump/LGE.tar.gz
Makefile included. Depends on:
SDL SDL_image SDL_gfx SDL_stretch OpenGL.

Any comments are appreciated, whether they're suggestions on how to improve my hashmap or insight on this problem. Don't hesitate to ask about any code you find confusing/weird/horrible (line mem_mngr.c:20 comes to mind ;) ). Note that I'm still in the process of debugging after a large refactoring operation so if you look carefully you'll find bugs all over the place. :oops:

Post Reply