Data Breakpoint: Please change method of data changing detec

Got an idea for enhancing PureBasic? New command(s) you'd like to see?
User avatar
Kurzer
Enthusiast
Enthusiast
Posts: 666
Joined: Sun Jun 11, 2006 12:07 am
Location: Near Hamburg

Data Breakpoint: Please change method of data changing detec

Post by Kurzer »

The data breakpoint debugger is very limited, because it checks a data condition in every line without any advanced cleverness.

A little theoretical example for a better understanding of the problem:
(no deepl translater this time, sorry for my imperfect english)

In line 100 we allocate memory and store the memory address in the variable *mymem.
Until line 200 the program do some stuff with this memory and then the memory will be freed and *mymem set to = 0 again.

In line 250 we allocate again some memory and re-use the *mymem variable. So from line 201 to line 249 *mymem is 0. From line 250 *mymem is again <> 0, because it holds the memory adress of the second allocation.

It is not possible to break at line 250 with a data breakpoint condition like this: *mymem <> 0.
The problem is: The debugger stops the first time at line 100 where *mymem stored the the memory adress of the first allocation. Thats correct so far.

If you now continue the programm the condition will be removed from the data breakpoint window. If you re-enter the condition, the debugger would stop at the next following line (because *mymem ist still <> 0). So if you "get involved with the debuggers game" you have to re-enter the condition for every following line.

You have no chance to stop at the second allocation at line 200, because you would have to enter the condition "*mymem <> 0" 99 times (for line 100 to line 199).

It would be much better, if the debugger checks the condition only, when the data changes. it should ignore the condition after the first match and continues the condition matching after the traced variable changed to a value which does not longer match the condition. That would also make the automatic remove of the condition from the list superfluous and the debugger would stop only at this points where the condition matchs for the first time. This makes much more sense in case of debugging.

Here is a code example to explain the problem in practice:

Code: Select all

Define *mymem = 12345

Debug "Now open the data breakpoint window and set up a new data breakpoint condition"
Debug "Use this condition: *mymem <> 0"
Debug "After this press Enter in the Console window to continue the programm."
Debug "btw: You cannot see your added condition unless you pressed Enter."
Debug "But the data breakpoint window add this condition to the list, even if its invisible at this time (bug?)"

OpenConsole("Test")
Input()

*mymem = 0
*mymem = AllocateMemory(100)

Debug "Imagine, there would be a lot of code here."
Debug "Maybe 100 lines of code and all the time *mymem is Not 0."
Debug "That means, every time you add an new condition *mem <> 0 and continue the programm"
Debug "the debugger will stop at the next line, because *mymem is still <> 0 in every line."

FreeMemory(*mymem)
*mymem = 0

Debug "okay, *mymem is 0 again and we allocate a second time some memory"
*mymem = AllocateMemory(100)

Debug "now try to debug this second allocation with the data breakpoint debugger ;-)"

FreeMemory(*mymem)
*mymem = 0

Image
PB 6.02 x64, OS: Win 7 Pro x64 & Win 11 x64, Desktopscaling: 125%, CPU: I7 6500, RAM: 16 GB, GPU: Intel Graphics HD 520, User age in 2024: 56y
"Happiness is a pet." | "Never run a changing system!"