[PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

Lubomir I. Ivanov neolit123 at gmail.com
Mon Apr 17 12:01:48 PDT 2017

On 17 April 2017 at 21:04, Stefan Fuchs <sfuchs at gmx.de> wrote:
> Hello Lubomir, hello All,
> Am 09.04.2017 um 22:15 schrieb Lubomir I. Ivanov:
> I applied the patch, continued testing and now have new results:
> I don't have a "zombie" Subsurface.exe any more every ~10th startup but I
> see a "real" crash. Call stacks of two occurrences attached. I guess what

hello, something isn't right here.

0420BBA8 00000020 00000001 5B92FCC8  Qt5Cored.dll! ??
@ 217]
04038406 5A913E94 5AAADBD8 0427600A  Qt5Cored.dll! ??
@ 158]
22E78B1F 00000001 5AA22CA8 00000006  libssrfmarblewidgetd.dll!run
@ 138]

Marble's FileLoader does a:
mDebug() << "starting parser for" << d->m_filepath;

MarbleDebug does returns this for mDebug(), post applying the patch
and if MarbleDebug::m_enabled() == false:
static QFile *nullDevice = new QFile(QProcess::nullDevice());
if ( !nullDevice->isOpen() )
return QDebug( nullDevice );

qdebug.cpp @ 158 is the destructor for the QDebug object in 5.7.

it asserts releasing a "stream" object, because the size of it's ring
buffer is 0. this should not happen.
the destructor seems to be called because the object is going out of
scope (maybe?). i don't understand why the stream is being released
maybe that's caused by the concurrency issues you've reported earlier.

your best bet is to change the function to this:

QDebug mDebug()
    return QDebug( QtDebugMsg ); // or "return qDebug();"

which will essentially enable debug output for everything in Marble,
until we write a dummy Class with an overloaded << operator to void
all the incoming debug calls.


More information about the subsurface mailing list