Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-debug-dev] multiple threads and call stack update 
Well, it might be not a bug.
My environment is a C program hosted on linux.
My point is just to understand why Eclipse behaves like that in the current version. It requests the debugger for some information that are not displayed, and in some cases, it could take more than 10 seconds to make a single step. 

I though we could first discuss that thru the mailing list ?

Denis



Elena Laskavaia wrote:

Please send a bug report if it is not already there and specify your
debugger and environment

-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Denis PILAT
Sent: January 16, 2008 4:25 AM
To: CDT Debug developers list; cdt-dev@xxxxxxxxxxx
Subject: [cdt-debug-dev] multiple threads and call stack update 
I have an application that creates around 100 threads.
On Eclipse 3.3, after a stepping operation, an update of the call stack is requested by Eclipse to the debugger for some of these threads.
After the program stops, you can see with the verbose console mode something like: 
[1,200,399,158,705] 649-thread-select 3
[1,200,399,158,732] 650-stack-list-frames 0 8
[1,200,399,159,169] 651-stack-list-frames 0 8
[1,200,399,159,181] 652-thread-select 103
[1,200,399,159,209] 653-thread-select 2
[1,200,399,159,235] 654-stack-info-depth
[1,200,399,159,329] 655-stack-info-depth
[1,200,399,159,330] 656-thread-select 103
[1,200,399,159,345] 657-thread-select 2
[1,200,399,159,371] 658-stack-list-frames 0 5
[1,200,399,159,480] 659-thread-select 103
[1,200,399,159,508] 660-thread-select 1
[1,200,399,159,532] 661-stack-info-depth
[1,200,399,159,536] 662-stack-info-depth
[1,200,399,159,538] 663-thread-select 103
[1,200,399,159,551] 664-thread-select 1
[1,200,399,159,574] 665-stack-list-frames 0 2
...etc...
On Eclipse 3.2 only the current thread requested a call stack frame. Other thread requested an update only if they are selected in the debug view, and as threads in the debug view are all collapsed at each step (like in the 3.3 version), that was much more optimized in term of number of requests done to the debugger. 


Is the 3.3 behaviour a normal behaviour or a regression ?
I'm wondering why Eclipse requests call stack frame for threads that are not expanded in the debug view ? 
And why it requests that only for parts of the threads ?


Thanks for you answer
Denis PILAT / STMicroelectronics





_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

Back to the top