Core-saturating hang problem worse today.
Posted: 20 May 2015 17:29The longstanding bug that causes periods of 100%/one-full-core CPU use with an unresponsive UI got a quantum leap worse sometime overnight. For long stretches today I've found Shareaza all but unusable due to this, with it spending long periods frozen (sometimes over a minute) and often freezing again only a few seconds after unfreezing. At the worst times it has spent as much as 70% of the time in the high-CPU-use frozen state and only 30% in the normal, responsive state with low CPU use.
There was one long stretch of about an hour or so when it was nicely stably connected to all networks and hummed along properly like it's supposed to, without any of these problems, but then it got flaky again about 20 minutes ago, both freezing frequently (maybe 40-50% of the time nonresponsive) and fumbling connections (mainly G1 ones).
What could have changed externally (as I made no settings changes) that could possibly have exacerbated this bug? Why does it freeze like this at all? There are a few situations where it "normally" does something similar -- changing a search tab's filters when there's a very large number of results (say, over 10,000 including currently hidden results) can cause a second or two of high CPU use "thinking", and adding or editing a security rule causes a hang of up to three or four seconds with a core saturated. But these troubling hangs are often much longer and happen apparently spontaneously. Any user input such as dragging a scrollbar, selecting or deselecting something, or clicking "download" seemingly can precipitate this hang, without any apparent rhyme or reason. The same input two seconds earlier can have failed to do so. Indeed, merely mousing over something can set it off, particularly, trying to get a tooltip by hovering over a search tab heading or a list item for a few seconds. And even if I completely ignore the computer for five minutes and come back to it the ProcessExplorer CPU use graph will show half a dozen spikes for the Shareaza process while I was absent, indicating that not making any user inputs can, incredibly, also trigger the hang! This, and the sudden vastly worsened severity of this bug starting sometime while I was asleep last night, strongly implies to me that the hang is actually being triggered by something received over the network, which if true is a VERY SERIOUS PROBLEM, for three reasons:
1. Obviously it is not correct that the user can be punished for something someone else did. It's one thing if the application hangs because of some click or mousemove I made -- even if it really shouldn't do so, even if there is some reasonable sense in which the user input can be considered to have been in error -- but it's quite another if some random joker in Australia or the West Indies or something can push a button halfway around the world and cause my copy of Shareaza to freeze.
2. As the last part of the above paragraph implies, this constitutes a denial of service vulnerability, a form of security hole. Shareaza cannot be permitted to contain security holes. If there is a DoS vulnerability whereby someone can send a Shareaza instance (directly to its listen port, or via e.g. polluting a gwebcache with malformed entries or with well-formed entries that point to malicious hosts that respond to a connect request with a Packet of Death(tm)) malicious traffic that causes it to temporarily freeze, then I must in no uncertain terms demand the immediate rectification of the bug, without any delay and dropping all other priorities until it is fixed and a 2.7.8.1 has been publicly released with the hole closed.
3. The sudden increase in the frequency of this then points to a sudden increase in whatever network traffic provokes the hang, likely because of a spate of malicious traffic exploiting the bug for DoS purposes. In other words, the evidence indicates that I am under attack and that quite possibly every Shareaza user is under attack. This only underscores the urgency of investigating and correcting the bug.
There was one long stretch of about an hour or so when it was nicely stably connected to all networks and hummed along properly like it's supposed to, without any of these problems, but then it got flaky again about 20 minutes ago, both freezing frequently (maybe 40-50% of the time nonresponsive) and fumbling connections (mainly G1 ones).
What could have changed externally (as I made no settings changes) that could possibly have exacerbated this bug? Why does it freeze like this at all? There are a few situations where it "normally" does something similar -- changing a search tab's filters when there's a very large number of results (say, over 10,000 including currently hidden results) can cause a second or two of high CPU use "thinking", and adding or editing a security rule causes a hang of up to three or four seconds with a core saturated. But these troubling hangs are often much longer and happen apparently spontaneously. Any user input such as dragging a scrollbar, selecting or deselecting something, or clicking "download" seemingly can precipitate this hang, without any apparent rhyme or reason. The same input two seconds earlier can have failed to do so. Indeed, merely mousing over something can set it off, particularly, trying to get a tooltip by hovering over a search tab heading or a list item for a few seconds. And even if I completely ignore the computer for five minutes and come back to it the ProcessExplorer CPU use graph will show half a dozen spikes for the Shareaza process while I was absent, indicating that not making any user inputs can, incredibly, also trigger the hang! This, and the sudden vastly worsened severity of this bug starting sometime while I was asleep last night, strongly implies to me that the hang is actually being triggered by something received over the network, which if true is a VERY SERIOUS PROBLEM, for three reasons:
1. Obviously it is not correct that the user can be punished for something someone else did. It's one thing if the application hangs because of some click or mousemove I made -- even if it really shouldn't do so, even if there is some reasonable sense in which the user input can be considered to have been in error -- but it's quite another if some random joker in Australia or the West Indies or something can push a button halfway around the world and cause my copy of Shareaza to freeze.
2. As the last part of the above paragraph implies, this constitutes a denial of service vulnerability, a form of security hole. Shareaza cannot be permitted to contain security holes. If there is a DoS vulnerability whereby someone can send a Shareaza instance (directly to its listen port, or via e.g. polluting a gwebcache with malformed entries or with well-formed entries that point to malicious hosts that respond to a connect request with a Packet of Death(tm)) malicious traffic that causes it to temporarily freeze, then I must in no uncertain terms demand the immediate rectification of the bug, without any delay and dropping all other priorities until it is fixed and a 2.7.8.1 has been publicly released with the hole closed.
3. The sudden increase in the frequency of this then points to a sudden increase in whatever network traffic provokes the hang, likely because of a spate of malicious traffic exploiting the bug for DoS purposes. In other words, the evidence indicates that I am under attack and that quite possibly every Shareaza user is under attack. This only underscores the urgency of investigating and correcting the bug.