Bug 99346 - [glamor]: Assertion !pixmap_priv->fbo failed in glamor_upload_picture_to_texture() at glamor_picture.c:291
Summary: [glamor]: Assertion !pixmap_priv->fbo failed in glamor_upload_picture_to_text...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/glamor (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-10 14:22 UTC by Olivier Fourdan
Modified: 2017-01-25 08:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Olivier Fourdan 2017-01-10 14:22:43 UTC 
Decription:

I can reliably kill Xwayland 1.19.0 using gtk-demo's (from gtk2) "rotated text" demo.

Assertion !pixmap_priv->fbo failed in glamor_upload_picture_to_texture() at glamor_picture.c:291

How reproducible:

Always

Steps to reproduce:

On Fedora 25:

1. Run GNOME (on Wayland)
2. Start gtk-demo (this is the gtk2 version using Xwayland)
3. Double-click on "Rotated Text" demo

Actual result:

Thread 1 "Xwayland" received signal SIGABRT, Aborted.
Assertion !pixmap_priv->fbo failed in glamor_upload_picture_to_texture() at glamor_picture.c:291

Additional data:

Hardware is an older GeForce go 7950GTX on a Dell XPS M1710.

01:00.0 VGA compatible controller: NVIDIA Corporation G71M [GeForce Go 7950 GTX] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Dell Device 019b
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 29
	Region 0: Memory at ed000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Region 3: Memory at ee000000 (64-bit, non-prefetchable) [size=16M]
	Region 5: I/O ports at ef00 [size=128]
	Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee0200c  Data: 41a2
	Capabilities: [78] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 75.000W
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <256ns, L1 <4us
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 128 bytes Disabled- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=01
			Status:	NegoPending- InProgress-
	Capabilities: [128 v1] Power Budgeting <?>
	Kernel driver in use: nouveau
	Kernel modules: nouveau


(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1  0x00007f936f22951a in __GI_abort () at abort.c:89
#2  0x00007f936f21fda7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x5a9081 "!pixmap_priv->fbo", file=file@entry=0x5a9070 "glamor_picture.c", 
    line=line@entry=291, function=function@entry=0x5a91a0 <__PRETTY_FUNCTION__.45180> "glamor_upload_picture_to_texture") at assert.c:92
#3  0x00007f936f21fe52 in __GI___assert_fail (assertion=assertion@entry=0x5a9081 "!pixmap_priv->fbo", file=file@entry=0x5a9070 "glamor_picture.c", line=line@entry=291, 
    function=function@entry=0x5a91a0 <__PRETTY_FUNCTION__.45180> "glamor_upload_picture_to_texture") at assert.c:101
#4  0x000000000044519e in glamor_upload_picture_to_texture (picture=picture@entry=0x2fff6e0) at glamor_picture.c:291
#5  0x000000000043564e in glamor_composite_choose_shader (op=op@entry=12 '\f', source=source@entry=0x2f6b930, mask=mask@entry=0x2fff6e0, dest=dest@entry=0x2fcf2d0, 
    source_pixmap=source_pixmap@entry=0x2f96d70, mask_pixmap=mask_pixmap@entry=0x2fff450, dest_pixmap=0x2fd4a00, source_pixmap_priv=0x2f96dc0, mask_pixmap_priv=0x2fff4a0, 
    dest_pixmap_priv=0x2fd4a50, s_key=0x7ffc5eb848b0, shader=0x7ffc5eb84890, op_info=0x7ffc5eb848d0, psaved_source_format=0x7ffc5eb84884, ca_state=CA_TWO_PASS)
    at glamor_render.c:1002
#6  0x0000000000437913 in glamor_composite_with_shader (ca_state=CA_TWO_PASS, rects=0x7ffc5eb84940, nrect=1, dest_pixmap_priv=0x2fd4a50, mask_pixmap_priv=0x2fff4a0, 
    source_pixmap_priv=0x2f96dc0, dest_pixmap=0x2fd4a00, mask_pixmap=0x2fff450, source_pixmap=0x2f96d70, dest=0x2fcf2d0, mask=0x2fff6e0, source=0x2f6b930, op=0 '\000')
    at glamor_render.c:1152
#7  glamor_composite_clipped_region (op=op@entry=3 '\003', source=source@entry=0x2f887e0, mask=mask@entry=0x2fff6e0, dest=dest@entry=0x2fcf2d0, 
    source_pixmap=source_pixmap@entry=0x0, mask_pixmap=<optimized out>, dest_pixmap=0x2fd4a00, region=0x7ffc5eb84ab0, x_source=<optimized out>, y_source=<optimized out>, 
    x_mask=<optimized out>, y_mask=<optimized out>, x_dest=91, y_dest=19) at glamor_render.c:1547
#8  0x000000000043893e in glamor_composite (op=op@entry=3 '\003', source=source@entry=0x2f887e0, mask=mask@entry=0x2fff6e0, dest=dest@entry=0x2fcf2d0, 
    x_source=<optimized out>, y_source=<optimized out>, x_mask=0, y_mask=0, x_dest=91, y_dest=19, width=6, height=18) at glamor_render.c:1686
#9  0x000000000043041e in glamor_composite_glyphs (op=3 '\003', src=0x2f887e0, dst=0x2fcf2d0, glyph_format=<optimized out>, x_src=-60, y_src=<optimized out>, 
    nlist=<optimized out>, list=0x7ffc5eb84e40, glyphs=0x7ffc5eb85238) at glamor_composite_glyphs.c:399
#10 0x00000000004f87b7 in damageGlyphs (op=<optimized out>, pSrc=0x2f887e0, pDst=0x2fcf2d0, maskFormat=0x0, xSrc=<optimized out>, ySrc=<optimized out>, nlist=1, 
    list=0x7ffc5eb84e30, glyphs=0x7ffc5eb85230) at damage.c:569
#11 0x00000000004ebdfa in ProcRenderCompositeGlyphs (client=0x2f083e0) at render.c:1377
#12 0x00000000005567d5 in Dispatch () at dispatch.c:469
#13 0x000000000055a758 in dix_main (argc=10, argv=0x7ffc5eb85c18, envp=<optimized out>) at main.c:287
#14 0x00007f936f212401 in __libc_start_main (main=0x423d80 <main>, argc=10, argv=0x7ffc5eb85c18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7ffc5eb85c08) at ../csu/libc-start.c:289
#15 0x0000000000423dba in _start ()

#4  0x000000000044519e in glamor_upload_picture_to_texture (picture=picture@entry=0x2fff6e0) at glamor_picture.c:291
291	    assert(!pixmap_priv->fbo);
(gdb) list
286	    Bool ret = TRUE;
287	    Bool needs_swizzle;
288	    pixman_image_t *converted_image = NULL;
289	
290	    assert(glamor_pixmap_is_memory(pixmap));
291	    assert(!pixmap_priv->fbo);
292	
293	    glamor_make_current(glamor_priv);
294	
295	    /* No handling of large pixmap pictures here (would need to make
(gdb)
Comment 1 Olivier Fourdan 2017-01-10 14:34:10 UTC 
Yeap, it's not Xwayland specific, I can achieve the same by using X11 with the modesetting driver and glamor accel.
Comment 2 Olivier Fourdan 2017-01-20 15:51:19 UTC 
We have quite a few similar reports downstream affecting various hardware (so it's not just nouveau).

 https://bugzilla.redhat.com/show_bug.cgi?id=1414596
 https://bugzilla.redhat.com/show_bug.cgi?id=1413960
 https://bugzilla.redhat.com/show_bug.cgi?id=1414038

The backtrace is always the same though, i.e. it's apparently the mask that triggers it, when glamor_upload_picture_to_texture(mask) is called from glamor_composite_choose_shader()

Seems this occurs *only* when running gnome-shell, I cannot reproduce in xfce.

Also, this occurs with the modesetting driver using glamor accel but not with "Xephyr -glamor" even when running gnome-shell on Xephyr.
Comment 3 Olivier Fourdan 2017-01-23 14:43:20 UTC 
gdb) p *mask_pixmap_priv
$1 = {type = GLAMOR_MEMORY, gl_fbo = GLAMOR_FBO_UNATTACHED,
      map_access = GLAMOR_ACCESS_RO, fbo = 0x335b740,
      box = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, pbo = 0, 
      prepare_region = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x0},
      prepared = 0, image = 0x0, block_w = 0, block_h = 0,  block_wcnt = 0,
      block_hcnt = 0, box_array = 0x0, fbo_array = 0x0}

So the problem is with the texture type actually, type = GLAMOR_MEMORY, gl_fbo = GLAMOR_FBO_UNATTACHED

In glamor_pixmap_attach_fbo() if goes like:

https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_fbo.c#n251

  | /* The pixmap must not be attached to another fbo. */
  | void
  | glamor_pixmap_attach_fbo(PixmapPtr pixmap, glamor_pixmap_fbo *fbo)
  | {
  |     glamor_pixmap_private *pixmap_priv;
  | 
  |     pixmap_priv = glamor_get_pixmap_private(pixmap);
  | 
  |     if (pixmap_priv->fbo)
  |         return;
  | 
  |     pixmap_priv->fbo = fbo;
  | 
  |     switch (pixmap_priv->type) {
  |     case GLAMOR_TEXTURE_ONLY:
  |     case GLAMOR_TEXTURE_DRM:
  |         pixmap_priv->gl_fbo = GLAMOR_FBO_NORMAL;
  |         pixmap->devPrivate.ptr = NULL;
  |     default:
  |         break;
  |     }
  | }

So in the "default" case, we can end up with pixmap_priv->fbo set but pixmap_priv->gl_fbo not set when the type is GLAMOR_MEMORY.

The first approach to the problem would be to set the fbo along with the rest of the gl_fbo type in glamor_pixmap_attach_fbo() but that would fail later as glamor_upload_picture_to_texture() assumes the fbo is non-NULL.

So this needs to be caught earlier, possibly in glamor_composite_choose_shader() and fallback if either the source or mask need update but the type doesn't match a texture.
Comment 4 Olivier Fourdan 2017-01-23 14:53:29 UTC 
FWIW, the patch I posted here avoids the issue:

https://patchwork.freedesktop.org/series/18413/

The assertion failure is avoided and the rendering looks fine (using the steps in comment 0)
Comment 5 Olivier Fourdan 2017-01-25 08:30:34 UTC 
Eric has pushed the latest iteration of the patch as commit 8646398, closing.

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.