----- Original Message ----- From: "Waldek Hebisch" hebisch@math.uni.wroc.pl To: gpc@gnu.de Sent: Tuesday, February 28, 2006 10:54 PM Subject: Re: Problem with gpc20060215 under Red Hat Enterprise Linux ES release
Hi Waldek,
I applied the gdb-6.3.diff to the gdb 6.3 and now the segmentation fault stack is showed correctly. The problem is related to a rewrite operation under trap handler, it seems that the _p_Rewrite procedure received a wrong pointer to file variable.
Pascal source code which generate the segmentation fault:
procedure tmp_opn_fnm (var p : iop_out_t; var fn: fil_spec_t; var f : text); var fs: string(fil_spec_l); tstr: TString;
procedure TrapRewriteIOErr (Trapped : Boolean); begin if Trapped then begin ioerr := true; tstr := TrappedErrorMessageString; end else begin rewrite (f,fs); end end;
begin fs := fn.body; SetLength(fs,fn.length); TrapExec(TrapRewriteIOErr); {apertura file in output} TrapReset; if (ioerr = true) then begin ios_traperr (tstr); prg_abort; end; p.trnctr := p.trnctr + [iop_opn]; end;
This source is incomplete
Segmentation Fault Stack frames:
(gdb) run Starting program: /dktlvqpe1/grfdev/ags/grfpkglnxv12/grfc.exe GRF> cc_gra_sc.smt /out= cc_gra_sc.c Program received signal SIGSEGV, Segmentation fault. 0x0807ef1a in _p_InternalOpen (f=0x0, FileName=0xbfffe238 '/dktlvqpe1/grfdev/ags/grfpkglnxv12/cc_gra_sc.111', Length=1, BufferSize=1, Mode=Fo_reset) at files.pas:1639 1639 if f^.Status.Untyped then (gdb) where #0 0x0807ef1a in _p_InternalOpen (f=0x0, FileName=0xbfffe238 '/dktlvqpe1/grfdev/ags/grfpkglnxv12/cc_gra_sc.111', Length=1, BufferSize=1, Mode=Fo_reset) at files.pas:1639 #1 0x08084fab in _p_Rewrite (f=0x0, aFileName=@0xbfffe230, FileNameGiven=true, BufferSize=1) at files.pas:3238 #2 0x0804fe9b in Traprewriteioerr.1 () at grfuxtmp.p:85 #3 0x0807311f in Docall.0 () #4 0x080732fb in dosetjmp () #5 0x080731e4 in _p__M4_Trap_S3_Trapexec () #6 0x08050024 in tmp_opn_fnm (p=@0x80a2940, fn=@0xbfffe2f0, f=@0x80a28ec) at grfuxtmp.p:94 #7 0x08051c17 in iniz () at grfcdini.p:169 #8 0x080511ce in mcm_begin () at grfcdpin.p:154 #9 0x0804b100 in main_pre (d_verb='GRF ') at grfdpmai.p:50 #10 0x0804a06c in main program () at grfidt.p:8 #11 0x0804a0e1 in main (argc=1, argv=0xbfffe494, envp=0xbfffe49c) at <implicit code>:14 (gdb)
it seems that _p_Rewrite function receives a wrong paramenter (0x0) as a reference to a file (f) variable. Does such variable (referenced by TrapExec nesting calls) to be defined with specific attributes?
No, it should just work. Since your source is incomplete I tried to add missing parts to it. However, my completed version works fine. Have you verified that the argument to tmp_opn_fnm is initialized? The backtrace shows non-null value, but the backtrace may be inaccurate, so it is better to print value of your variable.
-- Waldek Hebisch hebisch@math.uni.wroc.pl
Hi Waldek,
The file vriable and the procedure invocation are declared in other units, as:
unit grfeveis; interface const ..... var tmpf : text; tmpf2: text; sym: text; ..... end.
unit grfcdini; interface uses ...,grfeveis; procedure iniz; attribute(n ame='Iniz'); implementation procedure iniz; var fn: file_spec_t; begin ... get_fnmtmp(fn,'.111'); tmp_opn_fnm(tmp2_pkt,fn,tmpf); ... end ... unit grfuxtmp; interface uses GPC,Trap,...,grfeveis; procedure tmp_opn_fnm (var p : iop_out_t; var fn: fil_spec_t; var f : text); attribute(name='Tmp_opn_fnm'); implementation procedure tmp_opn_fnm (var p : iop_out_t; var fn: fil_spec_t; var f : text); var fs: string(fil_spec_l); tstr: TString;
procedure TrapRewriteIOErr (Trapped : Boolean); begin if Trapped then begin ioerr := true; tstr := TrappedErrorMessageString; end else begin rewrite (f,fs); end end;
begin fs := fn.body; SetLength(fs,fn.length); TrapExec(TrapRewriteIOErr); {apertura file in output} TrapReset; if (ioerr = true) then begin ios_traperr (tstr); prg_abort; end; p.trnctr := p.trnctr + [iop_opn]; end; _______________________________________________________________________ The problem is related to the fact that file variable tmpf isn't initialized automatically, I set a beakpoint at the beginning of the program (main_pre) and I saw that some file variables (inp, ou) declared in unother pascal unit (prenv) were properly initialized, but which (tmpf, tmpf2, sym) declared into the grfeveis unit are not initialized. In fact the gdb report is:
(gdb) break main_pre Breakpoint 1 at 0x804b0a7: file grfdpmai.p, line 44. (gdb) run Starting program: /dktlvqpe1/grfdev/ags/grfpkglnxv12/grfc.exe
Breakpoint 1, main_pre (d_verb='GRF ') at grfdpmai.p:44 44 if not(prg_host in [1,3]) then cli_setraw; (gdb) where #0 main_pre (d_verb='GRF ') at grfdpmai.p:44 #1 0x0804a06c in main program () at grfidt.p:8 #2 0x0804a0e1 in main (argc=1, argv=0xbfffb4d4, envp=0xbfffb4dc) at <implicit code>:14 (gdb) print _p__M5_Prenv_S7_Inp $1 = {_p_File_ = 0x9f83080} (gdb) print _p__M5_Prenv_S9_Ou $2 = {_p_File_ = 0x9f7f000} (gdb) print _p__M8_Grfeveis_S2_Tmpf2 $3 = {_p_File_ = 0x0} (gdb) print _p__M8_Grfeveis_S3_Tmpf $4 = {_p_File_ = 0x0} (gdb) print _p__M8_Grfeveis_S4_Sym $6 = {_p_File_ = 0x0} (gdb) __________________________________________
The question is: Why such file variables aren't initialized automatically at the program start? I need to call some internal gpc function to force the proper initialization?
Thank you very much in advance for your help.
Kind regards.
Angelo Fumagalli