Bizarre bug with a slot

I have a function which makes an XML request of a server to request the data for lookup tables. The server responds with an XML message of the data to insert into a local sqlite database.

On Linux, this all works perfectly.

On Windows, for some strange reason, the requestFinished signal of the QHttp object fires twice. I have checked, and neither time is it sending in an error code, and the id of the request is the id of the request that I have sent. I have verified that I am not making the request twice.

In my requestFinished handler, I create a QDomDocument of the received XML, and I fire off a signal to let another class know it can grab the resulting QDomDocument. The slot for that class loops through the document and inserts the data into a SQLIte database.

The really odd thing is that if I simply comment out the QSqlQuery exec line in this slot's function, the requestFinished signal doesn't fire a second time.

I have no idea what is going on here. If my slot for requestFinished doesn't return quickly enough, can it cause the signal to somehow fire again?

Could you prepare a minimal compilable example reproducing the problem?

Quote:

---

Originally Posted by wysota

Could you prepare a minimal compilable example reproducing the problem?

---

I'm trying, but I can't even reproduce it in other parts of the same codebase, much less in a pared-down app.

I keep thinking that maybe I'm attaching to the signal twice, but the only time it fires multiple times is if there's a delay (I replaced my insert statement with just a long sleep, and that caused the same effect)

Quote:

---

Originally Posted by wysota

Could you prepare a minimal compilable example reproducing the problem?

---

OK, after a bit of pain I managed to isolate the problem and produce a compilable example. Note that this bug actually *can* be reproduced under Linux even though I stated earlier that it cannot. You simply have to change the line _sleep(90000) with sleep(90) and this code will produce the same results under Linux.

Well.. this code doesn't compile. It complains _sleep() is undefined. Anyway don't take it personal but sleeping in a slot is a really stupid idea :) And I can imagine some failsafe mechanism kicks in and emits a signal for the second time because of a timeout or something.

Quote:

---

Originally Posted by wysota

Well.. this code doesn't compile. It complains _sleep() is undefined. Anyway don't take it personal but sleeping in a slot is a really stupid idea :) And I can imagine some failsafe mechanism kicks in and emits a signal for the second time because of a timeout or something.

---

Regarding compilation, Note my earlier explanation that under Linux you have to remove the "_" from the sleep function and change the argument from microsectonds to seconds.

At any rate, the sleep is only there to reproduce the bug :)

In the actual code, I am taking the XML I received and inserting into a local SQLite database. The insert loop is taking about a minute or so, and that is where I run into this bug.

If I have an expensive operation to perform as the result of an HTTP request, where else can I execute my code other than in the callback slot? I really don't think re-firing the signal is desirable behavior from the signal/slot mechanism...Is this re-firing documented behavior?

Quote:

---

Originally Posted by hardgeus

At any rate, the sleep is only there to reproduce the bug :)

In the actual code, I am taking the XML I received and inserting into a local SQLite database. The insert loop is taking about a minute or so, and that is where I run into this bug.

---

So make it last a second or don't insert into the database as a reaction to a timer-based signal. Post an event or use a 0 timeout timer to trigger a deffered call.

Quote:

---

If I have an expensive operation to perform as the result of an HTTP request, where else can I execute my code other than in the callback slot? I really don't think re-firing the signal is desirable behavior from the signal/slot mechanism...Is this re-firing documented behavior?

---

It's not the same signal. It might be a signal related to timing out something. Anyway I'm just guessing here. Move the query elsewhere and your problem will go away. Otherwise closely examine the second signal to see if it is a copy of the first one.