This image (8.098 × 7.811): http://de.wikipedia.org/w/index.php?title=Datei:Aerial_photo_of_WTC_groundzero.jpg&filetimestamp=20090206120807 reproducibly crashes my X server 1.11.0 when displayed in Firefox 11/12. Backtrace: [ 51081.924] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x56e8a8] [ 51081.924] 1: /usr/bin/Xorg (0x400000+0x1726b5) [0x5726b5] [ 51081.924] 2: /lib64/libpthread.so.0 (0x7ffff6efc000+0xea90) [0x7ffff6f0aa90] [ 51081.924] 3: /lib64/libc.so.6 (memcpy+0x15b) [0x7ffff5849e5b] [ 51081.924] 4: .../xorg/modules/drivers/radeon_drv.so (0x7ffff3dcf000+0xc6f8e) [0x7ffff3e95f8e] [ 51081.924] 5: .../xorg/modules/libexa.so (0x7ffff37a4000+0x9549) [0x7ffff37ad549] [ 51081.924] 6: /usr/bin/Xorg (0x400000+0xfcc02) [0x4fcc02] [ 51081.924] 7: /usr/bin/Xorg (0x400000+0x33a0a) [0x433a0a] [ 51081.924] 8: /usr/bin/Xorg (0x400000+0x37099) [0x437099] [ 51081.924] 9: /usr/bin/Xorg (0x400000+0x25d35) [0x425d35] [ 51081.924] 10: /lib64/libc.so.6 (__libc_start_main+0xe6) [0x7ffff57e8586] [ 51081.924] 11: /usr/bin/Xorg (0x400000+0x258c9) [0x4258c9] [ 51081.924] Bus error at address 0x7fffe5989000 [ 51081.924] Fatal server error: [ 51081.924] Caught signal 7 (Bus error). Server aborting
The "direct" URL to the 10-MB-JPEG is http://upload.wikimedia.org/wikipedia/commons/d/db/Aerial_photo_of_WTC_groundzero.jpg It crashes the X server not only when viewed in Firefox but also when using kuickshow. Full Backtrace: Program received signal SIGBUS, Bus error. 0x00007ffff5849e5b in memcpy () from /lib64/libc.so.6 #0 0x00007ffff5849e5b in memcpy () from /lib64/libc.so.6 No symbol table info available. #1 0x00007ffff3e95f8e in R600UploadToScreenCS (pDst=0x15d7080, x=0, y=0, w=8098, h=8, src=0x1b74f88 "LD\025", src_pitch=32392) at r600_exa.c:1851 pScrn = 0x80ba50 info = 0x810110 accel_state = 0x8116e0 driver_priv = 0x16891c0 scratch = 0x0 copy_dst = 0x1641c30 dst = 0x7fffe0df7000 <Address 0x7fffe0df7000 out of bounds> dst_domain = 4 bpp = <optimized out> scratch_pitch = <optimized out> copy_pitch = 32768 ret = <optimized out> flush = 0 r = <optimized out> i = 1 src_obj = {pitch = 22900864, width = 0, height = 4092015433, offset = 32767, bpp = 0, domain = 0, bo = 0x7ffff37abeba, tiling_flags = 22900864} dst_obj = {pitch = 0, width = 0, height = 8567792, offset = 0, bpp = 32392, domain = 0, bo = 0x0, tiling_flags = 0} #2 0x00007ffff37ad549 in exaDoPutImage (src_stride=<optimized out>, bits=<optimized out>, format=<optimized out>, h=<optimized out>, w=<optimized out>, y=<optimized out>, x=<optimized out>, depth=<optimized out>, pGC=<optimized out>, pDrawable=<optimized out>) at exa_accel.c:219 No locals. #3 exaPutImage (pDrawable=0x15d7080, pGC=0x1685c90, depth=24, x=0, y=0, w=8098, h=8, leftPad=0, format=2, bits=0x1b74f88 "LD\025") at exa_accel.c:240 No locals. #4 0x00000000004fcc02 in damagePutImage (pDrawable=0x15d7080, pGC=0x1685c90, depth=24, x=0, y=0, w=8098, h=8, leftPad=0, format=2, pImage=0x1b74f88 "LD\025") at damage.c:830 oldFuncs = 0x7d3460 #5 0x0000000000433a0a in ProcPutImage (client=0x1653b30) at dispatch.c:1986 pGC = 0x1685c90 pDraw = 0x15d7080 length = <optimized out> #6 0x0000000000437099 in Dispatch () at dispatch.c:432 result = 0 client = 0x1653b30 nready = 0 start_tick = 160 #7 0x0000000000425d35 in main (argc=8, argv=0x7fffffffe238, envp=<optimized out>) at main.c:287 i = 1 alwaysCheckForInput = {0, 1}
Created attachment 57144 [details] [review] Always use scratch BO for uploads to VRAM Does this patch work around the problem?
> Does this patch work around the problem? Yes. Thanks for the patch!
(In reply to comment #2) > Created attachment 57144 [details] [review] [review] > Always use scratch BO for uploads to VRAM > > Does this patch work around the problem? Is there some similar workaround for rv280 (9250)?
(In reply to comment #4) > (In reply to comment #2) > > Created attachment 57144 [details] [review] [review] [review] > > Always use scratch BO for uploads to VRAM > > > > Does this patch work around the problem? > > Is there some similar workaround for rv280 (9250)? You should be able to manually apply the same patch to the older radeon code (RADEONUploadToScreenCS() in radeon_exa_funcs.c).
Thanks Alex i applay it there. But corruption is stil there, no crash. Firefox 10 crashes X without patch, but 15 no crash even without patch. Hmmm... Do someone have corupted images there: http://vincentsanders.blogspot.com/2012/07/travels-with-mr-brown.html
I can confirm that X crashes sometimes when using firefox on image heavy webpages (FireGL Mobility T2).
Having the same issue when loading huge images (>40MP) in Firefox 22 or Gnome Image Viewer 3.8.2. My graphics card is a Radeon HD4830 (RV770). X.Org X Server 1.14.2 Release Date: 2013-06-25 [ 27966.734] X Protocol Version 11, Revision 0 [ 27966.734] Build Operating System: 2.6.32-358.14.1.el6.x86_64 [ 27966.734] Current Operating System: Linux linux.fritz.box 3.10.3-300.fc19.x86_64 #1 SMP Fri Jul 26 00:00:58 UTC 2013 x86_64 [ 27966.734] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.10.3-300.fc19.x86_64 root=UUID=24acd717-6b10-4d0a-bcc7-466c0004015d ro rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=latarcyrheb-sun16 KEYTABLE=de rd.luks=0 LANG=en_US.UTF-8 rhgb quiet libata.force=5:1.5Gbps [ 27966.734] Build Date: 22 July 2013 04:33:06AM [ 27966.735] Build ID: xorg-x11-server 1.14.2-7.fc19 [ 27966.735] Current version of pixman: 0.30.0 [...] [ 28097.487] (EE) Backtrace: [ 28097.489] (EE) 0: /usr/bin/Xorg (OsLookupColor+0x129) [0x46edb9] [ 28097.490] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x347640ef9f] [ 28097.490] (EE) 2: /lib64/libc.so.6 (__memcpy_ssse3+0xf67) [0x347613fe77] [ 28097.491] (EE) 3: /usr/lib64/xorg/modules/drivers/radeon_drv.so (_init+0x1ec9f) [0x7fb7f589278f] [ 28097.492] (EE) 4: /usr/lib64/xorg/modules/libexa.so (exaMoveOutPixmap+0x42d4) [0x7fb7f4c188d4] [ 28097.493] (EE) 5: /usr/bin/Xorg (dixDestroyPixmap+0x1109) [0x434e29] [ 28097.493] (EE) 6: /usr/bin/Xorg (SendErrorToClient+0x3f7) [0x436fa7] [ 28097.493] (EE) 7: /usr/bin/Xorg (_init+0x3aaa) [0x429b4a] [ 28097.493] (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3476021b75] [ 28097.494] (EE) 9: /usr/bin/Xorg (_start+0x29) [0x4267b1] [ 28097.495] (EE) 10: ? (?+0x29) [0x29] [ 28097.495] (EE) [ 28097.495] (EE) Bus error at address 0x7fb7e174ccf0 [ 28097.495] (EE) Fatal server error: [ 28097.495] (EE) Caught signal 7 (Bus error). Server aborting
Possibly related: https://bugs.freedesktop.org/show_bug.cgi?id=64912
*** Bug 73083 has been marked as a duplicate of this bug. ***
Created attachment 91541 [details] [review] updated version of Michel's patch for all asics
Fix pushed: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=bcc454ea2fb239e13942270faec7801270615b9c
Not sure what the following means but after applying the patch from comment #11 I still get a crash when opening the image from comment #1. This is on FreeBSD (with Radeon KMS) though. X server stack trace: Core was generated by `Xorg'. Program terminated with signal 11, Segmentation fault. #0 memcpy () at /usr/src/lib/libc/amd64/string/bcopy.S:65 65 rep (gdb) bt #0 memcpy () at /usr/src/lib/libc/amd64/string/bcopy.S:65 #1 0x0000000804edd421 in R600UploadToScreenCS () from /usr/local/lib/xorg/modules/drivers/radeon_drv.so #2 0x0000000805b4866d in exaDoPutImage (depth=24, src_stride=<optimized out>, bits=0x817400000 <Address 0x817400000 out of bounds>, format=2, h=7811, w=8098, y=0, x=0, pGC=0x8097d6300, pDrawable=0x8101b6840) at exa_accel.c:212 #3 exaPutImage (pDrawable=0x8101b6840, pGC=0x8097d6300, depth=24, x=0, y=0, w=8098, h=7811, leftPad=0, format=2, bits=0x817400000 <Address 0x817400000 out of bounds>) at exa_accel.c:233 #4 0x00000000004f166a in damagePutImage (pDrawable=0x8101b6840, pGC=0x8097d6300, depth=24, x=<optimized out>, y=<optimized out>, w=<optimized out>, h=7811, leftPad=0, format=2, pImage=0x817400000 <Address 0x817400000 out of bounds>) at damage.c:795 #5 0x00000000004c6e19 in ProcShmPutImage (client=0x80978a6c0) at shm.c:583 #6 0x00000000004c7cc5 in ProcShmDispatch (client=0x80978a6c0) at shm.c:1108 #7 0x0000000000433091 in Dispatch () at dispatch.c:428 #8 0x00000000004224da in main (argc=8, argv=0x7fffffffdcd8, envp=<optimized out>) at main.c:288 Unfortunately, radeon_drv.so was compiled without debug symbols. There are also the following messages in the system log right from the crash time: kernel: [TTM] Unable to allocate page kernel: error: [drm:pid42432:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (254115840, 2, 4096, -12) kernel: vm_fault: pager read error, pid 42432 (Xorg) kernel: pid 42432 (Xorg), uid 0: exited on signal 11 (core dumped)
(In reply to comment #13) > Program terminated with signal 11, Segmentation fault. [...] > kernel: error: [drm:pid42432:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (254115840, 2, 4096, -12) > kernel: vm_fault: pager read error, pid 42432 (Xorg) > kernel: pid 42432 (Xorg), uid 0: exited on signal 11 (core dumped) That's a different problem, apparently caused by the image being too big to even allocate a buffer object for it on your system. Please file another bug report for that.
*** Bug 72716 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > Fix pushed: > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/ > ?id=bcc454ea2fb239e13942270faec7801270615b9c With that fix on rv280 now have gpu lockup i think, there is nothing in logs :(. Pictures on that web page from Comment 6 now start to load and instead of logouting now i have mouse freeze so must reboot on button... vts does not work :(. Current Debian Sid i386, xorg 1.15, ddx 7.3.0.
(In reply to comment #16) > With that fix on rv280 now have gpu lockup i think, there is nothing in logs > :(. Please file your own report for that.
(In reply to comment #17) > (In reply to comment #16) > > With that fix on rv280 now have gpu lockup i think, there is nothing in logs > > :(. > > Please file your own report for that. Never mind Michel, fixed it when i set AGP Gart Size to 32 MB in BIOS an it is stable for few days - so that is it, no more problem with those picture corruption, X freezes, lockups :).
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.