Debugger sometimes doesn't delete breakpoints

[280Z28]

I don't know how reliably this can be repeated. Can anyone else?

Steps:
Debug C::B
Set breakpoint at parser.cpp:899

Code Select Expand

if ((event.GetInt() == 0 && !m_Options.followLocalIncludes) ||

Run
When it breaks, click twice pretty quickly on line 904.

Actual result:
Sets the breakpoint, but does not clear it. GDB still has a breakpoint there, but it is no longer marked in the editor and can't be deleted from then on.

Expected result: Set a new breakpoint and clear it.

[lesnewell]

I don't know if it is related to your problem but try this:

Put a breakpoint in a file. Run GDB and check it stops at the breakpoint. Stop GDB and edit the file, adding a few lines or removing a few lines before the breakpoint. Now delete the breakpoint. Run GDB and you will often find there is still a breakpoint there although you can't see one in the editor.

As an aside, how about having a 'delete all breakpoints' function?

Les

[mandrav]

As an aside, how about having a 'delete all breakpoints' function?

Try "Debug->Breakpoints->Remove all"

As for the other problems mentioned, I 'm aware of some bugs with the breakpoints and I will work on them on the next few days.

[lesnewell]

Try "Debug->Breakpoints->Remove all"

Well, er, that would do the trick  :oops:
Time for new glasses...

Les

[theven]

This behavior is in svn8647, gdb linux 64bit.

Reseting, removing breakpoint, "Debug->Breakpoints->Remove all", restarting CB, restarting system, moving, shifting and breaking line do not help. "Breakpoints" window does not contain this point.

How to fix this or clear all gdb data manually?

[oBFusCATed]

How to fix this or clear all gdb data manually?

Debug -> Remove all breakpoints or execute delete breakpoints command in the command field in the debugger's log window.

Would you like to post the full log of the debugger, so we can see what is going wrong there?

[theven]

Log from Debugger tab:

Code Select Expand

Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: /main/rain/dev/src/ClientLauncher/
Adding source dir: /main/rain/dev/src/ClientLauncher/
Adding file: /main/rain/dev/RAIN/Platforms/Linux64_Debug/ClientLauncher
Changing directory to: /main/rain/dev/RAIN/Platforms/Linux64_Debug/
Set variable: LD_LIBRARY_PATH=.:/main/rain/dev/RAIN/Platforms/Linux64_Debug/:
Starting debugger: /usr/bin/gdb -nx -fullname  -quiet  -args /main/rain/dev/RAIN/Platforms/Linux64_Debug/ClientLauncher
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (Gentoo 7.5 p1) 7.5
Child process PID: 20001
At /main/rain/dev/src/include/RainCore/Containers/DynamicArray.hpp:139

Running stop at line 139, but there are no breakpoints. Stop is only if there is at least one other breakpoint. In the example above, I have points at lines 120, 121, 124, not 139.

"Debug -> Remove all breakpoints" does not help. Execute "clear" in the command field in the debugger's log window delete 4 breakpoints (i have only 3), and after restart the point appears again. Execute "delete breakpoints" does not help too.

In "Debug -> Debugging Windows -> Breakpoints", too, only three.

[oBFusCATed]

Go to the settings of the debugger and provide the full log.

[theven]

Full debug log http://www.everfall.com/paste/id.php?xodh1ueknlj2

[oBFusCATed]

I see no errors in this log. Can you try to reproduce the problem and then provide the log?

[theven]

There are no errors. The problem is always reproduced.

Add breakpoint:
64. [debug]Breakpoint 1 ("/main/rain/dev/src/include/RainCore/Containers/DynamicArray.hpp:93") pending.
Stop:
82. At /main/rain/dev/src/include/RainCore/Containers/DynamicArray.hpp:139

Gist in number of line: 139.

[Jenna]

Can you provide the code that leads to this problem ?
Or other (sample) code, that has the same issue ?

[theven]

The code does not matter. I can insert any code, and there will be a stop. The point is that once set the breakpoint and after removed, it appears again, and again. Maybe it's a gdb bug. We need to determine where the bug, as long as there are reproducible behavior.
A similar case was six months - a year ago. I can not remember what it was.

[theven]

But phantom breakpoint follows the code. I cut and pasted destructor to another location of the same file (inside class), the point has moved along with the code (moved from 139 to line 120 with "if(mBuffer)").

Code Select Expand


136.
137. ~DynamicArrayImplStack()
138. {
139. if(mBuffer) { // <---- There (line 139)
140. for(size_t pos = 0; pos < mSize; ++pos) mBuffer[pos].destroy();
141. Core::Free(mBuffer, mBuffSize*sizeof(T));
142. }
143. }
144.

Code Select Expand


117.
118. ~DynamicArrayImplStack()
119. {
120. if(mBuffer) { // <---- There (line 120)!
121. for(size_t pos = 0; pos < mSize; ++pos) mBuffer[pos].destroy();
122. Core::Free(mBuffer, mBuffSize*sizeof(T));
123. }
124. }
125.

The next thing I did, remove the destructor from the class

Code Select Expand


117.
118. ~DynamicArrayImplStack();
119.
120. IteratorType begin() { return IteratorType( mBuffer[0].getElementPtr() ); } // <---- There!!! (line 120 again)
121.

743.
744. template <typename T, typename BufferStrategy>
745. DynamicArrayImplStack<T, BufferStrategy>::~DynamicArrayImplStack()
746. {
747. if(mBuffer) {
748. for(size_t pos = 0; pos < mSize; ++pos) mBuffer[pos].destroy();
749. Core::Free(mBuffer, mBuffSize*sizeof(T));
750. }
751. }
752.

and the phantom breakpoint remained on line 120! (With method "begin").

[oBFusCATed]

The code does not matter. I can insert any code, and there will be a stop. The point is that once set the breakpoint and after removed, it appears again, and again. Maybe it's a gdb bug. We need to determine where the bug, as long as there are reproducible behavior.
A similar case was six months - a year ago. I can not remember what it was.

Probably the code is inlined in many translation units and the breakpoint is inserted many times.
But I've not seen any commands to delete the breakpoint from your log.
Please do a session reproducing the exact bug you see. And when the breakpoint is hit for the second time execute the gdb command "info breakpoints".