Ticket #254 (new defect)

Opened 18 months ago

Last modified 4 months ago

Vidalia process using 100% of CPU cycles

Reported by: vidalia Owned by: developer
Priority: critical Milestone:
Component: Vidalia Version: 0.0.12
Keywords: Maximum CPU usage Cc: ttag@…

Description

Hi Vidalia support,

Could you help us please with this weird problem. Without the added Sleep calls below, we see the Vidalia process use up 100% of the CPU cycles. With the sleep calls, everything seems normal. Any ideas?

The machine this happens on is a Panasonic CF-W2 running XP Pro SP2

Thanks, Tarek and Steve at Ironkey

void QAbstractSocketPrivate::_q_connectToNextAddress() {

Q_Q(QAbstractSocket); do {

// Check for more pending addresses if (addresses.isEmpty()) {

#if defined(QABSTRACTSOCKET_DEBUG)

qDebug("QAbstractSocketPrivate::_q_connectToNextAddress(), all addresses failed.");

#endif

state = QAbstractSocket::UnconnectedState?; if (socketEngine) {

if ((socketEngine->error() == QAbstractSocket::UnknownSocketError?

#ifdef Q_OS_AIX

// On AIX, the second connect call will result in EINVAL and not // ECONNECTIONREFUSED; although the meaning is the same.

socketEngine->error() == QAbstractSocket::UnsupportedSocketOperationError?

#endif

) && socketEngine->state() == QAbstractSocket::ConnectingState?) { socketError = QAbstractSocket::ConnectionRefusedError?; q->setErrorString(QLatin1String(QT_TRANSLATE_NOOP("QAbstractSocket",

"Connection refused")));

} else {

socketError = socketEngine->error(); q->setErrorString(socketEngine->errorString());

}

} else {

socketError = QAbstractSocket::ConnectionRefusedError?; q->setErrorString(QLatin1String(QT_TRANSLATE_NOOP("QAbstractSocket",

"Connection refused")));

} emit q->stateChanged(state); emit q->error(QAbstractSocket::ConnectionRefusedError?); return;

}

// Pick the first host address candidate host = addresses.takeFirst();

#if defined(QABSTRACTSOCKET_DEBUG)

qDebug("QAbstractSocketPrivate::_q_connectToNextAddress(), connecting to %s:%i",

host.toString().toLatin1().constData(), port);

#endif

#if defined(QT_NO_IPV6)

if (host.protocol() == QAbstractSocket::IPv6Protocol) {

// If we have no IPv6 support, then we will not be able to // connect. So we just pretend we didn't see this address. continue;

}

#endif

if (!initSocketLayer(host, q->socketType())) {

// hope that the next address is better continue;

}

// Tries to connect to the address. If it succeeds immediately // (localhost address on BSD or any UDP connect), emit // connected() and return. if (socketEngine->connectToHost(host, port)) {

fetchConnectionParameters(); return;

}

// Check that we're in delayed connection state. If not, try // the next address if (socketEngine->state() != QAbstractSocket::ConnectingState?) {

#if defined(QABSTRACTSOCKET_DEBUG)

qDebug("QAbstractSocketPrivate::_q_connectToNextAddress(), connection failed (%s)",

socketEngine->errorString().toLatin1().constData());

#endif

continue;

}

// Start the connect timer.

/* IK Added stuff...starts here....*/

if(oneOff <= 0) {

Sleep( 1750 ); oneOff++; }

Sleep( 250 );

/* IK Added stuff...ends here......*/

if (threadData->eventDispatcher) {

if (!connectTimer) {

connectTimer = new QTimer(q); QObject::connect(connectTimer, SIGNAL(timeout()),

q, SLOT(_q_abortConnectionAttempt()));

} connectTimer->start(QT_CONNECT_TIMEOUT);

}

// Wait for a write notification that will eventually call // _q_testConnection(). socketEngine->setWriteNotificationEnabled(true); break;

} while (state != QAbstractSocket::ConnectedState?);

}

Attachments

bt-1.jpg (97.9 kB) - added by edmanm 18 months ago.
bt-2.jpg (95.8 kB) - added by edmanm 18 months ago.
Procexp.txt (4.1 kB) - added by vidalia 14 months ago.

Change History

Changed 18 months ago by edmanm

Changed 18 months ago by edmanm

  Changed 16 months ago by edmanm

As an update on this bug for those following along, Tarek Tag from IronKey? has been able to narrow this bug down to Qt getting stuck on a call to WSASelect() whenever we call QAbstractSocket::waitForConnected(), which happens in net_test_connect() (where we test if Tor has a control port open already), and ControlSocket::connect() (where we connect to Tor's control port). I'm working on a workaround patch to simply avoid ever calling QAbstractSocket::waitForConnected().

Thanks to the IronKey? folks for helping track this down. I will update this ticket again when I get the patch committed, and hopefully the IronKey? folks can give it a try and see if it fixes the problem since they seem to be able to reliably reproduce this bug.

  Changed 16 months ago by vidalia

What's the status of this?

In my case this problem occurs only when downloading large files. 10-15 files of about 1 MB each is enough to trigger the problem. I don't quite understand the technical stuff referred to above.

B.T.W.: I'm another user... (not from Ironkey)

  Changed 16 months ago by edmanm

Um. The status hasn't changed in the 6 hours between my original comment and yours (note the timestamps on the ticket comments).

If this only happens for you when you're downloading large files through Tor, then it is likely not the same thing. The bug referenced in this ticket occurs whenever Vidalia tests whether Tor is already running or when connecting to Tor's control port, as mentioned above.

  Changed 16 months ago by edmanm

  • milestone set to Vidalia 0.0.14

  Changed 16 months ago by vidalia

Excuse me. I hadn't notice the timestamps.

As I said I don't understand the technical stuff, so if you say it's another issue, I'll take your word for it. Can you make a new ticket of it then?

  Changed 15 months ago by vidalia

I have this same problem. It's better described in ticket 276, and I don't see how this is the same. I installed the bundle, and I never see the Vidalia tray icon. Privoxy tray icon is there, and TOR works, but no vidalia ever, and it's taking 100% CPU time. I've even re-installed Vidalia from it's installer, and no good. Same behviour. And this is under no file transfer at all. Mike ubermevans@…

in reply to: ↑ description   Changed 14 months ago by vidalia

Replying to vidalia:

Hi Vidalia support, Could you help us please with this weird problem. Without the added Sleep calls below, we see the Vidalia process use up 100% of the CPU cycles. With the sleep calls, everything seems normal. Any ideas? The machine this happens on is a Panasonic CF-W2 running XP Pro SP2 Thanks, Tarek and Steve at Ironkey void QAbstractSocketPrivate::_q_connectToNextAddress() { Q_Q(QAbstractSocket); do { // Check for more pending addresses if (addresses.isEmpty()) { #if defined(QABSTRACTSOCKET_DEBUG) qDebug("QAbstractSocketPrivate::_q_connectToNextAddress(), all addresses failed."); #endif state = QAbstractSocket::UnconnectedState?; if (socketEngine) { if ((socketEngine->error() == QAbstractSocket::UnknownSocketError? #ifdef Q_OS_AIX // On AIX, the second connect call will result in EINVAL and not // ECONNECTIONREFUSED; although the meaning is the same.

socketEngine->error() == QAbstractSocket::UnsupportedSocketOperationError? #endif ) && socketEngine->state() == QAbstractSocket::ConnectingState?) { socketError = QAbstractSocket::ConnectionRefusedError?; q->setErrorString(QLatin1String(QT_TRANSLATE_NOOP("QAbstractSocket", "Connection refused"))); } else { socketError = socketEngine->error(); q->setErrorString(socketEngine->errorString()); } } else { socketError = QAbstractSocket::ConnectionRefusedError?; q->setErrorString(QLatin1String(QT_TRANSLATE_NOOP("QAbstractSocket", "Connection refused"))); } emit q->stateChanged(state); emit q->error(QAbstractSocket::ConnectionRefusedError?); return; } // Pick the first host address candidate host = addresses.takeFirst(); #if defined(QABSTRACTSOCKET_DEBUG) qDebug("QAbstractSocketPrivate::_q_connectToNextAddress(), connecting to %s:%i", host.toString().toLatin1().constData(), port); #endif #if defined(QT_NO_IPV6) if (host.protocol() == QAbstractSocket::IPv6Protocol) { // If we have no IPv6 support, then we will not be able to // connect. So we just pretend we didn't see this address. continue; } #endif if (!initSocketLayer(host, q->socketType())) { // hope that the next address is better continue; } // Tries to connect to the address. If it succeeds immediately // (localhost address on BSD or any UDP connect), emit // connected() and return. if (socketEngine->connectToHost(host, port)) { fetchConnectionParameters(); return; } // Check that we're in delayed connection state. If not, try // the next address if (socketEngine->state() != QAbstractSocket::ConnectingState?) { #if defined(QABSTRACTSOCKET_DEBUG) qDebug("QAbstractSocketPrivate::_q_connectToNextAddress(), connection failed (%s)", socketEngine->errorString().toLatin1().constData()); #endif continue; } // Start the connect timer. /* IK Added stuff...starts here....*/ if(oneOff <= 0) { Sleep( 1750 ); oneOff++; } Sleep( 250 ); /* IK Added stuff...ends here......*/ if (threadData->eventDispatcher) { if (!connectTimer) { connectTimer = new QTimer(q); QObject::connect(connectTimer, SIGNAL(timeout()), q, SLOT(_q_abortConnectionAttempt())); } connectTimer->start(QT_CONNECT_TIMEOUT); } // Wait for a write notification that will eventually call // _q_testConnection(). socketEngine->setWriteNotificationEnabled(true); break; } while (state != QAbstractSocket::ConnectedState?); }

I am having the same issue. My system info: Windows XP Professional Service Pack 2 Build Lab 2600.xpsp_sp2_qfe.070227-2300 tor 0.2.0.6-alpha Privoxy 3.0.6 vidalia 0.0.14.0

process explorer reports vidalia running, tor not running, privoxy running. vidalia is using 50% cpu

I have attached process explorer file

I installed the latest bundle and had the same results, so i installed an earlier version - still no better

09/27/07 21:07:51 changed by vidalia ¶

per an earlier thread re: kaspersky - i have disabled kaspersky but vidalia still does not load in system tray; i downloaded a new bundle after un-installing vidalia and re-loaded it, but still no go. I was able to start tor, but vidalia continues to run 50% cpu

If this is a software issue and not a compatibility issue, wouldn't there be a lot more tickets? What would cause this behavior to manifest itself even in earlier releases (I installed 2 earlier bundles with the same results)?

Changed 14 months ago by vidalia

  Changed 14 months ago by edmanm

The best information we have so far points to this bug in Qt. As you can see, it has been fixed and is scheduled to go out in Qt 4.3.2, but I'm not sure when that will be.

I'm hoping to build the latest Qt snapshot from source within the next day or two and get some people who have experienced this bug to let me know if fixing Qt's bug fixed our bug or not.

  Changed 14 months ago by edmanm

I built Vidalia 0.0.15-svn (r1932) against the latest Qt 4.3.2 snapshot (4.3.2-snapshot-20070928). People who have been experiencing this bug should give this binary a try and see if it fixes your problem.

You can find the binary and signature here: http://pasiphae.cs.rpi.edu/~edmanm/vidalia/vidalia-0.0.15-svn.exe http://pasiphae.cs.rpi.edu/~edmanm/vidalia/vidalia-0.0.15-svn.exe.asc

This has the added excitement of being the first Vidalia Win32 binary to be built on Windows Vista. Please let me know if it works or doesn't work.

  Changed 14 months ago by vidalia

It does not work for me - do I have to create a "bundle" or will it configure itself if privoxy and tor are installed to the default locations?

  Changed 14 months ago by edmanm

No, you do not have to "create a bundle." Ideally, you should remove whatever version of Vidalia you currently have installed, and then install the 0.0.15-svn build above.

When you run the 0.0.15-svn build, check Vidalia's 'About' dialog to make sure Vidalia's version and Qt's version are as stated above.

  Changed 14 months ago by vidalia

I can't get to the about dialog; vidalia freezes when started, properties says it is 0.0.15, but I can't check Qt.

  Changed 13 months ago by edmanm

  • milestone Vidalia 0.0.15 deleted

  Changed 13 months ago by edmanm

I noticed some people are still downloading the Vidalia 0.0.15-svn installer linked above. Vidalia 0.0.15 has been released and is available on the download page. If you've experienced this bug, let me know if Vidalia 0.0.15 is any better. If it's not, I'd appreciate some more hints.

follow-up: ↓ 16   Changed 13 months ago by vidalia

I just installed the package suggested by edmanm. The Vidalia process still ramps up to 100% of the CPU after starting Tor. When Vidalia is first started, it puts up a dialog stating that another copy is already running. Of course, it is not. The about dialog states it's running QT 4.3.2.

Rick DeBay?

in reply to: ↑ 15   Changed 13 months ago by edmanm

Replying to vidalia:

When Vidalia is first started, it puts up a dialog stating that another copy is already running. Of course, it is not.

What version of Windows are you running? On all versions of Windows except Windows NT 4.0 Vidalia will look through your process list for another vidalia.exe. Are you sure there isn't some vidalia.exe listed in your Task Manager?

  Changed 13 months ago by vidalia

I am running NT 4.0, what do I need to do to get a stack trace since the program doesn't crash or hang?

  Changed 7 months ago by vidalia

I have the 100% cpu problem also with vidalia 0.1.2 on winxp At the begining Vidalia take the 100% of cpu for some second but after 10 min win crash

follow-up: ↓ 20   Changed 4 months ago by vidalia

0.0.16

and im still having this problem

in reply to: ↑ 19 ; follow-up: ↓ 21   Changed 4 months ago by edmanm

Replying to vidalia:

0.0.16

You need to upgrade. 0.0.16 is crazy old.

in reply to: ↑ 20   Changed 4 months ago by vidalia

Replying to edmanm:

0.0.16 is crazy old.

opps! i mean 0.1.6 :)

Note: See TracTickets for help on using tickets.