abcdump hits EOF on ecma3/JSON/e15_12_1.abc

ASSIGNED
Assigned to

Status

Tamarin
Tools
ASSIGNED
6 years ago
6 years ago

People

(Reporter: pnkfelix, Assigned: Dan Schaffer)

Tracking

Details

Attachments

(1 attachment, 1 obsolete attachment)

% 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.

Comment 3

6 years ago
changeset: 6769:7ab1ff9bee60
user:      Dan Schaffer <dschaffe@adobe.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...)
(Reporter)

Updated

6 years ago
Depends on: 723461
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').
Attachment #593804 - Flags: review?(edwsmith)
(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.)
Attachment #593804 - Flags: review?(edwsmith)
(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.
(Reporter)

Updated

6 years ago
Assignee: fklockii → dschaffe
(Reporter)

Updated

6 years ago
Attachment #593804 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.