[9fans] Bug Report

[9fans] Bug Report

[David]

Hello 9fans,

A friend read the Plan 9 source, and discovered some "bugs".
He don't know the Plan 9 operating system, but he has some competences 
in C.
I don't think that they all are bugs, but few seems to be.

URL of the report: http://schtarb.free.fr/plan9.txt

Good bye.

-- 
David

Re: [9fans] Bug Report

[Russ Cox]

> A friend read the Plan 9 source, and discovered some "bugs".
> He don't know the Plan 9 operating system, but he has some competences
> in C.
> I don't think that they all are bugs, but few seems to be.
> 
> URL of the report: http://schtarb.free.fr/plan9.txt

Thanks.  I hope your friend used a program to find these.

Russ

Re: [9fans] Bug Report

[andrey mirtchovski]

> http://schtarb.free.fr/plan9.txt

[Kung Pow]
That's a lot of bugs!
[/Kung Pow]

ps: http://www.evilnetwork.com/stuff/alottanuts.mp3

Re: [9fans] Bug report

[Russ Cox]

> in all cases, hiding and unhiding corrupt windows restores them to their
> correct state.  putting vmware into partial screen mode doesn't fix
> corrupt windows (but prevents the creation of new ones), but personally
> i find vmware in partial screen mode very painful.

you could run vmware in windows full screen mode.  :-)

unfortunately we simply don't have software cursor
support, which linux full screen mode basically requires.
a few people have tried adding software cursors before, and i have
yet to see a satisfactory solution, one that doesn't
introduce a lot of extra complexity.  i don't expect
to have this bug fixed for at least a few months.
sorry.

russ

Re: [9fans] Bug report

[Paul O'Donnell]

On Mon, 6 May 2002, Russ Cox wrote:

> To the VMware people, I have no idea how this could be happening.
> I'm fairly certain I got that code right, but try the /lib/words
> test.  Also, does the selection disappearing only happen in full
> screen mode under Linux?

cat /lib/words works fine, and I only have problems in full screen
mode.  I get problems with clock and stats killed.  I can reproduce
the following problems 100% of the time.

you can see them at http://paprika.spicy.org/p9/p9.jpg and
http://paprika.spicy.org/p9/acme.jpg.

- put the cursor over some text, mouse 2 or 3 to pop up a menu.
  release the button.  if you moved the mouse, the square behind
  where you started will be a latent cursor image, and behind where
  you finished will be a green square.  if you didn't move the mouse,
  you'll get a green square.

- create a new window, and drag it out over an existing window.  when
  you hide the new window, you get a line of crosses where you dragged
  across windows it covers.

- bring up a term window.  leave the cursor over it and run ps or
  some other command to put text in the window.  move the mouse.  the
  square behind where the mouse cursor was will be blank.

- bring up acme.  right mouse.  the square under the mouse will be
  blank.  see the highlighted word button in the top left of
  http://paprika.spicy.org/p9/acme.jpg

in all cases, hiding and unhiding corrupt windows restores them to their
correct state.  putting vmware into partial screen mode doesn't fix
corrupt windows (but prevents the creation of new ones), but personally
i find vmware in partial screen mode very painful.

Re: [9fans] Bug report

[paurea]

Russ Cox writes:
 > > Sometimes when you select text in acme, it completely disappears.
 > > The only way I've found to bring it back is to either scroll it out
 > > and back again, or hide and then unhide the window in rio.
 >

I use vmware under Linux.  For me it doesn't completely disappear. It
disappears some times and partially. Only on full screen and it
disappears only under the cursor, so it is related with the other bug.



 > Almost always this means that we've botched the hardware
 > acceleration, so that we're not waiting until the block fill
 > finishes before we manually fiddle with the memory to draw the
 > characters.  Having drawn the characters, the block fill then
 > happens and undoes all our hard work.  A good test is to draw a big
 > window, put it in auto-scroll mode and run cat /lib/words.  If the
 > race exists, you usually see half the text missing once it
 > finishes.
 >


This doen't do the trick for me. On full screen or on a window,
it works normally.



--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] Bug report

[Mike Haertel]

>To the VMware people, I have no idea how this could be happening.
>I'm fairly certain I got that code right, but try the /lib/words
>test.  Also, does the selection disappearing only happen in full
>screen mode under Linux?

I've seen it under vmware in win 2k.

Re: [9fans] Bug report

[Russ Cox]

> ThinkPad 600e - builtin NeoMagic MagicMedia 256av
> NEC Versa SX - builtin Trident Cyber 9388
> common to both - 1024x768x16, 2mb video RAM

there goes that theory.  neither card actually
implements hardware acceleration.

if you can further characterize the problem,
do let us know.

russ

Re: [9fans] Bug report

[markp]

| To the non-VMware people, what kind of video cards are you using?

ThinkPad 600e - builtin NeoMagic MagicMedia 256av
NEC Versa SX - builtin Trident Cyber 9388
common to both - 1024x768x16, 2mb video RAM

both do have hwaccel on. the neomagic video seems slightly more
susceptible to it, but that's purely subjective.  I haven't found a
reliably reproducible case yet but I haven't been trying all that hard
either - I can play around with it tonight and report what I come up
with, if that'll help.

thanks,
---mp

Re: [9fans] Bug report

[Russ Cox]

> Sometimes when you select text in acme, it completely disappears.
> The only way I've found to bring it back is to either scroll it out
> and back again, or hide and then unhide the window in rio.

Almost always this means that we've botched the hardware
acceleration, so that we're not waiting until the block fill
finishes before we manually fiddle with the memory to draw
the characters.  Having drawn the characters, the block fill
then happens and undoes all our hard work.  A good test is
to draw a big window, put it in auto-scroll mode and run
cat /lib/words.  If the race exists, you usually see half
the text missing once it finishes.

To the non-VMware people, what kind of video cards are you using?

To the VMware people, I have no idea how this could be happening.
I'm fairly certain I got that code right, but try the /lib/words
test.  Also, does the selection disappearing only happen in full
screen mode under Linux?

Re: [9fans] Bug report

[Mike Haertel]

>what is the "disappearing-text-in-selection"?

I've seen this too, but I've basically only run 4e under vmware so far.
So I can't confirm whether it happens without vmware.

Sometimes when you select text in acme, it completely disappears.
The only way I've found to bring it back is to either scroll it out
and back again, or hide and then unhide the window in rio.

Re: [9fans] Bug report

[Russ Cox]

what is the "disappearing-text-in-selection"?

Re: [9fans] Bug report

[markp]

I don't have a vmware system to compare but I'm seeing the disappearing-
text-in-selection once in awhile on my laptops. it's rare when I'm making
a selection with the mouse, but fairly common in acme when something's
making selections on its own, i.e. compiler output in an +Errors window.

Re: [9fans] Bug report

[Paul O'Donnell]

I see the same behaviour under Red Hat 7.1 and vmware 3.1.1-1790 with
an nvidia Riva TNT2 graphics card.

On Mon, 6 May 2002 paurea@gsyc.escet.urjc.es wrote:

> I am using plan 9 under vmware. Under some circunstances (I am not
> sure which, but it happens quite often), some windows seem not to get
> repainted and so the cursor stays drawn on them. Also selecting text
> makes some of the letters of the selected region not visible (as if
> there were only blanks some times and partially invisible others). You
> can see an example of the first simptom in:
>
>

Re: [9fans] Bug report

[Russ Cox]

You could use

	typedef unsigned long uvlong;
	typedef long vlong;

and then I think it would compile just fine.

If you don't have pread/pwrite then that will
be a little harder to work around.

Russ

Re: [9fans] Bug report

[paurea]

Russ Cox writes:
 > From: "Russ Cox" <rsc@plan9.bell-labs.com>
 > Subject: Re: [9fans] Bug report
 > Date: Sun, 5 May 2002 19:24:29 -0400
 >
 > I knew that that could happen.  I was under the impression
 > it was only supposed to happen when running in full screen
 > mode under Linux.  The problem is that under certain
 > conditions (that is, full screen mode under Linux) the
 > virtual hardware cursor is really a software cursor,
 > so you have to turn it off before drawing.  I was hoping
 > that VMware would add real hardware cursor support and
 > I could avoid this.

After some tests, I have found I can reproduce the bug only in full
screen mode.

 >
 > What if you kill off the clock and the stats windows,
 > so that nothing could possibly be drawing on the display?
 > Then does the mouse still have problems?  If so, it's probably

Yes. I still have problems if I kill the stats and clock. When in full
screen mode the mouse leaves a trace when I create a new window. Also
it leaves a trace on the little green window with new resize etc. which
appears when you click the right button on rio.

 > just a bug of mine rather than this pseudo-hardware cursor
 > problem.
 >

I only happens on full screen mode, so it may be the software cursor problem...
--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] Bug report

[arisawa]

Hello,

It seems new u9fs requires 64bit integer.
My UNIX system(NEXTSTEP) does not support that.

Is there any way to connect from v4 terminal to NEXSTEP using u9fs?
Can srvold9p be applied for this purpose?

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

Re: [9fans] Bug report

[Russ Cox]

I knew that that could happen.  I was under the impression
it was only supposed to happen when running in full screen
mode under Linux.  The problem is that under certain
conditions (that is, full screen mode under Linux) the
virtual hardware cursor is really a software cursor,
so you have to turn it off before drawing.  I was hoping
that VMware would add real hardware cursor support and
I could avoid this.

What if you kill off the clock and the stats windows,
so that nothing could possibly be drawing on the display?
Then does the mouse still have problems?  If so, it's probably
just a bug of mine rather than this pseudo-hardware cursor
problem.

Russ

[9fans] Bug report

[paurea]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 397 bytes --]

I am using plan 9 under vmware. Under some circunstances (I am not
sure which, but it happens quite often), some windows seem not to get
repainted and so the cursor stays drawn on them. Also selecting text
makes some of the letters of the selected region not visible (as if
there were only blanks some times and partially invisible others). You
can see an example of the first simptom in:


[-- Attachment #2: display.gif --]
[-- Type: image/gif, Size: 15752 bytes --]

[-- Attachment #3: message body and .signature --]
[-- Type: text/plain, Size: 147 bytes --]


If you want I can make any tests and report back.
--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"