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