| Summary: | XvPutImage using multiple different-sized images leaks memory | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Marton Balint <cus> | ||||||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | medium | ||||||||||
| Version: | unspecified | ||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 42118 [details] [review] Try harder to free all textured video memory Does this patch help? No, but it crashes the X server in a radeon_bo_unref call of RADEONPutImageTextured, when running my testxv application. Using only the patch for radeon_video.c seems to be OK (the X server does not crash) but the bug is not fixed either. I think you had a mistake in your patch and that caused the crash. With a minor fix I can no longer reproduce the bug! See the attached patch. Created attachment 42135 [details] [review] The patch to fix radeon_legacy_allocate_memory (In reply to comment #3) > I think you had a mistake in your patch and that caused the crash. With a minor > fix I can no longer reproduce the bug! See the attached patch. Ah yeah, good catch, thanks. (In reply to comment #2) > Using only the patch for radeon_video.c seems to be OK (the X server does not > crash) but the bug is not fixed either. Was that with the radeon_textured_video.c hunk applied as well? Just asking to satisfy my curiosity about which path(s) were actually leaking. :) v2 fix pushed to Git. The v2 fix causes Xorg segfaults on my machine:
Backtrace:
[ 2930.901] 0: /usr/bin/X (xorg_backtrace+0x28) [0x49db48]
[ 2930.902] 1: /usr/bin/X (0x400000+0x5f649) [0x45f649]
[ 2930.902] 2: /lib/libpthread.so.0 (0x7fda16786000+0xea90) [0x7fda16794a90]
[ 2930.902] 3: /usr/lib64/libdrm_radeon.so.1 (radeon_bo_unref+0xc) [0x7fda174a410c]
[ 2930.902] 4: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7fda14368000+0x4b56a) [0x7fda143b356a]
[ 2930.902] 5: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7fda14368000+0x79ea6) [0x7fda143e1ea6]
[ 2930.902] 6: /usr/bin/X (0x400000+0x124c20) [0x524c20]
[ 2930.902] 7: /usr/lib64/xorg/modules/extensions/libextmod.so (0x7fda15107000+0xf206) [0x7fda15116206]
[ 2930.902] 8: /usr/bin/X (0x400000+0x2cc29) [0x42cc29]
[ 2930.902] 9: /usr/bin/X (0x400000+0x2114d) [0x42114d]
[ 2930.903] 10: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fda15970d9d]
[ 2930.903] 11: /usr/bin/X (0x400000+0x20ca9) [0x420ca9]
[ 2930.903] Segmentation fault at address (nil)
[ 2930.903]
Fatal server error:
[ 2930.903] Caught signal 11 (Segmentation fault). Server aborting
[ 2930.903]
[ 2930.903]
Please consult the The X.Org Foundation support
at http://wiki.x.org
Reverting the commit fixes the problem.
To reproduce I just start a few movies with smplayer.
It's line 1659 of src/radeon_video.c that causes the crash: radeon_legacy_free_memory(pScrn, (void*)&pPriv->src_bo[1]); When I comment it out Xorg no longer crashes. Fix for the crash pushed. > > Using only the patch for radeon_video.c seems to be OK (the X server does not
> > crash) but the bug is not fixed either.
> Was that with the radeon_textured_video.c hunk applied as well? Just asking to
> satisfy my curiosity about which path(s) were actually leaking. :)
> v2 fix pushed to Git.
Well, if I remember correctly, it also crashed with the radeon_textured_video.c hunk applied as well as the hunks for radeon_video.c.
|
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.
Created attachment 42110 [details] Testxv.c to reproduce the memory leak It seems that if I use multiple images with different sizes and display them using XvShmPutImage from one application, then a severe memory leak occurs, and my memory is eaten up. /sys/devices/virtual/drm/ttm/memory_accounting/kernel/used_memory is getting bigger and bigger, and the increasing only stops if I exit the application. On the other hand, the occupied memory is not freed when the application exists, only the increasing stops. It is important to use images with different sizes, and to use the XvPutImage from one application to hit the bug. See the attached C program to reproduce the bug, it is a slightly modified version of testxv.c (I found it in the X video extension article of Wikipedia). You can compile it with "gcc -o testxv testxv.c -L/usr/X11R6/lib -lX11 -lXext -lXv" I tested it with an openSUSE 11.3 x86_64 LiveCD and with my current system (Xorg 7.6, Mesa 7.10, libdrm 2.4.23, xorg radeon driver from git). My graphics card is a Radeon HD4850. If you need any more information please let me know. Thanks.