valgrind warning in Qt

[vitaly]

I use Qt 3.3.2, gcc 3.3.3. I wrote simple xml parsing test.

#include <qxml.h>
 
int main( int argc, char** argv)
{
    QString s = "<xml></xml>";
 
    QXmlInputSource input;
    input.setData(s);
 
    QXmlSimpleReader reader;
    if (!reader.parse(&input, FALSE))
        return 1;
 
    return 0;
}

#include <qxml.h>

int main( int argc, char** argv)
{
    QString s = "<xml></xml>";

    QXmlInputSource input;
    input.setData(s);

    QXmlSimpleReader reader;
    if (!reader.parse(&input, FALSE))
        return 1;

    return 0;
}

To copy to clipboard, switch view to plain text mode 

If to compile this test and run under valgrind the following warning will be shown:

==10134== Conditional jump or move depends on uninitialised value(s)
==10134== at 0x446B9CE: QXmlSimpleReader:arseElement() (in /usr/local/qt-3.3.2-3.3.3/lib/libqt-mt.so.3.3.2)
==10134== by 0x446B200: QXmlSimpleReader:arseBeginOrContinue(int, bool) (in /usr/local/qt-3.3.2-3.3.3/lib/libqt-mt.so.3.3.2)
==10134== by 0x446AEE1: QXmlSimpleReader:arse(QXmlInputSource const*, bool) (in /usr/local/qt-3.3.2-3.3.3/lib/libqt-mt.so.3.3.2)
==10134== by 0x8048D52: main (main.cpp:<this line number points to reader.parse(..) string)

Is it Qt bug and how to avoid it?

Thanks,
Vitaly

[jpn]

If to compile this test and run under valgrind the following warning will be shown:

==10134== Conditional jump or move depends on uninitialised value(s)
==10134== at 0x446B9CE: QXmlSimpleReader:arseElement() (in /usr/local/qt-3.3.2-3.3.3/lib/libqt-mt.so.3.3.2)
==10134== by 0x446B200: QXmlSimpleReader:arseBeginOrContinue(int, bool) (in /usr/local/qt-3.3.2-3.3.3/lib/libqt-mt.so.3.3.2)
==10134== by 0x446AEE1: QXmlSimpleReader:arse(QXmlInputSource const*, bool) (in /usr/local/qt-3.3.2-3.3.3/lib/libqt-mt.so.3.3.2)
==10134== by 0x8048D52: main (main.cpp:<this line number points to reader.parse(..) string)

Is it Qt bug and how to avoid it?

There's not much you can do about it, unless you stab the QXmlSimpleReader sources. Valgrind just doesn't like the way it is written..

[Mad Max]

You can use valgrind's options "gen-suppressions" and "suppressions" to suppress any errors which are not interesting for you.

# valgrind --gen-suppressions=yes ./app
# valgrind --suppressions=suppressions.err ./app

# valgrind --gen-suppressions=yes ./app
# valgrind --suppressions=suppressions.err ./app

To copy to clipboard, switch view to plain text mode 

[vitaly]

Thanks for reply!

My project has only this Valgrind warning at the moment. But our QA group doesn't like it. They suspect me of making a bug. I thought to investigate the problem but it may need much timе. With high probability (and with your help in answering me, of course) I suspect Qt in this warning, so I will demonstrate our QA that it is not my "bug" by presenting the test described above.

Thanks a lot
Vitaly

[wysota]

It's not really a bug. Valgrind is too stupid to guess from the context that the variable will be initialised. Take this example:

int i;
if(something){
  i=7;
}
if(!something){
 i=5;
}
if(i==5){
// ...
} else {
// ...
}

int i;
if(something){
  i=7;
}
if(!something){
 i=5;
}
if(i==5){
// ...
} else {
// ...
}

To copy to clipboard, switch view to plain text mode 

Now from machine's point of view, i may be uninitialised during "if(i==5)" test, but based on the context you'll notice that i will always be initialised, either as 7 or as 5. So there's no bug here. And this could and probably is the same case with the xml parser.