Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] remote debugging sync problem

Sounds like
Bug 280631 - [debug view][cdi] Thread list in Debug view not updated with non-Linux target
https://bugs.eclipse.org/bugs/show_bug.cgi?id=280631
and
Bug 323276 - [debug view][cdi] "Force thread list update feature" does not work with GDB 7.0 or later
https://bugs.eclipse.org/bugs/show_bug.cgi?id=323276

Which were both fixed in Helios (3.6)

Marc


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Heyendal, Carl
> Sent: Thursday, April 07, 2011 12:51 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] remote debugging sync problem
> 
> Hi,
> 
> Hopefully this is the correct group to ask. I'm having 
> trouble getting remote debugging synchronized with Eclipse 
> when I hit a breakpoint in a thread. 
> 
> I wrote a simple "Hello World" app that prints out "H-W" in 
> both main() and also prints it out in a created thread. 
> Running the app on the target with no breakpoints, the app 
> runs fine from start to finish. I can even step through the 
> main() code....but not the thread code.
> 
> The problem happens when I put a breakpoint in the thread. 
> The app hits and stops at the breakpoint but Eclipse doesn't 
> update the Debug window with new thread information, nor does 
> it change the focus in the source code to where the 
> breakpoint is at. If I step, then it's really obvious that 
> Eclipse is lost.
> 
> Here are the GDB traces once it hits the thread breakpoint:
> 
>   183,882 ~"[New Thread 509]\n"
>   183,890 ~"[Switching to Thread 509]\n"
>   183,907 
> 19*stopped,reason="breakpoint-hit",bkptno="1",thread-id="2",fr
> ame={addr="0x000084e4",func="h\
>   
> ello_thread",args=[],file="../hello.c",fullname="/home/heyenda
> l/workspace/hello2/hello.c",line="42"}\
> 
>   183,908 (gdb) 
>   184,160 20-thread-select 1
>   184,160 21-stack-info-depth 11
>   184,173 
> 20^done,new-thread-id="1",frame={level="0",addr="0x401304b0",f
> unc="sigsuspend",args=[],from=\
>   
> "/home/heyendal/projects/Buildroot/buildroot-2011.02/output/ta
> rget/lib/libc.so.0"}
>   184,173 (gdb) 
>   184,238 21^done,depth="4"
>   184,238 (gdb)
> 
> It doesn't look like Eclipse is trying to refresh any 
> information once it hits the breakpoint.
> 
> 
> However, I figured out a manual way to get Eclipse back into 
> sync when I reach a thread breakpoint: 
> 
> -	I put a breakpoint in the thread and run the H-W app
> -	I watch the debug window and wait until I notice that 
> the original single thread has suspended
> -	when his happens I click the refresh button to get the 
> debug window to update with all the new threads information, 
> -	open the new thread that is marked as 'hit breakpoint', 
> -	select the last function in the call stack indicating 
> 'breakpoint' 
> -     now the source code window will change and display its 
> arrival at the breakpoint
> 
> Once I have done the above Eclipse is back in sync and I can 
> step through the thread code.
> 
> Should it behave this way? 
> 
> Running Galileo 3.5. Using "GDB (DSF) Remote System Process 
> Launcher". The same app running locally on my workstation 
> doesn't require my manual workaround. Once it hits the 
> breakpoint, Eclipse is fully in sync and I can step through 
> the thread code.
> 
> The app also behaves properly when using GDB without Eclipse. 
> I can set a breakpoint in the thread and GDB and the remote 
> app stay in sync with each other once the breakpoint in the 
> thread is hit, and I step along the thread code with no problems.
> 
> Appreciate any help.
> 
> thanx
> /carl
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 

Back to the top