Bug 88354 - glXSwapBuffers() can cause BadMatch or lock X when performed repeatedly
Summary: glXSwapBuffers() can cause BadMatch or lock X when performed repeatedly
Alias: None
Product: Mesa
Classification: Unclassified
Component: GLX (show other bugs)
Version: 10.4
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
Depends on:
Reported: 2015-01-13 06:07 UTC by Seán de Búrca
Modified: 2019-09-18 17:44 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Test program demonstrating crash/lock (2.30 KB, text/plain)
2015-01-13 06:07 UTC, Seán de Búrca

Description Seán de Búrca 2015-01-13 06:07:23 UTC
Created attachment 112152 [details]
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.
Comment 1 Eero Tamminen 2015-01-13 10:24:46 UTC
What about the X server and X intel driver versions?

Are you using DRI2 or DRI3?  If latter, can you reproduce the issue also with DRI2?
Comment 2 Seán de Búrca 2015-01-14 02:25:10 UTC
I believe I'm using DRI2. My Xorg logs contain the following:

(II) GLX: Initialized DRI2 GL provider for screen 0

If this may be incorrect, please let me know. I am using xorg-server and X Intel driver 2.99.916.
Comment 3 Eero Tamminen 2016-09-19 14:33:19 UTC
On SKL with Ubuntu 16.04, using latest Mesa from Git everything seems to work fine, same with older Mesa 11.2 coming with Ubuntu.  No crashes / locks either with Intel DDX or modesetting, with DRI3 or DRI2.

I would think that the issue is either fixed in Mesa, or culprit is something else than Mesa. Can you try newer Mesa, and if that doesn't help, newer Intel DDX version?

Btw. your test program shows interesting difference between DRI3 & DRI2.

I increased the test loop count a bit.  With Intel XX / DRI2, test goes through 10 000 rounds "instantly".

With DRI3, it takes 5-10x longer, and perf says following of the Xorg 100% CPU usage:
23.83%  Xorg Xorg  [.] SyncAddTriggerToSyncObject  
18.20%  Xorg intel_drv.so  [.] 0x000000000010a5e5  
16.83%  Xorg Xorg  [.] TimerSet
16.49%  Xorg Xorg  [.] present_pixmap  
14.41%  Xorg Xorg  [.] present_event_notify
 7.96%  Xorg Xorg  [.] SyncDeleteTriggerFromSyncObject 

With modesetting instead of Intel DDX:
- test takes even longer and seems to be limited to 60 FPS
- with DRI2, CPU usage is ~1% (LIBGL_DRI3_DISABLE=1 Mesa option)
- with DRI3, CPU usage is 100%
 98.99% Xorg
     80.49% [kernel.kallsyms]
      6.66% [unknown]  (I think this is on kernel side also)
      5.12% [vdso]
      3.99% modesetting_drv.so
      1.68% libc-2.23.so
      1.64% libdrm.so.2.4.0

 16.55%  Xorg   [kernel.kallsyms]    [k] copy_user_enhanced_fast_string   
  9.27%  Xorg   [kernel.kallsyms]    [k] do_sys_poll  
  8.13%  Xorg   [kernel.kallsyms]    [.] entry_SYSCALL_64_fastpath   
  5.43%  Xorg   [kernel.kallsyms]    [k] _raw_spin_unlock_irqrestore 
  4.51%  Xorg   [kernel.kallsyms]    [k] entry_SYSCALL_64_after_swapgs    
  4.44%  Xorg   [kernel.kallsyms]    [k] _raw_spin_lock_irqsave 
  4.20%  Xorg   [kernel.kallsyms]    [k] kfree   
  3.79%  Xorg   [kernel.kallsyms]    [k] drm_ioctl    
  3.48%  Xorg   [kernel.kallsyms]    [k] drm_wait_vblank   
  3.44%  Xorg   [kernel.kallsyms]    [k] kmem_cache_alloc_trace

In general, with DRI3, first (few thousand) swaps go faster than the later ones.
Comment 4 GitLab Migration User 2019-09-18 17:44:57 UTC
-- 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/97.

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.