[Qt-interest] QDebugStream quit working with Qt 4.8.0-rc1 and new compiler

[Thiago Macieira]

On Sunday, 30 de October de 2011 20:26:31 K. Frank wrote:
> > And I'd also say that testing gcc 4.7.0 on a more "supported" platform
> > like
> > Linux would be recommended. (supported by GCC developers)
> 
> Yes, this is certainly a worthwhile suggestion.  Unfortunately, I don't
> currently have access to a linux platform.

Let me put it this way: whenever someone on IRC comes with a problem that 
looks to me like memory error, I ask them to run valgrind. Regardless of 
operating system they're in.

And yes, there's no Valgrind for Windows.

> > When I tried to build Qt with gcc 4.6.0 on Windows (mingw), I had to apply
> > patches to make it work.
> 
> I will note that my build of Qt 4.8.0-rc1 with the 64-bit mingw-w64 4.7.0
> compiler went altogether quite smoothly.  (I had to patch the compiler's
> pthread.h in order to get qdatetime.cpp to compile.  Also, starting the
> build with about 2 GB of memory free led to a "Memory exhausted" error.
> Re-running the build with 3 GB free succeeded.  One very minor patch
> to qwt, to fix a 32-bit --> 64-bit issue, was also required.)

That's good to know. I wasn't so lucky with my gcc 4.6.0 mingw installation.

> Well, that's part of the reason I included the QDebugStream code in my
> post.  The code is small and pretty simple.  When I look at it, it looks
> correct, but I could easily be overlooking something.  It only uses Qt by
> way of QTextEdit, which is uses very simply, and, as far as I can see,
> not in any undocumented way.  It uses iostream's basic_streambuf,
> which I'm no expert on, but again, as far as I can tell, it's using it
> correctly.

Well, I'd guess most developers on this mailing list are not experts in 
iostream either.

> For example, it looks like there's a certain amount of usage of QDebugStream
> in the community -- not just me.  Perhaps someone has used it successfully
> with the 4.7.0 compiler, or perhaps with Qt 4.8.0-rc1.  Or perhaps someone
> has seen problems similar to what I see.

I don't have any experience with QDebugStream nor anything other than basic 
experience with iostream. But I can offer some insight into what I'd do if I 
were faced with this problem:

The first thing to note is that you have too many variables to deal with. You 
have a new, unreleased and unsupported compiler, running with a release 
candidate of Qt and an unsupported class found on a post on a mailing list. So 
the bug may be in any one of:

 - gcc 4.7 code generation
 - gcc 4.7's iostream classes
 - mingw's build of gcc 4.7
 - QTextEdit in Qt 4.8
 - QDebugStream

So you have to change those variables so as to isolate where precisely the 
problem may be. What I'd do first is to find the latest combination of released 
Qt with supported GCC that still worked with QDebugStream.  I would use Linux, 
Qt 4.7.4, gcc 4.6.1, but let's say you can do that on Windows.

After that, change one variable only: try upgrading to Qt 4.8.0-rc1. If that 
breaks, it's likely the bug is in Qt. If it still works, it has to be in one 
of the four other variables.

At this point, whichever way you go, you need to break up QDebugStream into 
the function calls you expect, either to iostream or to QTextEdit. Since no 
one supports QDebugStream, you cannot report an issue against it: you need to 
remove it *completely* from the codebase. Leave only the side-effects.

The difference is which side-effects: if the bug is likely in Qt, make a 
testcase using QTextEdit only, with NO iostream #includes. If the bug is 
likely in GCC, make sure you have NO Qt #includes.

Now, I have no experience reporting bugs to GCC developers containing problems 
with STL, but when it comes to Qt, even the tool classes, we have to make it a 
no-#include testcase. I guess what you'll need to do here is decide whether 
the bug is in the code generation or in the library. The best way would be to 
use GCC 4.6's headers in GCC 4.7, because that fixes one variable while the 
other changes, but I am not sure if the headers compile with different GCC 
versions than the one intended. Another way is to verify if there's any 
optimisation level that changes the pass/fail status, but it's not a guarantee 
(there might be undefined behaviour code in the library).

If you conclude it's a code generation error, you need to reduce it to a very, 
very small testcase, possibly with no #includes at all. If you cannot conclude 
that, then I guess you need to report the smallest testcase possible while 
still using the iostream headers.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20111031/8365a076/attachment.bin