[haiku-appserver] Re: [openbeos] Re: Launching the input_server from the app_server...

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 5 Jan 2007 20:55:44 +0100 (MET)

"Ryan Leavengood" <leavengood@xxxxxxxxx> wrote:
> Axel Dörfler wrote:
> > That's a bit strange: the input port, and the cursor semaphore are
> > both
> > owned by the input_server - if that server is gone, both objects
> > will
> > be deleted automatically, and both threads in the app_server will
> > notice that.
> It works fine now. I guess the problem yesterday was a fluke. I blame
> QEMU. On another note I am getting this on the console output when

I looked into it, and I could easily reproduce your problem - in fact,
our kernel was to blame for this: due to handling all signals as if
SA_RESTART was set, the shutdown mechanism of the mouse device failed,
and it was therefore waiting forever; it's fixed in r19711.
Thanks for the hint!

You didn't get the problem when you moved the mouse - if you don't move
the mouse around at all, the problem could be reproduced 100%.

> quitting the input_server:
>
> 41: DEBUGGER: You can't call delete on a BLooper object once it is
> running.
> *** GUI server died: thread 41, /boot/beos/system/servers/
> input_server:
> Debugger call: `You can't call delete on a BLooper object once it is
> running.'
> *** GUI server died: thread 41, /boot/beos/system/servers/
> input_server:
> After syscall
>
> This seems like something that should be fixed. Of course how often
> is
> the input_server quit, hehe. But I figure I better document the above
> somewhere.

I looked into that one as well: the screen_saver filter tried to delete
its controlling BLooper; it's fixed in r19713.

Bye,
   Axel.


Other related posts: