[Qt-interest] Problem with Qt QWS font bitmap caching among multiple processes.
Atlant Schmidt
aschmidt at dekaresearch.com
Tue Mar 22 20:52:47 CET 2011
Folks:
I've now created a fix for this problem. Here's the affected routine in the
gui/text/qfontengine_qpf.cpp file. The added text (shown in
bolded green) is the fix along with some added debug information:
void QFontEngineQPF::ensureGlyphsLoaded(const QGlyphLayout &glyphs)
{
if (readOnly)
return;
quint32 * blockSizePtr = (quint32 *)(fontData + glyphDataOffset - 4);
if (glyphDataSize != *blockSizePtr) {
#if defined(DEBUG_FONTENGINE)
qDebug() << "QFontEngine::ensureGlyphsLoaded() glyphDataSize member ("
<< glyphDataSize
<< ") mismatches file value ("
<< *blockSizePtr
<< ")";
#endif
remapFontData();
}
bool locked = false;
for (int i = 0; i < glyphs.numGlyphs; ++i) {
if (!glyphs.glyphs[i])
continue;
const Glyph *g = findGlyph(glyphs.glyphs[i]);
if (g)
continue;
if (!locked) {
if (!lockFile())
return;
locked = true;
g = findGlyph(glyphs.glyphs[i]);
if (g)
continue;
}
loadGlyph(glyphs.glyphs[i]);
}
if (locked) {
unlockFile();
#if defined(DEBUG_FONTENGINE)
qDebug() << "Finished rendering glyphs\n";
#endif
}
}
Essentially, the fix just compares the glyphDataSize stored in the class member
variable and the equivalent value stored in the .qsf file and forces a remap if they
differ*. That ensures that each process using the .qsf file always keeps its
mmap()ed window updated to the latest size stored in the file.
If anyone sees an error in my diagnosis or a problem with my fix, please let
me know!
As far as I can see, this bug is still present in Qt 4.7.2. Someone who knows
how should fix it in the various source trees.
There are also five small bugs with the conditionally-compiled debug code,
four of which cause the compilation to fail:
343: qErrnoWarning("QFontEngineQPF: unable to open %s", encodedFileName.constData());
350: qWarning("QFontEngineQPF: insufficient access rights to %s", encodedFileName.constData());
362: qErrnoWarning(errno, "QFontEngineQPF: open() failed for %s", encodedFileName.constData());
375: qErrnoWarning(errno, "QFontEngineQPF: write() failed for %s", encodedFileName.constData());
1038**: qErrnoWarning(status, "QFontEngineQPF::remapFomrData: munmap failed!");
qErrnoWarning(status, "QFontEngineQPF::remapFontData: munmap failed!");
Atlant
* The loadGlyph() routine forces them to be the same size but of course
that only holds true for the process that holds that member; the equivalent
members in other instances of the class in other processes will still hold
their old value until a remap (or in-process glyph creation?) makes them
equal again.
* This is its line number in the 4.7.2 version of the file. The other four line
numbers are the same in both 4.6.2 and 4.7.2.
________________________________
From: qt-embedded-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com [mailto:qt-embedded-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com] On Behalf Of Atlant Schmidt
Sent: Thursday, March 17, 2011 16:33
To: qt-interest at qt.nokia.com; qt-embedded-interest at qt.nokia.com
Subject: [Qt-embedded-interest] Problem with Qt QWS font bitmap caching among multiple processes.
Folks:
We're having a problem with font corruption in our Qt / QWS / Embedded
Linux environment. We've diagnosed it, but haven't corrected it yet.
Executive summary:
We have multiple processes sharing a single QWS instance (as you'd
expect). They also share .qsf cached font bitmap files in the /tmp
directory. When Process A expands a cached bitmap file, Process B
may try to use one of the new characters (because it sees from the
QPF glyph index that the glyph has now been rendered) but Process B
hasn't yet expanded its mmap'ed window into the .qsf file. As a result,
Process B either copies garbage (if there's additional accessible
mmap'ed space immediately beyond that window) or SEGVs (if
there's no mapped space immediately beyond that window).
This is with Qt 4.6.2. (4.6.3 was current when we froze our specs but it
had a different font problems that I've previously mentioned here.)
Does anyone recognize this problem? And better yet, know of a patch
that fixes it? Or can say with certainty that it's fixed in a newer version
of Qt?
A few more details:
[cid:image001.gif at 01CBE8A9.30EC7130] [cid:image002.gif at 01CBE8A9.30EC7130]
Here's a "2" character in Luxi Sans 40-pixel bold font in both the
correct and typically-corrupted state. The grey stuff in the middle
of that "2" is actually the QPF2 header of the next .qsf file in
virtual memory. If you read the bytes of the grey stuff, the
printable bytes are:
"QPF2 ... Luxi Sans ... /usr/lib/fonts/luxisr.ttf".
Various characters in various fonts can get corrupted but it always
has to be a character whose position in the .qsf file causes it to
span two pages in virtual memory. Because we never get entire
characters corrupted, I'm supposing that Qt apparently does the
right thing (unmmaps and remmaps the file) if the starting address
of the character in the QPF2 glyph map is beyond the currently-
mapped memory; it only fouls up if the character starts in the
currently-mapped memory and "runs over" into memory that
doesn't belong to that .qsf file.
Atlant
________________________________
This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
Click here<https://www.mailcontrol.com/sr/aNDHzSr+FQDTndxI!oX7UpIe2cJSs1VgPG5qskqxV0xTTILgoqvsM!59pfr4pLHyvKFFx74AC6Q28mHCioHNDQ==> to report this email as spam.
________________________________
This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110322/b2724912/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2750 bytes
Desc: image001.gif
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110322/b2724912/attachment.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 3803 bytes
Desc: image002.gif
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110322/b2724912/attachment-0001.gif
More information about the Qt-interest-old
mailing list