Lazarus debugger fail in Ubuntu 13.04

[macmike]

I'm using the English versions. Where can I find the log file?
(sorry for the dumb question!)

As I wrote earlier in this thread:
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

Sorry, I need to read more and type less 

I'm using Laz 1.0.8 (which is awesome cakes) FPC: 2.6.2 on i386-linux-gtk 2

I set a breakpoint on some code and then when it gets invoked I'm hovering over a variable, at that point a tooltip shows saying the var=??? which is not surprising as it's a property with an accessor. More importantly though the debugger appears to crash in that I can't move in or over the next statement (F7,F8) or out of the method. In fact pressing run F9 doesn't do anything either.

Pressing the stop button doesn't stop the debugging app and the breakpoint no longer stops execution. Here's what I think is the relevant bit of the log?

[Martin_fr]

. More importantly though the debugger appears to crash in that I can't move in or over the next statement (F7,F8) or out of the method. In fact pressing run F9 doesn't do anything either.

Pressing the stop button doesn't stop the debugging app and the breakpoint no longer stops execution. Here's what I think is the relevant bit of the log?

Indeed seems you found a bug in gdb. And gdb crashed:

Code: [Select]

<< TCmdLineDebugger.ReadLn "&"/build/buildd/gdb-7.6~20130417/gdb/parse.c:588: internal-error: mark_struct_expression: Assertion `parse_completion && expout_tag_completion_type == TYPE_CODE_UNDEF' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.""
  [Debugger] Log output: &"/build/buildd/gdb-7.6~20130417/gdb/parse.c:588: internal-error: mark_struct_expression: Assertion `parse_completion && expout_tag_completion_type == TYPE_CODE_UNDEF' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable."
  << TCmdLineDebugger.ReadLn "&"\n""
  [Debugger] Log output: &"\n"

GDb may be able to recover and continue, after this crash (may be, or may not be.)

The problem is that gdb does not print the prompt, that it is ready for the next command. So the IDE waits indefinitely.


You may want to try, and change between stabs and dwarf (whatever you currently use). Maybe that will fix the error.
If you do, ensure you do for *ALL* packages, that have debug info.


If it doesn't help, you can try and configure a timeout.
In the debugger page of the option dialog is a property grid. This has an entry "TimeOutForEval" set it to 50. (And disable the "WarnOnTimeOut" if you like.)

[miguel-laz]

An English gdb will reply with a phrase containing "not being run" (as the program is not being run), and the IDE checks for this text.
Your gdb responds  (as you actually pointed out correct)
Code: [Select]
&"info program\n"
~"El programa que ha sido depurado no estaba corriendo.\n"

The IDE does not understand this, and assumes something went wrong.

I can not understand that the answer is a text and not a numeric identifier unique to the gdb reply message, do not understand!. Not a criticism to the work done by the developers of Lazarus, is a thought.

I searched a parameter to force "gdb" to work internally with the English language for message, but I have not found.
Could this be a workaround?

Should I report this bug somewhere else that Lazarus developers it fixed in future revisions?
What I can do to fix the problem? Any solution?

[BigChimp]

I can not understand that the answer is a text and not a numeric identifier unique to the gdb reply message, do not understand!. Not a criticism to the work done by the developers of Lazarus, is a thought.

Should I report this bug somewhere else that Lazarus developers it fixed in future revisions?
What I can do to fix the problem? Any solution?

You could report it at the gdb bugtracker so they build in numeric result codes, I'd say...

[Martin_fr]

GDB provides a "machine readable" interface -mi
And Lazarus uses this.

But not all commands are available in this. So Lazarus still needs to use some of the human commands.

Over the years GDB responses (English) from many platforms, and lots of gdb versions have been collected. There are already many differences there (last gdb 7.5 changed some spacing, and fooled the IDE).

It will be near impossible to collect all that info, in dozens of extra languages. And even if, it will be a
maintenance issue.

One could add translation files, which the IDE can load, and which the user(s) can maintain. That would actually be a good idea. But I do not know if or when I would have time for that.

----
For now: you can search
     debugger\gdbmidebugger.pp

It has all the text fragments. Search for "info program", "info file"

You will find several bits like this or similar

Code: [Select]

  if CmdRes
  then CmdRes := ExecuteCommand('info program', R, [], 1500); // Hardcoded timeout
  if (not CmdRes)
  or (Pos('not being run', R.Values) <= 0)
  then begin

You need to change the  (Pos('not being run', R.Values) <= 0)
to

Code: [Select]

(
   (Pos('not being run', R.Values) <= 0)
and
   (Pos('sido depurado no estaba corriendo', R.Values) <= 0)
)
or similar

Note: it is "and" here, because it is an error, only if both fail. In other cases below, it may be "or"

Otherwise use your language only. But I advice to keep the english, in case the text exists in more than one message, and is not always translated.

----
The following is OK / IT is NOT yet translated

Code: [Select]

    if ExecuteCommand('info program', [], R, [cfCheckState])
    then begin
      s := GetPart(['child process ', 'child thread ', 'lwp '], [' ', '.', ')'],

----
For info file

Code: [Select]

    if ExecuteCommand('info file', R)
    then begin
      if rfNoMI in R.Flags
      then begin
        FileType := GetPart('file type ', '.', R.Values);
        EntryPoint := GetPart(['Entry point: '], [#10, #13, '\t'], R.Values);
use "tipo de archivo "
and "Punto de entrada: "

Note spaces at end

"S\303\255mbolos desde \302\253/home/miguel/Programacion/LazarusTest1/project1\302\273.\n"
~"Local exec file:\n"
~"\t`/home/miguel/Programacion/LazarusTest1/project1', tipo de archivo elf64-x86-64.\n"
~"\tPunto de entrada: 0x446cb0\n"

----
If you want threads to update *while* running (it is no problem to skip that) also search for thread-created', 'thread-exited'

""[Nuevo Thread 0x7fffecaf9700"

[BigChimp]

GDB provides a "machine readable" interface -mi
And Lazarus uses this.

But not all commands are available in this. So Lazarus still needs to use some of the human commands.

Over the years GDB responses (English) from many platforms, and lots of gdb versions have been collected. There are already many differences there (last gdb 7.5 changed some spacing, and fooled the IDE).

It will be near impossible to collect all that info, in dozens of extra languages. And even if, it will be a
maintenance issue.

One could add translation files, which the IDE can load, and which the user(s) can maintain. That would actually be a good idea. But I do not know if or when I would have time for that.

Wouldn't it be much better to raise a bug with gdb that the -mi interface needs to be extended?
----

[Martin_fr]

Wouldn't it be much better to raise a bug with gdb that the -mi interface needs to be extended?

You can go and report them...

I actually need to check. Seems there are some new ones (maybe already for a while) which the IDE does not yet use.


But the IDE also must maintain the old stuff, because on some platforms only old GDB are available (Mac is is still at 6.3.50)

[BigChimp]

Wouldn't it be much better to raise a bug with gdb that the -mi interface needs to be extended?

You can go and report them...

I'll leave that to Miguel as he has the actual problems...

But the IDE also must maintain the old stuff, because on some platforms only old GDB are available (Mac is is still at 6.3.50)

I understand.

[miguel-laz]

You could report it at the gdb bugtracker so they build in numeric result codes, I'd say...

I do not feel able to report a problem I really do not understand well, besides my English is basic, I use google-translator, I can hardly express something so complex.

I think the problem should be addressed by the easy way, I think it'll force "gdb" to that uses only English message strings.

I will continue looking for a solution this way.

[Martin_fr]

You do not need to report them.  At the moment it would not benefit us much.

Lot me know if the change to gdbmidebugger are helping you.

Or lets see if we can add info, how to get an english gdb. But that would have to come from some one who knows the linux distro very good.

[miguel-laz]

Finally I tried to send an email to gdb-patches@sourceware.org for help, but it's not possible, "Invalid mime type" text / html "detected in message text or attachment. Please send plain text messages only."

I do not understand anything.

[exdatis]

Just set your mail client to send text messages?

[Martin_fr]

Finally I tried to send an email to gdb-patches@sourceware.org for help, but it's not possible, "Invalid mime type" text / html "detected in message text or attachment. Please send plain text messages only."

I do not understand anything.

They have a web based bug tracker.

But without a list of thinks that we need, nothing will happen.

Even then, some one on their team would need to be interested to do the work, or patches need to be supplied.

Trying to change gdb would be a very lengthy process. Unless we can sent them patches.

[miguel-laz]

Just set your mail client to send text messages?

I use Gmail, I've pasted the text as "plain text" and I marked the message as "plain text" ....

It seems that this time it was sent, fingers crossed! and to wait for the answer ...

[Martin_fr]

gdb-patches is for patches not general question...

But besides that: I do not *know* how to change the gdb language. But I *believe* it is an installation issue.  The language is probably compiled in. So you need to re-install re-compile gdb. How exactly to do that is probably something that depends on your linux distro (but I do not know).