From: Michel <mi...@da...> - 2002-01-28 08:34:27
|
On Son, 2002-01-27 at 19:41, Peter Surda wrote: > On Sun, Jan 27, 2002 at 06:03:42PM +0100, Michel D=E4nzer wrote: >=20 > > > The first one definitely wasn't correct. A process of pid 0 doesn't e= xist, but > > > it has been handled as if it existed. > > The test ( buf->pid !=3D current->pid ) isn't there for fun. The pid fi= eld > > of the buffer must contain the current process' pid. > Yes, exactly. But this test fails if buf->pid =3D=3D 0, which is wrong. No. As you say, 0 isn't a valid pid, which is covered by this test. > Hence I added this test. See "added", not "deleted" or "replaced" You "deleted" part of the ( buf->pid !=3D current->pid ) test. > > Looking at r128_freelist_get(), ( buf->pid =3D=3D 0 ) means the buffer = is > > free, i.e. not supposed to be in use by any process. > Yes thats exactly what I'm talking about, this isn't tested though in oth= er > places. It is, see above. > > is in the LeaveServer() function, where it releases the indirect buffer= . Can > > you try if that fixes the problem? Another idea is to set > > info->indirectBuffer to NULL in R128CCEAccelInit(). > Sounds reasonable, I'll try it. So the first solution works, what about the second one? > I hope I'll be around on tomorrows irc meeting, we can try stuff in realt= ime then :-) Unfortunately, I can't attend tonight's meeting because I'm in military service this week. :( --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |