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.
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.
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.
*** 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.