Signals and Threads debugging...
-
Ladies and Gentlemen, Is there any way to debug signals and threads under Windows, using VC ( 7, in my case ), which actually works..? - The VC debugger displays a list of the active threads. Great... - The VC debugger doesn't tell me which signals, mutex'es or semaphores a thread is waiting for, ( or even if the thread is blocking ). - Spy++ tells me a little more, but still no news about which signal/mutex/sem is being waited for. ( How many context switches a thread does isn't really that usefull... ) - Signals/mutexes/semaphores are global under windows. I know they are ring0 objects, but why can't I see them, peek them and poke them ? ( It's no wonder perhaps, that most of Microsoft's apps are hopelessly single-threaded...:( ) Sorry for the rant, btw, I'm just frustrated at having to write tons of debugging code which someone else should have provided aeons ago... Help ? Anyone ? :) -=jarl=-
-
Ladies and Gentlemen, Is there any way to debug signals and threads under Windows, using VC ( 7, in my case ), which actually works..? - The VC debugger displays a list of the active threads. Great... - The VC debugger doesn't tell me which signals, mutex'es or semaphores a thread is waiting for, ( or even if the thread is blocking ). - Spy++ tells me a little more, but still no news about which signal/mutex/sem is being waited for. ( How many context switches a thread does isn't really that usefull... ) - Signals/mutexes/semaphores are global under windows. I know they are ring0 objects, but why can't I see them, peek them and poke them ? ( It's no wonder perhaps, that most of Microsoft's apps are hopelessly single-threaded...:( ) Sorry for the rant, btw, I'm just frustrated at having to write tons of debugging code which someone else should have provided aeons ago... Help ? Anyone ? :) -=jarl=-
check out sysinternals.com we (Microsoft programmers :)) usually use tools from there. PS> On that note could you point me to development environment that provides at least as much information as VS?:cool:
-
check out sysinternals.com we (Microsoft programmers :)) usually use tools from there. PS> On that note could you point me to development environment that provides at least as much information as VS?:cool:
ah......hello there! :cool: Ok, I'll check out sysinternals... ;) No, can't do. Nope. Nada. No-one does it right...( however, if I was evil overlord.... ) Well, actually, I used to work for a company which had their own "os" which supported multithreading on a host of platforms. They had an internal suite of tools which provided such things as; - global signal monitoring - signal/mutex/sem usage logging - priority inversion workarounds that worked... - break on set/reset - break on multiple threads waiting on same signal etc. Since the "os" was custom, ( based on the Amiga OS, will you believe it...? ), this was possible. I think Microsoft and its brilliant programmers...( cough ;) ), should be able to provide the same.... Anyways...moving on.... :-D -=jarl=-
-
Ladies and Gentlemen, Is there any way to debug signals and threads under Windows, using VC ( 7, in my case ), which actually works..? - The VC debugger displays a list of the active threads. Great... - The VC debugger doesn't tell me which signals, mutex'es or semaphores a thread is waiting for, ( or even if the thread is blocking ). - Spy++ tells me a little more, but still no news about which signal/mutex/sem is being waited for. ( How many context switches a thread does isn't really that usefull... ) - Signals/mutexes/semaphores are global under windows. I know they are ring0 objects, but why can't I see them, peek them and poke them ? ( It's no wonder perhaps, that most of Microsoft's apps are hopelessly single-threaded...:( ) Sorry for the rant, btw, I'm just frustrated at having to write tons of debugging code which someone else should have provided aeons ago... Help ? Anyone ? :) -=jarl=-
Actually...there is a concrete problem here.... I have threads A, B, C and D and signals 1, 2, 3 and 4. A waits for 1, B for 2, C waits for 3, D for 4 I set signal 2 from thread A and....C wakes up! This is why I would like to be able to know for certain that signal 2 is actually set. (From the windows kernel's point of view ) Currently I have a debug-info structure stored with each signal, and set/reset/create/wait wrappers which update this information. Such as; waiting-thread id number of waiting threads, ( is allways 1 in this case ) id of thread which last set this signal id of thread which last cleared this signal etc. Imagine my frustration.... I know for certain that the two signals 2 and 3 are distinct. I know for certain that C is waiting for 3, ( and not for 2 ). I know for certain that I am going mad. Any ideas, inspirational thoughts, haiku's or anything such which might give me a push in the right direction would be much appreciated. p.s. Signal = Event, in Windows speak p.p.s ProcExp from the Sysinternals homepage doesn't do what I need. I am concerned now that I have found out that the Windows Native API doesn't have any methods for monitoring signals... -=jarl=-
-
Actually...there is a concrete problem here.... I have threads A, B, C and D and signals 1, 2, 3 and 4. A waits for 1, B for 2, C waits for 3, D for 4 I set signal 2 from thread A and....C wakes up! This is why I would like to be able to know for certain that signal 2 is actually set. (From the windows kernel's point of view ) Currently I have a debug-info structure stored with each signal, and set/reset/create/wait wrappers which update this information. Such as; waiting-thread id number of waiting threads, ( is allways 1 in this case ) id of thread which last set this signal id of thread which last cleared this signal etc. Imagine my frustration.... I know for certain that the two signals 2 and 3 are distinct. I know for certain that C is waiting for 3, ( and not for 2 ). I know for certain that I am going mad. Any ideas, inspirational thoughts, haiku's or anything such which might give me a push in the right direction would be much appreciated. p.s. Signal = Event, in Windows speak p.p.s ProcExp from the Sysinternals homepage doesn't do what I need. I am concerned now that I have found out that the Windows Native API doesn't have any methods for monitoring signals... -=jarl=-
Man, that must suck! X| Any chance we can see some code? It's the only way to verify what you "know for certain". :-) It might also help to isolate this code into a little sample project and see if it still breaks. If so, then it would be a lot easier for any of us to help you debug it. Regards, Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
-
Man, that must suck! X| Any chance we can see some code? It's the only way to verify what you "know for certain". :-) It might also help to isolate this code into a little sample project and see if it still breaks. If so, then it would be a lot easier for any of us to help you debug it. Regards, Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
And, the one thing which annoys me the most, is the knowledge, ( or assumption ), that there is going to be some exceedingly stupid thing somewhere which is causing this... X| Anyways, let me get on with isolating this in some form or other so that I can share my grief in a more concrete form. :) cheers! -=jarl=-
-
And, the one thing which annoys me the most, is the knowledge, ( or assumption ), that there is going to be some exceedingly stupid thing somewhere which is causing this... X| Anyways, let me get on with isolating this in some form or other so that I can share my grief in a more concrete form. :) cheers! -=jarl=-
-
I'll go an shoot myself now.... This is just too stupid..... I had a name...a const char*...and I used it...twice....and you can all figure out the rest from there and tell me I'm a monkey...thanks, I knew that... X| oh...well.. -=jarl=-
:) We help all kinds here, even monkeys. ;P Sometimes it helps to take a tenth look at the code, doesn't it? Regards, Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain