ass5 understanding examine_heap()

[Taha Liaqat]

SFU ID: tliaqat

Github username: tliaqat

Github: https://github.com/CMPT-295-SFU/assignment-5-tliaqat.git

Line and file: mm.c, line 449

Expected behavior: code doesn't seg fault

Observed behavior: code seg faults

Question: when running the short tests, the functions work properly. When running just ./mdriver, the program seg faults. I put in a call to examine_heap() right before my call to removeFreeBlock(), and I am struggling to understand the output. I don't understand why the heap no longer has a free block after 5 calls. I believe it has something to do with my mm_free() method but I don't know what it could be.

[Arrvindh Shriraman]

Your trace does not appear to have any free blocks as I am not seeing the heap get back any free space. 

You may want to examine_heap after every call in the trace. 

[Taha Liaqat]

but the program seg faults before any calls to free, so the heap won't be getting any free space back. But for some reason the short traces can make it to >5 mallocs and not seg fault, but the longer programs can't. Whats the difference between the two traces up and till that point?

[Arrvindh Shriraman]

Ok; I only mentioned free because you mentioned it "I believe it has something to do with my mm_free()".

Does your trace contain a free call or not ? Are you failing before you hit free ? 

This just seems a case of you not requestingmorespace and trying to allocate.

Check why you are not requesting more space? when you ran out of space ?

The searchforfree block should have returned NULL at the time of the segfault, triggering a request for more freespace. 

[Taha Liaqat]

yes, im failing before the trace calls free. I do seem to be requesting more space before when I need to(added a print statement to check), but the problem seems to be that the head of the free list becomes NULL. I'm not sure where I am directly affecting the pointers of the head of the list, the only place seems to be calls to insertFreeBlock() and removeFreeBlock().

[ashrir...@gmail.com]

That seems to imply you have a strange pointer write somewhere. 

You can watch the FREE_LIST_HEAD address from the start and see when its being modified.

See tutorial here on how to use it. http://www.unknownroad.com/rtfm/gdbtut/gdbwatch.html

Typical route

start gdb

break somwhere

insert watchpoint for variable

continue

You will break when the FREE_LIST is updated. You can see who is setting it to NULL