[patch] Accessing freed memory crash
Mikulas Patocka
mikulas at artax.karlin.mff.cuni.cz
Sat Aug 12 18:02:40 UTC 2006
> 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
>
>
More information about the mc-devel
mailing list