Bug 99866 - xrandr makes Xorg memory leak on Debian8
Summary: xrandr makes Xorg memory leak on Debian8
Status: RESOLVED DUPLICATE of bug 99521
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Ext/RandR (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-02-20 07:18 UTC by jorge_monteagudo
Modified: 2017-02-22 07:08 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (54.86 KB, text/plain)
2017-02-20 07:18 UTC, jorge_monteagudo
no flags Details
Little test app implementing xrandr loop (6.53 KB, text/plain)
2017-02-20 07:20 UTC, jorge_monteagudo
no flags Details
Script to read memfree from /proc/meminfo and stay alive while a given process is alive (91 bytes, application/x-shellscript)
2017-02-20 07:21 UTC, jorge_monteagudo
no flags Details
dmesg (54.62 KB, application/force-download)
2017-02-20 07:24 UTC, jorge_monteagudo
no flags Details
Xorg running under Valgrind log (1.25 MB, application/force-download)
2017-02-21 09:16 UTC, jorge_monteagudo
no flags Details

Description jorge_monteagudo 2017-02-20 07:18:49 UTC
Created attachment 129748 [details]
Xorg.0.log

Hi all!

This bug is something related to bug 99521, but on Debian8 with an older Xorg version.

My system:

- 3.16.0-4-amd64
- X.Org X Server 1.16.4
- Catalyst 15.20.3 with an AMD Radeon(TM) HD 8400E

I have a little test program that implements the 'xrandr -q' command in a loop running in a terminal. The same behavior is observed with xrandr in a bash script loop. In a second terminal I've left a top -d 1 and in a third terminal a little script reading the 'memfree' field from /proc/meminfo.

I've left this configuration all the weekend and I've seen the next. At the beginning:

second terminal:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                               
  671 root      20   0  272692  92720  75248 S   2.0  2.7   0:07.86 Xorg                               
 1381 unidesa   20   0  426844  30564  23072 S   1.0  0.9   0:03.38 gnome-terminal-                         
 1458 unidesa   20   0   13244   2992   2756 S   1.0  0.1   0:00.03 check_mem.sh                               
 1487 unidesa   20   0   23644   3024   2536 R   1.0  0.1   0:00.14 top                               
    1 root      20   0  176344   5180   3084 S   0.0  0.2   0:01.66 systemd                               


third terminal:
MemFree:         2509136 kB
MemFree:         2508780 kB
MemFree:         2508376 kB
MemFree:         2508532 kB


And after 37 hours:

second terminal:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                               
  671 root      20   0  467696 292728  77180 S  28.5  8.6  37:59.12 Xorg                               
 1213 unidesa   20   0 1823056 203720  98792 R  23.6  6.0   4:46.66 gnome-shell                               
 1416 unidesa   20   0  535520  35652  25556 S  21.6  1.0   0:06.85 gedit                               
 1381 unidesa   20   0  423276  30196  22560 S  16.7  0.9  32:59.89 gnome-terminal-                         
    7 root      20   0       0      0      0 S   1.0  0.0   5:50.81 rcu_sched                               
  555 unidesa   20   0   23636   3024   2536 R   1.0  0.1   0:36.56 top                               
 1175 unidesa   20   0   18788   3028   2596 S   1.0  0.1   0:00.02 xprop                               
    1 root      20   0  176344   5180   3084 S   0.0  0.2   0:10.17 systemd                               


third terminal:
MemFree:         1556232 kB
MemFree:         1556092 kB
MemFree:         1556140 kB
MemFree:         1555836 kB
MemFree:         1555736 kB


Another clue. The Xorg.0.log files is logging on every xrandr iteration

[229949.213] (II) fglrx(0): EDID vendor "TOV", prod id 21   
[229949.214] (II) fglrx(0): Printing DDC gathered Modelines:
[229949.214] (II) fglrx(0): Modeline "1920x1080"x0.0  138.50  1920 1968 2000 2080  1080 1083 1088 1111 +hsync -vsync (66.6 kHz eP)
[229949.214] (II) fglrx(0): Modeline "1366x768"x0.0   72.01  1366 1414 1446 1528  768 770 775 790 -hsync -vsync (47.1 kHz e)
[229949.214] (II) fglrx(0): Modeline "1280x800"x0.0   83.48  1280 1352 1480 1680  800 803 809 831 -hsync +vsync (49.7 kHz e)
[229949.214] (II) fglrx(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[229949.214] (II) fglrx(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[229949.214] (II) fglrx(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[229949.214] (II) fglrx(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[229949.214] (II) fglrx(0): Modeline "1920x1080"x60.0  172.80  1920 2040 2248 2576  1080 1081 1084 1118 -hsync +vsync (67.1 kHz e)
[229949.214] (II) fglrx(0): Modeline "1600x900"x60.0  119.00  1600 1696 1864 2128  900 901 904 932 -hsync +vsync (55.9 kHz e)
[229949.214] (II) fglrx(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[229949.214] (II) fglrx(0): Modeline "1280x720"x60.0   74.48  1280 1336 1472 1664  720 721 724 746 -hsync +vsync (44.8 kHz e)


Now is a 14.5MB file! I've attached a reduced version removing the repeated text.

Regards
Comment 1 jorge_monteagudo 2017-02-20 07:20:06 UTC
Created attachment 129749 [details]
Little test app implementing xrandr loop
Comment 2 jorge_monteagudo 2017-02-20 07:21:02 UTC
Created attachment 129750 [details]
Script to read memfree from /proc/meminfo and stay alive while a given process is alive
Comment 3 jorge_monteagudo 2017-02-20 07:24:46 UTC
Created attachment 129751 [details]
dmesg
Comment 4 Michel Dänzer 2017-02-20 09:58:28 UTC
As mentioned in bug 99521, there will likely be no more upstream 1.18.y releases, much less 1.16.y.

Does the problem also happen with a different Xorg driver? If so, can you reproduce with Xorg running in valgrind --leak-check=full and attach the valgrind output (from after Xorg terminated) here? Make sure debugging symbols are available for the binaries of Xorg and its modules.
Comment 5 jorge_monteagudo 2017-02-21 09:15:40 UTC
Hi,

Xorg running under valgrind with this command:

#!/bin/bash
exec valgrind --error-limit=no --log-file=/home/Xorg-valgrind.log --leak-check=full --leak-resolution=high --show-reachable=yes /usr/bin/Xorg.valgrind-testing "$@"


I've attached a log with the test app running 1 hour more or less... Next night I'll leave the test running with valgrind but I think something is shown in the log. Basically this calls

==659== 307,824 bytes in 1,749 blocks are still reachable in loss record 470 of 473
==659==    at 0x4C2AD10: calloc (vg_replace_malloc.c:623)
==659==    by 0x2C5140: XNFcalloc (utils.c:1129)
==659==    by 0x1DCBA7: DDCModeFromDetailedTiming (xf86EdidModes.c:583)
==659==    by 0x1DCBA7: handle_detailed_modes (xf86EdidModes.c:1010)
==659==    by 0x1E91CF: xf86ForEachDetailedBlock (interpret_edid.c:247)
==659==    by 0x1DD10F: xf86DDCGetModes (xf86EdidModes.c:1066)
==659==    by 0x1DD2D4: xf86EdidMonitorSet (xf86EdidModes.c:1172)
==659==    by 0x1EAF63: xf86SetDDCproperties (ddcProperty.c:81)
==659==    by 0x9728257: amd_xserver116_xf86OutputSetEDID (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x8FA0EEC: amd_xf86OutputSetEDID (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x91E2638: atiddxDisplayMonitorCallbackDetect (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x972677D: amd_xserver116_xf86ProbeOutputModes (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x97307D2: xf86RandR12GetInfo12 (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659== 
==659== 307,824 bytes in 1,749 blocks are still reachable in loss record 471 of 473
==659==    at 0x4C2AD10: calloc (vg_replace_malloc.c:623)
==659==    by 0x2C5140: XNFcalloc (utils.c:1129)
==659==    by 0x1DB446: xf86GTFMode (xf86gtf.c:107)
==659==    by 0x1DCA11: DDCModesFromStandardTiming.isra.7 (xf86EdidModes.c:492)
==659==    by 0x1DD1A0: xf86DDCGetModes (xf86EdidModes.c:1074)
==659==    by 0x1DD2D4: xf86EdidMonitorSet (xf86EdidModes.c:1172)
==659==    by 0x1EAF63: xf86SetDDCproperties (ddcProperty.c:81)
==659==    by 0x9728257: amd_xserver116_xf86OutputSetEDID (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x8FA0EEC: amd_xf86OutputSetEDID (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x91E2638: atiddxDisplayMonitorCallbackDetect (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x972677D: amd_xserver116_xf86ProbeOutputModes (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x97307D2: xf86RandR12GetInfo12 (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659== 
==659== 410,432 bytes in 2,332 blocks are still reachable in loss record 472 of 473
==659==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==659==    by 0x2C5108: XNFalloc (utils.c:1113)
==659==    by 0x1DDAA2: xf86DuplicateMode (xf86Modes.c:218)
==659==    by 0x1DD16C: DDCModesFromEstablished (xf86EdidModes.c:307)
==659==    by 0x1DD16C: xf86DDCGetModes (xf86EdidModes.c:1070)
==659==    by 0x1DD2D4: xf86EdidMonitorSet (xf86EdidModes.c:1172)
==659==    by 0x1EAF63: xf86SetDDCproperties (ddcProperty.c:81)
==659==    by 0x9728257: amd_xserver116_xf86OutputSetEDID (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x8FA0EEC: amd_xf86OutputSetEDID (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x91E2638: atiddxDisplayMonitorCallbackDetect (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x972677D: amd_xserver116_xf86ProbeOutputModes (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x97307D2: xf86RandR12GetInfo12 (in /usr/lib/xorg/modules/drivers/fglrx_drv.so)
==659==    by 0x224D21: RRGetInfo (rrinfo.c:196)
==659== 

Regards
Comment 6 jorge_monteagudo 2017-02-21 09:16:27 UTC
Created attachment 129788 [details]
Xorg running under Valgrind log
Comment 7 Michel Dänzer 2017-02-22 07:08:25 UTC

*** This bug has been marked as a duplicate of bug 99521 ***


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.