Recent

Author Topic: GO32V2 Compiler internal error: EListError : List index exceeds bounds (9)  (Read 7471 times)

MartenR

  • New member
  • *
  • Posts: 8
Hi there,

 From time to time I run into an internal compiler error:

An unhandled exception occured at $00041DE2 :
EListError : List index exceeds bounds (9)
  $00041D2

This problem seems to occur when a unit interface has changed between compilations.
A second compilation run of the same source usually does NOT solve the problem.
A fresh new full build does solve the problem.

Is this a known problem for the GO32V2 compiler version 2.6.2 [2013/02/12] for i386
for Target GO32 V2 DOS extender?

Note that the number in brackets may vary per case.
 
The full message on screen is:

Free Pascal Compiler version 2.6.2 [2013/02/12] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: GO32 V2 DOS extender
Compiling mon.pas
Compiling frm_scr.pas
Compiling frm_scr.pas
Compiling frm_vchn.pas
Compiling frm_bme.pas
Compiling frm_card.pas
Compiling frm_hdlc.pas
Compiling frm_l1s0.pas
Compiling frm_l1e1.pas
Compiling frm_e1.pas
Compiling frm_hfc.pas
Compiling frm_4s.pas
Compiling frm_8s.pas
Compiling frm_dme1.pas
Compiling frm_term.pas
Compiling frm_cc.pas
Compiling frm_l3.pas
Compiling frm_l3.pas
Compiling frm_cc_c.pas
Compiling frm_cc.pas
Compiling frm_tax.pas
Compiling frm_rctr.pas
Compiling frm_acf.pas
frm_l3_7.pas(431,17) Warning: unreachable code
Compiling frm_user.pas
Compiling frm_cpe.pas
Compiling frm_l2.pas
Fatal: Compilation aborted
An unhandled exception occurred at $00041DE2 :
EListError : List index exceeds bounds (9)
  $00041DE2

Error: E:\FPC\PP262\BIN\GO32V2\ppc386.exe returned an error exitcode (normal if
you did not specify a source file to be compiled)


Regards,
Marten

 
   

Ñuño_Martínez

  • Hero Member
  • *****
  • Posts: 1186
    • Burdjia
Did you tried the newer fpc 3 compiler?  IIRC it has DOS support again.
Are you interested in game programming? Join the Pascal Game Development community!
Also visit the Game Development Portal

MartenR

  • New member
  • *
  • Posts: 8
Have tried installing a new fpc3, but something went wrong.
Still have to find what I should do about that.

Hence the question whether this would be a known bug that would be solved in a newer version.
Up to some time ago I did not have this problem with the 2.6.2. version.

MartenR

Ñuño_Martínez

  • Hero Member
  • *****
  • Posts: 1186
    • Burdjia
Then I can't help you more.  I don't use DOS for a long time.

Anyway, a few questions that may help:
I it cross-compiling or are you compiling in DOS?
What DOS are you using:  MS-DOS, DR-DOS, FreeDOS, DOSbox...?
« Last Edit: November 25, 2017, 11:40:09 am by Ñuño_Martínez »
Are you interested in game programming? Join the Pascal Game Development community!
Also visit the Game Development Portal

MartenR

  • New member
  • *
  • Posts: 8
Eventually I suceeded in installing fpc3.
The thing seems to be that it now supports long file names (LFN).
The installation procedure checks for support of LFN by the OS it is installed on.
As my MSDOS 6.0 does not support LFN, it is switched off. However, this also means that by default some required parts are not installed, like the CRT unit. As a result I could not compile my program.
Only after setting the list of parts to be installed such that required parts are installed as well, the compilation with fpc3 on MSDOS 6.0 does work.

The next point is that, due to LFN support and/or UniCode support, the internal structure of TextRec has been changed. This causes a compilation error, since I do access its field "Name" with the StrIComp() function, which expects an array of char, but meets an array of widechar.
When all this has been solved (and anything else that may pop up) I may check for the compiler behaviour with respect to the original problem :-)

Until then, thank you for your support.
MartenR

Ñuño_Martínez

  • Hero Member
  • *****
  • Posts: 1186
    • Burdjia
I've just read that FPC 3.0.4 is almost complete (just waiting a few files).  May be they fixed this issue.
Are you interested in game programming? Join the Pascal Game Development community!
Also visit the Game Development Portal

MartenR

  • New member
  • *
  • Posts: 8
I got FPC3 (3.0.2) running and succeeded in compiling the program without errors.

After that I ran the compiler on the source exactly as it failed with the 2.6.2 version.
I found that a similar behaviour under 3.0.2 does occur.

So the EListError happens in both compiler versions and can be reproduced with 3.0.2 based on a defined set of files (*.pas, *.o and *.ppu, etc)

So it seems we have a bug here...

Marten
 

Ñuño_Martínez

  • Hero Member
  • *****
  • Posts: 1186
    • Burdjia
I got FPC3 (3.0.2) running and succeeded in compiling the program without errors.

After that I ran the compiler on the source exactly as it failed with the 2.6.2 version.
I found that a similar behaviour under 3.0.2 does occur.

So the EListError happens in both compiler versions and can be reproduced with 3.0.2 based on a defined set of files (*.pas, *.o and *.ppu, etc)

So it seems we have a bug here...

Marten
Maybe.  Did you look at the bug tracker?  I never used it so I don't know...  ::)
Are you interested in game programming? Join the Pascal Game Development community!
Also visit the Game Development Portal

Thaddy

  • Hero Member
  • *****
  • Posts: 14157
  • Probably until I exterminate Putin.
Both are fixed in trunk. If you need them you can factor them out into a separate unit as a quick fix.
Specialize a type, not a var.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Both are fixed in trunk. If you need them you can factor them out into a separate unit as a quick fix.

Which revision was that?

MartenR

  • New member
  • *
  • Posts: 8
fpc 3.0.4 is available, so I'll check its behaviour soon.

Marten

MartenR

  • New member
  • *
  • Posts: 8
Did install fpc 3.0.4.
Managed to compile the program without errors. (The program itself doesn't run and crashes probably on DPMI stuff and HW interrupts, but that probably has to do with changes between 2.6.2 and later 3.0.x versions).

Now I worked on the program again with 2.6.2.
Again I found a set of sources that causes this older compiler to crash (under 2.6.2) as described above.

Next I copied the sources and tried to compile under fpc 3.0.4.
As under 2.6.2 and 3.0.2 the problem still reproduces:

Free Pascal Compiler version 3.0.4 [2017/10/08] for i386
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: GO32 V2 DOS extender
Compiling mon.pas
Compiling frm_scr.pas
Compiling frm_l1.pas
Compiling frm_cfg.pas
Compiling frm_scr.pas
Compiling frm_vchn.pas
Fatal: Compilation aborted
An unhandled exception occurred at $000236DE:
EListError: List index exceeds bounds (12)
  $000236DE
  $00142CC7
  $00142CC7
  $00142906
  $00143099
  $00142CC7
  $00142CC7
  $00142CC7
  $00136D78
  $00143288
  $00142906
  $00143099
  $00142906
  $00143099
  $0014B24F
  $0014BFDE
  $00136D78

Error: E:\FPC\PP304\BIN\GO32V2\ppc386.exe returned an error exitcode

So it seems I should register a bug for the 3.0.4 version.

Marten

Thaddy

  • Hero Member
  • *****
  • Posts: 14157
  • Probably until I exterminate Putin.
My suspicion is that frm_vchn.pas really HAS a list index out of bounce. Compiling with -glh will probably point you to it.
Where can we find that file? We will see such a thing in minutes, usually.
« Last Edit: December 25, 2017, 10:42:35 pm by Thaddy »
Specialize a type, not a var.

MartenR

  • New member
  • *
  • Posts: 8
Just to be shure...

The problem here is that an execption is occuring at compile time.

So adding runtime debugging stuff in the executable would not help.
Anyway: the -gl is already in the fpc.cfg file and the Unit Heaptrace ( for -gh) is already in the program sourcefile.

Note also that the problem also may occur while the compiler is working on other units, not just frm_vchan.pas. See the first post.
Finally, a full build of the program always succeeeds, which would make persistent sourcefile errors unlikely.

Regards,
Marten   

Thaddy

  • Hero Member
  • *****
  • Posts: 14157
  • Probably until I exterminate Putin.
Sigh,
Quote
and the Unit Heaptrace ( for -gh) is already in the program sourcefile.
heaptrc should *never, ever* be added manually to your sourcefiles. There maybe your error....
 http://wiki.freepascal.org/heaptrc
https://www.freepascal.org/docs-html/rtl/heaptrc/usage.html

It is rather handy if you read some documentation...

I doubt for example that -gl is even active: which paramaters did you use? The default fpc.cfg does not activate -gl by itself, you need to specify -dDEBUG.

And if you specified -Xs it will remove the lineinfo again.... Now, that is by default and you have to comment that out in fpc.cfg (the "always strip" comment)
I filed a recent bug report against that.
« Last Edit: December 26, 2017, 01:56:46 pm by Thaddy »
Specialize a type, not a var.

 

TinyPortal © 2005-2018