Bug 2524

Summary: Allocating too much pixmap memory hangs system
Product: xorg Reporter: Karl Schultz <Karl.W.Schultz>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED DUPLICATE QA Contact:
Severity: enhancement    
Priority: low    
Version: 6.7.0   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Karl Schultz 2005-02-11 10:35:26 UTC 
Seen on Fedora Core 2 X server.

If an application allocates too much pixmap memory via XCreatePixmap, the 
system starts paging and effectively hangs, requiring a system power-off and 
reboot.

My guess is that the X server allocates pixmaps in system memory, either all 
the time or after video memory is exhausted.  It continues to do so until 
malloc() fails when virual memory is exhausted.  After physical RAM is 
exhausted the pixmap creations cause heavy paging.  With the X server probably 
running at a higher priority than other user processes, the system gets 
extremely sluggish or hangs to the point where it needs to be restarted by 
powering off.

The requested enhancement is to have the server fail XCreatePixmap requests 
with BadAlloc before this hanging condition is reached.  As it may be 
difficult to determine when this happens, consider a configuation file 
parameter where a user or sysadmin may set a "maximum pixmap memory limit", 
based on user preferences and system capabilities (i.e. real memory).  The 
default behavior would be to act as it does today.  The user/sysadmin would 
add the config file param after growing tired of power-down restarts.

I realize that an application should just "not do that", and impose its own 
limits on pixmap allocation.  But this sort of enhancement would help prevent 
the unusally harsh punishment of a power-down reboot.
Comment 1 Adam Jackson 2005-02-12 09:30:17 UTC 
many operating systems lie about malloc success on the assumption that not all memory is used 
immediately, that the storage can be done on the fly with the pagefault handler, and that it conserves 
memory overall leading to better performance.  so such an option might not even work.

in addition this limit would need to be quite high, since quite a few applications do highly stupid things 
with their pixmap usage.  gecko browsers for example use tons of pixmaps and pretty much never free 
them.
Comment 2 Karl Schultz 2005-02-14 16:10:09 UTC 
Yes, I agree and understand about the behavior of malloc on many systems.

There still may be value in implementing an *optional* upper bound on the 
amount of pixmap storage the server can allocate.  The server can do this 
simply by keeping track of the create and destroy requests, also accounting 
for pixmaps that get destroyed when client connections drop.  The behavior of 
malloc plays no part in this tracking of pixmap storage.

The point is to give the user an alternative to allowing a client to 
completely hang the server by simply allocating pixmaps until it hangs.  Yes, 
it is the application's fault for doing this, but it is better to simply fail 
the create pixmap request so that the application can at least recover and 
prevent the lost work due to a hang that requires pulling the plug.

I know that this request is a bit close to the edge between server stability 
and application responsibility, since any app can cause this sort of resource 
usage problem.  But since the server often runs at a higher priority and needs 
to be stable, it is more than some other app or client that has run amuck.  
And this seems to be a reasonable safety measure to keep the server stable at 
the possible inconvenience of figuring out the right value to use for the 
upper limit.
Comment 3 Adam Jackson 2005-11-12 14:10:18 UTC 

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

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.