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

[Sergey Korshunoff]

About the story...

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.

There is defenitely some wrong memory reference which destroys sometimes
tinputfile.name and tinputfile.path. But You can not catch it with heaptrc.
And I did not catch bounds overrides even with ElectroFence library
(I uses cmem with reference to libefence.so insteed of libc.so). So this
override is only inside valid memory block (and not outside).

Currendtly I do not work under Win32 -> I can not use TurboDebugger
to catch a change of tinputfile.name when we compile a pp.pas.
Can someone (who work under Win32) to try this?  Can a gdb
to use i386 hardware to catch memory change?

Regards,
 	Sergey Korshunoff