I'm sorry it has taken a little while to get back to you. On Sat, Dec 18, 2004 at 04:02:32PM +0200, Gintautas Miliauskas wrote: [...] > > Option "XaaNoPixmapCache" [...] > > Option "XaaNoOffscreenPixmaps" [...] > I added both of these to the "Device" section, didn't change anything. > I also tried to add them to the "Screen" section (as the manual says), > without any difference either. Bummer. > Taking this a step further, I completely disabled XAA (Option "Accel" > "off"). It did wonders to slowing my system to a crawl, yet gpdf would > still hoard memory, which means that the problem has not gone away. Okay. > I presume that these results do not go well with your hypothesis? No, they pretty much blow it away. :) > Is there anything else I can do to at least help find out which part of X > is the culprit? This bug is really a PITA for me (I even made a tiny > cron script that mails me if X takes up more than 80MB (resident); it > takes about two days to reach that threshold). Well, you could try using a different X display driver. There are two possibilities: 1) vesa 2) fbdev The former may not work at all -- it seems to be kind of touch-and-go. The latter requires that your kernel be compiled with fbcon support, and be booted that way. If you can reproduce your resource leak problems with either or both of these drivers, then I strongly suspect a problem in the hardware-neutral parts of the XFree86 DDX implementation (which I think is mostly stubs), or the DIX portion. Thanks for your indulgence with my proposed experiments, and I'm sorry they did not mitigate or rectify the issue. -- G. Branden Robinson | To Republicans, limited government Debian GNU/Linux | means not assisting people they branden@debian.org | would sooner see shoveled into mass http://people.debian.org/~branden/ | graves. -- Kenneth R. Kahn
Attachment:
signature.asc
Description: Digital signature