Bug 90354 - Software rendering cuses X BadMatch error
Summary: Software rendering cuses X BadMatch error
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: GLX (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-06 22:22 UTC by Igor Gnatenko
Modified: 2015-05-07 02:45 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
backtrace (52.15 KB, text/plain)
2015-05-06 22:22 UTC, Igor Gnatenko
Details

Description Igor Gnatenko 2015-05-06 22:22:25 UTC
Created attachment 115606 [details]
backtrace

Original report: https://bugzilla.redhat.com/show_bug.cgi?id=1206960
Comment 1 Igor Gnatenko 2015-05-06 22:25:34 UTC
Looks like a bug in swrast.

The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 801 error_code 8 request_code 72 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


#5  0x00007ffff43c43fd in _XError (dpy=dpy@entry=0x5555557981a0, rep=rep@entry=0x5555564a4650) at XlibInt.c:1429
#6  0x00007ffff43c1287 in handle_error (dpy=0x5555557981a0, err=0x5555564a4650, in_XReply=<optimized out>) at xcb_io.c:213
#7  0x00007ffff43c1345 in handle_response (dpy=dpy@entry=0x5555557981a0, response=0x5555564a4650, in_XReply=in_XReply@entry=1) at xcb_io.c:325
#8  0x00007ffff43c2300 in _XReply (dpy=dpy@entry=0x5555557981a0, rep=rep@entry=0x7fffffffd2e0, extra=extra@entry=0, discard=discard@entry=1) at xcb_io.c:627
#9  0x00007ffff43bdc3d in XSync (dpy=0x5555557981a0, discard=discard@entry=0) at Sync.c:44
#10 0x00007ffff43bdcdb in _XSyncFunction (dpy=<optimized out>) at Synchro.c:35
#11 0x00007ffff43b70fe in XPutImage (dpy=0x5555557981a0, d=27263047, gc=0x555555dc2840, image=image@entry=0x555555eb1050, req_xoffset=req_xoffset@entry=0, req_yoffset=<optimized out>, req_yoffset@entry=0, x=0, y=0, req_width=704, req_height=384) at PutImage.c:1022
#12 0x00007fffeb2b45d7 in swrastPutImage2 (draw=<optimized out>, op=<optimized out>, x=<optimized out>, y=<optimized out>, w=<optimized out>, h=<optimized out>, stride=0, data=0x7fffb4438040 "", loaderPrivate=0x555555dc2720) at drisw_glx.c:166
#13 0x00007fffeb2b4603 in swrastPutImage (draw=<optimized out>, op=<optimized out>, x=<optimized out>, y=<optimized out>, w=<optimized out>, h=<optimized out>, data=0x7fffb4438040 "", loaderPrivate=0x555555dc2720) at drisw_glx.c:176
#14 0x00007fffdd611ce6 in drisw_put_image (height=<optimized out>, width=<optimized out>, data=<optimized out>, dPriv=<optimized out>) at drisw.c:70
#15 0x00007fffdd611ce6 in drisw_put_image (drawable=<optimized out>, data=<optimized out>, width=<optimized out>, height=<optimized out>) at drisw.c:113
#16 0x00007fffdd6123ae in drisw_swap_buffers (sub_box=0x0, ptex=0x5555562f65d0, dPriv=0x555555eae4e0) at drisw.c:136
#17 0x00007fffdd6123ae in drisw_swap_buffers (ptex=0x5555562f65d0, dPriv=0x555555eae4e0) at drisw.c:153
#18 0x00007fffdd6123ae in drisw_swap_buffers (dPriv=0x555555eae4e0) at drisw.c:180
#19 0x00007fffeb2b40a5 in driswSwapBuffers (pdraw=0x555555dc2720, target_msc=<optimized out>, divisor=<optimized out>, remainder=<optimized out>, flush=<optimized out>)
    at drisw_glx.c:552
#20 0x00007ffff5c0aea7 in _cogl_winsys_onscreen_swap_buffers_with_damage (onscreen=0x555555eae150, rectangles=<optimized out>, n_rectangles=<optimized out>)
    at winsys/cogl-winsys-glx.c:1995
#21 0x00007ffff5bfa29e in cogl_onscreen_swap_buffers_with_damage (onscreen=<optimized out>, rectangles=<optimized out>, n_rectangles=<optimized out>) at ./cogl-onscreen.c:315
#22 0x00007ffff629e195 in clutter_stage_cogl_redraw (stage_window=0x555555c981a0) at cogl/clutter-stage-cogl.c:641
#23 0x00007ffff62a0f4a in clutter_stage_gdk_redraw (stage_window=0x555555c981a0) at gdk/clutter-stage-gdk.c:468
#24 0x00007ffff630da57 in _clutter_stage_do_update (stage=0x555555b2e9c0 [ClutterStage]) at clutter-stage.c:1130
#25 0x00007ffff630da57 in _clutter_stage_do_update (stage=stage@entry=0x555555b2e9c0 [ClutterStage]) at clutter-stage.c:1186
#26 0x00007ffff62a0905 in clutter_master_clock_gdk_update (master_clock=0x5555560ebdc0 [ClutterMasterClockGdk], stage=0x555555b2e9c0 [ClutterStage])
    at gdk/clutter-master-clock-gdk.c:223
#27 0x00007ffff62a0905 in clutter_master_clock_gdk_update (frame_clock=0x5555557c2df0 [GdkFrameClockIdle], master_clock=0x5555560ebdc0 [ClutterMasterClockGdk])
    at gdk/clutter-master-clock-gdk.c:280
Comment 2 Dave Airlie 2015-05-07 02:45:22 UTC
seems to be a gtk/cogl interaction problem

gtk creates a 32-bit depth window, cogl use a 24-bit depth visual on it, swrast PutImage 24 onto 32, world ends here.


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.