----- Original Message -----

From: "Waldek Hebisch" <hebisch@math.uni.wroc.pl>

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
>
>

The file vriable and the procedure invocation are declared in other units, as:

procedure iniz; attribute(n ame='Iniz');

get_fnmtmp(fn,'.111');

tmp_opn_fnm(tmp2_pkt,fn,tmpf);

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');

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.