xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

#1087 closed defect (wontfix)

Scaling up and down triggered client side gdk_is_colormap assertion failure

Reported by: alas Owned by: Antoine Martin
Priority: major Milestone: 0.17
Component: client Version: trunk
Keywords: Cc:

Description

Testing with OSX client 0.17.0 r11653 against 0.17.0 r11669 fedora 23 server against #976, with --desktop-scaling=1.8,110% (as well as --opengl=on with an Intel Iris video card, in case that might be a culprit here)... as I was scaling up and down to check scaling ratios, the client crashed with the following traceback (also including some of the desktop re-sizings, in case those are of any interest).

2016-01-12 13:00:52,988 setting scaling to 125% x 69%:
2016-01-12 13:00:52,988 sending updated screen size to server: 2048x3586 with 1 screens
2016-01-12 13:00:52,988   schadenfreude.local (903x878 mm - DPI: 57x103)
2016-01-12 13:00:52,988     monitor 1 1344x1512 at 704x2074 (592x370 mm - DPI: 57x103)
2016-01-12 13:00:52,988     monitor 2 2048x2074 (903x508 mm - DPI: 57x103)
2016-01-12 13:00:56,548 Warning: cannot scale by 100% x 55% or lower
2016-01-12 13:00:56,548  the scaled client screen 2560 x 2490 -> 2560 x 4481
2016-01-12 13:00:56,548  would overflow the server's screen: 8192 x 4096
2016-01-12 13:01:08,288 Warning: cannot scale by 100% x 55% or lower
2016-01-12 13:01:08,288  the scaled client screen 2560 x 2490 -> 2560 x 4481
2016-01-12 13:01:08,288  would overflow the server's screen: 8192 x 4096
2016-01-12 13:01:10,400 setting scaling to 150% x 83%:
2016-01-12 13:01:10,400 sending updated screen size to server: 1707x2988 with 1 screens
2016-01-12 13:01:10,400   schadenfreude.local (903x878 mm - DPI: 48x86)
2016-01-12 13:01:10,401     monitor 1 1120x1260 at 587x1728 (592x370 mm - DPI: 48x86)
2016-01-12 13:01:10,401     monitor 2 1707x1728 (903x508 mm - DPI: 48x86)
2016-01-12 13:01:12,080 setting scaling to 200% x 111%:
2016-01-12 13:01:12,080 sending updated screen size to server: 1280x2241 with 1 screens
2016-01-12 13:01:12,080   schadenfreude.local (903x878 mm - DPI: 36x64)
2016-01-12 13:01:12,081     monitor 1 840x945 at 440x1296 (592x370 mm - DPI: 36x64)
2016-01-12 13:01:12,081     monitor 2 1280x1296 (903x508 mm - DPI: 36x64)
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11653/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk_compat.py:101: GtkWarning: gtk_widget_set_colormap: assertion 'GDK_IS_COLORMAP (colormap)' failed
  gtkgl.widget_set_gl_capability(glarea, glconfig, None, True, RGBA_TYPE)
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11653/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/gtk_client_window_base.py:326: GtkWarning: gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed
  gtk.Window.show(self)
Bus error: 10
2016-01-12 13:01:14,231 sound output stopping

Attachments (1)

ticket1087_some-server-output-of-scaling-changes-up-to-crashes-on-osx.txt (86.3 KB) - added by alas 4 years ago.
some scaling output data maybe worth the effort of looking through

Download all attachments as: .zip

Change History (5)

comment:1 Changed 4 years ago by alas

Was able to reproduce relatively easily with osx client... but with second repro, was also seeing a traceback that seems oddly familiar:

2016-01-12 13:47:14,316 draw error
Traceback (most recent call last):
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11653/Xpra.app/Contents/Resources/lib/python/xpra/client/ui_client_base.py", line 2514, in _do_draw
    window.draw_region(x, y, width, height, coding, data, rowstride, packet_sequence, options, [record_decode_time])
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11653/Xpra.app/Contents/Resources/lib/python/xpra/client/client_window_base.py", line 538, in draw_region
    backing.draw_region(x, y, width, height, coding, img_data, rowstride, options, callbacks)
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11653/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 521, in draw_region
    self.paint_rgb32(img_data, x, y, width, height, rowstride, options, callbacks)
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11653/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 301, in paint_rgb32
    rgb32_data = self.process_delta(raw_data, width, height, rowstride, options)
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11653/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 180, in process_delta
    raise Exception("delta region bucket %s references pixmap data we do not have!" % bucket)
Exception: delta region bucket 0 references pixmap data we do not have!

I am not able to repro the original 'GDK_IS_COLORMAP (colormap)' failed error without forcing opengl with the OSX client, however... and I am not able to repro with windows client even with opengl forced (though, with --opengl=on with the windows client, I am able to repro the delta region bucket 0 references pixmap data we do not have! exception, usually by scaling up/down quickly).

I suppose this ticket might just want to be added to the list of why forcing opengl with Intel drivers is at your own risk...

comment:2 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

The stacktrace from comment:1 can be safely ignored, it's a race condition which would be hard to fix - just not worth the effort.

As for the real bug in this ticket: it looks like we fail to re-create the new opengl window with the new dimensions. How big was it? Does the window size matter? Can you reproduce with small / big window more easily? Or does it occur at a particular scaling ratio? (or combination thereof..)
If that's the case, we may be able to set a limit and avoid the crashes.

comment:3 Changed 4 years ago by alas

Owner: changed from alas to Antoine Martin

Using a 0.17.0 r12380 osx client against 0.17.0 r12385 fedora 23 server...

I was able to reproduce more/less easily depending on my luck.

Was triggered sometimes when scaling up/down to the uppper/lower limits... other times when adjusting up/down between 125% and 400% (fairly standard scaling sizes)... sometimes only after a lot of scaling adjustments, other times within 6-12 shifts... sometimes with scaling adjustments in close succession, other times taking my time.

I'm out of ideas of patterns to look for.

I'll attach a file with a number of passes through and server-side output of scaling changes... in case you feel like trying to find anything I might've missed... and I'll hand this back to you.

Pass back with any ideas to try (obviously), or maybe we should just write this off as an osx/gtk/forced-opengl issue?

Changed 4 years ago by alas

some scaling output data maybe worth the effort of looking through

comment:4 Changed 4 years ago by Antoine Martin

Resolution: wontfix
Status: newclosed

Looks like a platform quirk to me.
Hopefully we can move to another toolkit at some point, which should fix this problem.
So closing as wontfix, just something to be aware of and keep in your errata.

Note: See TracTickets for help on using tickets.