Bo Berglund wrote 20 lines
On Fri, 29 Jul 2016 14:45:22 +0100, Martin Frb
wrote:
> On 29/07/2016 14:31, Bo Berglund wrote:
>> The GDB command:
>> "-gdb-set confirm off"
>> did not return any result.
> what happens (does gdb return a prompt " (gdb)" for the next commad?),
> if you run (by hand)
> gdb -i mi
> and then enter
> -gdb-set confirm off
>
> what if you alternatively enter
> set confirm off
All of these suggestions do not really mean anything to me. Can you be
more specific?
I have never used gdb by itself, I assume it is used by Lazarus to
handle the breakpoints I set in teh source code, but HOW that is done
is way beyond me.
Can you open a shell or terminal, and in it enter
gdb -i mi
(and then return)
gdb will print some message, and then let you enter gdb commands. Enter
-gdb-set confirm off
(and then return)
copy the output.
Enter
q
to exit gdb
This is just to be on the save side. I expect this will work with no error, in which case there is no easy way to find the problem....
Show quoted text 14 lines
> Sounds like a bug in gdb.
>
> what is in the "debug output" window? (open the window BEFORE pressing F9)
This is what I get:
=thread-group-added,id="i1"
(gdb)
<-gdb-set confirm off>
&"//\n"
&"Undefined command: \"\". Try \"help\".\n"
437^error,msg="Undefined command: \"\". Try \"help\"."
(gdb)
<kill>
Depends on what output you get from the above: run gdb yourself... Assuming that this does not give any error (it probably will be fine), then the bug could be anywhere.
what else did you upgrade? Lazarus? FPC?
From the code in components\lazdebuggergdbmi\cmdlinedebugger.pp
Show quoted text 10 lines
DoDbgOutput('<' + ACommand + '>'); // this causes the log in the
debug output, the ACommand is correct here
if ACommand ''
then FDbgProcess.Input.Write(ACommand[1], Length(ACommand));
// store LineEnding in local variable, so the same statement can
be used
// for windows and *nix (1 or 2 character line ending)
LE := LineEnding; // this hopefully is a lineend
\n (gdb output suggest it got a line end)
FDbgProcess.Input.Write(LE[1], Length(LE));
But it seem gdb did not get the command, it got "//" instead. the "&" in the text, is gdb echoing back what it got.
I have no idea where that could have been lost/changed.... (assuming I interpret this correct)
I dont know if some of those could be caused by changes in fpc. if I remember correctly fpc TProccess may start a terminal/shell. Maybe there is a change there?
Do you have a pstree (or use ps with parent pid), to see the parent of gdb process?
Sorry but at this stage I dont have any more than those (wild) guesses.
----------------
There is something else in the output that makes no sense. the 437 does not belong there.
I dont know if gdb generated this, or if something else in the middle caused it.
Usually all gdb output is prefixed &, ^, * and a few chars like that.
The GDB line starts with the ^ after the 437. That strongly suggests something else printed that. (And it is not your app, the IDE has not even send the filename at this stage, so your app can not be loaded yet)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160730/abc51768/attachment.html>
