Closed Bug 686283 Opened 9 years ago Closed 8 years ago

JSAPI Test "testScriptinfo" hangs on ARM.

Categories

(Core :: JavaScript Engine, defect, major)

ARM
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla10
Tracking Status
firefox7 --- unaffected
firefox8 --- affected
firefox9 --- fixed

People

(Reporter: jbramley, Assigned: glandium)

References

Details

(Whiteboard: [inbound])

Attachments

(1 file, 1 obsolete file)

When running jsapi-tests on an ARM build of the JS shell, the "testScriptInfo" test hangs for a while, then eventually fills the console with the following error:

    "<no filename>:0:out of memory"

The board is a Tegra-2 running Ubuntu Maverick. The same test works fine on my desktop (amd64).

I've seen this on a few recent mozilla-central builds, but most recently http://hg.mozilla.org/mozilla-central/rev/0c7303e897c5. The shell was built with "--enable-debug".
A release build produces the same behaviour.
Attempting to find similar symptoms in other tests, I stumbled across testDebugger. testDebugger and testScriptInfo are the only tests that include the "debugger" keyword. I don't know what that keyword does. (It might just be used to trigger a 'catch' clause.)

In testScriptInfo, I think I'm hitting an infinite loop of some kind, resulting in an out-of-memory condition.

In testDebugger, I hit an assertion:
Assertion failure: failed to find call site, at /work/moz/mc/js/src/methodjit/Retcon.cpp:117
(in Recompiler::patchCall)

Is it possible that we're trying to patch a call that doesn't exist, or is somehow invalid?
(In reply to Jacob Bramley [:jbramley] from comment #2)
> In testDebugger, I hit an assertion:
> Assertion failure: failed to find call site, at
> /work/moz/mc/js/src/methodjit/Retcon.cpp:117
> (in Recompiler::patchCall)

I hit the same assertion with jit-tests, on debug/Frame-onStep-07.js. It might be a different bug.
Assignee: general → mh+mozilla
This actually happens on all architectures using unsigned chars. So at least powerpc, s390, arm and avr32.

It obviously happens on other architectures when building with -funsigned-char.
Attachment #565882 - Flags: review?(luke)
Comment on attachment 565882 [details] [diff] [review]
Properly handle EOF in TokenStream::getAtSourceMappingURL on platforms with unsigned chars

Review of attachment 565882 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jsscan.cpp
@@ +1223,5 @@
>          tokenbuf.clear();
>  
>          jschar c;
>          while (!IsSpaceOrBOM2((c = getChar())) &&
>                 ((char) c) != '\0' &&

Note that this also looks wrong. It probably should be changed to c != 0 (or simply c)
Attachment #565882 - Flags: review?(luke) → review+
Attachment #565882 - Attachment is obsolete: true
Attachment #565952 - Flags: review?(luke)
Attachment #565952 - Flags: review?(luke) → review+
https://hg.mozilla.org/mozilla-central/rev/3dfc425966f4
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
Blocks: 674283
Comment on attachment 565952 [details] [diff] [review]
Properly handle EOF in TokenStream::getAtSourceMappingURL on platforms with unsigned chars

I think there is a possibility of DoS on Android with sourceMappingURLs.
Attachment #565952 - Flags: approval-mozilla-beta?
Attachment #565952 - Flags: approval-mozilla-aurora?
Attachment #565952 - Flags: approval-mozilla-beta?
Attachment #565952 - Flags: approval-mozilla-beta-
Attachment #565952 - Flags: approval-mozilla-aurora?
Attachment #565952 - Flags: approval-mozilla-aurora+
http://hg.mozilla.org/releases/mozilla-aurora/rev/3ea3354a2d60
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla10 → ---
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in before you can comment on or make changes to this bug.