Re: deref/use after free

[john heasley]

Thu, Jan 22, 2009 at 08:38:00PM -0500, Thomas Dickey:
> On Fri, 23 Jan 2009, john heasley wrote:
> 
> >Sat, Nov 22, 2008 at 06:43:41PM -0500, Thomas Dickey:
> >>On Fri, Nov 21, 2008 at 08:51:51AM +0000, john heasley wrote:
> >>>I have a home-grown curses application which dumps core within ncurses 
> >>>5.7
> >>>when the window is repeatedly resized.  The traceback is
> >>...
> >>>Without resizing, there are no segfaults.  I'm hoping that one of those
> >>>familiar with ncurses source will know where to look straight away.  If
> >>>not, i'll spend the time to track it down.
> >>
> >>I don't see the problem in the test-cases that I use for wresize and
> >>resizeterm, but did modify some of the logic last year, e.g., in 20080105.
> >
> >The trigger seems to stem from the deletion of a sub-window.  the subwin
> >is used for a menu.  When the screen is resized, our code (not written by
> >me) unposts the menu, gets the subwin pointer, delwins it, werases the
> >parent window, then recalculates parent and menu sizes, recreates the
> >subwin and reposts the menu.
> 
> (presumably _not_ in the signal handler ;-)
> 
> >if I change this to derwin (though I don't see how derwin is that different
> >from subwin) and not delwin it, instead adjusting it as necessary and
> >reposting the menu, then there is no corruption.
> 
> subwin is implemented in terms of derwin, in ncurses.
> (I don't see why it would differ, either)
> 
> >I narrowed this with dmalloc's fencepost, where I see what seems like
> >free'd memory being used.  I'm not yet certain if that is our code or
> >ncurses.
> 
> valgrind (for Linux) tends to give better information than dmalloc,
> though it still takes some study to see.

I don't use linux; it'd take some effort to use the box I can access.
I added a bunch of free(strdup("foo")) calls through the window/resizing
code to trigger the fencepost checking.  I'll poke some more; thanks
for your comments/suggestions.