This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 151761 - gdb confused on line breakpoints for files with embedded spaces
Summary: gdb confused on line breakpoints for files with embedded spaces
Alias: None
Product: cnd
Classification: Unclassified
Component: Debugger (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: _ gordonp
Depends on:
Reported: 2008-10-29 18:25 UTC by _ gordonp
Modified: 2009-06-25 10:59 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ gordonp 2008-10-29 18:25:08 UTC
The gdb/mi quoting mechanism is messed up (see for
details). A side affect of this is that if we try and set a line breakpoint with an absolute path with
embedded spaces, the command fails. So we check for embedded spaces and send a path relative to the
project basedir or source directory in this case.

The problem is that this isn't always unique and can cause a breakpoint in one project to stop another
project. If I have 2 projects ("/tmp/Spaced Out/Args_1" and "/tmp/Spaced_out/Args_2") and set a line
breakpoint in Args_1 at the 1st printf, the bp command will set the bp at "src/args.c:9". If I then
debug Args_2, I'll stop at line 9 because src/args.c:9 is ambiguous.

I tried *many* different escapes by hand to see if I could figure out a correct syntax and never got
one to work. Its possible it can be done, but not clear what that syntax would be.

This issue is a corner case of IZ #149603 (Debugger confuses source files with the same name). I'm
closing that as fixed and opening this.
Comment 1 _ gordonp 2008-10-30 16:17:28 UTC
Right after filing this I thought of a probable solution. While I can't set a bp with an
absolute path in gdb/mi2, I can check the response (which contains the full path of the
file the bp was applied to) against the full original path. If they're not the same, I got
a bp in a different file. In that case, I can -break-delete and mark the bp as BP_VALIDATION_FAILED.
Comment 2 _ gordonp 2008-10-30 17:50:42 UTC
Fixed while my idea was fresh in my mind:-)

Comment 3 Quality Engineering 2008-10-31 04:47:30 UTC
Integrated into 'main-golden', will be available in build *200810310201* on (upload may still be in progress)
User: Gordon Prieur <>
Log: Fixed IZ #151761  gdb confused on line breakpoints for files with embedded spaces
Comment 4 _ gordonp 2008-11-20 19:11:41 UTC
> This issue is a corner case of IZ #149603 (Debugger confuses source files with the same
> name). 

To fix this issue in a NB65 patch you need to apply;node=79fff0b61390
(from 149603) before;node=1bb3be2653b4.
Comment 5 Alexander Pepin 2008-11-20 21:13:35 UTC
verified in build 200811200201
Comment 7 pgebauer 2008-11-27 09:35:44 UTC
The issue has been rolled back from the 65patch1 and moved to 65patch2 based on the QE request.

Comment 8 jinb 2009-01-08 18:38:59 UTC
it impossible to apply mentioned changeset(s) to release65_fixes [ref1] branch because a lot of non-this IZ related
changes were made and other changesets pushed into main [ref2] repository between release65_fixes branching time and
mentioned changeset(s) pushing time. Please provide cumulative changeset/ set of changesets applicable to
release65_fixes branch otherwise this fix will be skipped for current NB65 patch.
This problem is common for following IZs: 151761, 151610, 151577, 133134, 155487 
Comment 9 Alexander Pepin 2009-01-13 15:17:52 UTC
It would be nice to have the fix in NB 6.5 patch
Comment 10 Alexander Pepin 2009-01-14 14:02:49 UTC
verified in NB6.5 with provided jar files
Comment 11 jinb 2009-01-14 17:44:02 UTC
Cumulative backport of fixes of IZ 151481(rebackport), 151577, 151610, 153473, 151640, 151761, 155487, 151631, 133134
provided by developer.
Backported into release65_fixes branch
Comment 12 Alexander Pepin 2009-01-19 15:07:36 UTC
verified in patch2
Comment 13 o_schn 2009-05-27 09:44:29 UTC
I got a related issue in NB 651 (Build 200903060201) on Win XP: When I try to debug into a shared library of the C++ 
sample project "Subproject Application", e.g., NB immediately removes the added breakpoint, as the path is 
written with different separators:

125-break-insert -f C:/temp/test/SubProjects/hello3lib/
126-break-delete 7

So it is very necessary to compare a unified form of the path.
Comment 14 Egor Ushakov 2009-05-27 09:58:44 UTC
what you describe was fixed in the issue 159525
Comment 15 o_schn 2009-05-27 16:40:24 UTC
Yes, it is fixed in NB67 beta (Build 200904242137)