I have a very wierd problem. In a big project, stopping in a breakpoint always works. But, if I simply set to store the session info in a lps file, then step into stops working =( with this error:

http://imagizer.imageshack.us/v2/800x600q90/513/2op1.png

It is the same with Lazarus 1.0.4 + fpc 2.6.2 and also Lazarus SVN + fpc 2.6.2

Windows XP 32 bits

Very wierd ... I already checked the diff between the lpi where step into/over works with the one that is broken and really, only the session info storage differs =/

Deleting the lps file didn't help.

thanks,

Very strange indeed. If it is the session then I have no Idea. Except: Use a logfile for the IDE, and check, if fpc is called with identical arguments.

Also check the diff between debug logfiles:
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

About the error (8 digit address, so you are on win32?): Cannot insert breakpoint,can happen with positive or negative numbers.
- positive: A user set breakpoint
- negative gdb internal breakpoint (used for stepping)

GDB predicted all possible points where the step can end. And one is in memory that gdb can not set a breakpoint.

The address suggests (if normal mem layout applies), that this is inside a dll (system dll). So that would explain why it cant set a breakpoint there.
That can happen, if the dll is executed in a 2nd thread. E.g. the file open/close dialogs, start several system threads.

But how that goes with the session ...? No idea.

------------------------------
This may help:

http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#gdb.exe_has_stopped_working

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140129/58c53981/attachment.html>

Martin Frb wrote

The address suggests (if normal mem layout applies), that this is inside a dll (system dll). So that would explain why it cant set a breakpoint there. That can happen, if the dll is executed in a 2nd thread. E.g. the file open/close dialogs, start several system threads.

There are no DLLs involved and the code is running in the main thread. The project uses some threads, however, but not in this part of the code.

On windows there always are. like kernel32.dll or whatever it is called.

And about threading, even if you do not use them, open a file-open dialog, and there will be some.