Community
Participate
Working Groups
Using CDT 8.8.0.201508011003 1. Create a Hello world C project 2. Start debugging 3. In the Breakpoints view, use Add Line Breakpoint to add a breakpoint inside main (main.c line 16). The breakpoint marker does not appear in the vertical ruler of the editor.
What is going on here is that the user in this case has inserted the breakpoint on main.c:16, which despite appearances is different that /path/to/main.c:16. The former's resource is the workspace root, the latter is the main.c in the project. With full paths on in the breakpoint table, it looks like this: main.c [line: 16] /scratch/eclipse/src/cdt/runtime-CDT/HelloWorld/src/main.c [line: 15] Until a debug session is running the former (main.c:16) has no resolution to resources. Therefore, I think the full solution to this problem is to create installed breakpoint markers for the resolved breakpoints. There are other cases that have the same problem. For example, doing a "b main.c:16" when that creates a pending breakpoint causes the platform breakpoint to be created without a full path, but do the same "b main.c:16" after that file has been loaded (ie not pending breakpoint) causes the platform breakpoint to be created with the resolved path. I know some work was done on trying to show relocated breakpoints (similar, problem) and perhaps that can be used here too. Perhaps in the meantime of resolving the above inconsistencies I could do something to ameliorate the users experience. I am not not keen on requiring the file to exist to enable the insertion, but perhaps a warning would be appropriate? I will submit a patch for review to see if this meets expectations.
New Gerrit change created: https://git.eclipse.org/r/53419
(In reply to Jonah Graham from comment #1) > There are other cases that have the same problem. For example, doing a "b > main.c:16" when that creates a pending breakpoint causes the platform > breakpoint to be created without a full path, but do the same "b main.c:16" > after that file has been loaded (ie not pending breakpoint) causes the > platform breakpoint to be created with the resolved path. Interesting. We should probably update the platform breakpoint once the debugger resolves it. But that is not the goal of this bug. We should have another bug for this particular situation. > I know some work was done on trying to show relocated breakpoints (similar, > problem) and perhaps that can be used here too. > > Perhaps in the meantime of resolving the above inconsistencies I could do > something to ameliorate the users experience. I am not not keen on requiring > the file to exist to enable the insertion, but perhaps a warning would be > appropriate? I will submit a patch for review to see if this meets > expectations. I tried the warning patch and to be honest, I didn't think it helped much. Would it be a valuable enough step to update the platform breakpoint to the full file path based on the debugger ^done response? So, when the bp is created using "Add Line Breakpoint (C/C++)", we could check if we have an absolute path, and if not, we could use the debugger response to set that path.
I have submitted an updated gerrit for making this case an error. That should resolve this bug and the other issues (i.e. displaying installed breakpoints) are not for the 8.8 release.
Gerrit change https://git.eclipse.org/r/53419 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=bd6fa94e63387dbaf42ce0f5f426cf1f1b1b4d00
(In reply to Eclipse Genie from comment #5) > Gerrit change https://git.eclipse.org/r/53419 was merged to [master]. > Commit: > http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/ > ?id=bd6fa94e63387dbaf42ce0f5f426cf1f1b1b4d00 Thanks, I tested the patch and it's much clearer. One small thing though. Normally, Eclipse dialogs do not display errors until the user has entered information. See: https://eclipse.org/articles/Article-UI-Guidelines/Contents.html#Wizards "When a wizard first opens, the focus should be placed in the first field requiring information (see Guidelines 3.1). The header should be used to prompt the user for the first piece of required information. ... It is not appropriate to display an error message. At this point, the user hasn't done anything yet."
New Gerrit change created: https://git.eclipse.org/r/53908
Gerrit change https://git.eclipse.org/r/53908 was merged to [cdt_8_8]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=75001014046d2d1c5678e3d4b347c56f213ee58d
(In reply to Marc-Andre Laperle from comment #6) I've committed Jonah improvement to master and cdt_8_8 so as to have it for RC1. > "When a wizard first opens, the focus should be placed in the first field > requiring information (see Guidelines 3.1). The header should be used to > prompt the user for the first piece of required information. > > ... > > It is not appropriate to display an error message. At this point, the user > hasn't done anything yet." This is a worthwhile improvement that can go in for RC2. Jonah, are you able to have a look at that?
(In reply to Marc-Andre Laperle from comment #6) > (In reply to Eclipse Genie from comment #5) > > Gerrit change https://git.eclipse.org/r/53419 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/ > > ?id=bd6fa94e63387dbaf42ce0f5f426cf1f1b1b4d00 > > Thanks, I tested the patch and it's much clearer. One small thing though. > Normally, Eclipse dialogs do not display errors until the user has entered > information. See: > https://eclipse.org/articles/Article-UI-Guidelines/Contents.html#Wizards > > "When a wizard first opens, the focus should be placed in the first field > requiring information (see Guidelines 3.1). The header should be used to > prompt the user for the first piece of required information. > > ... > > It is not appropriate to display an error message. At this point, the user > hasn't done anything yet." I agree completely, but that is indeed a bug for another day as it requires at least some amount of refactoring of all the insert breakpoint dialogs (and the underlying property pages they use). I will next attach a screenshot of the add function breakpoint for comparison.
Created attachment 255904 [details] error on function breakpoint
(In reply to Tracy Miranda from comment #10) > I agree completely, but that is indeed a bug for another day as it requires > at least some amount of refactoring of all the insert breakpoint dialogs > (and the underlying property pages they use). I will next attach a > screenshot of the add function breakpoint for comparison. Sounds good, it can be addressed in a separate bug/patch. It's pretty minor.
I believe the reason for this bug has been addressed properly
