debugging stops in TControl.Click

[Middlecope]

On linux (OpenSUSE 12.3) machine
FPC 2.7.1, x86_64-linux gtk2, SVN Lazarus Revision 41152
After updating to the above configuration the F8 doesn't work properly.
It starts at the breakpoint and after some lines I enter in "control.inc" and staying in FOnClick(Self)
Does anybody has an idea what went wrong?

[Martin_fr]

What is your version of gdb?

* Even so it may have previously worked, please check your configuration.

* What does the stack window show?

* Finally please provide a log:
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

When you provide the log, please also show the snippet of your source (your ButtonClick), indicate where the breakpoint was.

-----------------
Which of these have you (or could you have ) recently updated!
- fpc
- gdb


There was a similar post on the mailing list, but no conclusion yet.

[Middlecope]

It happens after updating the fpc to 2.7.1 Before that I worked with 2.6.2 and the source code was 2.7.1 (ignoring the warning about code completion)
gdb is not changed  and is 7.5.1-2.1.1-x86_64
I tried to attach the laz.log. It is too large.
Can you give a hint where to look for?
The cursor hangs in control.inc

Code: [Select]

{------------------------------------------------------------------------------
       TControl Click
------------------------------------------------------------------------------}
procedure TControl.Click;
begin

  //DebugLn(['TControl.Click ',DbgSName(Self)]);
  if Assigned(FOnClick) and (Action<>nil)
  and (not CompareMethods(TMethod(Action.OnExecute),TMethod(FOnClick))) then
    // the OnClick is set and differs from the Action => call the OnClick
    FOnClick(Self)
  else if (not (csDesigning in ComponentState)) and (ActionLink <> nil) then
    ActionLink.Execute(Self)
  else if Assigned(FOnClick) then
    FOnClick(Self);   //Here the cursor is hanging. After 2-10 F8 it continues
end;   Fpc and lazarus are only in /home/user/
My configuration is in directory /home/ser/.lazarus  Not in  /etc/lazarus.
Thanks for your attention

[Martin_fr]

On the linker page, of the project options

Does it change the behaviour if you use stabs or dwarf?

[Middlecope]

The linking was "Automatic -g" changing to "stabs" or "dwarf2" did not change the debug behaviour.

[Martin_fr]

Ok, looked at the log.

BTW: Do all the lines (except empty ones) in your procedure show the blue dots on the left?

-------------

I can see from a technical point what is happening. But it is either in fpc or GDB (or both), and I will have to see if I can get some infos from others. (hopefully someone will have an idea)

The IDE is sending the right command, but gdb comes to an unexpected result.

Technically/internally what happens is:
- the step (F8) you are trying to do includes a fpc_ansistr_copy   "Copy(s,i,j)"
  (But it does not have to be this, it can be others, as I have seen from another person with the same issue)
- gdb believes the step end inside the copy. so it stops in the fpc code.

So technically you stepped into this function. Since this function has no debug info (other than the name, but there is no file or line) it can not be shown.
The IDE seeks the caller. (Which is your procedure). But the RTL (and therefore fpc_ansistr_copy are optimized. This optimization changes how the stack is organized. And it hides the direct caller.
So only the 2nd caller can be found and is shown.

-----
I will see if I can find some more info.
I am afraid that is likely to take quite a while.

[Martin_fr]

This may be the same as:
http://bugs.freepascal.org/view.php?id=14399

[Middlecope]

I changed the FPC back from 2.7.1 to 2.6.2
Now the debugging is correct.
Conclusion: FPC 2.7.1 on linux can not handle debugging ansistrings correct.
I am an old man and not very bright. I hope someone can fix the problem in the future
I love FPC and LAZARUS

[Martin_fr]

A guess it is just a coincident that it is ansistring.

AFAIK GDB analyses certain bits of the machine code (assembler) in a debugged app. And it *probably* (I guess) just happens that some of the ansistring handling code now looks to GDB like something GDB would be meant to stop at.

But that is just a guess so far.