Ticket #928 (new bug)

Opened 5 years ago

Probable edge-condition bug in PBC file generation

Reported by: Austin_Hastings Owned by:
Priority: normal Milestone:
Component: none Version: 1.4.0
Severity: high Keywords: .pbc, byte code, segment, file format
Cc: Language:
Patch status: Platform: linux


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:

	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/Types.pir			\
	library/close/Compiler/Types.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.

Note: See TracTickets for help on using tickets.