Too-much-recursion crash on some Macs with <body onload="onload()"> (stack limit varies?)

NEW
Unassigned

Status

()

P5
critical
14 years ago
2 months ago

People

(Reporter: roine, Unassigned)

Tracking

({crash})

1.7 Branch
PowerPC
Mac OS X
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needs decision about whether to fix - brendan & jst], URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
Immediately going to http://www.opic.com will crash Camino nightly 13/12 (as
well as older builds). There seems to be an infinite loop where js_Interpret
calls js_Invoke and crashes after >500 nests.
Will attach crash log.

It also crashes Firefox 1.0, but not Safari.
Mac OS X 10.2.8.
(Reporter)

Comment 1

14 years ago
Created attachment 168697 [details]
Crash log

Attaching crash log.

Also: The talkback ID# is TB2539764X

Updated

14 years ago
Assignee: pinkerton → general
Severity: normal → critical
Component: General → JavaScript Engine
Keywords: crash
Product: Camino → Core
QA Contact: pschwartau
Summary: Crash at [js_Interpret] → Crash at [@ js_Interpret]
Version: unspecified → 1.7 Branch

Comment 2

14 years ago
On trunk Mozilla, I get no crash and get in my js console:

Error: too much recursion
Source File: http://www.opic.com/frames/starttopp_2.asp
Line: 1

This is on linux though.

Comment 3

14 years ago
no crash with
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041201
Camino/0.8+

or
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041026

Warning: function loggain does not always return a value
Source File: http://www.opic.com/frames/starttopp_2.asp
Line: 29
Source Code:
}
Error: too much recursion
Source File: http://www.opic.com/frames/starttopp_2.asp
Line: 1
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
the reporter was using a 12/13 trunk build, timeless tested with two builds that
were 2 weeks and 2 months older, respectively. Can someone try the latest sm/ff
nightly before marking this wfm?
This is likely to go to DOM, if the size we pass there to JS_SetThreadStackLimit
is not small enough to avoid overflow on OS X.  From the crash log, is there any
way to estimate the stack depth when it overflowed?  Or is that crash not a
stack overflow?

/be

Comment 6

14 years ago
500 tends to be stack overflow
(Reporter)

Comment 7

14 years ago
The Reporter can report same crash with Camino nightly 26/12.
There are always 253 recursions before crash.

(The original ">500" was for 2 functions; see log).

Comment 8

14 years ago
No crash with:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041225
Camino/0.8+
i did get:
2004-12-27 11:08:12.287 Camino[616] JS error: too much recursion
in Console.app

pink: note that doron *did* test with a current nightly, but whatever.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041227
Error: too much recursion
Source File: http://www.opic.com/frames/starttopp_2.asp
Line: 1

ok. so what's so different between your box and mine?

what is your box?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → WORKSFORME

Updated

14 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(Reporter)

Comment 9

14 years ago
Like it says, Mac OS X 10.2.8. On an iBook 600 G3. US english. 16M colors.
Background pic is Penelope Cruz. Has a cool Looney Tunes Sylvester sticker on
the cover. 

Tried trashing ~/Application Support/Camino, but it still crashes.

Nothing in Console.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0

Mac OS X 10.3.7, iBook 500 MHz (dual USB/white)

I don't get a crash, but I do get the "too much recursion" error in the JS
console.  I have an external firewire drive with a couple free partitions on it
that I can throw 10.2.8 on to test with if necessary.  I'll give it a shot later
tonight or tomorrow (I'm not at home right now)
The content at www.opic.com is buggy, as grep onload shows:

$ grep onload starttopp_2.asp
function onload() {
<body bgcolor="#F0F0F0" leftmargin="0" topmargin="5" marginwidth="0"
marginheight="0" onload="javascript:onload()">

IE may do something completely unspecified by ECMA and the w3c to make this
work, but no other browser to my knowledge does (perhaps Opera does; cc'ing Hixie).

The javascript: label (that's a goto label, not a URI scheme) at the front of
the body tag's onload attribute's value is useless, and shows some confusion
between URIs and event handlers.

So the onload handler calls itself, ad infinitum.  Why some Macs can't allow the
stack to grow to the same depth as other Macs needs to be sorted out, so we can
tune down the argument passed to JS_SetThreadStackLimit by the DOM code.  Clues
from Mac gurus welcome.

/be
Assignee: general → general
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → DOM: Level 0
Ever confirmed: true
QA Contact: pschwartau → ian
Roine, anyone: Feel free to spin off a Tech Evangelism bug on this site.

/be
Simon, any ideas on the questions in comment 11?

Comment 14

14 years ago
Having an onload handler called 'onload' is bug 77271, which was fixed (but is
now reopened).

However, I'm not sure why the stack limit would be different on different
machines. We can, however, get the max stack size by calling
getrlimit(RLIMIT_STACK, ...).
bug 77271 is likely WFM due to the several limits on recursion, plus the thread
stack limit -- except where the latter doesn't seem generous enough on certain
Macs.  I'm marking it WFM so we can focus on this bug.

The rlimit could be set by the user to be less than 512K, for sure.  jst, I can
work with you to hack up an autoconf-#ifdef'd call when we're in the office next.

/be

Updated

9 years ago
Summary: Crash at [@ js_Interpret] → Too-much-recursion crash on some Macs with <body onload="onload()"> (stack limit varies?)

Comment 16

9 years ago
Should we ask the OS for the stack limit and use it to set our own stack limit, or should we WONTFIX this bug on the grounds that very few users tweak the stack limit?

Updated

9 years ago
Whiteboard: [needs decision about whether to fix - brendan & jst]
Assignee: general → nobody
QA Contact: ian → general

Comment 17

7 years ago
I have Mac OS X 10.6.7. I recently upgraded to SeaMonkey 2.0.13, and the application crashes when I attempt to open composer page. Crashes with particular web pages. Crashes for no reason. Is there any way I can get back the older version?

Comment 18

7 years ago
In Firefox 7.0.1 WinXP SP3 the Firefox hangs in the case of onload recursion.
It's not only Mac-specific

Comment 19

7 years ago
Hanging (failing to bring up the slow-script dialog) would be a different bug, even though the testcase is the same.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.