[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