Recent

Author Topic: Feature request: Proper call stack  (Read 8746 times)

zex2011

  • New Member
  • *
  • Posts: 17
Feature request: Proper call stack
« on: May 01, 2014, 10:43:08 pm »
When a freeware or trial program crashes on the user's computer, you have only one chance to get the error report. Because after that the unsatisfied customer will probably uninstall the application. That means even the finished production code should contain some sort of debug info.

Every serious developer (including the FPC and Lazarus teams) needs error reports from their customers. Unfortunately, in FPC there's no good compromise between reasonable executable file size and debug information.

One of the most useful things to a programmer is the call stack. Since release code contains no range checking, other debug symbols aren't that useful. So, here's my suggestion about a useful release-code call stack:

1. Add a new compiler directive (say {$CALLSTACK ON} and {$CALLSTACK OFF}). Any procedure or function between these two directives would have additional entry code to add the FileName.ClassName.FunctionName to the call stack and remove it upon function exit.

2. Since constantly repeating FileName and ClassName can occupy lots of space, there should be a table of file and class names, so that function entry code contains just an index to the file and class tables, plus the function name.

3. Make public functions to retrieve the call stack as a string at any moment. So the call stack can be stored, displayed, or uploaded to developer's site as a part of bug report.

For now there's no such option. Yes, one could turn full debug symbols on, but that's a waste of space, since it contains too much. We also have {$I %FILE%} and {$I %LINE%} directives, but not the {$I %FN%} directive to insert the function/procedure name. Because you don't always have the source for that particular version of the module, so the line number may point to another function.

If the system described above would be implemented, customer bug reports would become much more useful, while at the same time executable files wouldn't grow too much in size.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
Re: Feature request: Proper call stack
« Reply #1 on: May 01, 2014, 11:04:05 pm »
The program you distribute does not have to contain any debug information. The way this is normally done is also completely unrelated to the compiler in use:
1) compile the program with full debug info (this does not have to include range checking, that is unrelated to debug info)
2) make a copy of the compiled program
3) strip the copy of the debug info (run the "strip" command on it)
4) ship the stripped copy
5) when a user has a crash and sends you the backtrace, you can use your copy with debug info to translate those addresses back to line numbers

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Feature request: Proper call stack
« Reply #2 on: May 01, 2014, 11:37:18 pm »
There is
 -gl

Which adds only the line number info of the debug info, but nothing else. Yet that is of rather big size already.
Note it adds every single line, not just procedure start,stop. But not knowing where you are in a procedure, is not useful either.

There is a better way anyway.

1) Compile your app with debug info.
2) Make a copy
3) strip.exe thecopy.exe

Now the copy is small and can be shipped.
It will only print addresses, in the stacktrace.

But you can use gdb or the Lazarus IDE to resolve them  (so long as you do not make the exe randomly relocating)

To do that, you must have the exact matching exe, that still has debug info.
In the IDE in the tools menu is an entry "Leak info" (in newer IDE 1.3 "Find source lines for leakstack trace"). It has a resolve button that asks for the exe with debug info.

You can test this yourself. Put an intentional crash in your exe. Make sure you have code reporting the trace. Then follow the steps.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
Re: Feature request: Proper call stack
« Reply #3 on: May 02, 2014, 12:12:51 pm »
There is
 -gl

Which adds only the line number info of the debug info, but nothing else.
That's incorrect: -gl generates full debug information and additionally adds the lineinfo unit. You have to use -g-l to only get the line number info and the lineinfo unit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Feature request: Proper call stack
« Reply #4 on: May 02, 2014, 12:21:58 pm »
That's incorrect: -gl generates full debug information and additionally adds the lineinfo unit. You have to use -g-l to only get the line number info and the lineinfo unit.
Ups, my bad.

Btw, how do you decide between stabs and dwarf if you do -g-l ? 

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
Re: Feature request: Proper call stack
« Reply #5 on: May 02, 2014, 01:10:38 pm »
Btw, how do you decide between stabs and dwarf if you do -g-l ?

-gw -g-l

zex2011

  • New Member
  • *
  • Posts: 17
Re: Feature request: Proper call stack
« Reply #6 on: May 13, 2014, 06:34:06 pm »
Thanks for the answers.

Martin_Fr, I'll use the method you described.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Feature request: Proper call stack
« Reply #7 on: May 13, 2014, 06:43:05 pm »
Just tests that it all works as expected for you, before you ship the exe.

 

TinyPortal © 2005-2018