686283 - JSAPI Test "testScriptinfo" hangs on ARM.

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jacob Bramley [:jbramley]]

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

Comment 1

[Jacob Bramley [:jbramley]]

A release build produces the same behaviour.

Comment 2

[Jacob Bramley [:jbramley]]

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?

Comment 3

[Jacob Bramley [:jbramley]]

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

Comment 4

[Mike Hommey [:glandium]]

Attachment: 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.

Comment 5

[Mike Hommey [:glandium]]

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)

Comment 6

[Mike Hommey [:glandium]]

Attachment: Properly handle EOF in TokenStream::getAtSourceMappingURL on platforms with unsigned chars

Comment 7

[Mike Hommey [:glandium]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/3dfc425966f4

Comment 8

[Marco Bonardo [:mak] (Away 10-21 August)]

https://hg.mozilla.org/mozilla-central/rev/3dfc425966f4

Comment 9

[Mike Hommey [:glandium]]

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.

Comment 10

[Mike Hommey [:glandium]]

http://hg.mozilla.org/releases/mozilla-aurora/rev/3ea3354a2d60