2008/10/8 andrey mirtchovski

> while looking around for information on the RC strangeness i triggered
> a bug with rio: if the last window on the "hidden" stack disappears
> _while_ the third mouse button menu is opened, then upon attempting to
> unhide the window without releasing the mouse button in between will
> result in a read addr fault in 'wunhide()'
>
> here's a stack trace and error message:
>
> acid: lstk()
> wunhide(h=0x1)+0x30 /sys/src/cmd/rio/rio.c:1099
> w=0x1768e0
> i=0x0
> unhide(h=0x6)+0x27 /sys/src/cmd/rio/rio.c:1129
> button3menu()+0x97 /sys/src/cmd/rio/rio.c:686
> mousethread()+0x2c4 /sys/src/cmd/rio/rio.c:589
> sending=0x0
> scrolling=0x0
> moving=0x0
> winput=0xdaf40
> xy=0x1f6
> inside=0x1
> tmp=0x0
> w=0xdaf40
> oin=0x929e0
> band=0x1
> r=0xfefefefe
>
> to reproduce:
>
> open a rio window
> run "window -hide 'sleep 10'"
> click the third mouse button (to bring the "New" menu)
> wait 10 seconds (you will know that 10 seconds have passed if you move
> the mouse over the last hidden window and the highlighted text appears
> to be gibberish)
> unhide the last hidden window by releasing the third mouse button
> while pointing at it in the menu
>
> if you simply release the third mouse button and bring the menu up
> again you will see that the window has disappeared. it is only a bug
> when rio isn't given a chance to refresh the third button menu.
>
> cheers: andrey
>
>
Nice. I tried to follow your instructions and ended up in a situation that
my mouse was movable across my screen, but that was also all I could do...
(no menus, no a simple resize/move action) ... reboot with ^t^tr...
(btw. can I do sth. else??! -- in linux one can usually kill X with
alt-ctrl-backspace. Is there anything like that? I hope the underlining
system is just working)
(and one more question: if sth. like this happens on a file server -- I have
a single machine running all --, is it safe to reboot it with ^t^tr? --
usually I use 'fshalt -r'...)
Ruda

> (btw. can I do sth. else??! -- in linux one can usually kill X with
> alt-ctrl-backspace. Is there anything like that? I hope the underlining
> system is just working)

you can log in to the node if it allows that and reboot it. i crashed
quite a few drawterm sessions to the same node to make sure it's
repeatable.

> (and one more question: if sth. like this happens on a file server -- I have
> a single machine running all --, is it safe to reboot it with ^t^tr? --
> usually I use 'fshalt -r'...)

that should be fine most of the time. fossil rarely gets angry if you
restart it without halting.

>> (and one more question: if sth. like this happens on a file server -- I have
>> a single machine running all --, is it safe to reboot it with ^t^tr? --
>> usually I use 'fshalt -r'...)
>
> that should be fine most of the time. fossil rarely gets angry if you
> restart it without halting.

"most of the time" is likely dependent on how your
hd(s) cache writes and what part (if any) of the kernel
was trashed before the vulcan nerve pinch.

in other words, if "most of the time" makes you nervous,
it really is a good idea to have a seperate fileserver,
even if it is running a regular kernel.

- erik

> you can log in to the node if it allows that and reboot it. i crashed
> quite a few drawterm sessions to the same node to make sure it's
> repeatable.

i think i meant "kill and restart rio" here, not "reboot the node".

i think i meant "kill and restart rio" here, not "reboot the node".


How difficult would it be to add something similar to ^t^tr that would just
killed rio?
Ruda

> How difficult would it be to add something similar to ^t^tr that would just
> killed rio?

how about just fixing the bug?

- erik

2008/10/10 erik quanstrom

> > How difficult would it be to add something similar to ^t^tr that would
> just
> > killed rio?
>
> how about just fixing the bug?
>
> - erik


Well, sure. But somehow (don't know exactly how) sth. similar happened to me
lately -- i.e. I ended with not responding rio. And was just thinking: if I
could just kill it... and could not, not having an available shell. Could
not even stop the machine properly (not everybody can have several dedicated
machines, one for a file server, one for a terminal...). I even 'lost' some
of my data then, probably for having to press that ^t^tr and not stop the
filesystem -- one of my files just had a zero lenght after the reboot. To
some it up: I just always feel better when having some possibility to get to
some shell somehow and enter commands... (true, had I set up the files
allowing me to log in from a remote machine, it could have been some
solution then; but this also is not always on hand)
Ruda

> in other words, if "most of the time" makes you nervous,
> it really is a good idea to have a seperate fileserver,
> even if it is running a regular kernel.

As one who is at this moment trying to extricate himself from a corrupted
FS caused by an 'abrupt' restart, I can highly recommend you pay attention
to Erik's advice.

Rather than litter the kernel with special case code,
why not just set up your terminal to listen to the network?
Then if you get in that state again you can drawterm in.

Russ

2008/10/11 Russ Cox

> Rather than litter the kernel with special case code,
> why not just set up your terminal to listen to the network?
> Then if you get in that state again you can drawterm in.
>
> Russ
>
> Again, I am normally (with my notebook) _NOT_ connected to _ANY_ network.
Yet, I still dare want to be at least able to stop the filesystem when sth.
like that happens again.
(If I can do it elsewhere -- in linux I don't remember the case I could do
nothing -- unless I set and make the keybord unfuctional ...)
Ruda