Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] duplicate breakpoints with cdi, cdt 7.0.0 on windows

Send a bug please attach your solutions is a patch. Probably first
path comes from sources in eclipse and second from the binary -
processed by gcc.

On Wed, Dec 15, 2010 at 7:02 PM, Siva Velusamy <siva.velusamy@xxxxxxxxx> wrote:
> Ok, I've figured out what the issue is, but I'm not sure what the best
> way to solve it is.
>
> The class org.eclipse.cdt.debug.internal.core.CBreakpointManager
> maintains a BreakpointMap that stores a list of current breakpoints.
> Before adding a new breakpoint, this map is searched to see if the
> same breakpoint already exists. This logic is present in the method
> isSameBreakpoint.
>
> With our tools (or maybe I haven't configured something properly),
> when this method runs, it compares two breakpoints (as described in my
> previous email). The issue is that the two breakpoints use two
> different file separators in their path:
>
> C:\path\to\hello.c
> C://path//to//hello.c
>
> Obviously, a string comparison of the above two fails. If before
> comparing the above two, I make sure that both paths are converted
> into a single format (new Path(str).toOsString()), then the comparison
> works and there are no more duplicate breakpoints.
>
> If you have any thoughts on whether this is a bug, or if I'm missing
> some configuration somewhere, then do let me know. I can file a bug
> report if you guys think this is a bug.
>
> Thanks,
> Siva
>
> On Wed, Dec 15, 2010 at 3:00 PM, Siva Velusamy <siva.velusamy@xxxxxxxxx> wrote:
>> More info:
>>
>> I notice that when I first set the breakpoint, a CLineBreakpoint is
>> created. The stacktrace looks like this:
>>
>> -------
>> CLineBreakpoint(resource="L/hello_world_0/src/helloworld.c",
>> attributes=a map, add=true)
>> CDIDebugModel.createLineBreakpoint
>> ....
>> -------
>>
>> Once this completes, it looks like it sets this breakpoint on the
>> target, which causes a MIBreakpointCreatedEvent. As part of responding
>> to this event, another CLineBreakpoint is created. The stacktrace now
>> looks like this:
>>
>> --------
>> CLineBreakpoint(resource="P/hello_world_0",
>>                         attributes=a map one of whose attributes is a
>> sourceHandle which points to
>> /full/path/to/hello_world_0/src/helloworld.c",
>>                         add=true)
>> CDIDebugModel.createBreakpoint
>> ..
>> CBreakpointManager.handleBreakpointCreatedEvent
>> --------
>>
>> So it looks like the difference is that the first one is a breakpoint
>> on the file itself, while in reaction to the MI event, a breakpoint is
>> created on the project, with the attribute being the file. The code
>> seems to rely on the fact that these two should be identical (which
>> they are not), so resulting in duplicates.
>>
>> Any thoughts on what the correct behavior should be for these methods?
>>
>> Thanks,
>> Siva
>>
>> On Wed, Dec 15, 2010 at 12:06 PM, Siva Velusamy <siva.velusamy@xxxxxxxxx> wrote:
>>> I'm seeing breakpoints listed twice in the breakpoints view.
>>>
>>> - When debugging is active, and you double click on a line, two
>>> breakpoints are shown in the breakpoints view. However, only one
>>> "break-insert" command is actually sent via MI to gdb.
>>> - When you delete one of them, a "break-delete" command is sent. The
>>> breakpoint is deleted from gdb, and the marker on the line goes away,
>>> but the duplicate breakpoint remains in the breakpoints view.
>>> - If you set a breakpoint before launching debug, then only one
>>> breakpoint is added to the view. However, once you start debugging, a
>>> duplicate of the same now shows up in the breakpoints view.
>>>
>>> All these issues are present only on Windows with a MingW based
>>> toolchain. No issues on Linux. We are using CDI.
>>>
>>> Software versions: Eclipse Helios + CDT 7.0.0
>>>
>>> I'd appreciate it if anyone has any thoughts on which files to look at
>>> in the source code.
>>>
>>> Thanks,
>>> Siva
>>>
>>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>


Back to the top