9vx native OS X gui

9vx native OS X gui

[Russ Cox]

The 9vx 0.11 source code includes OS X gui code,
a severely cleaned-up version of the drawterm code.

It is not built by default, but you can build it by using

	make 9vx/9vx PLAN9GUI=osx

Unfortunately, it seems to have one problem: the
Carbon app event loop appears to install its own
handler for EXC_BAD_ACCESS, the Mach equivalent
of SIGBUS/SIGSEGV.  When it gets that exception,
it passes it along, but first it pops up an annoying
"The application 9vx quit unexpectedly" dialog.
Even if you turn the popup off (with TinkerTool),
the handler must record that things are broken,
and the cursor turns into a pinwheel forever:
Carbon/Quartz/whatever-it's-called-today can't
fathom the idea that an EXC_BAD_ACCESS came in
and the app actually survived it.

I assume the fix would be to install an EXC_BAD_ACCESS
handler after kicking off the app event loop.  That would
make sure that Carbon never saw it.
But I don't know how to do that.

Russ

Re: [9fans] 9vx native OS X gui

[Pietro Gagliardi]

Running the new native 9vx (which I was almost done doing myself, had
it not been for that missing file):

The process has forked and you cannot use this CoreFoundation
functionality safely. You MUST exec().
Break on
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
() to debug.

repeated 158 (!) times, followed by the first line and then an abort
before the second line is printed. :-(

Re: [9fans] 9vx native OS X gui

[Russ Cox]

> Unfortunately, it seems to have one problem: the
> Carbon app event loop appears to install its own
> handler for EXC_BAD_ACCESS, the Mach equivalent

It looks like this might be fixed in 10.5, according to

http://developer.apple.com/technotes/tn2004/tn2123.html#SECLIMITATIONS

Of course, if you get past that, you'll have to debug my
cleanup of the gui code.

Russ

Re: [9fans] 9vx native OS X gui

[underspecified]

Russ,

Great work with 9vx. I haven't played around with it too much, but I
did successfully build your native gui code cleanup.
When I start 9vx, I get the following messages dumped to terminal
repeatedly and the app hangs:

cpu10: runproc spurious wakeup
idlehands spurious wakeup

Perhaps this has something to do with the OS-X cpu bug mentioned
earlier in the thread?

--underspecified

On Sun, Jun 29, 2008 at 5:08 AM, Russ Cox <rsc@swtch.com> wrote:
>> Unfortunately, it seems to have one problem: the
>> Carbon app event loop appears to install its own
>> handler for EXC_BAD_ACCESS, the Mach equivalent
>
> It looks like this might be fixed in 10.5, according to
>
> http://developer.apple.com/technotes/tn2004/tn2123.html#SECLIMITATIONS
>
> Of course, if you get past that, you'll have to debug my
> cleanup of the gui code.
>
> Russ
>
>
>

Re: [9fans] 9vx native OS X gui

[Anant Narayanan]

Hi,

First off, 9vx is incredible! Thanks Russ and Bryan :)

> When I start 9vx, I get the following messages dumped to terminal
> repeatedly and the app hangs:
>
> cpu10: runproc spurious wakeup
> idlehands spurious wakeup

I got the new 0.11 source to build, but run into a similar error:
cpu3: runproc spurious wakeup

On 28-Jun-08, at 1:08 PM, Pietro Gagliardi wrote:
> Running the new native 9vx (which I was almost done doing myself,
> had it not been for that missing file):
>
> The process has forked and you cannot use this CoreFoundation
> functionality safely. You MUST exec().
> Break on
> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
> () to debug.

Running 9vx with the -F flag makes that error go away (tried on 10.5.3)

Regards,
Anant

Re: [9fans] 9vx native OS X gui

[Pietro Gagliardi]

On Jun 28, 2008, at 6:17 PM, Anant Narayanan wrote:
> Running 9vx with the -F flag makes that error go away (tried on
> 10.5.3)


That helped, but I get the spurious error.

Re: [9fans] 9vx native OS X gui

[Josh Wood]

> I assume the fix would be to install an EXC_BAD_ACCESS
> handler after kicking off the app event loop.  That would
> make sure that Carbon never saw it.
> But I don't know how to do that.


I don't have a 10.5 mac to see if this is moot with the changes to
CrashReporter.app.

mach/mach.h has thread_set_exception_ports() to install handlers for
mach exceptions. There is also a task_ version for all the threads in
a task.

The basics are like:

	/* recieve right */
	kret = mach_port_allocate(mach_task_self(),
							MACH_PORT_RIGHT_RECIEVE,
							&exception_port);

	/* send right */
	kret = mach_port_insert_right(mach_task_self(),
							exception_port,
							exception_port,
							MACH_MSG_TYPE_MAKE_SEND);

	/* select exc type */
	kret = thread_set_exception_ports(mach_thread_self(),
								EXC_MASK_BAD_ACCESS,
								exception_port,
								EXCEPTION_DEFAULT,
								THEAD_STATE_NONE);

Then you do what you want with the exception; in the common case that
means set up fake sigcontext and deliver to signal handler code.

Amit Singh's osx kernel book has example code (http://macosxbook.com/
book/src/ in fig. 9-38). http://tinyurl.com/46dsgp is a production
example with comments @ the phrase ``Mach's exception mechanism''.

It's Apple's bug, and that's too far to have to go to work around it,
IMO, but the technique might be interesting or handy for this kind of
software atop osx.

-Josh