something to get a proper stacktrace

[ciuly]

hello.

I posted this in the freepascal community but they don't seem to answer there.
I managed to find the lclproc unit but the stacktrace I get from there no matter which of the functions/methods I use has the originating call from the actual place of the error and what path that error followed.

for example, if I do a freeandnil on an invalid pointer/object I will get an AV from the sysutils unit. that really doesn't help.
I need something that goes a little deeper. one more level deeper would be sufficient since that should contain the calling place from my units, BUT, that is not always true. but it is a start.

any ideas?

[Leledumbo]

Hey, I've answered it! Here is goes again: Add -gl to your compiler option. It will show the line number of a file from which the exception occurs. SysUtils will only catch the exception, but it won't do anything unless you you handle it.

[ciuly]

indeed. I have to apologies in the name of the freepacal community administrators for their site not sending me the notification even though I am subscribed to receive it. ugly.

I checked my compile config, because I did get line numbers, and indeed, on debug page, the -gl option is checked (the only one though). is there any other option I need to check on that page or another in order to get DEEPER information?

later edit: here is how currently the stacktrace looks like:

Code: [Select]


  $004E0267  TLOGGER__LOG,  line 440 of logging.pas
  $0040E97B  TLOADBALANCER__ONEXCEPTION,  line 241 of LoadBalancer.pas
  $0040B1E1  TAPPLICATION__HANDLEEXCEPTION,  line 892 of ./include/application.inc
  $004012B0  EXCEPTIONOCCURRED,  line 1367 of Forms.pp
  $005103C0  DOUNHANDLEDEXCEPTION,  line 154 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/except.inc
  $0050BF6C  fpc_reraise,  line 266 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/except.inc
  $0052FA7F  RUNERRORTOEXCEPT,  line 265 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/objpas/sysutils/sysutils.inc
  $00513875  HANDLEERRORADDRFRAME,  line 701 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/system.inc
  $00000000
  $0052875F  FREEANDNIL,  line 112 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/objpas/sysutils/sysutils.inc
  $004F1134
  $005070F7 of TCPTransport.pas
  $0050C169  TOBJECT__FREE,  line 115 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/objpas.inc
  $0052875F  FREEANDNIL,  line 112 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/objpas/sysutils/sysutils.inc
  $004F1134
  $00509C8E of TCPTransport.pas
  $0050C169  TOBJECT__FREE,  line 115 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/objpas.inc
  $00522442  THREADPROC,  line 93 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/objpas/classes/classes.inc

as you can see I don't get teh source of originating call in my code but in fpc which doesn't help in locating the error.
TCPTransport.pas is indeed my unit, it's 20 lines long and contains only a declaration:

Code: [Select]


unit TCPTransport;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, Transport;

type

  { TTCPTransport }

  TTCPTransport=class(TTransport)
  end;

implementation

end.

there is another layer of the tcptransport which is the indy implementation.
so in my eyes, the last part of the stacktrace is not consistent. I need to somehow get into the calling place in my code.

[Leledumbo]

Try recompiling all fpc units stripped (-Xs), but let your unit compiled with -gl. The stacktrace should only print your unit's error now.

[ciuly]

I read through the readme of the rtl and it seems I need to get gnuutils and stuff. gets too complicated.

also, using my logic, I am thinking that if I were to strip the debug info and maybe some other info the only effect would be that that info does not apear in the stack trace. I really doubt that the rtl will go deeper in trhe stacktract if it doesn't find debug info.
in order for your idea to work, the exception handling of fpc is supposed to create a different exceptframe starting point which obviously will not happen.
what I think happens is that the value of bp is saved upon error and at every call made until the error is handled and thus the exceptframes is constructed and then used to iterate back in the stack to trace the error.

if the error originates from your code, this mechanism is fine, but if it originates from the rtl/fcl/3rd party code it is not fine because it does not help you. it is correct as it pinpoints the correct palce of the error, but it will not help.

stripping info will hardly change that behaviour. I'm 99% sure of that. if fpc does that would be the first programming language/framework to do such thing.

basically, what happens is that no matetr if you have debug info or not, the address of the exception on the stacj is known and thus you get a stack trace of addresses. IF you have debug info (and maybe some otehr extra info) you can corelate those addresses with human readable and understandable information like unit lines, procedure/funciton name, etc. stripping that info SHOULD in all cases only eliminate that information, but should leave the behaviour intact.

correct me if I'm wrong

[ciuly]

I played around with the functions already used and got to the point where I sqeezed everything out of it

Code: [Select]


  $004E05C7  TLOGGER__LOG,  line 476 of logging.pas
  $0040E97B  TLOADBALANCER__ONEXCEPTION,  line 241 of LoadBalancer.pas
  $0040B1E1  TAPPLICATION__HANDLEEXCEPTION,  line 892 of ./include/application.inc
  $004012B0  EXCEPTIONOCCURRED,  line 1367 of Forms.pp
  $00510720  DOUNHANDLEDEXCEPTION,  line 154 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/except.inc
  $0050C2CC  fpc_reraise,  line 266 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/except.inc
  $0052FDDF  RUNERRORTOEXCEPT,  line 265 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/objpas/sysutils/sysutils.inc
  $00513BD5  HANDLEERRORADDRFRAME,  line 701 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/system.inc
  $00000000
  $00528ABF  FREEANDNIL,  line 112 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/objpas/sysutils/sysutils.inc
  $004F1494
  $00507457 of TCPTransport.pas
  $0050C4C9  TOBJECT__FREE,  line 115 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/objpas.inc
  $00528ABF  FREEANDNIL,  line 112 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/objpas/sysutils/sysutils.inc
  $004F1494
  $00509FEE of TCPTransport.pas
  $0050C4C9  TOBJECT__FREE,  line 115 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/objpas.inc
  $005227A2  THREADPROC,  line 93 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/objpas/classes/classes.inc
  $00514FA6  THREADMAIN,  line 159 of systhrd.inc
  $7C80B50B  fpc_exp_real,  line 131 of WinExt.pas
  $00000000

which explains why I couldn't get anything to show up from my code: there is nothign to be shown from my code since the problem is with a dieing thread, which probably belongs to indy since I didn't create any thread and the error happens after a few seconds a clietn connectio disconnects.
however that fpc_exp_real which doesn't appear in my version of WinExt.pas makes stuff a little weird, but at least I tracked it down to a thread, which should norrow down the places for me to search for. it would be nice if I could track down the place where the thread was created as well, but ...

[ciuly]

and I tracked down my problem too: I was destroying an indy connection twice.