Closed Bug 304719 Opened 19 years ago Closed 19 years ago

loading JavaScript function definition (which is never called) crashes Firefox

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
1.7 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED DUPLICATE of bug 302439

People

(Reporter: henry.cejtin, Unassigned)

Details

Attachments

(1 file)

The page which causes the segfault
79.27 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4 (Debian package 1.0.4-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4 (Debian package 1.0.4-2)

I have a page consisting entirely of:
    <html>
    <head><title>Die</title></head>
    <body>
        <script type="text/javascript">
            function zzz() {
               LARGE MACHINE-GENERATED JAVASCRIPT
            }
        </script>
    </body>
    </html>

Note, the function zzz is defined but NEVER used.  No JavaScript code exists
except for the single function definition.
Loading this page causes Firefox to segfault.

The file is 81K bytes.  We have had many Firefox segfaults, and it is VERY
sensitive to the precise contents of the function definition.  It looks like
some kind of buffer overflow by the code generator which corrupts the heap.
We currently are working around the problem by simplifying the generated code
to reduce the size of some switch statements (but still just one function
which we usually call once).

The segfault occurs on all the following Firefox versions:
    Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517
Firefox/1.0.4 (Debian package 1.0.4-2)
    Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107
    Firefox/1.0
    Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524
    Fedora/1.0.4-4 Firefox/1.0.4

I can certainly provide the 81K file to any one (it just didn't seem right to
paste it in hear).
    

Reproducible: Always

Steps to Reproduce:
1.Load the page (either via http: or file:)
2.
3.

Actual Results:  
segfault

Expected Results:  
display a blank page with the title

I tried to get the talkback version of Firefox but could not see how to get it.
(Sorry for being an idiot.)

I would love to have some description of the cause and a possible work around so
that until the fix gets sent out (or for people using the current browser in the
future) my code will still work.
This is the page which causes the segfault.  Just load the page via http: or
even
file: and firefox will segfault.
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.7 Branch
Crashes:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050719
Firefox/1.0.6

Doesn't crash:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050814
Firefox/1.0+

This has therefore been fixed on the trunk. A stack trace would help pinpoint
where this was fixed.
Top of stack trace:
Thread 0 Crashed:
0   libmozjs.dylib           	0x0601c2ec js_EmitN + 2988
1   libmozjs.dylib           	0x06022d80 js_EmitTree + 14600
2   libmozjs.dylib           	0x0601f368 js_EmitFunctionBody + 136
3   libmozjs.dylib           	0x0601f7cc js_EmitTree + 852
4   libmozjs.dylib           	0x060213cc js_EmitTree + 8020
5   libmozjs.dylib           	0x0601f368 js_EmitFunctionBody + 136
6   libmozjs.dylib           	0x0601f7cc js_EmitTree + 852
7   libmozjs.dylib           	0x0604ab58 js_CompileFunctionBody + 2652
8   libmozjs.dylib           	0x06049c0c js_CompileTokenStream + 244
9   libmozjs.dylib           	0x0600672c JS_DefineUCFunction + 316
10  libmozjs.dylib           	0x0600694c JS_CompileUCScriptForPrincipals + 96
11  libmozjs.dylib           	0x060074b8 JS_EvaluateUCScriptForPrincipals + 44

This was fixed between 2005-07-28-07 and 2005-07-29-07, meaning it's probably a
dup of Bug 302439 (see Bug 302439 comment #1: "This is the [...] fix to a crash
bug.")

Anyway, WORKSFORME.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

*** This bug has been marked as a duplicate of 302439 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Yikes, what incredibly speedy tracking.  I'm sorry I couldn't find the original
bug.  (It wasn't clear that it was related to the switch size, although that was
somewhat suspected.)  Thanks a million.
If the switches generated all are dense I gather that we won't fall in to it.
Is that correct?
(In reply to comment #5)
> If the switches generated all are dense I gather that we won't fall in to it.
> Is that correct?

Yes, as my words about "density 1" in bug 302439 comment 0 implied.

/be
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: