RE: [Devel] NT crash in psaux

[Blinn, Eric W]

Okay, I finally found a consistent way to reproduce this in our application.
Since then I've started making some progress.  Unfortunately, I have to
leave for the day so I'm setting it aside until tomorrow.  However, let me
summarize what I know in case somebody want to continue looking into it
today...

What really leads to this crash is that when we get into PS_Table_Add(), we
pass in "table" and "object".  Sometimes table->block and object point to
the same piece of memory.  I haven't backtracked yet to see how we've gotten
ourselves into this messy state.  The bottom line is that if table->cursor +
length is greater than table->capacity, then we end up doing a realloc() on
table.  If realloc() can't increase the existing memory chunk, then it will
free it (leaving pointer object dangling) and malloc a new block of the
desired size.  Then we go on to do the MEM_Copy() a few lines later, at
which point NT/VC++ chokes when we try to read the unallocated memory object
is still pointing at.


> -----Original Message-----
> From: Werner LEMBERG [mailto:address@hidden
> Sent: Wednesday, January 31, 2001 1:35 PM
> To: address@hidden
> Cc: address@hidden
> Subject: Re: [Devel] NT crash in psaux
> 
> 
> 
> > The crash happens when PS_Table_Add() calls MEM_Copy() with a
> > "source" argument (variable name object) pointing to memory that has
> > already been freed.  This results in a free memory read and a crash
> > on NT/VC++.  I also work on DEC OSF/1 with the native DEC compiler,
> > but we don't crash there presumably because the platform let's us
> > get away with reading unallocated memory.
> 
> It seems to me that `reallocate_t1_table()' is buggy: It reallocates
> `table->block' (saving its old address in `old_base'), then calls
> `shift_elements()', using `old_base'.
> 
> IIRC it is not guaranteed that a newly allocated memory block (in case
> realloc() doesn't increase the old one) doesn't overlap with the old
> block, so shift_elements() will cause trouble.  Additionally, the
> memory pointed to by `old_base' is no longer valid in this case.
> 
> 
>     Werner
> 
> _______________________________________________
> Devel mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/devel
>