HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/tab-separated-values; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 03:05:46 GMT Content-length: 2871 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) 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 set to <em>fixed</em>