This seems unlikely to have anything to do with the i965 or i915 driver.  Reassigning to Adam and the GLX component.

I'll also point out that not only does the test fail, but it kills the xserver.  This is with:

xorg-x11-server-Xorg-1.9.5-1.fc14.x86_64
xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64

This regression only happens on mesa master branch.

Ajax, any idea?

ajax, could you respond?

This works on recent X servers.  I believe that there were some bugs with pixmap tracking on the X server that were fixed around the same time this patch went it.  Unless there is some compelling reason to do otherwise, we should consider this patch as being correct but tickling a latent bug elsewhere.  My inclination is to close as WONTFIX.

Ian, thanks for the reply. I agree we can close it if it works with recent xserver.

Xun, please verify.

It still fails with recent codes.
Libdrm:         (master)2.4.26-3-g2acaf160df584a5ef7b5c5b84819389948cd97ad
Mesa:           (master)efb4872a9d6e3aa6b02f6bc7426b311ae816e20d
Xserver:        (master)xorg-server-1.11.0
Xf86_video_intel:(master)2.16.0-10-g786a770f528a0daee2971494352672cb89f48384

That is weird.  I was able to reproduce this on Fedora 14 but not on Fedora 15.  In both cases I was using the same Mesa bits.

Fedora 14:

xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64
xorg-x11-server-Xorg-1.9.5-1.fc14.x86_64
kernel-3.0.0-1.fc16.x86_64

Fedora 15:

xorg-x11-drv-intel-2.15.0-5.fc15.x86_64
xorg-x11-server-Xorg-1.10.3-1.fc15.x86_64
kernel-3.0.0-1.fc16.x86_64

Talking to other folks on the team, nobody else can reproduce this crash either.  It must be related to some other component, but I'm not sure which.

I can confirm the bug with r600g (no crashes but it fails the test)!

HEAD is now at 9e2bc5d... glx: Alias glXFreeContextEXT to glXDestroyContext
...
failed to create pixmap
failed to create drawable
PIGLIT: {'result': 'pass' }



HEAD is now at 4833104... glx: Verify that drawable creation on the client side actually worked
...
failed to create pixmap
failed to create drawable
PIGLIT: {'result': 'fail' }


and still the same with todays master


xserver: 1.11.0
drm: current git master
kernel: 3.1-rc2

Xun, maybe you can have a test with the newest commit and xorg-server-1.10.3 commit of xserver on server-1.10-branch.

(In reply to comment #11)
> Xun, maybe you can have a test with the newest commit and xorg-server-1.10.3
> commit of xserver on server-1.10-branch.

It also fails on xorg-server-1.10.3 commit with mesa master branch. From my testing, this case fails on mesa master branch, whether xserver master or server-1.10-branch.

ajax/Ian, any idea?

(In reply to comment #13)
> ajax/Ian, any idea?

Pretty sure the test is correct and Mesa is wrong.  You simply happen to have found the change that turned a bogus pass into a deserved failure.

It also happens on mesa 8.0 branch.

The test fails because the second glXCreateGLXPixmap or glXCreatePixmap tries to add the same drawable ID to priv->drawHash.  The call fails because the key already exists.

I'm going to remove this from the blocker list.  Some further analysis suggests that Adam is correct.  The test was generating a pass result, but the underlying functionality was not working.  I'd argue, therefore, that this is not a regression.  In some sense this situation is better:  the user gets an error instead of some garbage that won't work.

I'm not working on this issue, reassigning back to Intel.

Hi All,
Do we have any update over this ?

what should be the expected behavior if we make multiple glXCreateGLXPixmap with same parameters?

As Ian Told ,
it is failing because key is already in the hash table.

I am not pretty sure , But if we can add some other condition check with __glxHashInsert(pdp->dri2Hash, xDrawable, pdraw) for if the key already exist.

Then might we can avoid this fail. 

Thanks,
Rahul

I tried locally:
and changed condition saying if Bad Magic or Error
if (__glxHashInsert(pdp->dri2Hash, xDrawable, pdraw) == -1)

then the test Passed.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/78.