petdance/scratch — Issue #103: Probable edge-condition bug in PBC file generation
Author: petdance
Created: 2011-11-01 05:41:13+00:00
State: open
Labels: bug, Pri-normal, Sev-high

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.

== Workaround ==

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.

Originally http://trac.parrot.org/parrot/ticket/928