[fpc-devel]Re: Another problem with fpc v1.1

[Sergey Korshunoff]

I found only one answer for the problem.
About the story again...

> 20  June 2002 04:14, Sergey Korshunoff wrote:
> > There is another problem with fpc v1.1
> > It is exposed (under Linux) when you add a cmem.pp into pp.pas
> > ( Uses cmem, ...)
> >
> > And you must add the following lines to parser.pas
> >
> >               orgpattern:=oldorgpattern;
> >               token:=oldtoken;
> >               idtoken:=oldidtoken;
> >               akttokenpos:=oldtokenpos;
> >               block_type:=old_block_type;
> >               current_scanner:=oldcurrent_scanner;
> > +              if current_scanner.inputfile.name = nil then
> > +                WriteLn(StdErr,'AAAAAAAAAAAAAAAAAAa') else
> > +                WriteLn(StdErr,'AAA:',current_scanner.inputfile.name^);
> >
> >               parser_current_file:=current_scanner.inputfile.name^;
> >               { restore cg }
> >               nextlabelnr:=oldnextlabelnr;
> >               parse_only:=oldparse_only;
> >               { restore asmlists }
> >
> > Look for output. For me it is like this:
> >   AAA:cpuasm.pas
> >   AAA:assemble.pas
> >   AAA:ag386att.pas
> >   AAA:ag386att.pas
> >   AAA:cpuasm.pas
> >   AAA:symsym.pas
> >   AAA:symdef.pas
> >   AAA:symdef.pas
> >   AAA:f─═/НW@ GETTYPEDEF╝°
> >   AAA:browlog.pas
> >   AAA:compiler.pas
> >   AAA:compiler.pas
> >   AAA:parser.pas
> >
> > A strange names appears only when we use cmem. And not
> > always in the same place. But definitely there is an error
> > somewhere (I always get an error building fp with such compiler). Because
> > fpc v1.0 do not have any problem with cmem then error is in fpc v1.1 (not
> > in cmem).
>
> I found (after testing) that the same problem go out when You change
> 512 to 352 (and below) in maxblocksize definition (rtl/inc/heap.inc).
> In such case You can not build fpc v1.1 too.

My answer: fpc v1.1 use a stack of modules which must be compiled
(may be as a local variables in parser.pas). Sometimes
this dynamic variable is destoryed (  aTInputFileVar.Free is executed), 
but it is keept in stack and fpc v1.1 go to use this already invalid 
reference.

Why we can not see a problem in standard configuration?
    there is a _big_ chance (for a standard heap.inc realization) that
    a freed block is used again for the same type of variable 

I think we can raise this error too by increasing a blocksize value in
heap.inc

What I found with fpc v1.1 made with
     maxblocksize := 304 + blocksize;
in rtl/inc/heap.inc.

I use the following commands:
  rm *.o *.ppu # it is important !!!
  gdb ./ppc1
  >set args -Fui386 -Futargtes
  >b main
  >b finput.pas:174
  >r
  ...

For me ppc1 go out in modified parser.pas when it
is executing

  WriteLn(StdErr, "AAA: ", current_scanner.inputfile.name^);

for inpufile "symtable.pas". But this instance of
tinputfile was destoryed before. After this
there was created a new instance of
the tinputfile('symtable.pas'), but
fpc go to use an old one too.

Here is a backtrace for point where
a first instance of tinputfile("symtable.pas")
was destoryed:

(www is a static var in fpinput.pas,
which holds an adress of  tinputfile.name='symtable.pas')

Hardware watchpoint 7: WWW^

Old value = 1078932964
New value = 0
STRINGDISPOSE (P=$0) at cutils.pas:620
620           end;
(gdb) bt
#0  STRINGDISPOSE (P=$0) at cutils.pas:620
#1  $0810d3bb in TINPUTFILE__DESTROY (this=$40580254) at finput.pas:210
#2  $08126b8f in TOBJECT__FREE (this=$40580254) at objpas.inc:128
#3  $0810da92 in TINPUTFILEMANAGER__DESTROY (this=$401ace94) at finput.pas:525
#4  $08126b8f in TOBJECT__FREE (this=$401ace94) at objpas.inc:128
#5  $0810a689 in TMODULE__RESET (this=$40580184) at fmodule.pas:498
#6  $080d24e5 in TPPUMODULE__RESET (this=$40580184) at fppu.pas:123
#7  $080d47e3 in LOADUNIT (S='symtable', FN='') at fppu.pas:1110
#8  $080971dd in LOADUNITS () at pmodules.pas:454
#9  $080976b7 in PARSE_IMPLEMENTATION_USES (SYMT=$40659434) at 
pmodules.pas:582
#10 $0809806d in PROC_UNIT () at pmodules.pas:881
#11 $080d50cd in COMPILE (FILENAME='symsym.pas') at parser.pas:453
#12 $080d4587 in TPPUMODULE__LOADPPU (this=$4067e2b4) at fppu.pas:1012
#13 $080d4886 in LOADUNIT (S='symsym', FN='') at fppu.pas:1138
#14 $080971dd in LOADUNITS () at pmodules.pas:454
#15 $080976b7 in PARSE_IMPLEMENTATION_USES (SYMT=$4057a6c4) at 
pmodules.pas:582
#16 $0809806d in PROC_UNIT () at pmodules.pas:881
#17 $080d50cd in COMPILE (FILENAME='symdef.pas') at parser.pas:453
#18 $080d4587 in TPPUMODULE__LOADPPU (this=$4060dda4) at fppu.pas:1012
#19 $080d4886 in LOADUNIT (S='symdef', FN='') at fppu.pas:1138
#20 $080971dd in LOADUNITS () at pmodules.pas:454
#21 $08097ee6 in PROC_UNIT () at pmodules.pas:804
#22 $080d50cd in COMPILE (FILENAME='symtable.pas') at parser.pas:453
#23 $080d4587 in TPPUMODULE__LOADPPU (this=$40580184) at fppu.pas:1012
#24 $080d4886 in LOADUNIT (S='symtable', FN='') at fppu.pas:1138
#25 $080971dd in LOADUNITS () at pmodules.pas:454
#26 $080976b7 in PARSE_IMPLEMENTATION_USES (SYMT=$405df684) at 
pmodules.pas:582
#27 $0809806d in PROC_UNIT () at pmodules.pas:881
#28 $080d50cd in COMPILE (FILENAME='parser.pas') at parser.pas:453
#29 $080d4587 in TPPUMODULE__LOADPPU (this=$40586694) at fppu.pas:1012
#30 $080d4886 in LOADUNIT (S='parser', FN='') at fppu.pas:1138
#31 $080971dd in LOADUNITS () at pmodules.pas:454
#32 $08097ee6 in PROC_UNIT () at pmodules.pas:804
#33 $080d50cd in COMPILE (FILENAME='compiler.pas') at parser.pas:453
#34 $080d4587 in TPPUMODULE__LOADPPU (this=$817e144) at fppu.pas:1012
#35 $080d4886 in LOADUNIT (S='compiler', FN='') at fppu.pas:1138
#36 $080971dd in LOADUNITS () at pmodules.pas:454
#37 $08098b43 in PROC_PROGRAM (ISLIBRARY=false) at pmodules.pas:1218
#38 $080d50df in COMPILE (FILENAME='pp.pas') at parser.pas:456
#39 $0810c048 in COMPILE (CMD='') at compiler.pas:295
#40 $0812e218 in main () at pp.pas:172
(gdb) q


Sorry, but I can not fix this error because I do not understand
a PPU-loading scheme.

Regards,
	Sergey Korshunoff