Bug#159503: Bug#159023: dselect: dselect core dumps

[Adam Heath <doogie@debian.org>]

On Sat, 31 Aug 2002, Adam Heath wrote:

> tag 159023 + pending
> thanks
>
> On Sat, 31 Aug 2002, Adam Heath wrote:
>
> > On Sat, 31 Aug 2002, Alex Romosan wrote:
> >
> > > after going into select trying to exit dselect or trying to go back
> > > to select causes dselect to core dump.
> >
> > Grr.  The unstripped dselect does *NOT* segfault, but the stripped one does.
>
> 1.10.5 was modified to call nffreeall(), and, only for dselect, does this
> segfault.
>
> The fix is to not call it at all, until I can figure out why freeing memory
> causes the segfault to occur.

ah ha!

dselect calls resetpackages() when exiting select.  This calls nffreeall().
Dselect then also calls nffreeall when exiting(this was new in 1.10.5).

So, this shows that obstacks don't support double free.

A little investigation, and I have made a patch to fix obstacks(bug#159493).

Now, the next problem, is that at the time resetpackages is called, curses is
on, so any output is lost.

And when nffreeall is called when dselect exits, all the memory has already
been freed, so --memstat produces no useful output.

A possible solution is to call resetpackages before going into select.

In any event, this will not be done on the 1.10 branch.