Created attachment 16035 [details] Xorg.9.log Current xserver git cause a lot of crash, when update to commit c14f5dc237a31b13d98ae2d0d6143bd91083cf13. It works fine at commit 9e7ced94a5e3a14762fe934aa69d91f0831cf5ca. From the Xorg.0.log, the crash is caused by miPointerSetPosition(). The only commit between these two commit that may cause crash is commit 9b30cc524867a0ad3d0d2227e167f4284830ab4e. After revert this commit, xserver seems run fine. commit 9b30cc524867a0ad3d0d2227e167f4284830ab4e try to optimize dixLookupPrivate(), but as it changing the link list of PrivateRec, it will break the lookup when two dixLookupPrivate() is called almost as the same time with the same *key*. This means one find the right PrivateRec and move it to the front, the other will reach the end of of list and create a new PrivateRec whose *value* field is NULL. miPointerSetPosition() crash the server when it access the NULL pointer.
On Fri, Apr 18, 2008 at 10:20:16PM -0700, bugzilla-daemon@freedesktop.org wrote: > Current xserver git cause a lot of crash, when update to commit > c14f5dc237a31b13d98ae2d0d6143bd91083cf13. It works fine at commit > 9e7ced94a5e3a14762fe934aa69d91f0831cf5ca. From the Xorg.0.log, the crash is > caused by miPointerSetPosition(). The only commit between these two commit that > may cause crash is commit 9b30cc524867a0ad3d0d2227e167f4284830ab4e. After > revert this commit, xserver seems run fine. I've reverted this one now, thanks.
(In reply to comment #1) > I've reverted this one now, thanks. Thanks, and sorry about that. Oddly enough, I'm still running that code and have yet to encounter the problem... Doesn't the race condition still exist though, it's just much less likely to be hit? Either way, I hope there will be other opportunities for optimizing this...
(In reply to comment #2) > (In reply to comment #1) > > I've reverted this one now, thanks. > > Thanks, and sorry about that. Oddly enough, I'm still running that code and > have yet to encounter the problem... > > Doesn't the race condition still exist though, it's just much less likely to be > hit? There should be no race condition in the loop part now, as it doesn't change the list. > > Either way, I hope there will be other opportunities for optimizing this... > Indeed, this part is sub optimized.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.