Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2005-07

Calling unassigned procedure gives no stack trace with -gl

9 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Tom Verhoeff

When the following program is compiled with option -gl -Mdelphi and executed, it results in

An unhandled exception occurred at $00000000 :
EAccessViolation : Access violation

without a stack trace or line numbers. How come? Is that a bug? (If so, I will submit it as such.)

The problem remains when SysUtils is used as well.

This makes it very awkward to find the source of such unhandled exceptions. (Something similar seems to happen with incorrect calls to Format.)

Is there any workaround?

Tom

program UnassignedProcedureBug; { compile with -gl -Mdelphi } { causes an unhandled exception (Access Violation) without stack trace } uses Classes; type TProcedure = procedure of object; TMyClass = class(TObject) public FP: TProcedure; procedure P; end; procedure TMyClass.P; begin writeln ( 'P called' ) end; var VMyClass: TMyClass; begin VMyClass := TMyClass.Create; //VMyClass.FP := VMyClass.P; { with this assignment, it works } VMyClass.FP; { this causes an Access Violation } end. -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25 | Eindhoven University of Technology FAX: +31 40 247 54 04 | PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands
Marcel Martin
to Tom Verhoeff
Tom Verhoeff wrote
begin VMyClass := TMyClass.Create; //VMyClass.FP := VMyClass.P; { with this assignment, it works } VMyClass.FP; { this causes an Access Violation }

Of course, at this point FP = nil since you didn't set it.

mm

Tom Verhoeff
to Marcel Martin: Of course, at this point FP = nil since you didn't set it. mm
Marcel Martin wrote 7 lines
Tom Verhoeff a écrit : >begin > VMyClass := TMyClass.Create; > //VMyClass.FP := VMyClass.P; { with this assignment, it works } > VMyClass.FP; { this causes an Access Violation } Of course, at this point FP = nil since you didn't set it.

Just in case, I was not understood:

The point is that there is no stack trace with line numbers on the (obviously correct) exception, in spite of the option -gl (even when explicitly using SysUtils).

I admit that the comment "it works" is misleading/confusing the issue. I wrote it that way, to show that the program is otherwise fine, and that the exception should indeed be a "normal"/correctly raised exception.

This may be a more general problem with SOME KINDS of unhandled exceptions stack traces/line numbers. Note that, in the following program, you do get a stack trace with line numbers:

program AsssertOk;
uses
  SysUtils;
begin
  Assert(False, 'Assertion failed on purpose')
end.

when compiled with options `-Sa -gl', produces as output

An unhandled exception occurred at $0806834E :
EAssertionFailed : Assertion failed on purpose (assert-ok.pp, line 7) $0806834E
$080540D4
$080480D1 main, line 7 of assert-ok.pp

That is, you get a stack trace with line numbers.

Without using SysUtils you just get (even if you compile w/o -gl):

Assertion failed on purpose (assert-ok.pp, line 7).

Use of SysUtils "converts" the unhandled exception. (Where is that documented?)

Tom

E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25 | Eindhoven University of Technology FAX: +31 40 247 54 04 | PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands
Peter Vreman
to Tom Verhoeff
Show quoted text 14 lines
On Thu, Jul 14, 2005 at 01:12:23AM +0200, Marcel Martin wrote: > Tom Verhoeff a écrit : > >begin > > VMyClass := TMyClass.Create; > > //VMyClass.FP := VMyClass.P; { with this assignment, it works } > > VMyClass.FP; { this causes an Access Violation } > > Of course, at this point FP = nil since you didn't set it. Just in case, I was not understood: The point is that there is no stack trace with line numbers on the (obviously correct) exception, in spite of the option -gl (even when explicitly using SysUtils).

The problem is that the framepointer register EBP is 0 in the sigcontext. We can't solve this.

(gdb) bt
#0 CATCHUNHANDLEDEXCEPTION (OBJ=0x40060054, ADDR=0x0, FRAMECOUNT=0, FRAMES=0x0) at sysutils.inc:206
#1 0x0805275c in DOUNHANDLEDEXCEPTION () at except.inc:168 #2 0x08052bae in fpc_reraise () at except.inc:278 #3 0x080869af in RUNERRORTOEXCEPT (ERRNO=216, ADDRESS=0x0, FRAME=0x0) at sysutils.inc:225
#4 0x0805515e in HANDLEERRORADDRFRAME (ERRNO=216, ADDR=0x0, FRAME=0x0) at system.inc:677
#5 0x0805d50d in SIGNALTORUNERROR (SIG=11, SIGINFO=0xbffff598, SIGCONTEXT=0xbffff618) at sighnd.inc:73
#6 <signal handler called>
#7 0x00000000 in ?? ()
#8 0x08048117 in main () at p.pp:24
(gdb) dir ~/fpc/rtl/linux/i386
Source directories searched: /home/pvreman/fpc/rtl/linux/i386:$cdir:$cwd (gdb) l
24 VMyClass.FP; { this causes an Access Violation } 25 end.
(gdb) fr 5
#5 0x0805d50d in SIGNALTORUNERROR (SIG=11, SIGINFO=0xbffff598, SIGCONTEXT=0xbffff618) at sighnd.inc:73
73
HandleErrorAddrFrame(res,pointer(SigContext^.eip),pointer(SigContext^.ebp)); (gdb) p sigcontext
$1 = (PSIGCONTEXT) 0xbffff618
(gdb) p sigcontext^
$2 = {GS = 0, __GSH = 0, FS = 0, __FSH = 0, ES = 0, __ESH = 0, DS = 2, __DSH = 0, EDI = 0, ESI = 0, EBP = 0, ESP = 123, EBX = 123, EDX = 134932428, ECX = 0, EAX = 3221223688, TRAPNO = 3221223684, ERR = 67584, EIP = 0, CS = 63724, __CSH = 49151, EFLAGS = 0, ESP_AT_SIGNAL = 14, SS = 4, __SSH = 0, FPSTATE = 0x0, OLDMASK = 115, CR2 = 2163270}

Tom Verhoeff
to Peter Vreman
Peter Vreman wrote 8 lines
> Tom Verhoeff a écrit : > > The point is that there is no stack trace with line numbers on the > (obviously correct) exception, in spite of the option -gl (even when > explicitly using SysUtils). The problem is that the framepointer register EBP is 0 in the sigcontext. We can't solve this.

So, where should a solution come from? Where in the software/hardware chain would a change be needed to make it work properly?

Tom

E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25 | Eindhoven University of Technology FAX: +31 40 247 54 04 | PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands
Marco van de Voort
to Tom Verhoeff
Show quoted text 12 lines
On Thu, Jul 14, 2005 at 10:27:01AM +0200, Peter Vreman wrote: > > Tom Verhoeff a ?crit : > > > > The point is that there is no stack trace with line numbers on the > > (obviously correct) exception, in spite of the option -gl (even when > > explicitly using SysUtils). > > The problem is that the framepointer register EBP is 0 in the sigcontext. > We can't solve this. So, where should a solution come from? Where in the software/hardware chain would a change be needed to make it work properly?

For *nix: prt/crt0, there is a xorl %ebp,%ebp But there might be code that relies on this (main program's parent's frame being nil)

Anton Tichawa
to Marco van de Voort
Marco van de Voort wrote 24 lines
>On Thu, Jul 14, 2005 at 10:27:01AM +0200, Peter Vreman wrote: > > >>>Tom Verhoeff a ?crit : >>> >>>The point is that there is no stack trace with line numbers on the >>>(obviously correct) exception, in spite of the option -gl (even when >>>explicitly using SysUtils). >>> >>> >>The problem is that the framepointer register EBP is 0 in the sigcontext. >>We can't solve this. >> >> >So, where should a solution come from? Where in the software/hardware >chain would a change be needed to make it work properly? > > For *nix: prt/crt0, there is a xorl %ebp,%ebp But there might be code that relies on this (main program's parent's frame being nil)

shouldn't this go to fpc-devel?

(sorry, couldn't resist).

Anton.

Peter Vreman
to Tom Verhoeff: So, where should a solution come from? Where in the software/hardware chain would a…
Show quoted text 10 lines
> > The point is that there is no stack trace with line numbers on the > > (obviously correct) exception, in spite of the option -gl (even when > > explicitly using SysUtils). > > The problem is that the framepointer register EBP is 0 in the > sigcontext. > We can't solve this. So, where should a solution come from? Where in the software/hardware chain would a change be needed to make it work properly?

Maybe somewhere in the signalhandler in the kernel.