[9fans] OSX Drawterm hangs on close - Plan9

This is a discussion on [9fans] OSX Drawterm hangs on close - Plan9 ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: [9fans] OSX Drawterm hangs on close

  1. [9fans] OSX Drawterm hangs on close

    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


  2. Re: [9fans] OSX Drawterm hangs on close

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


  3. Re: [9fans] OSX Drawterm hangs on close

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

    what's the bug?

    - erik



  4. Re: [9fans] OSX Drawterm hangs on close

    > what's the bug?

    drawterm hangs when closed through the doc icon


  5. Re: [9fans] OSX Drawterm hangs on close

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


  6. Re: [9fans] OSX Drawterm hangs on close

    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
    wrote:
    > I'll try to figure out what signal is sent. Any pointers on how do do this?
    >
    >



  7. Re: [9fans] OSX Drawterm hangs on close

    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.




  8. Re: [9fans] OSX Drawterm hangs on close

    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.

    >
    >
    >



  9. Re: [9fans] OSX Drawterm hangs on close


    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


  10. Re: [9fans] OSX Drawterm hangs on close


    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



  11. Re: [9fans] OSX Drawterm hangs on close

    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
    >
    >




  12. Re: [9fans] OSX Drawterm hangs on close

    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.




  13. Re: [9fans] OSX Drawterm hangs on close

    On Tue, Apr 8, 2008 at 3:34 PM, 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.


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

    uriel


  14. Re: [9fans] OSX Drawterm hangs on close

    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 wrote:
    > On Tue, Apr 8, 2008 at 3:34 PM, 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.

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



  15. Re: [9fans] OSX Drawterm hangs on close

    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.



  16. Re: [9fans] OSX Drawterm hangs on close

    On Tue, Jun 24, 2008 at 9:17 PM, Pietro Gagliardi 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


  17. Re: [9fans] OSX Drawterm hangs on close

    // 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



  18. Re: [9fans] OSX Drawterm hangs on close

    >>> 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



  19. Re: [9fans] OSX Drawterm hangs on close

    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 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.



  20. Re: [9fans] OSX Drawterm hangs on close

    > 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



+ Reply to Thread
Page 1 of 2 1 2 LastLast