QNAM pipelined HTTP requests receive data from another request that has been aborted

This was observed in QtLocation – our tile fetcher uses QNAM to download map tiles from servers. Sometimes (under particularly high load), a request that has been aborted (sometimes even one that hasn't been aborted at all, too) will have its data end up in another request. The transposition of data only occurs when pipelining is enabled. When no requests are aborted during the timeframe of interest, the transposition does not occur.

Attached is a simple application that reads from a "tracefile" containing a list of tile fetch/abort events generated by our actual mapping code and passes these requests with the necessary timing into QNAM. The bug is very timing sensitive. The app carries out the stimulus once without pipelining, and once with pipelining, and compares the results using the MD5 sums of the tile data received. Two "tracefile"s are included – one that is a full dump of a session with our mapping example app which has a number of instances of this bug in it ("tracefile.full") – and one that is a more minimal test case which exhibits the bug with approx 90-95% reliability on my machine ("tracefile").

The output that indicates the bug:

$ qmake && make
...
$ ./pipelinebug 
loaded 200 events
loaded 200 events
start trace with pipeline false 
start trace with pipeline true 
check...
tile mismatch: 8 240 148
tile mismatch: 8 232 145
tile mismatch: 8 240 150
compared 138 tiles

Output where the bug has not occurred shows no "tile mismatch:" lines after "check...". Note that the 200-event subset in "tracefile" does not produce the bug with 100% reliability (about 90-95% has been observed over a few hundred trials).