Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
mesa
mesa
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 2,379
    • Issues 2,379
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 663
    • Merge Requests 663
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Mesa
  • mesamesa
  • Issues
  • #97

Closed
Open
Opened Sep 18, 2019 by Bugzilla Migration User@bugzilla-migration

glXSwapBuffers() can cause BadMatch or lock X when performed repeatedly

Submitted by Seán de Búrca

Assigned to mes..@..op.org

Link to original bug (#88354)

Description

Created attachment 112152 Test program demonstrating crash/lock

When running a simple program to test window and GL context creation, I experience program crashes or X lockups when the main loop calls glXSwapBuffers() too rapidly. When the swap interval is not set, this appears to always cause X to lock, with only the mouse responding. (n.b. When attempting to drag windows, the cursor changes appropriately but the windows do not respond.) If glXSwapIntervalMESA(1) is called, this occasionally merely results in a program crash after some number of loops. In both cases, the following error appears in the output and the program stops execution:

X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 147 () Minor opcode of failed request: 1 Serial number of failed request: 163 Current serial number in output stream: 1034

After the end of execution, if X is locked, it remains locked until restarted. Putting a one second delay into the main loop prevents the crash and programs using GLX while rendering real results have not yet elicited any crashes, suggesting this is a race condition somewhere. The test program I am using to reproduce this is attached.

I am using mesa 10.4.1 with the i965 drivers on an Intel HD 3000 with kernel 3.17.8. All packages are from the Fedora 21 repositories.

Attachment 112152, "Test program demonstrating crash/lock":
glxwindow.c

Version: 10.4

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: mesa/mesa#97