13 bytes, text/plain
% pwd /Users/fklockii/Dev/tamarin-redux/test/acceptance % java -jar ~/Dev/FlashToolsP4/tools/asc/asc.jar \ -import ../../generated/builtin.abc \ -import ../../generated/shell_toplevel.abc \ -d ../../utils/abcdump.as abcdump.abc, 45661 bytes written % $AVM ../../utils/abcdump.abc -- ecma3/JSON/e15_12_1.abc // magic 2e0010 // Cpool numbers size 78 0 % Error: Error #2030: End of file was encountered. at flash.utils::ByteArray/readUTFBytes() at Abc/parseCpool()[../../utils/abcdump.as:911] at Abc()[../../utils/abcdump.as:758] at global$init()[../../utils/abcdump.as:1692]
Note that the EOF failure happens even right after doing: % java -jar ~/Dev/FlashToolsP4/tools/asc/asc.jar \ -import ../../generated/builtin.abc \ -import ../../generated/shell_toplevel.abc \ ecma3/JSON/e15_12_1.as
The big question for this bug: Is the compiled e15_12_1.abc a well-formed abc? If it is an ill-formed abc, then we have both an asc bug (since it is not properly compiling the input, as documented in comment 1) and then a new case for Bug 706799. If it is a well-formed abc (which I suspect to be the case), then this is an abcdump bug.
changeset: 6769:7ab1ff9bee60 user: Dan Schaffer <email@example.com> summary: bug 707700: mark ecma3/JSON/e15_12_1 as skip in --verify mode, until abcdump bug is fixed (r=me) http://hg.mozilla.org/tamarin-redux/rev/7ab1ff9bee60
Created attachment 593776 [details] as source holding only the literal '\ufeff1234' ; exposes error
Assignee: nobody → fklockii
Status: NEW → ASSIGNED
(Based on investigation logged in Bug 723461 I now suspect that a large component of the abcdump "bug" from comment 2 is actually a recent injection in AVM. It was a mistake for me to put the blame solely on abcdump; we should have tried running abcdump with an old reference version of AVM...)
Created attachment 593804 [details] [diff] [review] patch B: undo leading bom compensation in abcdump.as Ed: redirect review as you like (or rubber stamp if you prefer). I am pretty sure we would prefer to accurately capture the string constant we read in (that is, I am claiming this is a 'real bug').
(I don't plan to push this patch until post-review, since it is not fixing a crucial bug.)
(In reply to Felix S Klock II from comment #6) > Created attachment 593804 [details] [diff] [review] > patch B: undo leading bom compensation in abcdump.as > > Ed: redirect review as you like (or rubber stamp if you prefer). > > I am pretty sure we would prefer to accurately capture the string constant > we read in (that is, I am claiming this is a 'real bug'). (oops, this patch really belongs with Bug 723448. will move it there now.)
Comment on attachment 593804 [details] [diff] [review] patch B: undo leading bom compensation in abcdump.as (moved to Bug 723448, comment 3.)
(Bug 723448 does not block this one, because one does not need to compensate for the dropping of the leading-BOM in order to fix the EOF issue here. Fixing Bug 723461 is necessary and sufficient.)
While I'm leaving Bug 723461 unclosed while it waits for review, I have pushed the fix there, and verified that I can now abcdump ecma3/JSON/e15_12_1.abc So I think the only task left is to undo changeset: 6769:7ab1ff9bee60 that was pushed as a workaround in comment 3. Reassigning to Dan Schaffer to confirm this and do the follow-through.
Assignee: fklockii → dschaffe
Attachment #593804 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.