Closed Bug 495045 Opened 15 years ago Closed 15 years ago

280SLIDES stuck behaviour after 100% loaded

Categories

(Core :: JavaScript Engine, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: pr11t, Assigned: brendan)

References

()

Details

(Keywords: regression, testcase, verified1.9.1, Whiteboard: fixed-in-tracemonkey)

Attachments

(4 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090526 Firefox (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090526 Firefox (.NET CLR 3.5.30729) New page should be shown! Reproducible: Always Steps to Reproduce: 1.Go to URL 2.Wait until 100% loaded Actual Results: Nothing happens after 100% loaded! Expected Results: New page should open up! Works in Firefox 3.0.10 ; 3.0.12pre ; IE8 Error in the error console. Error: uncaught exception: - [CPString encodeWithCoder:] unrecognized selector sent to instance 0x00023a Offending checkins seem to be: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ec0e6d5f5bc7&tochange=2123c0ae89e8
Seamonkey 2.0b1pre is also affected. Any ideas why this is happening?
Affected also under linux. Though, there are two messages in the console: Error: uncaught exception: - [CPString encodeWithCoder:] unrecognized selector sent to instance 0x00023a Error: _gat is not defined Source File: http://280slides.com/Editor/ Line: 73
This also happens on 3.5pre Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1pre) Gecko/20090527 Shiretoko/3.5pre Firefox/3.0.10 ID:20090527044141 It also occurs with javascript.options.jit.content = false so doesn't look like a TM bug. works: 2009-05-21 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f9fdf276d414 broken: 2009-05-22 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/213e1980f998 Pushlog: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=f9fdf276d414&tochange=213e1980f998
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.9.1 Branch
Assignee: nobody → general
Blocks: 492914
Component: General → JavaScript Engine
Flags: blocking1.9.1?
QA Contact: general → general
Would be great to get narrower -- localghost has TM hourlies, I believe.
The earliest tm build I can find on local ghost is: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090514 Minefield/3.6a1pre http://hourly-archive.localgho.st/hourly-archive2/tracemonkey-win32/1242344326-20090514163846-a75d552b0c64-firefox-3.6a1pre.en-US.win32.zip Th url still fails to load with this build. Any ideas for earlier hourlies? I will try the tracemonkey nightlies on ftp.mozilla.org and see if that helps
If comment 0 is correct, there are exactly two changesets in question, that seems to call for a quick-n-easy bisection...
This bug is caused by bug 492914. It's the only one also in the branch range.
Flags: blocking1.9.1? → blocking1.9.1+
(In reply to comment #2) > Affected also under linux. Though, there are two messages in the console: > Error: uncaught exception: - [CPString encodeWithCoder:] unrecognized selector > sent to instance 0x00023a > Error: _gat is not defined > Source File: http://280slides.com/Editor/ > Line: 73 Looks like the document.written script loading google-analytics.com/ga.js didn't result in _gat being defined as a global variable. Is this still broken in tm tip? Comment 5 references a build from 5/14 (if I'm reading the UA correctly). /be
Assignee: general → brendan
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1
The bug is still present in the latest tracemonkey build (27 May).
I can confirm with my shiny new upvar disabling patch that this bug is related to upvar (slides appear if I disable upvar, loading freezes after 100% if I switch upvar back on). https://bugzilla.mozilla.org/show_bug.cgi?id=489255
We already knew this is related to upvar optimizations. Debugging now... /be
I'm still paying for 'with': var ... _CPKeyedArchiverNullReference = nil, ...; ... class_methods[0] = new objj_method(sel_registerName("initialize"), function $CPKeyedArchiver__initialize(self, _cmd) { with(self) { if (self != objj_msgSend(CPKeyedArchiver, "class")) return; _CPKeyedArchiverStringClass = objj_msgSend(CPString, "class"); _CPKeyedArchiverNumberClass = objj_msgSend(CPNumber, "class"); _CPKeyedArchiverNullReference = objj_msgSend(CPDictionary, "dictionaryWithObject:forKey:", 0, _CPKeyedArchiverUIDKey); } }); ... if (object == nil) return _CPKeyedArchiverNullReference; Sigh. Patch today. /be
The last use of _CPKeyedArchiverNullReference is of course in a lambda seemingly dominated by the var CPKeyedArchiverNullReference = nil, because the flat closure analysis turns a blind eye to assignments in a with statement. The whole mess of code (a very long string) is fed to new Function, btw. The upvars are in the created function's scope. /be
Attached file reduced js shell test
Comment on attachment 379985 [details] jsbeautifier.org version of google-analytics.js file declaring var _gat = ... Red herring. /be
Attachment #379985 - Attachment is obsolete: true
I'm paying for eval too. This says indirect eval can break flat closures, but not unsafely -- just resulting in incorrectness according to the insane, non-standard behavior of indirect eval from a function including the Call object on its With-enhanced scope chain. No way around this -- if anyone counts on it, they'll get what they deserve (finally). /be
The Function constructor is the reason why tcflags is a ref (in/out) parameter to JSCompiler::setFunctionKinds. /be
Attachment #380287 - Flags: review?(jorendorff)
Blocks: 493260
Attachment #380287 - Flags: review?(jorendorff) → review+
Whiteboard: fixed-in-tracemonkey
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Verified fixed on trunk with builds on all platforms like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090529 Minefield/3.6a1pre ID:20090529031523
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Target Milestone: mozilla1.9.1 → mozilla1.9.2a1
Version: 1.9.1 Branch → Trunk
Verified fixed on 1.9.1 with builds on all platforms like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090601 Shiretoko/3.5pre ID:20090601031153
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: