Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] DSF debug sets wrong breakpoint from another project with same source file name - Windows only

Thanks for the quick reply, Marc.

My debug traced to MIBreakpointsManager.adjustDebuggerPath() method. It strips the full path from the source file and returns only the base name of the file. It claims in its comment this was a temporary work-around for bug 232415

It only works for projects not having conflicting source file names. For projects large enough, the chance of stopping at the wrong source file is very high – in fact we have many re-producible cases in QNX.


From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Wed, 14 Dec 2011 14:26:20 -0500
To: "'CDT General developers list.'" <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] DSF debug sets wrong breakpoint from another project with same source file name - Windows only

DSF-GDB uses full paths to set breakpoints.  This situation is a good example why that is :-)
I'm surprised it does not do the same on Windows...
You might want to set a breakpoint in MIBreakpoints.formatLocation() and see the stack
trace to find out what part of the code does not set the file name properly.

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Jin
Sent: Wednesday, December 14, 2011 2:16 PM
To: CDT General developers list.
Subject: [cdt-dev] DSF debug sets wrong breakpoint from another project with same source file name - Windows only

I have two very simple c projects, "mingw1" and "mingw2". They were created by running the CDT new "HelloWorld" project wizard, so both projects have only one source file named "main.c". I attached my two projects to this message.

I built both projects using MingW toolchain, add one breakpoint in "mingw1/main.c" at line 16, and debug the second project "mingw2". In the debug, I select the DSF "Create Process Launcher", and unselect the "stop at main()" option.

Since I only have one breakpoint defined in "mingw1/main.c", I don't expect my debug of "mingw2" will stop. But in fact it stops at line 16 of "mingw2/main.c".

Looking at the gdb trace console I see the below section:

209,146 9-file-exec-and-symbols --thread-group i1 C:/workspace/PureCDT/mingw2/Debug/mingw2.exe

209,178 10-list-thread-groups

209,178 9^done

209,178 (gdb) 

209,193 11-break-insert --thread-group i1 -f main.c:16

209,193 10^done,groups=[{id="i1",type="process",executable="c:\\workspace\\purecdt\\mingw2\\debug\\mingw2.exe"}]

209,193 (gdb) 

209,193 11^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x004013a2",func="main",file="..\\src\\main.c",fullname="c:\\workspace\\purecdt\\mingw2\\src\\main.c",line="16",times="0",original-location="main.c:16"}

It's clearly that it uses just the base name of the source file when adding breakpoint, and it successfully finds "main.c" in the "mingw2" project so the breakpoint is added.

I only see this on Windows, Linux and Mac don’t have this problem. I tried the same on Mac and the gdb trace console shows below section:

482,001 5-file-exec-and-symbols /Users/ajin/workspace/mgrC-MacOSX2/Debug/mgrC-MacOSX2

482,027 5^done,time={wallclock="0.02525",user="0.01502",system="0.00724",start="1323888482.001276",end="1323888482.026527"}

482,027 (gdb) 

482,035 8-break-insert /Users/ajin/workspace/mgrC-MacOSX/src/main.c:16

482,036 6^error,msg="No source file named /Users/ajin/workspace/mgrC-MacOSX/src/main.c."

On Mac it uses the full path to add breakpoint.

I believe this is very similar (if not exactly the same) issue with CDI debugger bug To fix that CDI debugger bug a launch configuration option "Use full file name to set breakpoints" was introduced. But this option was lost in DSF debug.

Is there an explanation why this only happens on Windows? How shall we fix it in DSF? Do we need to introduce the same option from CDI debug?


Andy Jin

_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx

Back to the top