* [9fans] bug in rio: unhiding deleted windows @ 2008-10-08 20:51 andrey mirtchovski 2008-10-10 11:53 ` Rudolf Sykora 2008-11-23 19:50 ` Rudolf Sykora 0 siblings, 2 replies; 29+ messages in thread From: andrey mirtchovski @ 2008-10-08 20:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-08 20:51 [9fans] bug in rio: unhiding deleted windows andrey mirtchovski @ 2008-10-10 11:53 ` Rudolf Sykora 2008-10-10 12:32 ` andrey mirtchovski 2008-11-23 19:50 ` Rudolf Sykora 1 sibling, 1 reply; 29+ messages in thread From: Rudolf Sykora @ 2008-10-10 11:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 2154 bytes --] 2008/10/8 andrey mirtchovski <mirtchovski@gmail.com> > 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 [-- Attachment #2: Type: text/html, Size: 2881 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 11:53 ` Rudolf Sykora @ 2008-10-10 12:32 ` andrey mirtchovski 2008-10-10 12:54 ` erik quanstrom 2008-10-10 13:15 ` andrey mirtchovski 0 siblings, 2 replies; 29+ messages in thread From: andrey mirtchovski @ 2008-10-10 12:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > (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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 12:32 ` andrey mirtchovski @ 2008-10-10 12:54 ` erik quanstrom 2008-10-10 20:23 ` Lyndon Nerenberg 2008-10-10 13:15 ` andrey mirtchovski 1 sibling, 1 reply; 29+ messages in thread From: erik quanstrom @ 2008-10-10 12:54 UTC (permalink / raw) To: 9fans >> (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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 12:54 ` erik quanstrom @ 2008-10-10 20:23 ` Lyndon Nerenberg 2008-10-11 3:05 ` Russ Cox 0 siblings, 1 reply; 29+ messages in thread From: Lyndon Nerenberg @ 2008-10-10 20:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 20:23 ` Lyndon Nerenberg @ 2008-10-11 3:05 ` Russ Cox 2008-10-11 11:11 ` Rudolf Sykora 0 siblings, 1 reply; 29+ messages in thread From: Russ Cox @ 2008-10-11 3:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-11 3:05 ` Russ Cox @ 2008-10-11 11:11 ` Rudolf Sykora 0 siblings, 0 replies; 29+ messages in thread From: Rudolf Sykora @ 2008-10-11 11:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 558 bytes --] 2008/10/11 Russ Cox <rsc@swtch.com> > 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 [-- Attachment #2: Type: text/html, Size: 881 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 12:32 ` andrey mirtchovski 2008-10-10 12:54 ` erik quanstrom @ 2008-10-10 13:15 ` andrey mirtchovski 2008-10-10 13:21 ` Rudolf Sykora 1 sibling, 1 reply; 29+ messages in thread From: andrey mirtchovski @ 2008-10-10 13:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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". ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 13:15 ` andrey mirtchovski @ 2008-10-10 13:21 ` Rudolf Sykora 2008-10-10 13:18 ` erik quanstrom 0 siblings, 1 reply; 29+ messages in thread From: Rudolf Sykora @ 2008-10-10 13:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 169 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 412 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 13:21 ` Rudolf Sykora @ 2008-10-10 13:18 ` erik quanstrom 2008-10-10 14:02 ` Rudolf Sykora 0 siblings, 1 reply; 29+ messages in thread From: erik quanstrom @ 2008-10-10 13:18 UTC (permalink / raw) To: 9fans > How difficult would it be to add something similar to ^t^tr that would just > killed rio? how about just fixing the bug? - erik ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 13:18 ` erik quanstrom @ 2008-10-10 14:02 ` Rudolf Sykora 2008-10-10 14:41 ` erik quanstrom 0 siblings, 1 reply; 29+ messages in thread From: Rudolf Sykora @ 2008-10-10 14:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1022 bytes --] 2008/10/10 erik quanstrom <quanstro@quanstro.net> > > 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 [-- Attachment #2: Type: text/html, Size: 1396 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 14:02 ` Rudolf Sykora @ 2008-10-10 14:41 ` erik quanstrom 2008-10-10 15:25 ` Rudolf Sykora 2008-10-10 16:36 ` matt 0 siblings, 2 replies; 29+ messages in thread From: erik quanstrom @ 2008-10-10 14:41 UTC (permalink / raw) To: 9fans > 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 two points 1. you can run rio in a rio window so you can debug rio without fiddling with your root rio. 2. if you're not running the fileserver on your cpu server, it's always safe to reboot. in fact, the dozen or so cpu servers that i manage are rebooted by pulling the plug. this is one of my favorite features of plan 9's architecture. i'm not sure why you can't have a dedicated fileserver. i put mine original fs together for $12.95. this fs is still running, i just wanted to put together a diskless fs. my original fs is a 1998-vintage pIII running 64-bit kenfs. the $12.95 was for a 8169s gbe. i guess i didn't need to spend that money on the gbe, but i'm a performance weenie. it was fast enough for me, but probablly not for windows. i'd bet you could find a number of similar machines for just a few dollars. if you want new, a via or intel cpu/mobo/video combo is super cheep. - erik ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 14:41 ` erik quanstrom @ 2008-10-10 15:25 ` Rudolf Sykora 2008-10-10 15:21 ` erik quanstrom 2008-10-10 15:33 ` ron minnich 2008-10-10 16:36 ` matt 1 sibling, 2 replies; 29+ messages in thread From: Rudolf Sykora @ 2008-10-10 15:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1596 bytes --] two points > 1. you can run rio in a rio window so you can debug > rio without fiddling with your root rio. > True, but what happened to me was that I did not want to do any debugging. I wanted to work, i.e. use the computer in the conventional sense -- do sth. for my school. And you do not usually run rio in rio just for fun in that case. And then sth. bad happens. And you are ... Actually, this might just have happened when the bug we're talking about was found -- by chance, it just happened unexpectedly. On the other hand, If you know in advance... you run rio in rio. But again, not my case. What I am still convinced about is that always having a way to run a shell is invaluable. > 2. if you're not running the fileserver on your cpu server, > it's always safe to reboot. in fact, the dozen or so cpu > servers that i manage are rebooted by pulling the plug. > this is one of my favorite features of plan 9's architecture. Yes, I know. > > i'm not sure why you can't have a dedicated fileserver > It's not a question of money... but thanks for your recommendations. :) The main reason is I run plan9 only on one of my notebooks (otherwise I use linux machines since plan9 doesn't have a bit of the software I crucially need). And I want to be able to work on it, even though it is not at the moment connected to any network. I need to have my files with me. Is that enough? So once more and to conclude, wouldn't it be nice to be able to press something like ctrl-alt-backspace to, by some means guarantee a way to a shell? Ruda [-- Attachment #2: Type: text/html, Size: 2238 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 15:25 ` Rudolf Sykora @ 2008-10-10 15:21 ` erik quanstrom 2008-10-10 15:42 ` Rudolf Sykora 2008-10-10 15:33 ` ron minnich 1 sibling, 1 reply; 29+ messages in thread From: erik quanstrom @ 2008-10-10 15:21 UTC (permalink / raw) To: 9fans > So once more and to conclude, wouldn't it be nice to be able to press > something like ctrl-alt-backspace to, by some means guarantee a way to a > shell? it would be nicer to fix the bug. covering it up would be oh so linux-y. - erik ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 15:21 ` erik quanstrom @ 2008-10-10 15:42 ` Rudolf Sykora 0 siblings, 0 replies; 29+ messages in thread From: Rudolf Sykora @ 2008-10-10 15:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 184 bytes --] it would be nicer to fix the bug. covering it up would be oh so > linux-y. > > - erik > Are you sure, it is the last bug? :) Otherwise one can again loose some data... Ruda [-- Attachment #2: Type: text/html, Size: 437 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 15:25 ` Rudolf Sykora 2008-10-10 15:21 ` erik quanstrom @ 2008-10-10 15:33 ` ron minnich 2008-10-10 15:41 ` Rudolf Sykora 2008-10-10 15:45 ` andrey mirtchovski 1 sibling, 2 replies; 29+ messages in thread From: ron minnich @ 2008-10-10 15:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Ruda, go ahead and have a go at putting your key sequence into rio. You may find it pretty easy to do ... ron ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 15:33 ` ron minnich @ 2008-10-10 15:41 ` Rudolf Sykora 2008-10-10 16:20 ` andrey mirtchovski 2008-10-10 15:45 ` andrey mirtchovski 1 sibling, 1 reply; 29+ messages in thread From: Rudolf Sykora @ 2008-10-10 15:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 349 bytes --] 2008/10/10 ron minnich <rminnich@gmail.com> > Ruda, go ahead and have a go at putting your key sequence into rio. > You may find it pretty easy to do ... > > ron > Well, I will try to do so, just for fun :) And if I find how :) To this end (being a complete newbie to plan9, actually a physicist), is that ^t^tr handled by rio? Ruda [-- Attachment #2: Type: text/html, Size: 679 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 15:41 ` Rudolf Sykora @ 2008-10-10 16:20 ` andrey mirtchovski 2008-10-10 16:26 ` Rudolf Sykora 0 siblings, 1 reply; 29+ messages in thread From: andrey mirtchovski @ 2008-10-10 16:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs i'm sure jmk will kill me for this. is the proc arena contiguous? if not this could be a double-FAIL :) % diff /tmp/devcons.c devcons.c 481,490d480 < case '☺': < { < Proc *p; int i; < for(i = 0; i < conf.nproc; i++) { < p = proctab(i); < if(p->state == Broken) < unbreak(p); < } < } < return; ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 16:20 ` andrey mirtchovski @ 2008-10-10 16:26 ` Rudolf Sykora 2008-10-10 16:30 ` andrey mirtchovski 0 siblings, 1 reply; 29+ messages in thread From: Rudolf Sykora @ 2008-10-10 16:26 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 595 bytes --] > % diff /tmp/devcons.c devcons.c > 481,490d480 > < case '☺': > < { > < Proc *p; int i; > < for(i = 0; i < conf.nproc; i++) { > < p = proctab(i); > < if(p->state == Broken) > < unbreak(p); > < } > < } > < return; > Was looking right at the same place. :) Only didn't know what to write there... Ruda [-- Attachment #2: Type: text/html, Size: 1604 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 16:26 ` Rudolf Sykora @ 2008-10-10 16:30 ` andrey mirtchovski 2008-10-10 16:43 ` Rudolf Sykora 0 siblings, 1 reply; 29+ messages in thread From: andrey mirtchovski @ 2008-10-10 16:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Was looking right at the same place. :) Only didn't know what to write > there... > Ruda notice that i've provided you with the gun but only you can pull the trigger. i absolve myself of any responsibility :p ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 16:30 ` andrey mirtchovski @ 2008-10-10 16:43 ` Rudolf Sykora 0 siblings, 0 replies; 29+ messages in thread From: Rudolf Sykora @ 2008-10-10 16:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 298 bytes --] notice that i've provided you with the gun but only you can pull the > trigger. i absolve myself of any responsibility :p > Unfortunately, I can't do it now either. :( I should have already been elsewhere for a while. But if not someone else, I will get back to it on Monday. Thanks Ruda [-- Attachment #2: Type: text/html, Size: 527 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 15:33 ` ron minnich 2008-10-10 15:41 ` Rudolf Sykora @ 2008-10-10 15:45 ` andrey mirtchovski 1 sibling, 0 replies; 29+ messages in thread From: andrey mirtchovski @ 2008-10-10 15:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Oct 10, 2008 at 9:33 AM, ron minnich <rminnich@gmail.com> wrote: > Ruda, go ahead and have a go at putting your key sequence into rio. > You may find it pretty easy to do ... if rio is broken it may not be able to figure out the key sequence. it should go in devcons, where the rest of the ^T^T stuff is. i still think that a hard look at ^T^TD with a lot of poking around (preferably with a large hammer) may provide a method for killing a particular process but i don't have a terminal handy to verify. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 14:41 ` erik quanstrom 2008-10-10 15:25 ` Rudolf Sykora @ 2008-10-10 16:36 ` matt 2008-10-10 16:40 ` Rudolf Sykora 2008-10-11 12:44 ` erik quanstrom 1 sibling, 2 replies; 29+ messages in thread From: matt @ 2008-10-10 16:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > i'm not sure why you can't have a dedicated fileserver. > i put mine original fs together for $12.95. this fs is still > running, i just wanted to put together a diskless fs. > Electricity is 15p per KwHour round here 300w echo 'scale=3; 0.15 * 0.3 * 25 * 365' | bc 410.625 pounds per year 60w 82.125 pounds per year ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 16:36 ` matt @ 2008-10-10 16:40 ` Rudolf Sykora 2008-10-11 12:44 ` erik quanstrom 1 sibling, 0 replies; 29+ messages in thread From: Rudolf Sykora @ 2008-10-10 16:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 482 bytes --] 2008/10/10 matt <mattmobile@proweb.co.uk> > > i'm not sure why you can't have a dedicated fileserver. >> i put mine original fs together for $12.95. this fs is still >> running, i just wanted to put together a diskless fs. >> >> > > Electricity is 15p per KwHour round here > > 300w > > echo 'scale=3; 0.15 * 0.3 * 25 * 365' | bc > > 410.625 pounds per year > > 60w > > 82.125 pounds per year > for me it is less, but I think the argument counts :) Ruda [-- Attachment #2: Type: text/html, Size: 999 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-10 16:36 ` matt 2008-10-10 16:40 ` Rudolf Sykora @ 2008-10-11 12:44 ` erik quanstrom 1 sibling, 0 replies; 29+ messages in thread From: erik quanstrom @ 2008-10-11 12:44 UTC (permalink / raw) To: 9fans > Electricity is 15p per KwHour round here > > 300w > > echo 'scale=3; 0.15 * 0.3 * 25 * 365' | bc > > 410.625 pounds per year > > 60w > > 82.125 pounds per year you have a good point, though i assume you mean ; hoc 0.15*0.300 * 24 * 365 394.2 0.15*0.060 * 24 * 365 78.84 300 watts is a hungry computer. all 6 of my machines here, including an 8-disk hot swappable monster, take ~550VA according to my apc. but then again, i have nothing but 80+-rated power supplies and a few 35w and 65w cpus. if power is that big a deal, it might make sense to buy specialized hardware. soekris come in at <20w. an old laptop can make a good low-power fs. portwell has a <20w atom-based mb with gbe. you could have a small fleet of those for 60 watts. turn off a couple of lightbulbs and tell yourself it's free. :-) my personal bias is toward speed and reilability. how much is it worth to you not to worry about your fs? for me it's worth a lot. even at $350/year, that's cheep data insurance to me. - erik ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-10-08 20:51 [9fans] bug in rio: unhiding deleted windows andrey mirtchovski 2008-10-10 11:53 ` Rudolf Sykora @ 2008-11-23 19:50 ` Rudolf Sykora 2008-11-23 21:51 ` erik quanstrom 1 sibling, 1 reply; 29+ messages in thread From: Rudolf Sykora @ 2008-11-23 19:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2008/10/8 andrey mirtchovski <mirtchovski@gmail.com>: > 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 > > Although I have somehow realized that plan9 probably can't be of much use to me, I decided to at least somehow contribute to it (before I abandon it?) and tried to investigate what could be done with respect to the bug described above. Well, I am not a programmer... In order to at least not allow rio to break completely in the situation, maybe this could be added to /sys/src/cmd/rio/rio.c: : ruda; diff rio.c rio.c_orig 683c683 < if(hidden[i] != nil) unhide(i); --- > unhide(i); : ruda; This usually helps, but it neither solves much, nor it is 100 % sure it saves you. The problem, as I see it now, is more difficult. Rio apparently stores a list of hidden windows in Window *hidden[100] Should this list couldn't change when playing with rio's menus, things would be easy. But it can (the hidden window in our example exits). And, generally, it can possibly change in any way. To underline this fact, note that even on one single line like mine if(hidden[i] != nil) unhide(i); the hidden[i] and unhide(i) can possibly pertain to completely different windows if we somehow manage to terminate some and create others in the meanwhile (I suppose this can happen, the code can be interrupted and there are not locks). [In the described example, what really happens is this. We create the hidden window that will exit in 10 s. Before it does, we press the 3rd button and (keeping it down) we see the window item in the menu. By this time we are in menuhit() function of libdraw. To this function pointers to hidden windows' labels are passed (via Menu). When this function is entered, it draws the physical menu on the screen with correct names. When our hidden window exits, the menuhit() doesn't know anything about it. Since it has drawn the physical menu on the function entrance, when the label pointers still pointed somewhere, the screen picture stays intact. When we move our mouse above the item which corresponded to the hidden window, the drawing function needs to redraw the field (to change the colours). At this moment it reads the (now non-valid) pointer again and draws rubbish. As soon as we move back to another item of the menu (still keeping the 3rd button down), the drawing function redraws the field with something (a picture) it used (and remembers) from the time the drawing function was first entered. That's why the field looks incorrect only when being above the field... If we release the button above the field of the now nonexistent window, the unhide() (or wunhide()) function in rio.c tries to unhide the window, and it gets essentially stuck. This is where I try to intervene with my if condition.] [In order to not see any rubbish, but a (stale; can't be much better---the menu is rather detached from rio) menu, I thought it would suffice to make a copy of the labels before calling menuhit() from button3menu() in rio.c. Something like changing, close to the beginning of button3menu(), menu3str[i+Hidden] = hidden[i] -> label to menu3str[i+Hidden] = strdup(hidden[i] -> label) and releasing the memory upon exit from button3menu(). However, then I realized, that the windows can change at any time, as I tried to explain above, so that any such attempt is generally wrong from the very beginning, and things have to be repaired more thoroughly]. In this view I feel the whole thing is just flawed. I appologise to the authors, if I am wrong. But it definitely disappointed me, along with limitations like that 100 static allocation size (and there are more). I'd like to see a system _without_ any such static things in spite of the fact you probably will never have so many hidden windows. I consider it a good & only right way how it should be done today. If someone could check it... :) Best regards Ruda ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-11-23 19:50 ` Rudolf Sykora @ 2008-11-23 21:51 ` erik quanstrom 2008-11-26 19:52 ` Rudolf Sykora 0 siblings, 1 reply; 29+ messages in thread From: erik quanstrom @ 2008-11-23 21:51 UTC (permalink / raw) To: 9fans > situation, maybe this could be added to /sys/src/cmd/rio/rio.c: > > : ruda; diff rio.c rio.c_orig > 683c683 > < if(hidden[i] != nil) unhide(i); > --- >> unhide(i); > : ruda; > > This usually helps, but it neither solves much, nor it is 100 % sure > it saves you. The problem, as I see it now, is more difficult. > > Rio apparently stores a list of hidden windows in > Window *hidden[100] > Should this list couldn't change when playing with rio's menus, things > would be easy. But it can (the hidden window in our example exits). > And, generally, it can possibly change in any way. To underline this > fact, note that even on one single line like mine > if(hidden[i] != nil) unhide(i); the problem is that the fs proc and the keboard thread both fiddle with the the hidden array. in the style of rio, the solution would be along the lines of sending a message (say) the keyboard thread to hide the window. since windows have unique ids, sending a message like "hide 72" would be unambiguous. acme has similar problems that tend to show up on laggy connections. > In this view I feel the whole thing is just flawed. I appologise to > the authors, if I am wrong. i didn't write rio. saying the "whole thing is just flawed" is a bit over the top. you've identified a concurrency bug that isn't fatal. if it bothers you, then please fix it. we'd be appreciative. > But it definitely disappointed me, along > with limitations like that 100 static allocation size (and there are > more). I'd like to see a system _without_ any such static things in > spite of the fact you probably will never have so many hidden windows. why? i don't think it makes sense to say static sizes are unequivicablly bad. static allocation has advantages. it's simplier and less error prone, and there are no concurrency considerations. there are always tradeoffs. and in this case, i fail to see the advantage of allowing more than 100 hidden windows so if anything, i would only wonder why the limit was so high. > I consider it a good & only right way how it should be done today. i think you need to make a case for this and explain how you would handle concurrent access to allocated structures. keep in mind that realloc can move things around. - erik ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-11-23 21:51 ` erik quanstrom @ 2008-11-26 19:52 ` Rudolf Sykora 2008-11-26 20:55 ` erik quanstrom 0 siblings, 1 reply; 29+ messages in thread From: Rudolf Sykora @ 2008-11-26 19:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > the problem is that the fs proc and the keboard thread both fiddle with > the the hidden array. in the style of rio, the solution would be > along the lines of sending a message (say) the keyboard thread to hide > the window. since windows have unique ids, sending a message like > "hide 72" would be unambiguous. What do you mean by unique ids? I think it is not enough to have a unique id at just one instant. We need a unique id for a qualitatively long time (i.e. infinite). It seems to me that numbers in /dev/wsys do not get reused, which would be just wanted, but is it really so? > acme has similar problems that tend to show up on laggy connections. what actually happens? > why? i don't think it makes sense to say static sizes are unequivicablly bad. > static allocation has advantages. it's simplier and less error prone, and It's simpler in C, because dynamic allocation in C is a pain. If I were writing a window manager in say python, I wouldn't think about any allocation problems, I guess. I would just make a dictionary of windows hashed by a window's id and that would just work. Maybe I only have a very distorted view on it. I've never programmed anything like that. > there are no concurrency considerations. there are always tradeoffs. I can't see what you mean by concurrency considerations. :( Ruda ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [9fans] bug in rio: unhiding deleted windows 2008-11-26 19:52 ` Rudolf Sykora @ 2008-11-26 20:55 ` erik quanstrom 0 siblings, 0 replies; 29+ messages in thread From: erik quanstrom @ 2008-11-26 20:55 UTC (permalink / raw) To: 9fans > What do you mean by unique ids? I think it is not enough to have a > unique id at just one instant. We need a unique id for a qualitatively > long time (i.e. infinite). It seems to me that numbers in /dev/wsys do > not get reused, which would be just wanted, but is it really so? yes they are unique for all time. (per rio.) >> acme has similar problems that tend to show up on laggy connections. >what actually happens? the mouse, keyboard and screen may be out-of-sync for a short time. > > why? i don't think it makes sense to say static sizes are unequivicablly bad. > > static allocation has advantages. it's simplier and less error prone, and > It's simpler in C, because dynamic allocation in C is a pain. If I > were writing a window manager in say python, I wouldn't think about > any allocation problems, I guess. it's deeper than that. if you do dynamic allocation in any language you need to recover from the case that there is no memory. > I would just make a dictionary of > windows hashed by a window's id and that would just work. Maybe I only > have a very distorted view on it. I've never programmed anything like > that. fancy algorthims are slow when n is small. n is usually small. why hash something that is going to be a small number? > > there are no concurrency considerations. there are always tradeoffs. > I can't see what you mean by concurrency considerations. :( assignment of a shared pointer must consistent in all processes with access. thus some sort of atomic update or locking mechanism must be used. - erik ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2008-11-26 20:55 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-10-08 20:51 [9fans] bug in rio: unhiding deleted windows andrey mirtchovski 2008-10-10 11:53 ` Rudolf Sykora 2008-10-10 12:32 ` andrey mirtchovski 2008-10-10 12:54 ` erik quanstrom 2008-10-10 20:23 ` Lyndon Nerenberg 2008-10-11 3:05 ` Russ Cox 2008-10-11 11:11 ` Rudolf Sykora 2008-10-10 13:15 ` andrey mirtchovski 2008-10-10 13:21 ` Rudolf Sykora 2008-10-10 13:18 ` erik quanstrom 2008-10-10 14:02 ` Rudolf Sykora 2008-10-10 14:41 ` erik quanstrom 2008-10-10 15:25 ` Rudolf Sykora 2008-10-10 15:21 ` erik quanstrom 2008-10-10 15:42 ` Rudolf Sykora 2008-10-10 15:33 ` ron minnich 2008-10-10 15:41 ` Rudolf Sykora 2008-10-10 16:20 ` andrey mirtchovski 2008-10-10 16:26 ` Rudolf Sykora 2008-10-10 16:30 ` andrey mirtchovski 2008-10-10 16:43 ` Rudolf Sykora 2008-10-10 15:45 ` andrey mirtchovski 2008-10-10 16:36 ` matt 2008-10-10 16:40 ` Rudolf Sykora 2008-10-11 12:44 ` erik quanstrom 2008-11-23 19:50 ` Rudolf Sykora 2008-11-23 21:51 ` erik quanstrom 2008-11-26 19:52 ` Rudolf Sykora 2008-11-26 20:55 ` erik quanstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).