Re: Help wanted - problems with heap
- From: tyrecius13@xxxxxxxxx
- Date: Sat, 1 Dec 2007 22:56:11 -0800 (PST)
On Dec 2, 12:54 am, andrewdoull <andrewdo...@xxxxxxxxx> wrote:
I suspect that I'm either running into one of three things:
1. Memory pressure, because of limited heap size. But step 2 should have
identified that by failures to allocate memory. I'm not sure if any major OS
still has significant heap limits and what those are.
2. Heap fragmentation. Unangband allocates 'a lot of memory' in one go (up to
130K per init file) during the initialisation phase of the program where it
parses external data files and creates binary structures from them, then
determines what the correct size for the initialised data structure should be
once it has read in the data, then frees the larger chunks. This undoubtedly
causes problems with heap fragmentation. Again, I'd expect memory allocation
failures, which should results in quitting, if this is the case.
3. Heap corruption. This is the most likely.
Any pointers as to work out what is happening would be welcome.
Ah. Pointers are the problem. :-)
Here are a few things. First, make sure that you were had all the
options that valgrind allows for memory checking turned on. You might
also try similar tools that do the same thing. Some are more clever/
full-proof than others. Electric-fence tends to be popular. Also, make
sure that you don't fall outside of the tolerances of the tool. For
instance, valgrind assumes that it can replace the default malloc/free
with its own through the dynamic linker. If you are statically
linking, it doesn't help.
Second, tools like valgrind etc. do run-time checks which means that
if the bug does not get tickled on a particular run, then they don't
tell you about the problem. If you can't see the bug happening while
running this kind of tool, then you can't say anything about the
nature of the bug.
Third, it may be stack corruption. This might cause a later crash in
free() if the pointer that you are deleting was overwritten with a
weird value.
Fourth, unless you have a callstack from the crash, it may not be
happening where you think it is happening. Buffers are not flushed on
a crash so you can have situations where the last thing actually sent
to the screen or a log is far away from the actual problem.
I find that the best way to deal with these problems as a systemic
issue is to assign ownership to pointers. Pointer x has ownership and
pointer y is just using it, so you need to make sure that y is gone
before freeing x. That kind of reasoning. Make sure that you are
especially documenting interfaces that use pointers. When a pointer is
passed through an interface, it should always be clear whether the
interface expects to own that object from then on and delete it at its
own pace, or whether it is just borrowing it. If an interface is just
borrowing it, make sure that the interface is cleaned up before
destroying the object.
Oddly enough, I've been having heap/stack corruption problems on my
own roguelike (actually, it isn't very roguelike anymore). But in my
case it is in a garbage-collected sandbox where it should be
impossible (flash). Unfortunately, that makes it 10 times more
difficult to find. :(
-D
.
- Follow-Ups:
- Re: Help wanted - problems with heap
- From: andrewdoull
- Re: Help wanted - problems with heap
- References:
- Help wanted - problems with heap
- From: andrewdoull
- Help wanted - problems with heap
- Prev by Date: Re: Yet another roguelike dev guide, this time aimed at a non-rgrd audience
- Next by Date: Re: Yet another roguelike dev guide, this time aimed at a non-rgrd audience
- Previous by thread: Help wanted - problems with heap
- Next by thread: Re: Help wanted - problems with heap
- Index(es):
Relevant Pages
|
