{"issue":{"state":"open","pull_request":{"diff_url":null,"html_url":null,"patch_url":null},"milestone":null,"user":{"avatar_url":"https://secure.gravatar.com/avatar/d1588981e0248aaa0174906c99df180e?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"d1588981e0248aaa0174906c99df180e","url":"https://api.github.com/users/petdance","login":"petdance","id":41100},"assignee":null,"updated_at":"2011-11-14T06:13:39Z","labels":[{"name":"bug","color":"1AA195","url":"https://api.github.com/repos/petdance/scratch/labels/bug"},{"name":"Pri-normal","color":"6770F0","url":"https://api.github.com/repos/petdance/scratch/labels/Pri-normal"},{"name":"Sev-high","color":"0F6489","url":"https://api.github.com/repos/petdance/scratch/labels/Sev-high"}],"closed_at":null,"comments":0,"url":"https://api.github.com/repos/petdance/scratch/issues/822","body":"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.\nI'm working on a language compiler, using PGE+NQP with the generated language directory structure provided by the standard scripts.\r\n\r\nAt odd intervals, I'll make my compiler, and when I try to run \"close.pbc\" I'll get something like this:\r\n\r\n```\r\nCONSTANT_close.pir: Size in directory 231772 doesn't match size 0 at offset 0x38010\r\nPackFile_unpack segment 'FIXUP_close.pir' directory length 6236 length in file 6236 needed 6224 for unpack\r\nPackFile_unpack segment 'CONSTANT_close.pir' directory length 0 length in file 0 needed 8 for unpack\r\nPackFile_unpack segment 'PIC_idx_close.pir' directory length 0 length in file 0 needed 4 for unpack\r\nPackFile_unpack segment 'BYTECODE_close.pir_DB' directory length 0 length in file 0 needed 8 for unpack\r\nIllegal fixup offset (2) in enum_fixup_sub\r\n```\r\n\r\nExcept that the integer literals are usually different.\r\n\r\n== Workaround ==\r\n\r\nI 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.\r\n \r\nI have a set of library modules that I jam together into a single file for final assembly:\r\n```\r\nCOMPILER_LIBS_PIR := \\\r\n\tlibrary/close/Compiler/Array.pir\t\t\t\\\r\n\tlibrary/close/Compiler/Config.pir\t\t\t\\\r\n\tlibrary/close/Compiler/Dumper.pir\t\t\\\r\n\tlibrary/close/Compiler/Lookups.pir\t\t\\\r\n\tlibrary/close/Compiler/Messages.pir\t\t\\\r\n\tlibrary/close/Compiler/MessageVisitor.pir\t\\\r\n\tlibrary/close/Compiler/Namespaces.pir\t\t\\\r\n\tlibrary/close/Compiler/Node.pir\t\t\t\\\r\n\tlibrary/close/Compiler/PrettyPrintVisitor.pir\t\\\r\n\tlibrary/close/Compiler/Scopes.pir\t\t\t\\\r\n\tlibrary/close/Compiler/String.pir\t\t\t\\\r\n\tlibrary/close/Compiler/SymbolLookupVisitor.pir\t\\\r\n\tlibrary/close/Compiler/SymbolResolutionVisitor.pir\t\\\r\n\tlibrary/close/Compiler/Symbols.pir\t\t\\\r\n\tlibrary/close/Compiler/TypeResolutionVisitor.pir\\\r\n\tlibrary/close/Compiler/Types.pir\t\t\t\\\r\n\tlibrary/close/Compiler/Types.pir\t\t\t\\\r\n\tlibrary/close/Compiler/Visitor.pir\r\n```\r\n\r\nThese files are concatenated into a single `src/gen_library.pir` that is included into my close.pir compiler driver.\r\n\r\nIf 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.\r\n \r\nIt 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.\r\n\r\n\r\n\r\nOriginally http://trac.parrot.org/parrot/ticket/928 by Austin_Hastings","html_url":"https://github.com/petdance/scratch/issues/822","title":"Probable edge-condition bug in PBC file generation","number":822,"id":2227141,"created_at":"2011-11-14T06:13:39Z"},"action":"opened"}