2.7.4.0 bug, fairly serious, freeze while hashing files

[Lanigiro]

This bug has been around since at least the 2.5.0.0 days. I can now confirm that it's still not fixed, in 2.7.4.0.

Moving several files (sometimes even just one, but usually when it happens a batch of 5-20 triggered it) into the library can provoke a hang with 0% CPU use and an unresponsive UI. The hang resolves spontaneously, sometimes after only a second or two and sometimes not for several minutes. Occasionally it hashes a couple more files, freezes again, hashes another file, freezes, etc. for as much as a half-hour or more before it's done, instead of hashing all the remaining files-to-be-hashed after the first recovery. If it stays that way for very long, it drops all Gnutella hub connections (not ed2K or DC++ though) immediately after recovering.

ProcessExplorer will show the Shareaza process with I/O bytes of 128 and CPU of 0 most ticks while Shareaza is under the influence of this very nasty bug.

The bug is much more likely to trigger if files are moved while a previous group are still hashing, or a download completes while a group of files are hashing, and much much more likely to trigger if any of the files involved came from DC++ for some reason. It never triggers if there are zero active searches. Infrequently it correlates with a very large wodge of fresh search hits arriving, usually a big bolus of 2-300 from an ed2k server, but more usually there's no particular search-tab activity simultaneous with the onset of a hang.

This is clearly undesirable and incorrect behavior, and it's high time it was looked into.

The 0% CPU use and low, but nonzero, I/O suggests that Shareaza essentially pauses itself and starts waiting for something, which since it has stopped doing anything with the disk and stopped responding to UI input is presumably a network something. I haven't been able to use the network tab log buffer to identify any specific type of network input that triggers it to wake back up. The first item post-recovery can be almost any random thing. This suggests that the network input that thaws out Shareaza is something not logged there, or else a bunch of other pent-up updates are appended to the log ahead of the actual wakeup call event. Knowing what woke it up would theoretically allow construction of a workaround that would function as an "alarm clock" of sorts, but it's far preferable that the bug be simply fixed, so the hangs do not ever begin in the first place.

[ianap]

It seems you got a good grasp on reproducing this bug. It seems you're also familiar with Process Explorer.

Question to the developers: is there any specific tool that you would recommend that would yield valuable information to be used for debugging in this case? I'm kinda hoping for an answer which is not "Microsoft Debugging Tools + our debug builds", but I understand if that's the best one.

Is any kind of report from Process Monitor useful at all? It's fairly "simple" to use (almost as simple as Process Explorer) and it has helped me a lot in tough-to-debug-for-a-non-developer-but-computer-savvy-user situations. It can generate A TON of information at first, but it's very easy to trim it to your personal needs after a few scares.

[Lanigiro]

[queuesclimber]

As far as I can follow, a Stop-button for everything was asked long time ago, but never done.
And as far as I can follow, you are want to hash your lib.
Create emtpy downloadfolder, then try hashing again.
Just finished a 17,86 gig download without any hashing issues.

[ianap]

[Lanigiro]

I've attached a screenshot of ProcessExplorer showing it acting up. CPU, I/O, and part of the frozen hashing notification.

[Lanigiro]

I have what may be a recipe to reproduce this. While files are hashing, go to a search result tab that likely has many results (say, any tab that ran for the full four hours before it quit searching) and turn off all the filters -- bogus, non-matching files, the works -- except leave "files you have already" on (see below for why I think that may be critical).

It may "bog down", with the screen redrawing one line at a time and getting slower for a bit before stopping outright, then show the usual symptoms (0% CPU use, 128 B I/O every tick) for anywhere from a few seconds to several minutes.

This suggests that the problem is when a file is at a certain point during hashing and something in a search result tab is being (re)filtered at the same time. So, look for shared data structures that are accessed and locks that are locked during both adding a file to the library and filtering a newly-arrived or user-refiltered search result. The ones of these that are accessed under both circumstances include the one or ones responsible for the possibly-a-race-condition bug that's causing the hangs (and perhaps also causing search results to sometimes be lost completely that had been there -- race conditions are well known for causing data corruption, and disappearing search results could easily be a symptom of such a thing).

So, the prime suspect objects are locks and shared data structures used in both:

- Adding a file to the library
- Applying, or re-applying, filters to a search result

and the prime suspect code is the code in the above two procedures that touches the prime suspect objects. Check for:

- Shared data structures -- accessing without holding the appropriate lock
- Locks -- acquiring some pair of locks in both file-adding and result-filtering, but in the opposite order, with either spin-locking or a timeout

The specific filter likely to be relevant here is "files you have already", as that clearly involves querying the library data structures, which are modified by adding files to the library. None of the other filters for query hits are likely to intersect with library management. So it's likely the "files you have already" code that is interacting badly with the library adding code.