QUrlOperator doesn't emit finished signal

[hayati]

right it's v3.3.6

and v3.3.3 gives the same result

[jacek]

right it's v3.3.6

and v3.3.3 gives the same result

Try Qt 3.3.8. There was some problem with QDns fixed. On my system finished() is always emitted, but the application crashes after a while (it has something to do with event delivery).

[hayati]

thanks for the reply,
yes it's obvious that it has some problems internally.
unfortunately i can't use v3.3.8
even so, as you said it gets errors with internal SIGSEGV errors.
I'll use libcurl library for that purpose for now
thanks for help.

[jacek]

even so, as you said it gets errors with internal SIGSEGV errors.

I didn't say that they are internal errors.

[hayati]

yes you didn't say, sorry about misunderstanding.
I'm confused because i get SIGSEGV after my last try to fix the problem
That's why i said SIGSEGV, it's what i get, not yours.
If it's undertood like yours i apologize

Another amazing thing about the QUrlOperator is;
I placed a single-shot timer as error-interval. When timer is up then even if i don't get finished signal i delete the opened widget, at the destructor i stop m_op, and delete it.
But this time i got SIGSEGV.
In addition, gdb stack trace points out qsocket caused the SIGSEGV.
that's why i said -INTERNAL- error.
I think I get SIGSEGV because m_op opened a QSocket internally but after i delete m_op then m_op deletes QSocket and when system is about to use to deleted socket then SIGSEGV occurs. (just an estimation)
By the way that's not the point of the problem.

Problem is QUrlOperator doesn't emit finished signals after a while

[jacek]

But this time i got SIGSEGV.

Such fault can occur when you delete an object within event handler and it's usually solved using QObject::deleteLater().

Problem is QUrlOperator doesn't emit finished signals after a while

It looks like this problem doesn't occur on Qt 3.3.8. Try the narrowed-down example from the attachment.

[hayati]

Thanks for your quick replys. I really appreciated.
I couldn't answer your replys for a while because i got cold.
Unfortunately even v3.3.8 with your test code(main.cpp) fails when id is over 400.
After id value of 400, program didn't received any finished signal at all
Perharps you didn't wait as much as program starts failing
Because we don't know what is wrong and when the program starts failing best of best of us is to wait for ten minutes at least.
I am sure that my application uses v3.3.8 because i checked it with qVersion() within your test code.

[jacek]

Unfortunately even v3.3.8 with your test code(main.cpp) fails when id is over 400.
After id value of 400, program didn't received any finished signal at all

I've just tried it again and reached id = 1500 without any signs of failure.

I can't run Valgrind on my system, so I can't check whether the are any problems inside Qt, but try this:

Test() : _id( _nextId++ )
{
   std::cerr << "created " << _id << std::endl;
   _op = new QUrlOperator("http://test.domain.tld/");
 
   if( _op != 0 ) {
      connect( _op, SIGNAL(finished(QNetworkOperation*)), SLOT(finished()) );
      if( _op->get() == 0 ) {
         std::cerr << "get() failed " << _id << std::endl;
         deleteLater();
      }
   }
   else {
      std::cerr << "allocation failed " << _id << std::endl;
      deleteLater();
   }
}

Test() : _id( _nextId++ )
{
   std::cerr << "created " << _id << std::endl;
   _op = new QUrlOperator("http://test.domain.tld/");

   if( _op != 0 ) {
      connect( _op, SIGNAL(finished(QNetworkOperation*)), SLOT(finished()) );
      if( _op->get() == 0 ) {
         std::cerr << "get() failed " << _id << std::endl;
         deleteLater();
      }
   }
   else {
      std::cerr << "allocation failed " << _id << std::endl;
      deleteLater();
   }
}

To copy to clipboard, switch view to plain text mode 

[hayati]

It's about something different.
I tested main.cpp in my home network then it's like just you mentioned.
So it works perfectly even with v3.3.6 at my home. But what's missing with my job network or what's more.
My home network is very little it has three pc so name resolution could be very fast.
But my job network is quite big (and more will be- over 400 pc).
It has a heavy multicast traffic also. (But I don't think that's the problem) It must be something different. At first I thought it might be a protection from firewall or other network devices (just an estimation), but my network admin said it isn't.
But unfortunately I have no idea
By the way I started coding my own url class from curl.
Even if I know that qt has coded it more bugfree than me, I have no other chance to do now unless finding out the way to make it worked.

Thanks for your patience, because I give up counting at 1265 an I satisfied that it's something else

[jacek]

But my job network is quite big (and more will be- over 400 pc).
It has a heavy multicast traffic also.

Then it might be some subtle bug that might possibly have something to do with timeouts. You can try contacting Trolltech and ask whether they can do something about it.