Re: [patch] Accessing freed memory crash

[Mikulas Patocka <mikulas artax karlin mff cuni cz>]

> Hello Mikulas,
>
> On Sat, 2006-08-12 at 03:35 +0200, Mikulas Patocka wrote:
> > I think the code you committed is wrong. Imagine this: you have one event
> > in select list and that event is set in select_set. On the first pass, you
> > call callback and set retry to TRUE. Callback removes the event. You
> > return to "do" cycle, now select_list is empty, you never get to
> > retry=FALSE statement, and you loop forever with retry == TRUE.
>
> You are right.
>
> > do
>
> I'll set retry to FALSE here at the beginning of the do loop. Agreed?

Yes, that is fine now (btw. else retry = FALSE is useless in current code, 
but it doesn't hurt).

> >      for (p = select_list; p; p = p->next)
> >          if (FD_ISSET (p->fd, select_set)) {
> >              FD_CLR (p->fd, select_set);
>
> This morning I realized I didn't check out the consequences of clearing
> select_set here. Can we safely do this without disturbing the caller?

I think yes. It is called only from two places, and only input_fd and 
gpm_fd is checked after call to check_selects. So it should work fine 
unless there's add_select_channel called with input_fd or gpm_fd --- and 
there is none (it would not make much sense to check event with both 
add_select_channel and get_event).

Mikulas

> >              (*p->callback)(p->fd, p->info);
> >              retry = TRUE;
> >              break;
> >          } else
> >              retry = FALSE;
> > while (retry);
>
> Leonard.
>
> --
> mount -t life -o ro /dev/dna /genetic/research