Ticket #928 (new bug)
Opened 5 years ago
Probable edge-condition bug in PBC file generation
|Reported by:||Austin_Hastings||Owned by:|
|Severity:||high||Keywords:||.pbc, byte code, segment, file format|
For some time now (weeks), I've been dealing with an intermittent bug (apparently) with PBC file generation at the bottom of the PGE/NQP tool chain.
I'm working on a language compiler, using PGE+NQP with the generated language directory structure provided by the standard scripts.
At odd intervals, I'll make my compiler, and when I try to run "close.pbc" I'll get something like this:
CONSTANT_close.pir: Size in directory 231772 doesn't match size 0 at offset 0x38010 PackFile_unpack segment 'FIXUP_close.pir' directory length 6236 length in file 6236 needed 6224 for unpack PackFile_unpack segment 'CONSTANT_close.pir' directory length 0 length in file 0 needed 8 for unpack PackFile_unpack segment 'PIC_idx_close.pir' directory length 0 length in file 0 needed 4 for unpack PackFile_unpack segment 'BYTECODE_close.pir_DB' directory length 0 length in file 0 needed 8 for unpack Illegal fixup offset (2) in enum_fixup_sub
Except that the integer literals are usually different.
I have noticed that the problem seems to relate to the code being assembled. As a result, I find that if I doubly-include some .pir file the problem goes away - until the next time. I have a set of library modules that I jam together into a single file for final assembly:
COMPILER_LIBS_PIR := \ library/close/Compiler/Array.pir \ library/close/Compiler/Config.pir \ library/close/Compiler/Dumper.pir \ library/close/Compiler/Lookups.pir \ library/close/Compiler/Messages.pir \ library/close/Compiler/MessageVisitor.pir \ library/close/Compiler/Namespaces.pir \ library/close/Compiler/Node.pir \ library/close/Compiler/PrettyPrintVisitor.pir \ library/close/Compiler/Scopes.pir \ library/close/Compiler/String.pir \ library/close/Compiler/SymbolLookupVisitor.pir \ library/close/Compiler/SymbolResolutionVisitor.pir \ library/close/Compiler/Symbols.pir \ library/close/Compiler/TypeResolutionVisitor.pir\ library/close/Compiler/Types.pir \ library/close/Compiler/Types.pir \ library/close/Compiler/Visitor.pir
These files are concatenated into a single src/gen_library.pir that is included into my close.pir compiler driver.
If I pick one - Types.pir in this case - and double-include it, it pretty consistently changes whatever is happening enough that the generated .PBC file becomes valid again. It is for this reason that I suspect the problem is some kind of "edge case" - maybe a page boundary, or some 16-bit -ism. I have no real evidence, though.