Moving breakpoints

When debugging, I normally:
a) set breakpoints at key points to really follow the execution of the code/ program
b) have to stop debugging sessions, switch perspective, change code, recompile, and recommence debugging

It seems as if the 2 do not necessarily go hand in hand
When I have to add or delete code lines as part of b), I can be sure that the breakpoints in place will move up/ down to trigger different code lines during debugging

Should I expect this?


Can you provide an example of your use case for this issue?

Also, are you using Nsight EE for this? In general, if you’re stopping your debug session, switching perspective, changing code, and recompiling, then your breakpoints should move around as expected. Is there a case where that’s not happening?

Yes, Nsight Eclipse - cuda6

It seems as if I can reproduce the particular case
I am not sure whether it is again related to/ triggered by lengthy code; so I ran with that hypothesis, just in case

I again used a simple sum scan within a function called by the kernel, and have again duplicated the scan within the function to get the function’s code length up
I placed a breakpoint at line 1306; built the project; switched to the debugger perspective; ran the program up to the breakpoint; stopped the program; switched back to code perspective; added some code lines I could clearly differentiate before the line with breakpoint
Up to this point, the breakpoint moved along as I added code lines, and stayed with its initial line (now line 1306 + added lines); thus nothing wrong yet
I then re-built the project; again switched to the debugger perspective and again ran the program up to the breakpoint; I again stopped the program at that point and switched back to the code perspective
Only now the breakpoint was at the original line 1306, instead of line 1306 + added lines
If you then again run the program in the debugger perspective, you will find that it breaks on line 1306, instead of 1306 + added lines

Thanks for posting those steps! I was able to reproduce the problem on our end (it seems to require exactly those 3 transitions)

I will keep you updated on progress for fixing this bug.