Recent

Author Topic: Maximum size of unit: Internal Error 200205172  (Read 1333 times)

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8719
  • FPC developer.
Re: Maximum size of unit: Internal Error 200205172
« Reply #15 on: September 12, 2020, 11:22:03 am »
There are quite a lot of coff related changes between 3.2 and 3.3.1. Providing Testing results with 3.3.1 might speed up the bugreport.

Note that this is possibly a format limitation, not necessarily a FPC limitation (e.g. on *nix with a different object format it might be different)

Bart

  • Hero Member
  • *****
  • Posts: 3899
    • Bart en Mariska's Webstek
Re: Maximum size of unit: Internal Error 200205172
« Reply #16 on: September 12, 2020, 01:09:07 pm »
Note that this is possibly a format limitation, not necessarily a FPC limitation (e.g. on *nix with a different object format it might be different)

TS said that Delphi was able to compile/build, so it is a limitation of (the implementation in) FPC.

Bart

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8719
  • FPC developer.
Re: Maximum size of unit: Internal Error 200205172
« Reply #17 on: September 12, 2020, 05:06:52 pm »
Note that this is possibly a format limitation, not necessarily a FPC limitation (e.g. on *nix with a different object format it might be different)

TS said that Delphi was able to compile/build, so it is a limitation of (the implementation in) FPC.

But of the (PE)COFF implementation, not the general implementation. Though we don't link ELF, so that is maybe a stretch :-)

Grahame Grieve

  • New Member
  • *
  • Posts: 44
Re: Maximum size of unit: Internal Error 200205172
« Reply #18 on: September 14, 2020, 12:14:04 am »
So I'd like to try with the most recent FPC but I couldn't get the current version to compile?

Bug: https://bugs.freepascal.org/view.php?id=37745

mr-highball

  • Full Member
  • ***
  • Posts: 205
    • Highball Github
Re: Maximum size of unit: Internal Error 200205172
« Reply #19 on: September 14, 2020, 12:42:24 am »
So I'd like to try with the most recent FPC but I couldn't get the current version to compile?

Bug: https://bugs.freepascal.org/view.php?id=37745

Not sure if you are already using this, but fpcupdeluxe should simplify multi instances of fpc/lazarus as well as making it very easy to ensure you have latest trunk (and keep it up to date)

https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases

Grahame Grieve

  • New Member
  • *
  • Posts: 44
Re: Maximum size of unit: Internal Error 200205172
« Reply #20 on: September 15, 2020, 08:54:59 am »
Ah thanks. I has some vague memory that it existed, but I couldn't remember what it was actually called, and my google skills were inadequate for the task for finding it without knowing the name. I will give it a go.

in the mean time, I split my big units up into smaller units so I could move ahead, and I at least get a clean compile (3 million lines) - it's my Coronavirus lock-down project; now I just have to fix all the things I hacked to get it going.

Grahame Grieve

  • New Member
  • *
  • Posts: 44
Re: Maximum size of unit: Internal Error 200205172
« Reply #21 on: September 15, 2020, 09:15:36 am »
... not fixed in 3.3.1

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6600
  • Debugger - SynEdit - and more
    • wiki
Re: Maximum size of unit: Internal Error 200205172
« Reply #22 on: September 15, 2020, 10:17:44 am »
I have a program that compiles ok, but I get an error during linking:
Have you tried using an external linker?
-Xe

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 564
Re: Maximum size of unit: Internal Error 200205172
« Reply #23 on: September 15, 2020, 11:52:03 am »
Not sure about this case, but for me "Out of memory" is very common error for big modules in Delphi. In most cases it's caused by debug information for generics. Generics have long names. Especially when they're nested. I.e. something like "TGeneric1<TSomeType, TGeneric2<TSomeOtherType>>". This is one of the reasons, why I want to migrate to FPC.

UPD May be I have old sources. It's 3.0.0 sources. Don't have time to download new ones. And according to this sources, this internal error can happen in one of two places:
1) When reading long PE section name (that is longer, than 8 symbols). Dunno, if FPC uses long section names. I guess, it shouldn't.
2) When reading symbol table, mostly used as debug info.
This error happens, if:
1) Pointer to symbol table is nil.
2) Position to read exceeds size of symbol table.
3) #0 is found at that position, i.e. zero length string.

So, I guess, it's broken symbol table.
« Last Edit: September 15, 2020, 12:32:28 pm by Mr.Madguy »
DynamicData 3.0 is released!
Since now development is frozen - only optimization passes will be made at some point.
Lack of multiple inheritance turns it into abomination.

Thaddy

  • Hero Member
  • *****
  • Posts: 10445
Re: Maximum size of unit: Internal Error 200205172
« Reply #24 on: September 15, 2020, 01:21:04 pm »
I suspect resource starvation as well, but that does not hide that such huge units are bad software design in most - if not all - cases.
Anyway: internal errors are there for a reason, so this will likely be fixed.
When you ask a question that is actually answered in the documentation, you are either lazy or a moron.

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 564
Re: Maximum size of unit: Internal Error 200205172
« Reply #25 on: September 15, 2020, 01:59:25 pm »
There is change in 3.2.0 vs 3.0.0. Some big obj files are now supported. They have some different header structure. And may be bugged.
DynamicData 3.0 is released!
Since now development is frozen - only optimization passes will be made at some point.
Lack of multiple inheritance turns it into abomination.

PascalDragon

  • Hero Member
  • *****
  • Posts: 2103
  • Compiler Developer
Re: Maximum size of unit: Internal Error 200205172
« Reply #26 on: September 16, 2020, 07:24:23 am »
So, I guess, it's broken symbol table.

It was not the symbol table, but the string table: if a section name is larger than 8 it's replaced by an offset into the string table which is located at the end of the object. If that offset (in decimal) has less than 8 digits all is well (it's prefixed by a '/'), but larger offsets were the problem: it's sadly not documented that these need to be encoded as Base64-6-character strings (prefixed by '//'). I had to dig through LLVM to learn about that... ::) (note: this is independant of Big Obj COFF or not, though of course the former are more likely to be affected :-X )

Anyway, it should be fixed now in 46876 and I'll request to merge it to 3.2.1 as well.

Grahame Grieve

  • New Member
  • *
  • Posts: 44
Re: Maximum size of unit: Internal Error 200205172
« Reply #27 on: September 16, 2020, 08:56:08 am »
Great thanks

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 564
Re: Maximum size of unit: Internal Error 200205172
« Reply #28 on: September 16, 2020, 11:39:44 am »
It was not the symbol table, but the string table: if a section name is larger than 8 it's replaced by an offset into the string table which is located at the end of the object. If that offset (in decimal) has less than 8 digits all is well (it's prefixed by a '/'), but larger offsets were the problem: it's sadly not documented that these need to be encoded as Base64-6-character strings (prefixed by '//'). I had to dig through LLVM to learn about that... ::) (note: this is independant of Big Obj COFF or not, though of course the former are more likely to be affected :-X )

Anyway, it should be fixed now in 46876 and I'll request to merge it to 3.2.1 as well.
So, at the end it's case #1. And PE File format doesn't mention anything about // prefix and Base64 section names. So, it must be something new.
DynamicData 3.0 is released!
Since now development is frozen - only optimization passes will be made at some point.
Lack of multiple inheritance turns it into abomination.

PascalDragon

  • Hero Member
  • *****
  • Posts: 2103
  • Compiler Developer
Re: Maximum size of unit: Internal Error 200205172
« Reply #29 on: September 16, 2020, 01:52:44 pm »
So, at the end it's case #1. And PE File format doesn't mention anything about // prefix and Base64 section names. So, it must be something new.

Yes, that's where I had looked at first as well.

If I had to guess this mechanism was probably introduced at a similar time as Big Obj COFF (which isn't mentioned there either) cause having larger offsets is much more likely there.

 

TinyPortal © 2005-2018