bug#5515: 23.1.92; OSX: Emacs gets stuck while wanting to display a dialog box

[Carsten Bormann]

On Apr 10, 2010, at 08:26, Adrian Robert wrote:

> 
> On Apr 3, 2010, at 6:18 PM, Adrian Robert wrote:
> 
>> 
>> On Apr 3, 2010, at 12:57 PM, Carsten Bormann wrote:
>> 
>>> I have distilled the test case to the attached file.
>>> Sorry, I don't know how to reduce this further.
>>> At least it's fully reproduceable with various Emacs versions around 
>>> 23.1/24.0.
>>> I only tried it on 10.6, though.
>> 
>> <dot-emacs-reproduce-5515-1.el>
> 
> Hello Carsten,
> 
> Thank you for this test case.  I tried the procedure outlined, but could not 
> reproduce the issue on a somewhat older (23.1.90) version of emacs, running 
> 64-bit on 10.6.2.  

I just tried rebuilding Emacs 24.0. from scratch, from the git version 
218181d7f636089824e9f876a5d662bf2e350229.
Using the parameters you told me:

setenv CFLAGS '-g'
./configure --with-ns
make -j3
make install

Running this on 10.6.3 (but I previously reproduced this on 10.6.2).

Now it takes three attempts (not two as previously) to open a Ruby file to 
reproduce the bug.
(This appears to point to some randomness influencing the occurrence of the 
bug.)


> I guess we have a regression here.  However, I fixed a related dialog problem 
> (bug#5811) with the attached patch.  Would you be able to test it and see if 
> it does anything for the issue in your case?

I then applied the patch, rebuilt (make -j3; make install), and retried.
(I cannot reproduce 5811 with the patched version, but I didn't try before 
patching; I *can* reproduce 5811 with an earlier 24.0.50 from 
http://emacsformacosx.com/builds -- the one built 2010-03-30; so this bug now 
seems to be fixed.)

Unfortunately, the patch makes no difference in the behavior wrt 5515.

BTW, if I evoke the print dialog once (CMD-P), click No, and then try the C-x 
C-f, I need only two attempts to trigger the bug.  If I evoke the print dialog 
twice, click No, and then try the C-x C-f, I trigger the bug immediately.  So 
it looks like the third dialog gets hit, but:
I can evoke the print dialog as much as I want without triggering the bug.

So, it looks like:
-- the bug only happens if dialogs have been active before (used to be once, 
now twice).
-- the bug only happens if the dialog is evoked in some rather specific 
circumstances (such as here: from an error handler in the creation of a process 
that is started from a timer handler).

Looks like this needs more work to properly isolate.

Gruesse, Carsten