vx32, 9vx 0.12

vx32, 9vx 0.12

[Russ Cox]

There are new sources and binaries in the usual places.

If you missed the announcement before, there is now
a Mercurial repository at http://hg.pdos.csail.mit.edu/hg/vx32/

The OS X code seems to have stabilized, and it doesn't
require X11 anymore.  I think there are OS X bugs tickled
by having signals flying all over the place: I've seen both
pthread_cond_wait and pipe read miss the corresponding
pthread_cond_signal or pipe write.  If someone who is
knowledgeable wants to take a look, see 9vx/sched.c.
I've worked around the bugs, so you shouldn't see hangs
anymore.  You might see the occasional 1-second hiccup.

Russ

Re: [9fans] vx32, 9vx 0.12

[David Leimbach]

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

On Tue, Jul 1, 2008 at 7:53 AM, Russ Cox <rsc@swtch.com> wrote:

> There are new sources and binaries in the usual places.
>
> If you missed the announcement before, there is now
> a Mercurial repository at http://hg.pdos.csail.mit.edu/hg/vx32/
>
> The OS X code seems to have stabilized, and it doesn't
> require X11 anymore.  I think there are OS X bugs tickled
> by having signals flying all over the place: I've seen both
> pthread_cond_wait and pipe read miss the corresponding
> pthread_cond_signal or pipe write.  If someone who is
> knowledgeable wants to take a look, see 9vx/sched.c.
> I've worked around the bugs, so you shouldn't see hangs
> anymore.  You might see the occasional 1-second hiccup.
>
> Russ
>
>
>
Got this... still seems a little slow here and there on cpu and cp, but they
complete.

Also I ran ssh2 without factotum and got a crash... not sure if that's
expected or not.

247 ssh2: unhandled fault va=0 [1100000] eip=bee1b
cpu0: registers for ssh2 247
FLAGS=0 TRAP=0 ECODE=0 PC=BEE1B USP=FFFFF00
  AX 00000000  BX 001339C1  CX FFFFFFFF  DX 000FF2F2
  SI FFFFFFFF  DI 00000000  BP 00000000

[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

Re: [9fans] vx32, 9vx 0.12

[David Leimbach]

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

On Tue, Jul 1, 2008 at 9:06 AM, David Leimbach <leimy2k@gmail.com> wrote:

>
>
> On Tue, Jul 1, 2008 at 7:53 AM, Russ Cox <rsc@swtch.com> wrote:
>
>> There are new sources and binaries in the usual places.
>>
>> If you missed the announcement before, there is now
>> a Mercurial repository at http://hg.pdos.csail.mit.edu/hg/vx32/
>>
>> The OS X code seems to have stabilized, and it doesn't
>> require X11 anymore.  I think there are OS X bugs tickled
>> by having signals flying all over the place: I've seen both
>> pthread_cond_wait and pipe read miss the corresponding
>> pthread_cond_signal or pipe write.  If someone who is
>> knowledgeable wants to take a look, see 9vx/sched.c.
>> I've worked around the bugs, so you shouldn't see hangs
>> anymore.  You might see the occasional 1-second hiccup.
>>
>> Russ
>>
>>
>>
> Got this... still seems a little slow here and there on cpu and cp, but
> they complete.
>
> Also I ran ssh2 without factotum and got a crash... not sure if that's
> expected or not.
>
> 247 ssh2: unhandled fault va=0 [1100000] eip=bee1b
> cpu0: registers for ssh2 247
> FLAGS=0 TRAP=0 ECODE=0 PC=BEE1B USP=FFFFF00
>   AX 00000000  BX 001339C1  CX FFFFFFFF  DX 000FF2F2
>   SI FFFFFFFF  DI 00000000  BP 00000000
>

Also just noticed this on my Terminal where I launched 9vx:

[8:28] dave(mt64):..p/9vx-0.12 %> ./9vx.OSX
247 ssh2 fault 0 no segment
258 ssh2 fault 0 no segment


Dave

[-- Attachment #2: Type: text/html, Size: 2313 bytes --]

Re: [9fans] vx32, 9vx 0.12

[Russ Cox]

>> 247 ssh2: unhandled fault va=0 [1100000] eip=bee1b
>> cpu0: registers for ssh2 247
>> FLAGS=0 TRAP=0 ECODE=0 PC=BEE1B USP=FFFFF00
>>   AX 00000000  BX 001339C1  CX FFFFFFFF  DX 000FF2F2
>>   SI FFFFFFFF  DI 00000000  BP 00000000

As long as only ssh2 crashed, this doesn't bother me too much.
9vx does get a little chatty in that case, but that doesn't bother
me for now.

Can you test whether running ssh2 without factotum also dies
on native Plan 9?  I have no ssh2 binary.

Russ

Re: [9fans] vx32, 9vx 0.12

[David Leimbach]

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

On Tue, Jul 1, 2008 at 10:36 AM, Russ Cox <rsc@swtch.com> wrote:

> >> 247 ssh2: unhandled fault va=0 [1100000] eip=bee1b
> >> cpu0: registers for ssh2 247
> >> FLAGS=0 TRAP=0 ECODE=0 PC=BEE1B USP=FFFFF00
> >>   AX 00000000  BX 001339C1  CX FFFFFFFF  DX 000FF2F2
> >>   SI FFFFFFFF  DI 00000000  BP 00000000
>
> As long as only ssh2 crashed, this doesn't bother me too much.
> 9vx does get a little chatty in that case, but that doesn't bother
> me for now.
>
> Can you test whether running ssh2 without factotum also dies
> on native Plan 9?  I have no ssh2 binary.
>
> Russ
>
> Yes only ssh2 is crashing... it didn't do this before .12 to the best of my
recollection, that I'm getting SEGV errors on my terminal where I started
9vx seems important too:

[8:28] dave(mt64):..p/9vx-0.12 %> ./9vx.OSX
247 ssh2 fault 0 no segment
258 ssh2 fault 0 no segment

ssh2 can be found in /n/sources/contrib/john  and it works very nicely for
my needs so far.

[-- Attachment #2: Type: text/html, Size: 1495 bytes --]

Re: [9fans] vx32, 9vx 0.12

[Bakul Shah]

On OSX 9vx consistently sigsegv panics if you quickly resize
its window a few times, particluarly before it finishes
repainting.  This doesn't happen (or is hard to trigger) when
rio is not up.

Running it under gdb reveals:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
[Switching to process 832 thread 0x5c43]
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0x9631d78c in DispatchEventToHandlers ()
#2  0x9631cb9d in SendEventToEventTargetInternal ()
#3  0x9631ca02 in SendEventToEventTargetWithOptions ()
#4  0x9633944b in SendBoundsChangeEvent ()
#5  0x963391f0 in MoveResizeWindowInternal ()
#6  0x963388c6 in WindowData::SetBounds ()
#7  0x96434a9b in UpdateWindowBounds ()
#8  0x96433fb7 in TWindowTracker::TrackWindow ()
#9  0x96433053 in ResizeWindow ()
#10 0x963445be in HandleWindowEvent ()
#11 0x963a2096 in StandardWindowEventHandler ()
#12 0x9631d763 in DispatchEventToHandlers ()
#13 0x9631cb9d in SendEventToEventTargetInternal ()
#14 0x963394ee in SendEventToEventTarget ()
#15 0x9653b52f in SendEventFromMouseDown ()
#16 0x963e661f in HandleWindowClick ()
#17 0x963e63f7 in HandleMouseEvent ()
#18 0x963a208a in StandardWindowEventHandler ()
#19 0x9631d763 in DispatchEventToHandlers ()
#20 0x9631cb9d in SendEventToEventTargetInternal ()
#21 0x963394ee in SendEventToEventTarget ()
#22 0x9634c0eb in ToolboxEventDispatcherHandler ()
#23 0x9631db1c in DispatchEventToHandlers ()
#24 0x9631cb9d in SendEventToEventTargetInternal ()
#25 0x963394ee in SendEventToEventTarget ()
#26 0x963a6504 in ToolboxEventDispatcher ()
#27 0x963a2d5e in RunApplicationEventLoop ()
#28 0x000590d3 in screenproc (v=0x0) at 9vx/osx/screen.c:199
#29 0x0000f2f8 in linkproc () at 9vx/trap.c:484
(gdb)

Crash on window resize seems to be not so rare but I didn't
see a solution in 5 minutes of googling.