id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	lang	patch	platform
928	Probable edge-condition bug in PBC file generation	Austin_Hastings		"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.

"	bug	new	normal		none	1.4.0	high		.pbc, byte code, segment, file format				linux