bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo

bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo

[Jim Radford]

I often cannot connect to "emacs --daemon" with emacsclient because
instead of select()ing on the appropriate sockets it's stuck in [NSApp
run] waiting for an event which will never come.  Note at this time
there are no Cocoa windows open (I don't use them) so no events will
*ever* come (unless I, say, open and close the about box which triggers
an escape from the hang).  Here's the backtrace when this occurs.

    frame #9: 0x00007fff940cc89b AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
    frame #10: 0x00000001001a659f Emacs`-[EmacsApp run](self=0x0000000100a26910, _cmd=<unavailable>) + 223 at nsterm.m:4494
    frame #11: 0x00000001001a5219 Emacs`ns_select(nfds=<unavailable>, readfds=0x00007fff5fbfea00, writefds=0x00007fff5fbfe980, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) + 809 at nsterm.m:3748
    frame #12: 0x0000000100179811 Emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=-1, do_display=true, wait_for_cell=4328534074, wait_proc=0x0000000000000000, just_wait_proc=<unavailable>) + 2209 at process.c:4601
    frame #13: 0x00000001000c1ce4 Emacs`read_decoded_event_from_main_queue [inlined] kbd_buffer_get_event(kbp=<unavailable>, used_mouse_menu=<unavailable>, end_time=<unavailable>) + 807 at keyboard.c:3906
    frame #14: 0x00000001000c19bd Emacs`read_decoded_event_from_main_queue [inlined] read_event_from_main_queue(end_time=<unavailable>, local_getcjmp=<unavailable>) + 1569 at keyboard.c:2246
    frame #15: 0x00000001000c139c Emacs`read_decoded_event_from_main_queue(end_time=<unavailable>, local_getcjmp=<unavailable>, prev_event=<unavailable>, used_mouse_menu=<unavailable>) + 44 at keyboard.c:2310
    frame #16: 0x00000001000c021e Emacs`read_char(commandflag=1, map=4322429222, prev_event=4328534074, used_mouse_menu=0x00007fff5fbff1ff, end_time=0x0000000000000000) + 5918 at keyboard.c:2895
    frame #17: 0x00000001000bc9d3 Emacs`read_key_sequence(bufsize=<unavailable>, keybuf=<unavailable>, prompt=<unavailable>, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) + 1859 at keyboard.c:9088
    frame #18: 0x00000001000bc064 Emacs`command_loop_1 + 5188 at keyboard.c:1452
    frame #19: 0x000000010013714b Emacs`internal_condition_case(bfun=0x00000001000bac20, handlers=<unavailable>, hfun=<unavailable>) + 251 at eval.c:1354
    frame #20: 0x00000001000cc4ae Emacs`command_loop_2(ignore=<unavailable>) + 62 at keyboard.c:1177
    frame #21: 0x0000000100136ae3 Emacs`internal_catch(tag=<unavailable>, func=0x00000001000cc470, arg=4328534074) + 243 at eval.c:1118
    frame #22: 0x00000001000ba1ed Emacs`recursive_edit_1 [inlined] command_loop + 91 at keyboard.c:1156
    frame #23: 0x00000001000ba192 Emacs`recursive_edit_1 + 130 at keyboard.c:777
    frame #24: 0x00000001000ba39c Emacs`Frecursive_edit + 236 at keyboard.c:848
    frame #25: 0x00000001000b8fec Emacs`main(argc=0, argv=<unavailable>) + 5836 at emacs.c:1646
    frame #26: 0x00007fff928685fd libdyld.dylib`start + 1

In GNU Emacs 24.3.93.2 (x86_64-apple-darwin13.3.0, NS apple-appkit-1265.21)
 of 2014-09-20
Windowing system distributor `Apple', version 10.3.1265
Configured using:
 `configure --prefix=/tmp/emacs --with-ns'

bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo

[Jan Djärv]

Hello.

Cocoa does not allow you to disconnect and connect the GUI like X can.
So running a Cocoa compiled Emacs as --daemon does not make much sense.
You are seeing the consequence of this.

So basically, don't do this. :-)

	Jan D.

13 okt 2014 kl. 09:13 skrev Jim Radford <radford@blackbean.org>:

> I often cannot connect to "emacs --daemon" with emacsclient because
> instead of select()ing on the appropriate sockets it's stuck in [NSApp
> run] waiting for an event which will never come.  Note at this time
> there are no Cocoa windows open (I don't use them) so no events will
> *ever* come (unless I, say, open and close the about box which triggers
> an escape from the hang).  Here's the backtrace when this occurs.
> 
>    frame #9: 0x00007fff940cc89b AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
>    frame #10: 0x00000001001a659f Emacs`-[EmacsApp run](self=0x0000000100a26910, _cmd=<unavailable>) + 223 at nsterm.m:4494
>    frame #11: 0x00000001001a5219 Emacs`ns_select(nfds=<unavailable>, readfds=0x00007fff5fbfea00, writefds=0x00007fff5fbfe980, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) + 809 at nsterm.m:3748
>    frame #12: 0x0000000100179811 Emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=-1, do_display=true, wait_for_cell=4328534074, wait_proc=0x0000000000000000, just_wait_proc=<unavailable>) + 2209 at process.c:4601
>    frame #13: 0x00000001000c1ce4 Emacs`read_decoded_event_from_main_queue [inlined] kbd_buffer_get_event(kbp=<unavailable>, used_mouse_menu=<unavailable>, end_time=<unavailable>) + 807 at keyboard.c:3906
>    frame #14: 0x00000001000c19bd Emacs`read_decoded_event_from_main_queue [inlined] read_event_from_main_queue(end_time=<unavailable>, local_getcjmp=<unavailable>) + 1569 at keyboard.c:2246
>    frame #15: 0x00000001000c139c Emacs`read_decoded_event_from_main_queue(end_time=<unavailable>, local_getcjmp=<unavailable>, prev_event=<unavailable>, used_mouse_menu=<unavailable>) + 44 at keyboard.c:2310
>    frame #16: 0x00000001000c021e Emacs`read_char(commandflag=1, map=4322429222, prev_event=4328534074, used_mouse_menu=0x00007fff5fbff1ff, end_time=0x0000000000000000) + 5918 at keyboard.c:2895
>    frame #17: 0x00000001000bc9d3 Emacs`read_key_sequence(bufsize=<unavailable>, keybuf=<unavailable>, prompt=<unavailable>, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) + 1859 at keyboard.c:9088
>    frame #18: 0x00000001000bc064 Emacs`command_loop_1 + 5188 at keyboard.c:1452
>    frame #19: 0x000000010013714b Emacs`internal_condition_case(bfun=0x00000001000bac20, handlers=<unavailable>, hfun=<unavailable>) + 251 at eval.c:1354
>    frame #20: 0x00000001000cc4ae Emacs`command_loop_2(ignore=<unavailable>) + 62 at keyboard.c:1177
>    frame #21: 0x0000000100136ae3 Emacs`internal_catch(tag=<unavailable>, func=0x00000001000cc470, arg=4328534074) + 243 at eval.c:1118
>    frame #22: 0x00000001000ba1ed Emacs`recursive_edit_1 [inlined] command_loop + 91 at keyboard.c:1156
>    frame #23: 0x00000001000ba192 Emacs`recursive_edit_1 + 130 at keyboard.c:777
>    frame #24: 0x00000001000ba39c Emacs`Frecursive_edit + 236 at keyboard.c:848
>    frame #25: 0x00000001000b8fec Emacs`main(argc=0, argv=<unavailable>) + 5836 at emacs.c:1646
>    frame #26: 0x00007fff928685fd libdyld.dylib`start + 1
> 
> In GNU Emacs 24.3.93.2 (x86_64-apple-darwin13.3.0, NS apple-appkit-1265.21)
> of 2014-09-20
> Windowing system distributor `Apple', version 10.3.1265
> Configured using:
> `configure --prefix=/tmp/emacs --with-ns'
> 
> 

bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo

[Jim Radford]

On Wed, Oct 15, 2014 at 07:50:52PM +0200, Jan Djärv wrote:
> 13 okt 2014 kl. 09:13 skrev Jim Radford <radford@blackbean.org>:
> 
> > I often cannot connect to "emacs --daemon" with emacsclient because
> > instead of select()ing on the appropriate sockets it's stuck in [NSApp
> > run] waiting for an event which will never come.  Note at this time
> > there are no Cocoa windows open (I don't use them) so no events will
> > *ever* come (unless I, say, open and close the about box which triggers
> > an escape from the hang).  Here's the backtrace when this occurs.
> > 
> >    frame #9: 0x00007fff940cc89b AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
> >    frame #10: 0x00000001001a659f Emacs`-[EmacsApp run](self=0x0000000100a26910, _cmd=<unavailable>) + 223 at nsterm.m:4494
> >    frame #11: 0x00000001001a5219 Emacs`ns_select(nfds=<unavailable>, readfds=0x00007fff5fbfea00, writefds=0x00007fff5fbfe980, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) + 809 at nsterm.m:3748
> > 
> Cocoa does not allow you to disconnect and connect the GUI like X can.
> So running a Cocoa compiled Emacs as --daemon does not make much sense.
> You are seeing the consequence of this.

What doesn't make sense is running two main loops in the same thread
and trying to alternatively spin on one (EmacsApp run) and then the
other (select) without knowing which might produce the next event.
That is guaranteed to fail, as I am seeing.

I'm going to guess that you can't register file descriptors with the
Cocoa main loop nor get a file descriptor from it that you can pass to
select?  Could we instead spawn a thread just to run select() in a
loop, passing the results to the main thread as a Cocoa event?  Or
visa versa?

-Jim

bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo

[Stefan Monnier]

> Cocoa does not allow you to disconnect and connect the GUI like X can.

Would it make sense to never disconnect (when in daemon), then?
Kind of like what we do for Gtk to try and circumvent the infamous problem,


        Stefan

bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo

[Jan Djärv]

Hi.

Don't remove the debbugs address.

15 okt 2014 kl. 20:59 skrev Jim Radford <radford@blackbean.org>:

> 
> What doesn't make sense is running two main loops in the same thread
> and trying to alternatively spin on one (EmacsApp run) and then the
> other (select) without knowing which might produce the next event.
> That is guaranteed to fail, as I am seeing.

Probably.  That is why we don't do that.

> 
> I'm going to guess that you can't register file descriptors with the
> Cocoa main loop nor get a file descriptor from it that you can pass to
> select?  Could we instead spawn a thread just to run select() in a
> loop, passing the results to the main thread as a Cocoa event?  Or
> visa versa?

We do that.

	Jan D.

bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo

[Jan Djärv]

Hello.

15 okt 2014 kl. 21:21 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>> Cocoa does not allow you to disconnect and connect the GUI like X can.
> 
> Would it make sense to never disconnect (when in daemon), then?
> Kind of like what we do for Gtk to try and circumvent the infamous problem,

The original report was short on details, so we don't know the commands he did w.r.t. GUI frames or -nw frames.  Its mixing those that can get you into trouble.
AFAIK, the NS port never disconnects.  If the NSApp run loop has been entered once, it will always be used.

	Jan D.

bug#18705: 24.3.93; Hang in ns_select -> [NSApp run] -> oo

[Jan Djärv]

Closing this bug as not reproducable.
Reopen if there is a reproducable test case.

	Jan D.