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