Recent

Author Topic: Debugging, using run/pause  (Read 320 times)

sporer@sctn.de

  • New Member
  • *
  • Posts: 22
Debugging, using run/pause
« on: September 07, 2019, 04:06:47 pm »
I am trying to debug a code that hangs for a while at an unknown position and then continues after some time. I suppose it is related to TProcess.Execute, TProcess.Terminate.
I have compiled in standard debug mode on IDE v1.2.4/FPC 2.6.4 on raspbian jessie.

When I press Run/Pause execution is halted and I get an Assembler listing.
What I need is the codeline where execution is paused.

Is it possible to get that?

Thank you in advance.


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5714
    • wiki
Re: Debugging, using run/pause
« Reply #1 on: September 07, 2019, 04:32:37 pm »
Try the Thread and Stack windows from Menu: View > Debug Windows

Pause may hold you in a random thread (even if you have no threading, on some OS the debugger may add threads).

So set each thread to current. And see if the stack window shows something.

Thaddy

  • Hero Member
  • *****
  • Posts: 9191
Re: Debugging, using run/pause
« Reply #2 on: September 07, 2019, 04:43:19 pm »
Try TProcessAsync instead of TProcess. My feeling is Tprocess is hold back by external processing.
also related to equus asinus.

sporer@sctn.de

  • New Member
  • *
  • Posts: 22
Re: Debugging, using run/pause
« Reply #3 on: September 07, 2019, 04:47:27 pm »
Try the Thread and Stack windows from Menu: View > Debug Windows

Pause may hold you in a random thread (even if you have no threading, on some OS the debugger may add threads).

So set each thread to current. And see if the stack window shows something.

You mean that I should use the halt function and then watch the thread and Call Stack windows?
Indeed, the Stack window gives me a listing with line numbers (some of them are 0)

Am I using the last entry in the list to identify the line in the source code?

sporer@sctn.de

  • New Member
  • *
  • Posts: 22
Re: Debugging, using run/pause
« Reply #4 on: September 07, 2019, 05:03:53 pm »
Quote
Try TProcessAsync instead of TProcess. My feeling is Tprocess is hold back by external processing.

It seems that the version I am using is not supporting this type.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5714
    • wiki
Re: Debugging, using run/pause
« Reply #5 on: September 07, 2019, 05:19:45 pm »
Once you paused your app, open both the windows.

In the thread window, you can select an entry by mouse, and then must use the tool-button "current" to make it active.
If you press "current" the stack will likely change.

On the stack, you can double click, which should take you to the source code (if a line and source file are shown).
You can use the tool-button "green arrow" / "->" (or "current" depending on Lazarus version) to activate the stack frame.

If you "activate" a stack frame locals, watches and value hints will be shown according to that stack frame.

If your top frame has no source, but you have sources maybe for the 2nd or 3rd (or further down) frame, then you can then set breakpoints in that code (after the line that is highlighted when double clicking).
You can then run to that breakpoint, and single step from there.

If you do not reach that breakpoint, then your app may hang in the called code (upper frames).

sporer@sctn.de

  • New Member
  • *
  • Posts: 22
Re: Debugging, using run/pause
« Reply #6 on: September 07, 2019, 05:28:45 pm »
Once you paused your app, open both the windows.

In the thread window, you can select an entry by mouse, and then must use the tool-button "current" to make it active.
If you press "current" the stack will likely change.

On the stack, you can double click, which should take you to the source code (if a line and source file are shown).
You can use the tool-button "green arrow" / "->" (or "current" depending on Lazarus version) to activate the stack frame.

If you "activate" a stack frame locals, watches and value hints will be shown according to that stack frame.

If your top frame has no source, but you have sources maybe for the 2nd or 3rd (or further down) frame, then you can then set breakpoints in that code (after the line that is highlighted when double clicking).
You can then run to that breakpoint, and single step from there.

If you do not reach that breakpoint, then your app may hang in the called code (upper frames).

Thank you for your very detailed instructions. I will bookmark them for further reference.
But this time it was simply a LINUX problem.
I rebooted the MCU and ran the code again under the IDE and the problem was gone.