GNU bug report logs - #12447
24.1.50; Stuck in garbage collection on OS X

Previous Next

Full log

Message #64 received at 12447 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12447 <at> debbugs.gnu.org, hanche <at> math.ntnu.no
Subject: Re: bug#12447: 24.1.50; Stuck in garbage collection on OS X
Date: Sun, 16 Sep 2012 19:56:11 +0400

On 16.09.2012 18:54, Eli Zaretskii wrote:
>> Date: Sun, 16 Sep 2012 18:25:50 +0400
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> CC: hanche <at> math.ntnu.no, 12447 <at> debbugs.gnu.org
>>
>>> Perhaps the problem is that the value of 'difference' is not
>>> initialized:
>>>
>>>     while (CONSP (timers) || CONSP (idle_timers))
>>>       {
>>>         Lisp_Object timer = Qnil, idle_timer = Qnil;
>>>         EMACS_TIME timer_time, idle_timer_time;
>>>         EMACS_TIME difference;   <<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>
>>> and then never set to any specific value, until here:
>>>
>>>         else
>>> 	/* When we encounter a timer that is still waiting,
>>> 	   return the amount of time to wait before it is ripe.  */
>>> 	{
>>> 	  UNGCPRO;
>>> 	  return difference;
>>> 	}
>>>
>>> which causes us return garbage, potentially zero, to timer_check.
>>
>> It's assigned to, though. When we encounter a timer that's not yet ripe.
>
> What if all of them are ripe?

I don't see the problem. The first timer is ripe? Fire it and return 
'nexttime'. Otherwise, return 'difference', which now has been assigned 
a value.
If we've reached the end of the list, again return 'nexttime', which is 
initialized with invalid_emacs_time () at the beginning of timer_check_2.

Anyway, I think the immediate problem is that the newly created timer 
can be considered ripe.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.