[9fans] OSX Drawterm hangs on close

[9fans] OSX Drawterm hangs on close

[Michaelian Ennis]

Any idea why drawterm-osx hangs when I try to close it with the dock
icon or by issuing  shutdown from the apple menu?  I am not sure what
signal is sent.  I've included a capture from spincontrol in case that
helps.

Ian

Call graph:
    6001 Thread_5903
      6001 start
        6001 _start
          6001 main
            6001 cpumain
              6001 exportfs
                6001 read9pmsg
                  6001 readn
                    6001 sysread
                      6001 _syspread
                        6001 kread
                          6001 sslread
                            6001 sslbread
                              6001 ensure
                                6001 devbread
                                  6001 ipread
                                    6001 recvfrom$NOCANCEL$UNIX2003
                                      6001 recvfrom$NOCANCEL$UNIX2003
    6001 Thread_5a03
      6001 thread_start
        6001 _pthread_start
          6001 tramp
            6001 blockingslave
              6001 slaveread
                6001 syspread
                  6001 _syspread
                    6001 kread
                      6001 consread
                        6001 ksleep
                          6001 procsleep
                            6001 pthread_cond_wait$UNIX2003
                              6001 __semwait_signal
                                6001 __semwait_signal
    6001 Thread_5b03
      6001 thread_start
        6001 _pthread_start
          6001 tramp
            6001 blockingslave
              6001 slaveread
                6001 syspread
                  6001 _syspread
                    6001 kread
                      6001 mouseread
                        6001 ksleep
                          6001 procsleep
                            6001 pthread_cond_wait$UNIX2003
                              6001 __semwait_signal
                                6001 __semwait_signal
    6001 Thread_5c03
      6001 thread_start
        6001 _pthread_start
          6001 tramp
            6001 blockingslave
              6001 slaveread
                6001 syspread
                  6001 _syspread
                    6001 kread
                      6001 consread
                        6001 qread
                          6001 qwait
                            6001 ksleep
                              6001 procsleep
                                6001 pthread_cond_wait$UNIX2003
                                  6001 __semwait_signal
                                    6001 __semwait_signal

Total number in stack (recursive counted multiple, when >=5):

Sort by top of stack, same collapsed (when >= 5):
        __semwait_signal        18003
        recvfrom$NOCANCEL$UNIX2003        6001

Re: [9fans] OSX Drawterm hangs on close

[andrey mirtchovski]

it's a known bug, but i don't think there's a fix for it.

Re: [9fans] OSX Drawterm hangs on close

[erik quanstrom]

> it's a known bug, but i don't think there's a fix for it.

what's the bug?

- erik

Re: [9fans] OSX Drawterm hangs on close

[andrey mirtchovski]

>  what's the bug?

drawterm hangs when closed through the doc icon :)

Re: [9fans] OSX Drawterm hangs on close

[Michaelian Ennis]

I'll try to figure out what signal is sent.  Any pointers on how do do this?

Re: [9fans] OSX Drawterm hangs on close

[andrey mirtchovski]

i've lost my notes on this, but basically you need to figure out why
the drawterm Carbon event handlers are not being called. it could be a
configuration option that we're not setting or something more
sinister. i don't know enough osx to be able to say.

another manifestation of the same bug which may be easier to debug, is
when you do apple-Q while in full-screen mode. the apple-q never
arrives at the keyboard handler for drawterm and consequently the code
never does a proper "exit". what's the difference between fullscreen
and windowed mode according to OSX is beyond me.

i'm sorry, i know this doesn't help much.

On Sun, Apr 6, 2008 at 2:07 PM, Michaelian Ennis
<michaelian.ennis@gmail.com> wrote:
> I'll try to figure out what signal is sent.  Any pointers on how do do this?
>
>

Re: [9fans] OSX Drawterm hangs on close

[Skip Tavakkolian]

wouldn't the appleevents go to the drawterm applescript you
and Paul posted a while back? this one:

	do shell script "cd ~ && drawterm -a somebox -c somebox"

so maybe the applescript needs to field or forward those?

> i've lost my notes on this, but basically you need to figure out why
> the drawterm Carbon event handlers are not being called. it could be a
> configuration option that we're not setting or something more
> sinister. i don't know enough osx to be able to say.
>
> another manifestation of the same bug which may be easier to debug, is
> when you do apple-Q while in full-screen mode. the apple-q never
> arrives at the keyboard handler for drawterm and consequently the code
> never does a proper "exit". what's the difference between fullscreen
> and windowed mode according to OSX is beyond me.
>
> i'm sorry, i know this doesn't help much.

Re: [9fans] OSX Drawterm hangs on close

[andrey mirtchovski]

no, they should go to the program, since it's the one that set up the
listener, et al. the applescript does the equivalent of opening the
terminal and running a program in it, with keyboard and mouse events
going directly to the program.

besides, i haven't used the script in years, preferring to start from
the terminal instead.

On Sun, Apr 6, 2008 at 3:22 PM, Skip Tavakkolian <9nut@9netics.com> wrote:
> wouldn't the appleevents go to the drawterm applescript you
>  and Paul posted a while back? this one:
>
>         do shell script "cd ~ && drawterm -a somebox -c somebox"
>
>  so maybe the applescript needs to field or forward those?
>
>
>
>  > i've lost my notes on this, but basically you need to figure out why
>  > the drawterm Carbon event handlers are not being called. it could be a
>  > configuration option that we're not setting or something more
>  > sinister. i don't know enough osx to be able to say.
>  >
>  > another manifestation of the same bug which may be easier to debug, is
>  > when you do apple-Q while in full-screen mode. the apple-q never
>  > arrives at the keyboard handler for drawterm and consequently the code
>  > never does a proper "exit". what's the difference between fullscreen
>  > and windowed mode according to OSX is beyond me.
>  >
>  > i'm sorry, i know this doesn't help much.
>
>
>

Re: [9fans] OSX Drawterm hangs on close

[Anant Narayanan]

On 06-Apr-08, at 8:46 AM, erik quanstrom wrote:
>> it's a known bug, but i don't think there's a fix for it.
>
> what's the bug?

drawterm on OS X needs to be rewritten in Cocoa.

--
Anant

Re: [9fans] OSX Drawterm hangs on close

[Jeff Sickel]

On Apr 8, 2008, at 8:34 AM, Anant Narayanan wrote:
>
> On 06-Apr-08, at 8:46 AM, erik quanstrom wrote:
>>> it's a known bug, but i don't think there's a fix for it.
>>
>> what's the bug?
>
> drawterm on OS X needs to be rewritten in Cocoa.

Cocoa isn't completely needed... just getting rid of the Carbon
framework dependancy.

On 10.5.2, when quit from Dock->drawterm->Quit (should be the same as
a menu command for quit) we get:

(gdb) info threads
   6 process 4410 thread 0x5b03  0x902d2bce in __semwait_signal ()
   5 process 4410 thread 0x5903  0x902d2bce in __semwait_signal ()
   4 process 4410 thread 0x5803  0x902d2bce in __semwait_signal ()
   3 process 4410 thread 0x5703  0x902d2bce in __semwait_signal ()
* 1 process 4410 local thread 0x2f27  0x9031bb8e in recvfrom$UNIX2003 ()
(gdb) bt
#0  0x9031bb8e in recvfrom$UNIX2003 ()
#1  0x9031bb81 in recv$UNIX2003 ()
#2  0x00019c71 in so_recv (fd=5, d=0x162b0060, n=65536, f=0) at devip-
posix.c:209
#3  0x00018745 in ipread (ch=0x13cd70, a=0x162b0060, n=65536,
offset=0) at devip.c:377
#4  0x0000ba81 in devbread (c=0x13cd70, n=65536, offset=0) at dev.c:414
#5  0x0001f605 in ensure (s=0x1571d0, l=0x157224, n=3) at devssl.c:431
#6  0x0001f9e0 in sslbread (c=0x141de0, n=4, o=33837) at devssl.c:579
#7  0x0001ff00 in sslread (c=0x141de0, a=0x847600, n=4, off=33837) at
devssl.c:683
#8  0x00028e00 in kread (fd=7, buf=0x847600, n=4, offp=0x0) at
sysfile.c:408
#9  0x00028ea8 in _syspread (fd=7, buf=0x847600, n=4, off=-1) at
sysfile.c:434
#10 0x0002a34c in sysread (fd=7, buf=0x847600, n=4) at sysfile.c:1072
#11 0x00058135 in readn (f=7, av=0x847600, n=4) at readn.c:13
#12 0x0005802a in read9pmsg (fd=7, abuf=0x847600, n=8240) at
read9pmsg.c:14
#13 0x0002eb9a in exportfs (fd=7, msgsz=8240) at exportfs.c:84
#14 0x00003546 in cpumain (argc=0, argv=0xbfffeeec) at cpu.c:208
#15 0x000025b8 in main (argc=7, argv=0xbfffeed0) at main.c:68


I'll try building w/ proper 10.5 symbols and run a few more tests to
find out which part of the event loop should really be catching the
Quit message.

jas

Re: [9fans] OSX Drawterm hangs on close

[Pietro Gagliardi]

Also realize that Cocoa is written in Objective-C, not C, so you need
to learn a new language to get your hands on it. You CAN write a C
wrapper around the Objective-C (it was originally a C preprocessor),
but I don't think elite Mac programmers would recommend it.

On Apr 8, 2008, at 10:32 AM, Jeff Sickel wrote:

>
> On Apr 8, 2008, at 8:34 AM, Anant Narayanan wrote:
>>
>> On 06-Apr-08, at 8:46 AM, erik quanstrom wrote:
>>>> it's a known bug, but i don't think there's a fix for it.
>>>
>>> what's the bug?
>>
>> drawterm on OS X needs to be rewritten in Cocoa.
>
> Cocoa isn't completely needed... just getting rid of the Carbon
> framework dependancy.
>
> On 10.5.2, when quit from Dock->drawterm->Quit (should be the same
> as a menu command for quit) we get:
>
> (gdb) info threads
>   6 process 4410 thread 0x5b03  0x902d2bce in __semwait_signal ()
>   5 process 4410 thread 0x5903  0x902d2bce in __semwait_signal ()
>   4 process 4410 thread 0x5803  0x902d2bce in __semwait_signal ()
>   3 process 4410 thread 0x5703  0x902d2bce in __semwait_signal ()
> * 1 process 4410 local thread 0x2f27  0x9031bb8e in recvfrom
> $UNIX2003 ()
> (gdb) bt
> #0  0x9031bb8e in recvfrom$UNIX2003 ()
> #1  0x9031bb81 in recv$UNIX2003 ()
> #2  0x00019c71 in so_recv (fd=5, d=0x162b0060, n=65536, f=0) at
> devip-posix.c:209
> #3  0x00018745 in ipread (ch=0x13cd70, a=0x162b0060, n=65536,
> offset=0) at devip.c:377
> #4  0x0000ba81 in devbread (c=0x13cd70, n=65536, offset=0) at dev.c:
> 414
> #5  0x0001f605 in ensure (s=0x1571d0, l=0x157224, n=3) at devssl.c:431
> #6  0x0001f9e0 in sslbread (c=0x141de0, n=4, o=33837) at devssl.c:579
> #7  0x0001ff00 in sslread (c=0x141de0, a=0x847600, n=4, off=33837)
> at devssl.c:683
> #8  0x00028e00 in kread (fd=7, buf=0x847600, n=4, offp=0x0) at
> sysfile.c:408
> #9  0x00028ea8 in _syspread (fd=7, buf=0x847600, n=4, off=-1) at
> sysfile.c:434
> #10 0x0002a34c in sysread (fd=7, buf=0x847600, n=4) at sysfile.c:1072
> #11 0x00058135 in readn (f=7, av=0x847600, n=4) at readn.c:13
> #12 0x0005802a in read9pmsg (fd=7, abuf=0x847600, n=8240) at
> read9pmsg.c:14
> #13 0x0002eb9a in exportfs (fd=7, msgsz=8240) at exportfs.c:84
> #14 0x00003546 in cpumain (argc=0, argv=0xbfffeeec) at cpu.c:208
> #15 0x000025b8 in main (argc=7, argv=0xbfffeed0) at main.c:68
>
>
> I'll try building w/ proper 10.5 symbols and run a few more tests
> to find out which part of the event loop should really be catching
> the Quit message.
>
> jas
>
>

Re: [9fans] OSX Drawterm hangs on close

[Skip Tavakkolian]

why do you feel compelled to state the obvious?

> Also realize that Cocoa is written in Objective-C, not C, so you need
> to learn a new language to get your hands on it. You CAN write a C
> wrapper around the Objective-C (it was originally a C preprocessor),
> but I don't think elite Mac programmers would recommend it.

Re: [9fans] OSX Drawterm hangs on close

[underspecified]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

Greetings,

I came across this message while catching up on mailing lists.
This is a problem we were having that I recently fixed in Acme SAC for OS-X.
Basically, the problem was that there was no handler catching kEventAppQuit.

I am attaching a patch that creates a basic event handler and calls
exit(0) on any quit events.
This should prevent drawterm from hanging when being closed in any way
not using the menu
(system logouts, using the task switcher, etc.). My source for
drawterm might be a bit out of date,
so be careful when applying.

Take care,

--underspecified

On Wed, Apr 9, 2008 at 6:09 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
> why do you feel compelled to state the obvious?
>
>> Also realize that Cocoa is written in Objective-C, not C, so you need
>> to learn a new language to get your hands on it. You CAN write a C
>> wrapper around the Objective-C (it was originally a C preprocessor),
>> but I don't think elite Mac programmers would recommend it.
>
>
>

[-- Attachment #2: quit_event.diff --]
[-- Type: application/octet-stream, Size: 2432 bytes --]

diff -ru drawterm.orig/gui-osx/screen.c drawterm.new/gui-osx/screen.c
--- drawterm.orig/gui-osx/screen.c	2007-10-26 02:31:32.000000000 +0900
+++ drawterm.new/gui-osx/screen.c	2008-06-24 17:22:16.000000000 +0900
@@ -138,6 +138,7 @@
 	ksleep(&rend, isready, 0);
 }
 
+static OSStatus ApplicationQuitEventHandler(EventHandlerCallRef nextHandler, EventRef event, void *userData);
 static OSStatus MainWindowEventHandler(EventHandlerCallRef nextHandler, EventRef event, void *userData);
 static OSStatus MainWindowCommandHandler(EventHandlerCallRef nextHandler, EventRef event, void *userData);
 
@@ -192,6 +193,9 @@
 	if(PasteboardCreate(kPasteboardClipboard, &appleclip) != noErr)
 		sysfatal("pasteboard create failed");
 
+	const EventTypeSpec quit_events[] = {
+		{ kEventClassApplication, kEventAppQuit }
+	};
 	const EventTypeSpec commands[] = {
 		{ kEventClassWindow, kEventWindowClosed },
 		{ kEventClassWindow, kEventWindowBoundsChanged },
@@ -208,6 +212,13 @@
 		{ kEventClassMouse, kEventMouseWheelMoved },
 	};
 
+	InstallApplicationEventHandler (
+								NewEventHandlerUPP (ApplicationQuitEventHandler),
+								GetEventTypeCount(quit_events),
+								quit_events,
+								NULL,
+								NULL);
+
  	InstallApplicationEventHandler (
  								NewEventHandlerUPP (MainWindowEventHandler),
 								GetEventTypeCount(events),
@@ -496,6 +507,13 @@
 	return result;
 }
 
+// catch quit events to handle quits from menu, Cmd+Q, applescript, and task switcher
+static OSStatus ApplicationQuitEventHandler(EventHandlerCallRef nextHandler, EventRef event, void *userData)
+{
+	exit(0);
+//	QuitApplicationEventLoop();
+	return noErr;
+}
 
 //default window command handler (from menus)
 static OSStatus MainWindowCommandHandler(EventHandlerCallRef nextHandler,
@@ -543,11 +561,23 @@
 
 		switch (kind)
 		{
+			// send a quit carbon event instead of directly calling cleanexit 
+			// so that all quits are done in ApplicationQuitEventHandler
 			case kEventWindowClosed:
-				theWindow = NULL;
-				exit(0); // only one window
+				{
+				EventRef quitEvent;
+				CreateEvent(NULL,
+							kEventClassApplication,
+							kEventAppQuit,
+							0,
+							kEventAttributeNone,
+							&quitEvent);
+				EventTargetRef target;
+				target = GetApplicationEventTarget();
+				SendEventToEventTarget(quitEvent, target);
+				}
 				break;
-
+				
 			//resize window
 			case kEventWindowBoundsChanged:
 				window_resized();

Re: [9fans] OSX Drawterm hangs on close

[Uriel]

On Tue, Apr 8, 2008 at 3:34 PM, Anant Narayanan <anant@kix.in> wrote:
>
> On 06-Apr-08, at 8:46 AM, erik quanstrom wrote:
>>>
>>> it's a known bug, but i don't think there's a fix for it.
>>
>> what's the bug?
>
> drawterm on OS X needs to be rewritten in Cocoa.

Drawterm everywhere needs to die and be replaced with inferno. The
duplication of bug fixes and efforts is pointless.

uriel

Re: [9fans] OSX Drawterm hangs on close

[Pietro Gagliardi]

On Jun 24, 2008, at 8:51 AM, Uriel wrote:
>
> Drawterm everywhere needs to die and be replaced with inferno. The
> duplication of bug fixes and efforts is pointless.

I don't believe Inferno can interface with Plan 9 from Bell Labs, can
it? And Inferno can't interface with the native cut/copy/paste buffer
- a great convenience for me.

Re: [9fans] OSX Drawterm hangs on close

[Bruce Ellis]

or at the very least we need a OSX-9fans list that we don't have to read.

or a why-doesn't-fuse-work-on-ubuntu-this week list.

brucee

On Tue, Jun 24, 2008 at 10:51 PM, Uriel <uriel99@gmail.com> wrote:
> On Tue, Apr 8, 2008 at 3:34 PM, Anant Narayanan <anant@kix.in> wrote:
>>
>> On 06-Apr-08, at 8:46 AM, erik quanstrom wrote:
>>>>
>>>> it's a known bug, but i don't think there's a fix for it.
>>>
>>> what's the bug?
>>
>> drawterm on OS X needs to be rewritten in Cocoa.
>
> Drawterm everywhere needs to die and be replaced with inferno. The
> duplication of bug fixes and efforts is pointless.
>
> uriel
>
>

Re: [9fans] OSX Drawterm hangs on close

[Bruce Ellis]

wrong, wrong.

see what i mean, uriel? my puppy does better. he doesn't say to me "it
thought it was ok to chew on the router".

he seldom believes anything without investigating.

maybe an i'm-pietro-and-i-comment-on-everything list?

brucee

On Tue, Jun 24, 2008 at 11:17 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> On Jun 24, 2008, at 8:51 AM, Uriel wrote:
>>
>> Drawterm everywhere needs to die and be replaced with inferno. The
>> duplication of bug fixes and efforts is pointless.
>
> I don't believe Inferno can interface with Plan 9 from Bell Labs, can it?
> And Inferno can't interface with the native cut/copy/paste buffer - a great
> convenience for me.

Re: [9fans] OSX Drawterm hangs on close

[sqweek]

On Tue, Jun 24, 2008 at 9:17 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> On Jun 24, 2008, at 8:51 AM, Uriel wrote:
>> Drawterm everywhere needs to die and be replaced with inferno. The
>> duplication of bug fixes and efforts is pointless.
>
> I don't believe Inferno can interface with Plan 9 from Bell Labs, can it?

 If OS X can, inferno is going to have a much easier time of it.

> And Inferno can't interface with the native cut/copy/paste buffer - a great
> convenience for me.

 This is fixed in acme-sac I think?
-sqweek

Re: [9fans] OSX Drawterm hangs on close

[a]

// I don't believe Inferno can interface with Plan 9 from Bell Labs, can it?

It can. Stock Inferno has a few ways of doing this, although (last I tried)
there were authentication issues. Rog worked on those, but I'm not sure
to what extent they've been integrated.

// And Inferno can't interface with the native cut/copy/paste buffer...

It can. You can pick what you want. Compare /dev/snarf with
/chan/snarf.
Anthony

Re: [9fans] OSX Drawterm hangs on close

[Francisco J Ballesteros]

Not true.

Octopus is indeed Inferno, plus several programs.
Thus, I´m using Inferno as a front-end to a Plan 9 system, and
I have to say that it includes a shared clipboard as well.


On Tue, Jun 24, 2008 at 3:17 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
>
> I don't believe Inferno can interface with Plan 9 from Bell Labs, can it?
> And Inferno can't interface with the native cut/copy/paste buffer - a great
> convenience for me.
>
>
>

Re: [9fans] OSX Drawterm hangs on close

[erik quanstrom]

>>> Drawterm everywhere needs to die and be replaced with inferno. The
>>> duplication of bug fixes and efforts is pointless.
>>
>> I don't believe Inferno can interface with Plan 9 from Bell Labs, can it?
>
>  If OS X can, inferno is going to have a much easier time of it.

this isn't a useful comparison.  inferno is its own environment that
needs seperate configuration and management.  it's 159mb on my
(plan 9) machine.

drawterm is just a shim, requiring no seperate configuration or
maintence.  this can be an advantage.

- erik

Re: [9fans] OSX Drawterm hangs on close

[Russ Cox]

> Drawterm everywhere needs to die and be replaced with inferno. The
> duplication of bug fixes and efforts is pointless.

Just wait a few days.

Russ

Re: [9fans] OSX Drawterm hangs on close

[matt]

> Drawterm everywhere needs to die and be replaced with inferno. The
> duplication of bug fixes and efforts is pointless.

I thought we had to replace Inferno with Acme-Sac, I wish you'd make up
your mind.