On 23/02/17 06:46 AM, Chen, Xiaogang wrote: >> From: Michel Dänzer [mailto:[email protected]] >> >> Multiple calls to xf86EdidMonitorSet (which can be triggered e.g. by running >> xrandr) would potentially keep adding the same modes, causing the Monitor- >>> Modes list to keep growing larger and using up more memory. >> >> Fix this by calling xf86PruneDuplicateModes after adding the modes returned >> by xf86DDCGetModes. This removes any newly added modes which were >> already in the Monitor->Modes list before, but keeps new modes which weren't >> yet. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99521 >> Signed-off-by: Michel Dänzer <[email protected]> >> --- >> >> Xiaogang / Jorge, does this fix the memory leak you're seeing? >> > [XCHEN] Hi Michel: I tested your patch with same script I used before > (while true; do xrandr --verbose; done), the memory leak is still there. > Actually the xf86PruneDuplicateModes() is called before at > xf86DDCGetModes() which is called by xf86EdidMonitorSet().
xf86DDCGetModes only calls xf86PruneDuplicateModes for the list of modes it generates itself (note that xf86DDCGetModes isn't called only by xf86EdidMonitorSet). The xf86PruneDuplicateModes call added by my patch works on the combined Monitor->Modes list with the modes returned by xf86DDCGetModes appended. The question now is why that call doesn't actually eliminate the duplicate modes. > I think the point here is: why we need to have these "mode"? I do not > find these "mode" got used afterword. grep the tree for '->Modes'. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
