| Re: [cdt-debug-dev] multiple threads and call stack update |
Hi Denis,I think that bug 111570 cannot be resolved. CDT has to query GDB for its list of threads after each single step since there is no notification mechanism in GDB where a client can get notified of thread create/kill events. A remote GDB back-end (i.e. a GDB target.h implementation) can, however, implement "info threads" in an efficient way if there is a way to be notified of thread create/kill events from the remote target system.
However, CDT should not try to retrieve the stack backtrace for each thread after a single step; this will really kill performance.
Regards, Stefan Denis PILAT wrote:
I've just logged it (bug ID 215627) with testcase and console output as attachements.Thanks for your support,For your information, while looking for similar problem, I noticed the bug 111570 which is open for years.Denis Elena Laskavaia wrote:I agree with that - so I asked Denis to submit a bug, I can see it happeninghere with CDT 4.0.2 and I was surprised too. After I fix dead locks performance would be the first thing I will look into fixing in CDT debugger. -----Original Message----- From: cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan Bylund Sent: January 16, 2008 11:56 AM To: CDT Debug developers list Subject: Re: [cdt-debug-dev] multiple threads and call stack update Hi,I remember that in Eclipse 2.x / CDT 2.x, the stack backtrace was retrieved for all threads; this seriously reduced the performance of single stepping if you had many threads.In Eclipse 3.0-3.2 / CDT 3.x, the stack backtrace is only retrieved for the current thread and, if any, the expanded threads in the debug view; this greatly improves the performance of single stepping if you have many threads.I haven't tried Eclipse 3.3 / CDT 4.x that much yet, but I would find it very disappointing if the stack backtrace behaviour has changed negatively compared to Eclipse 3.0-3.2 / CDT 3.x. IMHO, if Eclipse 3.3 / CDT 4.x tries to retrieve the stack backtrace for anything else than the current thread and any expanded threads in the debug view, I would call it a serious bug that needs fixing.Regards, Stefan Denis PILAT wrote: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_______________________________________________ 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
-- --------------------------------- Stefan Bylund Senior Software Engineer Enea Skalholtsgatan 9, Box 1033, SE-164 21 Kista, Sweden Direct: +46 8 50 71 43 25 Mobile: +46 709 71 43 25 stefan.bylund@xxxxxxxx www.enea.com --------------------------------- Enea - Embedded for Leaders ---------------------------------