JSAPI Test "testScriptinfo" hangs on ARM.

RESOLVED FIXED in Firefox 9

Status

()

Core
JavaScript Engine
--
major
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: jbramley, Assigned: glandium)

Tracking

unspecified
mozilla10
ARM
Linux
Points:
---

Firefox Tracking Flags

(firefox7 unaffected, firefox8 affected, firefox9 fixed)

Details

(Whiteboard: [inbound])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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".
(Reporter)

Comment 1

6 years ago
A release build produces the same behaviour.
(Reporter)

Comment 2

6 years ago
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?
(Reporter)

Comment 3

6 years ago
(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)

Updated

6 years ago
Assignee: general → mh+mozilla
(Assignee)

Updated

6 years ago
status-firefox8: --- → affected
status-firefox9: --- → affected
(Assignee)

Comment 4

6 years ago
Created attachment 565882 [details] [diff] [review]
Properly handle EOF in TokenStream::getAtSourceMappingURL on platforms with unsigned chars

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)
(Assignee)

Comment 5

6 years ago
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)

Updated

6 years ago
Attachment #565882 - Flags: review?(luke) → review+
(Assignee)

Comment 6

6 years ago
Created attachment 565952 [details] [diff] [review]
Properly handle EOF in TokenStream::getAtSourceMappingURL on platforms with unsigned chars
(Assignee)

Updated

6 years ago
Attachment #565882 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
Attachment #565952 - Flags: review?(luke)

Updated

6 years ago
Attachment #565952 - Flags: review?(luke) → review+
(Assignee)

Comment 7

6 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/3dfc425966f4
Whiteboard: [inbound]
(Assignee)

Updated

6 years ago
status-firefox7: --- → unaffected
https://hg.mozilla.org/mozilla-central/rev/3dfc425966f4
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
(Assignee)

Updated

6 years ago
Blocks: 674283
(Assignee)

Comment 9

6 years ago
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+
(Assignee)

Comment 10

6 years ago
http://hg.mozilla.org/releases/mozilla-aurora/rev/3ea3354a2d60
Status: RESOLVED → REOPENED
status-firefox7: unaffected → ---
status-firefox9: affected → fixed
Resolution: FIXED → ---
Target Milestone: mozilla10 → ---
(Assignee)

Updated

6 years ago
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
status-firefox7: --- → unaffected
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in before you can comment on or make changes to this bug.