<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Shared Memory queuing up in xlib backend for slow X Server 1.9.5"
href="https://bugs.freedesktop.org/show_bug.cgi?id=75524">75524</a>
</td>
</tr>
<tr>
<th>Assignee</th>
<td>chris@chris-wilson.co.uk
</td>
</tr>
<tr>
<th>Summary</th>
<td>Shared Memory queuing up in xlib backend for slow X Server 1.9.5
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>cairo-bugs@cairographics.org
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Reporter</th>
<td>kasberger@heidenhain.de
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86 (IA32)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>1.12.16
</td>
</tr>
<tr>
<th>Component</th>
<td>xlib backend
</td>
</tr>
<tr>
<th>Product</th>
<td>cairo
</td>
</tr></table>
<p>
<div>
<pre>I let run the gvncviewer (from library gtk-vnc) in fullscreen mode.
Under heavy load e.g. changing the complete screen content on vnc server side
every 0.01 secs gvncviewer starts queueing up memory in SHM. (See bottom of the
mail)
Queueing up means more and more shared memory segments are allocated by cairo
The problem lies in function _cairo_xlib_shm_info_create
It tries to find a empty space in current shm pool.
If this not happens it simply create a new shm segment.
This happens all the time so on my slow computer it accumulates approx 1 GB in
10 minutes
I assume if the X Server is too slow to get managed with a work load it blocks
the shared memory segments until it is done. But the xserver is much slower
than the cairo backend produces the load the shared memory is growing until out
of mem.
For verification i just added a sync(display) call before searching in shm pool
and the problem is gone.
Here a shortened example of pmap output of the process after running a while
08048000 20K r-xp /usr/bin/gvncviewer
0804d000 4K rw-p /usr/bin/gvncviewer
0804e000 656K rw-p [heap]
7c8e6000 196K rw-p [ anon ]
7c917000 32768K rw-s /SYSV00000000
7e917000 196K rw-p [ anon ]
7e948000 32768K rw-s /SYSV00000000
80948000 196K rw-p [ anon ]
80979000 32768K rw-s /SYSV00000000
82979000 196K rw-p [ anon ]
829aa000 32768K rw-s /SYSV00000000
849aa000 196K rw-p [ anon ]
849db000 32768K rw-s /SYSV00000000
869db000 196K rw-p [ anon ]
86a0c000 32768K rw-s /SYSV00000000
88a0c000 196K rw-p [ anon ]
88a3d000 32768K rw-s /SYSV00000000
8aa3d000 196K rw-p [ anon ]
8aa6e000 32768K rw-s /SYSV00000000
8ca6e000 196K rw-p [ anon ]
8ca9f000 32768K rw-s /SYSV00000000
8ea9f000 196K rw-p [ anon ]
8ead0000 32768K rw-s /SYSV00000000
90ad0000 196K rw-p [ anon ]
90b01000 32768K rw-s /SYSV00000000
92b01000 196K rw-p [ anon ]
92b32000 32768K rw-s /SYSV00000000
94b32000 196K rw-p [ anon ]
94b63000 32768K rw-s /SYSV00000000
96b63000 196K rw-p [ anon ]
96b94000 32768K rw-s /SYSV00000000
98b94000 196K rw-p [ anon ]
98bc5000 32768K rw-s /SYSV00000000
9abc5000 196K rw-p [ anon ]
9abf6000 32768K rw-s /SYSV00000000
9cbf6000 196K rw-p [ anon ]
9cc27000 32768K rw-s /SYSV00000000
9ec27000 196K rw-p [ anon ]
9ec58000 32768K rw-s /SYSV00000000
a0c58000 196K rw-p [ anon ]
a0c89000 32768K rw-s /SYSV00000000
a2c89000 196K rw-p [ anon ]
a2cba000 32768K rw-s /SYSV00000000
a4cba000 196K rw-p [ anon ]
a4ceb000 32768K rw-s /SYSV00000000
a6ceb000 196K rw-p [ anon ]
a6d1c000 32768K rw-s /SYSV00000000
a8d1c000 196K rw-p [ anon ]
a8d4d000 32768K rw-s /SYSV00000000
aad4d000 196K rw-p [ anon ]
aad7e000 32768K rw-s /SYSV00000000
acd7e000 196K rw-p [ anon ]
acdaf000 32768K rw-s /SYSV00000000
aedaf000 196K rw-p [ anon ]
aede0000 32768K rw-s /SYSV00000000
b0de0000 196K rw-p [ anon ]
b0e11000 32768K rw-s /SYSV00000000
b2e11000 5128K rw-p [ anon ]
......
.....
..
.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>