ClientManager lockups

Problems compiling? Don't understand the source code? Don't know how to code your feature? Post here.

Moderator: Moderators

Locked
Beo
Posts: 4
Joined: 2004-01-13 04:35
Contact:

ClientManager lockups

Post by Beo » 2004-01-13 04:40

I'm finding that since version 0.304 the DC++ client locks, probabily in some calls to ClientManager::addListener or ClientManager::removeListener.

I'vee got also an older version, 0.263, where there were no such calls, and it doesn't lock. Any suggestion? Anyone can explain those methods?

Thanks,
Beo

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-01-13 13:36

You sound a little hesitant. Is that where the deadlocks are occuring or not?

Breaking in with the debugger and inspecting the call stack of all the threads should tell you what's happening, and is even better for guessing if it's your code that's causing the problem.

Beo
Posts: 4
Joined: 2004-01-13 04:35
Contact:

Post by Beo » 2004-01-14 04:33

Well, ya know, in multithreading environment is not that simple to break into the debugger and see where a thread (and which one, especially) is locked. But, I'm almost sure that the ClientManager was different in version 0.263 (it doesn't have AddListener and RemoveListener methods, which seem to be the causes of the locks).

So, I don't understand what are those methods used for (all the Listeners sequence is dark for me).

And, also, I didn't modify the code, I'm just looking there since it locks both in the release (the sourceforge) version and in the debug one, compiled by me.

Beo
Posts: 4
Joined: 2004-01-13 04:35
Contact:

Post by Beo » 2004-01-14 04:38

Better, the sources in 0.263 and 3.06 "are" different, and I am almost sure that the cause of the lock is these differences.

Also, and this is by far more worrying for me, I seem to be the only one having these problems.

Beo
Posts: 4
Joined: 2004-01-13 04:35
Contact:

Post by Beo » 2004-01-14 04:39

0.306, of course

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-01-14 12:09

Beo wrote:Well, ya know, in multithreading environment is not that simple to break into the debugger and see where a thread (and which one, especially) is locked
Well, if it's your primary client, you will get timeouts and screw things up for chat and downloads/uploads, since you can't debug just one thread and let the others run. However, breaking in and debugging each thread is technically possible (while debugging: Debug > Windows > Threads [and Call Stack]), if you want the bug fixed, why not get more concrete data on what's causing the behavior? :?

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2004-01-15 08:28

GargoyleMT wrote:Well, if it's your primary client, you will get timeouts and screw things up for chat and downloads/uploads, since you can't debug just one thread and let the others run. However, breaking in and debugging each thread is technically possible (while debugging: Debug > Windows > Threads [and Call Stack]), if you want the bug fixed, why not get more concrete data on what's causing the behavior? :?
actually you can, garg, back to debugging school with you =)
in any case, the critical_section struct has a field that tells which thread owns the critical section that a function is waiting for...so basically, you look at one locked thread (by using the "break" command in the debugger), check the number in the struct (it might even be a struct in the struct called debug or something similar, don't remember), and then look at the thread in that field (probably called owner or something equally obvious) to see what its waiting for (a different cs most probably), and that way you see which two locks are in conflict...in your case, you probably hit the freezing search window bug that I never get, so if you can find me the two threads, locks and call stacks (ctrl-c copies the stack in vc++)...

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-01-15 12:55

arnetheduck wrote:actually you can, garg, back to debugging school with you =)
I didn't know about those features of the CriticalSection, they should come in handy. Thanks!

Guitarm
Forum Moderator
Posts: 385
Joined: 2004-01-18 15:38

Post by Guitarm » 2004-02-20 17:36

What struct are we referring to ?
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-02-21 13:23

Code: Select all

	CRITICAL_SECTION cs;
It's in CriticalSection.h:50 or so.

If you chase it through the Platform SDK, you see (in winbase.h:294):

Code: Select all

typedef RTL_CRITICAL_SECTION CRITICAL_SECTION;
And then in winnt.h:8201:

Code: Select all

typedef struct _RTL_CRITICAL_SECTION {
    PRTL_CRITICAL_SECTION_DEBUG DebugInfo;

    //
    //  The following three fields control entering and exiting the critical
    //  section for the resource
    //

    LONG LockCount;
    LONG RecursionCount;
    HANDLE OwningThread;        // from the thread's ClientId->UniqueThread
    HANDLE LockSemaphore;
    ULONG_PTR SpinCount;        // force size on 64-bit systems when packed
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
Hopefully this (plus FarCry's nice commentary) will help further in the Search UI hang

Guitarm
Forum Moderator
Posts: 385
Joined: 2004-01-18 15:38

Post by Guitarm » 2004-02-21 16:27

Thanks, Well, I've come to understand that I surely do need alot more experience and understanding of both the Windows API and DC++'s template stuff to be able to do something productive here.

Is there any kind of documentation of DC++ that one would gain something from ?

By the way, how do you get these "GargoyleMT wrote:" instead of just "Quote:" (This is a bit embarrasing) :roll:

Regards
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."

Guitarm
Forum Moderator
Posts: 385
Joined: 2004-01-18 15:38

Post by Guitarm » 2004-02-21 16:37

Guitarm wrote: By the way, how do you get these "GargoyleMT wrote:" instead of just "Quote:" (This is a bit embarrasing) :roll:
Oh my, this is a classical "think before you write" kinda mess.......
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-02-21 17:19

Guitarm wrote:Thanks, Well, I've come to understand that I surely do need alot more experience and understanding of both the Windows API and DC++'s template stuff to be able to do something productive here.
Getting at the cs shouldn't be too bad. I'm not sure where you're stuck, so this is what I'd do:

1. Reproduce the bug
2. Attach with the debugger and pause execution
3. Go through the thread list, double click each thread and find the one that seems to be stuck in CriticalSection::enter()
4. Double-click on the Critical Section portion of the call stack
5. In "Locals", expand this and look for the CRITICAL_SECTION
6. Extract the thread id from the cs.
7. Post the call stack of both threads here or to the original thread

I... hope that helps.
Guitarm wrote:Is there any kind of documentation of DC++ that one would gain something from ?
Not really, it takes some experimentation before you get familar with the layout. I still feel like a freaking n00b with a good chunk of it. :shock:
Guitarm wrote:Oh my, this is a classical "think before you write" kinda mess.......
Been there, done that, got the t-shirt. (And I still keep doing it. ;))

Guitarm
Forum Moderator
Posts: 385
Joined: 2004-01-18 15:38

Post by Guitarm » 2004-02-22 08:21

GargoyleMT wrote: 5. In "Locals", expand this and look for the CRITICAL_SECTION
== _RTL_CRITICAL_SECTION_DEBUG * ?
GargoyleMT wrote: 6. Extract the thread id from the cs.
== OwningThread 0x00000730 void * ? (for example...)
GargoyleMT wrote: 7. Post the call stack of both threads here or to the original thread
== Like I've done.......Hopefully ? (Maybe with a bit more info than you needed ?)
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-02-22 23:20

Guitarm wrote: == _RTL_CRITICAL_SECTION_DEBUG * ?
It seems so. :)
Guitarm wrote:== OwningThread 0x00000730 void * ? (for example...)
Yeah, I think you can toggle display of local variables in hex or decimal, if it makes it easier to correlate.
Guitarm wrote:== Like I've done.......Hopefully ? (Maybe with a bit more info than you needed ?)
Yes, this is exactly what sort of help is needed to pinpoint the problem!

liny
Posts: 30
Joined: 2003-11-01 09:18

Post by liny » 2004-02-23 09:19

arnetheduck wrote: you probably hit the freezing search window bug that I never get
I will show you.
In SearchFrame::initHubs():

clientMgr->lock();
::Sleep(2000); // add this between two locks <br> clientMgr->addListener(this);

connect to 5 hubs and open search frame at the same time, you will see everything freeze. It should only freeze for 2 seconds.

Locked