[cc'ing jackit-devel for technical bit]
On Wednesday 08 Nov 2006 01:09, Lars Luthman wrote:
> From the jackd manual:
>
> -u, --unlock
> Unlock libraries GTK+, QT, FLTK, Wine.
>
> This means that even if you are running jackd in realtime mode (and thus
> locking all memory of the clients into physical RAM), the actual code
> from the GTK+, Qt, FLTK, and Wine libraries will be recognised and
> unlocked (if the clients link to those libraries) so the kernel can swap
> it to disk if it wants.
That reminds me -- this option doesn't seem to work any more for me, as the
format of /proc/<pid>/maps appears to have changed slightly since the code
was written. A patch to libjack/client.c is attached below.
I don't pretend to understand the format of the maps file, but there's an
assumption in the original client.c that any line in the file such as
b58db000-b60da000 rwxp b58db000 00:00 0
that has 0 as its final numeric field, will have no further text following
that 0. However, on this machine there are routinely several lines like this
0804e000-08070000 rwxp 0804e000 00:00 0 [heap]
with additional text. When one of those is encountered, the zero is read into
the aptly named "whoknows" variable, the loop continues, the following
iteration's fscanf (which is intended to read the next line) fails as it gets
the spare text as input instead, and parsing ends. This patch just pulls the
fscanf for the path field up a few lines, so it can eat any spare text that
may be present before moving on to the next line. It should be backward
compatible.
I've only tested this against one kernel so far, and it's not a very new one
(2.6.13-something).
Chris
--- unlock.c.orig 2006-11-08 11:15:20.000000000 +0000
+++ unlock.c 2006-11-08 11:16:27.000000000 +0000
@@ -78,12 +78,12 @@
break;
}
+ fscanf (map, " %[^\n]", path);
+
if (!whoknows) {
continue;
}
- fscanf (map, " %[^\n]", path);
-
/* if it doesn't look like a library, forget it */
looks_like_library = 0;
