ClientManager lockups
Moderator: Moderators
ClientManager lockups
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
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
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.
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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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?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
-
- The Creator Himself
- Posts: 296
- Joined: 2003-01-02 17:15
actually you can, garg, back to debugging school with you =)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? :?
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++)...
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Code: Select all
CRITICAL_SECTION cs;
If you chase it through the Platform SDK, you see (in winbase.h:294):
Code: Select all
typedef RTL_CRITICAL_SECTION CRITICAL_SECTION;
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;
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)
Regards
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)
Regards
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."
Oh my, this is a classical "think before you write" kinda mess.......Guitarm wrote: By the way, how do you get these "GargoyleMT wrote:" instead of just "Quote:" (This is a bit embarrasing)
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Getting at the cs shouldn't be too bad. I'm not sure where you're stuck, so this is what I'd do: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.
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.
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.Guitarm wrote:Is there any kind of documentation of DC++ that one would gain something from ?
Been there, done that, got the t-shirt. (And I still keep doing it. )Guitarm wrote:Oh my, this is a classical "think before you write" kinda mess.......
== _RTL_CRITICAL_SECTION_DEBUG * ?GargoyleMT wrote: 5. In "Locals", expand this and look for the CRITICAL_SECTION
== OwningThread 0x00000730 void * ? (for example...)GargoyleMT wrote: 6. Extract the thread id from the cs.
== Like I've done.......Hopefully ? (Maybe with a bit more info than you needed ?)GargoyleMT wrote: 7. Post the call stack of both threads here or to the original thread
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
It seems so.Guitarm wrote: == _RTL_CRITICAL_SECTION_DEBUG * ?
Yeah, I think you can toggle display of local variables in hex or decimal, if it makes it easier to correlate.Guitarm wrote:== OwningThread 0x00000730 void * ? (for example...)
Yes, this is exactly what sort of help is needed to pinpoint the problem!Guitarm wrote:== Like I've done.......Hopefully ? (Maybe with a bit more info than you needed ?)
I will show you.arnetheduck wrote: you probably hit the freezing search window bug that I never get
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.