Gnutella causes temporary hangs in debug build

[blackflag100]

The exact version is Shareaza_2.5.3.1_Win32_Debug_r8846_2010-11-06.exe. The released version of 2.5.3.0 lacks this defect.

When a G2 hub is connected "Handshaking" is displayed in the Networking tab and then Shareaza freezes for several tens of seconds with 100% CPU use. By the time it recovers, commonly several of the connections have timed out, often including the new G2 connection. This results in Shareaza freezing, unfreezing, and freezing again repeatedly as it tries to establish G2 connections, while also preventing G1 connections from becoming established for very long. (Oddly, if there's an ed2k connection it stays rock solid through all this; ed2k hubs must be more tolerant of briefly unresponsive leaf nodes.)

Needless to say as G2 is "Shareaza's premier network" this makes this debug build pretty much unusable; G2 can't effectively be used at all. Briefer freezes with 100% CPU use also occur at random times when G2 is disconnected to prevent the long, frequent freezes. Memory use also seems higher than 2.5.3.0, other things (library size, open search tabs, downloads, uploads) being equal. Combined, these things slow down other applications on the host machine (directly, in the instances where Shareaza hogs the CPU, and indirectly when its higher memory use prompts paging).

Using only ed2k results in Shareaza not freezing. Using G1 suffices to cause some freezing.

[old_death]

Did you use a different debug build previously? And if that is the case, have you noticed the same problems on that version? Is the problem also present if you use a release build (r8846) instead of the debug build? (As debug build need to run much checks etc. they are generally much slower than release builds, BTW.)

EDIT: Do not link directly to Negatis files. Kindly, kevogod.

[blackflag100]

There's a "release build" without the checks? This wasn't linked on the debug builds page, and the main download link is still for 2.5.3.0.

Can the r8846 release build be installed over the r8846 debug build without losing/damaging partials/etc.?

[blackflag100]

Can the r8846 release build be installed over the r8846 debug build without losing/damaging partials/etc.?

Also, where is the link? I'm sure there was a link to the release build in here and now I can't find it.

[kevogod]

[blackflag100]

[old_death]

[blackflag100]

Less freezing (MUCH less) than Shareaza_2.5.3.1_Win32_Debug_r8846_2010-11-06.exe but slightly more than 2.5.3.0. The most important thing is that it's actually usable, and has a couple of major 2.5.3.0 bugs fixed; thanks.

[old_death]

So the problems you're having are most certainly caused by the debugging checks and mechanisms not included in the release builds... which means we can't do anything about it.

[blackflag100]

[old_death]

Most devs and beta testers have relatively fast PCs, so that's only a problem in theory.

And as these tests are absolutely needed if we want to find out why certain things don't work as they are supposed to do.

[blackflag100]

[cyko_01]

[old_death]

Cyko, that's not true - /me got only quad-core with 12GB RAM ATM...

[blackflag100]

And most of the user base doesn't. It's no wonder the debug builds are perceived as more unstable than they really are. People start them up, they go "connecting..." and then seize up, Windows says the task is Not Responding, and they give it the three-finger salute, go back to 2.5.3.0, and complain in the forums. And then you get guys like grey_hame and Tim Harrison that steadfastly refuse to try them after reading a few horror stories.

[old_death]

[blackflag100]

[old_death]

No, we don't have a choice here. The checks are hardcoded, which means they are not some option we can set in the compiler, but they are actually within the code. To remove them (or parts of them), we would have to revise the entire code of Shareaza - which means we'd have to check half a million of lines of code - which requires more work and time than the positive effect of removing them could ever help us saving...

[blackflag100]

[old_death]

We haven't made that choice, it has been made long before our time... And I think it to be the right choice, BTW.

However, we agree that this makes it difficult for some to test the alpha/beta builds, so Ryo has invested some hours into it by removing further checks and debug logging functionality (but mainly from the release builds) to have even less problems there. I hope you will see the benefits by these improvements, too.

[siavoshkc]

Debug builds are slow. We all know. But on a 2 GHz CPU and above when in some points Shareaza or system freezes, it is not because of debug checks. It has something to do with the way threads are handled I think.

The main reason of slowness of debug builds is because compiler optimizations are off to make executable mapable to its source code, not the checks.

[edit]
As I said before one problem is that we don't have beta releases. If we had we could release beta ones optimized.

[old_death]

[blackflag100]

[kevogod]

[blackflag100]

[old_death]

Migration to a different framework would be the best thing of course, but that should present itself as a similar amount of work than if we were to rewrite Shareaza completely...

What we *might* be able to do however, is to replace our thread management by the respective boost counterpart of MFC, as it is supposed to be more efficient. (At least according to some computer newspaper article I read some weeks ago.) This would also allow us to reorganize the different threats, maybe we could even separate GUI and program core... However, I have to admit, this is a big *might*...

[ailurophobe]

Making a dump of the heap state might do that. And since it is done by Microsoft code it is quite possible parts of it run in kernel mode and with high priority to minimize the effect on the performance of the application being debugged. And Shareaza has quite a lot of heap activity so... The effect different networks have on it might be due to a memory leak. The function for testing for memory leaks takes longer if it founds something... Or the Gnutella code might just have extra checks because ryo suspects it might have leaks in it.

[old_death]

[ailurophobe]

Yes, that was what I was answering to. Testing for memory leaks is relatively slow for programs such as Shareaza, by necessity synchronous, only enabled in debug builds, and might reasonably lock parts of the kernel at least pre-Windows 7.

[old_death]

Hmmm... was there a change in Win7?

[ailurophobe]

Yes (this is totally off-topic btw).

This is where I heard of it.
But this might be more informative.

[old_death]

[blackflag100]

[old_death]

I thought you might be able to speak German, as "Gesundheit!" means "good health!" in German.

As for the forums: there are known problems, however it is beyond our power to fix them, as those problems are problems with SourceForge, and so it's them who should fix those bugs.
Often using a different web browser does also help if you have posting problems.

[cyko_01]

[old_death]

[smokex]

BTW G1 and G2 are so intertwined that an error in one might freeze the other network while eDonkey does not. This might be why eDonkey keps going smoothly and G1 fails on G2 hang.

[old_death]

Yeah, true, that can happen because of the bad internal design of some of the networking code of Shareaza.