Created attachment 30578 [details] gdb.txt - bt full I have this hardware: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon 3100 Graphics (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 82ee Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at d0000000 (32-bit, prefetchable) [size=256M] I/O ports at d000 [size=256] Memory at fbef0000 (32-bit, non-prefetchable) [size=64K] Memory at fbd00000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at <unassigned> [disabled] Capabilities: [50] Power Management version 3 Capabilities: [a0] MSI: Mask- 64bit+ Count=1/1 Enable- Kernel driver in use: radeon Kernel modules: radeon software used: kernel - Linus's tree up to commit 2fdc246aaf9a7fa088451ad2a72e9119b5f7f029 pixman - commit 358f96d20219b4460bfd8ecf88e69ff10044b577 xserver - commit 63f4bf39170eb2262617ef2dc95fd6d337b9dad5 mesa - commit ec5c23551cdb4c369d8f8f392208f4d4bf29911b libdrm - commit 3a387a983ec40cd443e22c1f8d9a6b5b5a8fa0d1 xf86-video-ati - commit bd89b7501f294ac645390ef144df569953c81dc4 E16 1.0.0 - window manager with built-in compositor. (crash observed only with compositing on) wine 1.2.25 (yes, its old, but even old Wine shouldn't crash whole X server?) 3DMark2000 (win32 3D benchmark, used for tracking basic wine performance) If I run default benchmark (only change mode to 1024x768x32 and buffering to double), let it run, note result (some 1500-2900, depending on compositor on/off), and try to leave app with menu -> exit - it crashes.
Created attachment 30579 [details] X log
Created attachment 30580 [details] xorg.conf
For me, it looks like crash in some fallback codepath .... because Wine tries to create very big window (i can see it with compositor off), and E16 pager tries to read it back at the same time (it doesn't crash if i set E16 pager to another mode, not 'Live Update'. Just some black rectangle in place of window, slowly fading in).
The log file appears to be from an old Git snapshot of xserver - in current Git, line 307 of fbpict.c is no longer even in the function image_from_pict(). Does the problem still occur with a current Git snapshot? If so, please attach an updated backtrace. Also reassigning away from EXA as the evidence so far points to fb.
Actually, the backtrace may just be confusing due to function inlining... try getting another backtrace with at least the fb module rebuilt without optimization.
Created attachment 30588 [details] gdb.txt - hopefully better log X server was compiled with CFLAGS="-O0 -g"
Created attachment 30982 [details] [review] Handle NULL return value from fbpict.c:copy_drawable(). Looks like this goes back to commit c3d6799cee7ff8411b3a05a7ab7e2a9e80c95059 ('Bug #594: CAN-2005-2495: Fix exploitable integer overflow in pixmap creation, [...]'), which prevents the allocation of pixmaps with width or height > 32767. Does this patch fix the crash? It probably results in lost rendering though.
(In reply to comment #7) > Created an attachment (id=30982) [details] > Handle NULL return value from fbpict.c:copy_drawable(). > > Looks like this goes back to commit c3d6799cee7ff8411b3a05a7ab7e2a9e80c95059 > ('Bug #594: CAN-2005-2495: Fix exploitable integer overflow in pixmap creation, > [...]'), which prevents the allocation of pixmaps with width or height > 32767. > > Does this patch fix the crash? It probably results in lost rendering though. > Yes, this patch helps, and super-long window was nearly always hardly visible with compositor, anyway.
The fix has landed in xserver master (and the crashing code has been removed on server-1.7-branch).
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.