bug#12834: 24.3.50; OS X selecting a font can lock Emacs

[Ivan Andrus <darthandrus@gmail.com>]

Well it went from being 100% reproducible to only about 10%.  Although I haven't tested it exhaustively, it seems to only be a problem when I type in some ridiculously large font size e.g. 7000.  So I think it's probably not really an issue.

-Ivan

On Nov 17, 2012, at 4:29 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> Hello.
> 
> I can reproduce it sometimes, but not most of the times.  Anyway, I made another checkin in the emacs-24 branch.  Please try it.
> 
> 	Jan D.
> 
> 14 nov 2012 kl. 10:39 skrev Ivan Andrus <darthandrus@gmail.com>:
> 
>> On Nov 14, 2012, at 7:08 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> 
>>> Hello.
>>> 
>>> 13 nov 2012 kl. 19:40 skrev Ivan Andrus <darthandrus@gmail.com>:
>>> On Nov 13, 2012, at 4:19 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>>> Which version did you build? Are you sure you built the emacs-24 branch, not trunk?
>>>> 
>>>> To be honest I'm not entirely sure how to figure that out.  Every time I think I understand bzr it doesn't do what I think.  Anyway, updating on the branch I get
>>>> 
>>>> $ bzr pull
>>>> Using saved parent location: bzr://bzr.savannah.gnu.org/emacs/emacs-24/                                                                                                             
>>>> No revisions or tags to pull.                                                                                                                                                       
>>>> 
>>>> In src/nsterm.m I see
>>>> 
>>>> 303  static void
>>>> 304  hold_event (struct input_event *event)
>>>> 305  {
>>>> 306    if (hold_event_q.nr == hold_event_q.cap)
>>>> 307      {
>>>> 308        if (hold_event_q.cap == 0) hold_event_q.cap = 10;
>>>> 309        else hold_event_q.cap *= 2;
>>>> 310        hold_event_q.q = (struct input_event *)
>>>> 311          xrealloc (hold_event_q.q, hold_event_q.cap * sizeof (*hold_event_q.q));
>>>> 312      }
>>>> 313  
>>>> 314    hold_event_q.q[hold_event_q.nr++] = *event;
>>>> 315    /* Make sure ns_read_socket is called, i.e. we have input.  */
>>>> 316    kill (0, SIGIO);
>>>> 317  }
>>>> 
>>>> which I think is the required change.  I still see the problem.  When I run under gdb I am unable to interrupt the process with Ctrl-C once it has stopped responding.  I'm afraid I'm not sure how to help debug it otherwise.  Sending SIGIO manually doesn't cause it to become responsive.
>>> 
>>> That is the fix.  Sending SIGIO manually is pointless.  I can not reproduce the error anymore, so make sure you did make install, and give the exact steps you did to encounter the bug, starting from -Q.
>> 
>> I ran make install to be sure.
>> 
>> ./nextstep/Emacs.app/Contents/MacOS/Emacs -Q
>> 
>> Interestingly this opens ~/.emacs.d/abbref_defs which had an error on my machine.  Is this expected with -Q?  Anyway, it's probably not relevant to the discussion at hand since I see the same behaviour if I move .emacs.d entirely.
>> 
>> Then I run `menu-set-font', either from the menu or with C-x C-e.  I can change the font and the size freely.  Then I click in the "Size" text box.  A few times this hasn't caused problems, but usually it causes Emacs to stop responding.  The font panel still responds, but nothing changes in terms of the font displayed and it doesn't register typing etc.  FWIW, I added a printf to hold_event and it gets called 3 times when I click on anything other than the text box, but only twice when I click on the text box. 
>> 
>> Thanks for looking into this.  I'm running 10.8.2 with home brew installed with the latest XCode installed.  I recently upgraded from 10.6.8.  I'm not sure what else might be at play.
>> 
>> -Ivan
>