QDataStream corruption (testcase provided)

We have a custom datatype (called Message) that we routinely serialize via QDataStream into a QByteArray to transmit it over the wire and unpack it on the other end. With one particular dataset (possibly others, but overall only a few cases), we experience corruption in the process: when loading from the QByteArray, QBuffer complains about an illegal seek, and we end up with a corrupted list. We have reduced this to a testcase loading this particular dataset showing the issue.

The following happens:

• We load 140 Message objects from the provided .ini file
• All the individual Message objects serialize and unserialize fine, the QByteArray is fully read, the source and restored Message objects are identical
• Adding all the Message objects into a QVariantList, the QVariantList as a whole serializes and unserializes fine
• Putting this QVariantList into a QVariant: serializing and unserializing leads to corrupt data. This step (encapsulating the list in a QVariant) seems to be necessary to trigger the issue
• Using only the first 137 elements of the list, serialization works fine
• Using at least the first 138, serialization breaks
• Other combinations (e.g. using elements 100-140) seem to work. In a larger dataset, we found various ranges that would break, but larger or smaller ranges containing some or all of the objects then work again, so we can't pinpoint this to a particular Message object. It seems to be particular combinations that trigger the issue

The provided testcase demonstrates this (testcase code is in main.cpp). Note that we had to add a few files from our project that handle the custom datatypes we need to demonstrate the issue. The provided code for those should be quite straightforward. Running the testcase with a recent version of Qt 4.7 should produce a QBuffer warning. Outputting the resulting QVariantList should show garbage data at the end.

The issue started recently (about a week ago) in the public 4.7 branch. I have found a good and a bad revision and tried to bisect, but unfortunately I couldn't compile a lot of the revisions in between, so I wasn't able to find the faulty commit. The provided bisect.out file contains a list of about 80 candidate revisions for introducing this bug, as well as a good revision for bisection start.

Plesae feel free to contact me about further information. Thanks!