[Lazarus] invisible break points??

[Martin]

On 07/01/2011 22:59, David Emerson wrote:
> I'm attaching some debug output. One of the logs was an execution with no
> breakpoints (view>  debug info>  breakpoints list is empty; also the lpi file
> has no breakpoints) and in the other execution I created one breakpoint.
>
> In the execution with no breakpoints, everything went smoothly.
>
> In the execution with the one breakpoint, the program stopped at debug log line
> 186,
> *stopped,reason="breakpoint-hit",bkptno="38", [...]
> (gdb)
>
> However, when I say the "program stopped", lazarus did not behave as if it had
> encountered a breakpoint. The lazarus main and source windows did not raise; in
> the source editor, the line with the breakpoint is marked with a red highlight
> and checkmark, not with a blue highlight and arrow. Pressing F9 (while focused
> on the source window) has no effect whatsoever. The call stack window is empty,
> and the gdb debug output window does not show any stack info, either.
Hm, I guess part of the problem is that console output of the 
application does not work well with gdb. It seems to mix with the gdb 
output....

 From your log:
=====  
Databas*stopped,reason="breakpoint-hit",bkptno="38",thread-id="1",frame={addr="0x08073656",func="T_COMMAND_WINDOW__DO_MY_THING_BUTTON_PRESS",args=[{name="SENDER",value="0xb76998e0"},{name="this",value="0xb7861f10"}],file="ab_fpgui_types_unit.inc",fullname="/ab/Pascal/ab_fpgui_types_unit.inc",line="230"}
(gdb)

the msgs from gdb goes on the same line, as the app's output.
There is nothing the IDE can do, it has no chance of  identifying the 
gdb output, or knowing there was a breakpoint...

see http://bugs.freepascal.org/view.php?id=12172
I haven't looked at this issue further, not sure if there are updates or 
when there will be. (I know not the news anyone wants to hear; but it 
seems it's a bug that will take a while to fix / we are unfortunately 
bound to gdb, there isn't any better solution yet)

Btw: which version of gdb do you use? [edit: found answer]
IIRC you are using a very recent Lazarus

I wonder so, the IDE should see the "(gdb)" prompt....
If you start lazarus from a console, can you watch out for an error msg 
like one of those? [edit: found answer]
    ERROR: Got stop params, but did not chnage FTheDebugger.state: ...
    ERROR: Got NO stop params at all, but was running

You can look for them in gdmidepugger.pp and add code like
    SetDebuggerState(dsPause);
it may prove a workaround for your case, but could break other stuff, 
and certainly is not the solution....
You can see there is a commented error-state in this place. => problem 
is there is indeed a valid case where this can happen..... (don't 
remember details though)

------------------
As for the rest that happens, when you set/unset the breakpoints....

The IDE believes the app is still runing (at least that is the most 
likely case to be concluded from the details provided)

> I clicked on the breakpoint line in the source editor, and pressed F5 to remove
> the breakpoint. The gdb window shows:
> <-break-delete 38>
> ^done
> (gdb)
>
> However the program is still not moving.
In order to remove the breakpoint, the IDE does have to send a interrupt 
(SigInt) to the app, otherwise gdb can not be told to perform anything 
(the app must pause temporarily)

The IDE should continue "exec-continue" after deleting the breakpoint, 
strange that it does not. So possible to be explained, because the IDE 
expects to be in the run command, that would take care => only it is 
not.....

> So at this point, I put the same breakpoint back in. The gdb window shows:
> <-break-insert -f ab_fpgui_types_unit.inc:230>
> ^done,bkpt={number="39",type="breakpoint",disp="keep",enabled="y",addr="0x08073656",func="T_COMMAND_WINDOW__DO_MY_THING_BUTTON_PRESS",file="ab_fpgui_types_unit.inc",fullname="/ab/Pascal/ab_fpgui_types_unit.inc",line="230",times="0"}
> (gdb)
> <-break-enable 39>
> ^done
> (gdb)
> <-exec-continue>
> ^running
> (gdb)
So somehow the IDE recovers and starts the app


> *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",thread-id="1",frame={addr="0x08073656",func="T_COMMAND_WINDOW__DO_MY_THING_BUTTON_PRESS",args=[{name="SENDER",value="0xb76998e0"},
> {name="this",value="0xb7861f10"}],file="ab_fpgui_types_unit.inc",fullname="/ab/Pascal/ab_fpgui_types_unit.inc",line="230"}
> (gdb)
> <-stack-info-depth>
> [...] and all the rest.
Caused by the earlier attempt to pause the app, while it was actually 
already halted

Have you tried, if you can F9 after that, and continue?


>> version of gdb?
> GNU gdb 6.8-debian
>

ah, ok...

>> Also start Lazarus from console, and watch for any output of the IDE. It
>> may report something there....
> Yes, it does give this interesting output when the program myteriously stops:
> ERROR: Got NO stop params at all, but was running
>
ah, ok...



>> An other issue is that if you open 2 independent copies of the same file
>> (via different sym links) you may be able to irritate the IDE, and the
>> breakpoint may be in the one copy, the execution mark in the other...
> This *is* extremely annoying, actually -- the IDE often opens up multiple copies
> of the same (symlinked) source all on its own. Not at all sure why it does
> this, but it's very irritating. However, in this case, I made sure no copies
> were open; and even if there were, F9 should resume execution.
>
> I guess I'll report this on Mantis, now that there's presumably enough info to
> do so.

Well it is already on mantis.....

I don't know, but can you somewhere in the "run param" specify an output 
redirection for your app?
Since you do not seem to need console input, if you could simply 
redirect all the stuff printed by you app, into a file? then tail the 
file while you debug....

Not sure if it is possible, just an idea, till something better comes up.


> Any idea how to "clean" my project, so it doesn't do this? Perhaps I just need
> to create a new project from scratch? Or delete the project.compiled file, or
> something? I'll play around.
>
the symlinked files may come from old lpi/lps files ... either in 
project file or in ~/.lazarus/projectsessions
the IDE did have issues creating some invalid pathes, but the ones I 
knew of have been fixed (but pathes in lpi/lps would remain)