Closed Bug 274595 Opened 20 years ago Closed 3 years ago

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

Categories

(Core :: DOM: Core & HTML, defect, P5)

Product:
Core
Component:
DOM: Core & HTML
Version:
1.7 Branch
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: roine, Unassigned)

References

(
URL
)

Details

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

Attachments

(1 file)

Crash log
18.28 KB, text/plain
Details 
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.
Attached file Crash log — 
Attaching crash log.

Also: The talkback ID# is TB2539764X
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
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.
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
Closed: 20 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
500 tends to be stack overflow
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).

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
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
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?
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
Summary: Crash at [@ js_Interpret] → Too-much-recursion crash on some Macs with <body onload="onload()"> (stack limit varies?)
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?
Whiteboard: [needs decision about whether to fix - brendan & jst]
Assignee: general → nobody
QA Contact: ian → general
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?
In Firefox 7.0.1 WinXP SP3 the Firefox hangs in the case of onload recursion.
It's not only Mac-specific
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

This issue is really old, can't reproduce it on the latest Firefox Nightly 88.0a1 on MacOS 10.15. Since the reporter has the account disabled will close this as resolved:worksforme. Please do re-open this issue if it is still reproducible on the latest Firefox versions.

Status: NEW → RESOLVED
Closed: 20 years ago → 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: