[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