Closed Bug 309897 Opened 19 years ago Closed 19 years ago

long running javascript using E4X crashes browser [@ DeepCopySetInLRS]

Categories

(Core :: JavaScript Engine, defect, P1)

Product:
Core
Component:
JavaScript Engine
Version:
1.8 Branch
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8beta5

People

(Reporter: conor, Assigned: brendan)

References

(
URL
)

Details

(Keywords: crash, crashreportid, verified1.8)

Crash Data

Attachments

(2 files)

fix
5.02 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
alterna-patch, touches only jsxml.c
3.38 KB, patch
mrbkap
: review+
shaver
: superreview+
asa
: approval1.8b5+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

If you use E4X in a long running script, the browser doesn't pop up an alert
that it is "running slowly" - it just crashes.

Reproducible: Always

Steps to Reproduce:
click on stress test in test file
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050924
Firefox/1.6a1 ID:2005092408

TB9691326M
Assignee: nobody → general
Component: General → JavaScript Engine
Keywords: talkbackid
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.8 Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
OS: MacOS X → All
Hardware: Macintosh → All
Summary: long running javascript using E4X crashes browser → long running javascript using E4X crashes browser [ @ DeepCopySetInLRS]
Incident ID: 9695808
Stack Signature	DeepCopySetInLRS c09241ed
Product ID	FirefoxTrunk
Build ID	2005092306
Trigger Time	2005-09-24 15:51:25.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	js3250.dll + (0004cee4)
URL visited	
User Comments	
Since Last Crash	102374 sec
Total Uptime	103200 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsxml.c, line 3229
Stack Trace 	
DeepCopySetInLRS 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsxml.c, line 3229]
DeepCopyInLRS 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsxml.c, line 3270]
PutProperty 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsxml.c, line 4431]
xml_setProperty 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsxml.c, line 4916]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1183]
js_InternalInvoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1260]
JS_CallFunctionValue 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 4016]
nsJSContext::CompileFunction 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1386]
nsJSEventListener::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/dom/src/events/nsJSEventListener.cpp,
line 138]
nsEventListenerManager::HandleEventSubType 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1665]
nsEventListenerManager::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1766]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2063]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6051]
nsButtonBoxFrame::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp,
line 110]
nsListBoxLayout::LayoutInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsListBoxLayout.cpp,
line 221]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 5998]
PresShell::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 5773]
nsEventStateManager::SetClickCount 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 2924]
nsEventStateManager::PostHandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 1886]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6022]
PresShell::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 5699]
nsViewManager::BuildEventTargetList 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp,
line 2475]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp,
line 2160]
nsIView::CreateWidget 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsView.cpp, line
645]
nsWindow::InitEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 999]
nsWindow::DispatchMouseEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5716]
nsWindow::DispatchFocus 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5980]
nsWindow::SetNSWindowPtr 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1206]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0x89cd (0x77d489cd)
USER32.dll + 0x8a10 (0x77d48a10)
nsAppShell::Run 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsAppShell.cpp,
line 121]
nsAppStartup::Run 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 149]
main 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 61]
kernel32.dll + 0x16d4f (0x7c816d4f)
Mine!

/be
Assignee: general → brendan
Status: NEW → ASSIGNED
Flags: blocking1.8b5+
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta5
Attached patch fix — — Splinter Review 
Often enough in jsxml.c, we optimize by creating a local-root-stack-protected
XML object, preallocating its namespaces or kids JSXMLArray to the desired
length (as capacity -- length is not set till the array is populated
successfully), and then use XMLARRAY_SET_MEMBER to store directly into the
preallocated array.

Such code may create other new GC-things, however, and we don't want to trim
XML arrays when marking (an optimization to give back memory allocated during
binary expontential growth in other cases, where we did not have higher-level
knowledge of how to set capacity to preallocate) during a last-ditch GC nesting
in such an allocation callsite.

/be
Attachment #197353 - Flags: superreview?(shaver)
Attachment #197353 - Flags: review?(mrbkap)
Comment on attachment 197353 [details] [diff] [review]
fix

The a->avail change is unrelated to this fix, right?

r=mrbkap
Attachment #197353 - Flags: review?(mrbkap) → review+
On second thought, this seems better to me.  We might have a preset capacity
across a non-last-ditch GC, although code wouldn't count on it and nest such a
non-last-ditch GC.

/be
Attachment #197422 - Flags: superreview?(shaver)
Attachment #197422 - Flags: review?(mrbkap)
(In reply to comment #5)
> (From update of attachment 197353 [details] [diff] [review] [edit])
> The a->avail change is unrelated to this fix, right?

Right.  It's obviously harmless and undoes a useless assignment.

/be
Comment on attachment 197422 [details] [diff] [review]
alterna-patch, touches only jsxml.c

sr=shaver; this is a better approach.
Attachment #197422 - Flags: superreview?(shaver) → superreview+
Comment on attachment 197422 [details] [diff] [review]
alterna-patch, touches only jsxml.c

r=mrbkap
Attachment #197422 - Flags: review?(mrbkap) → review+
blake, can you drive this altnerative patch into the trunk?
alterna-patch (attachment 197422 [details] [diff] [review]) checked into trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment on attachment 197422 [details] [diff] [review]
alterna-patch, touches only jsxml.c

Blake, can you land this today? Thanks.
Attachment #197422 - Flags: approval1.8b5+
blake says he just landed this on the branch so I'm going to add the fixe1.8
keyword.
Keywords: fixed1.8
Sorry, I got confused with all of my checkins. I *just* checked this into
MOZILLA_1_8_BRANCH.
is the fix in the latest nightlies? If it is, then the problem's still there -
the test still crashes the browser ... 
(In reply to comment #15)
> is the fix in the latest nightlies? If it is, then the problem's still there -
> the test still crashes the browser ... 

What build id?  What stack backtrace or talkback id?

/be
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051003
Firefox/1.6a1 ID:2005100313

TB10144844X
My fault - was using an SVG-specific nightly (Mozilla/5.0 (Windows; U; Windows
NT 5.1; en-US; rv:1.8b5) Gecko/20050930 Firefox/1.4).

Latest works fine:
- Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1)
Gecko/20051003 Firefox/1.6a1 works
- Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051003
Firefox/1.6a1
Yeah. I made the mistake of grabbing firefox-1.4.en-US.win32.zip instead of
firefox-1.4.1.en-US.win32.zip. Works fine in a build that actually has the patch
in it!
Status: RESOLVED → VERIFIED
Attachment #197353 - Flags: superreview?(shaver)
Checking in regress-309897.js;
/cvsroot/mozilla/js/tests/e4x/Regress/regress-309897.js,v  <--  regress-309897.js
initial revision: 1.1
done
Flags: testcase+
no crash firefox 1.5 rc2 winxp/linux
Keywords: fixed1.8 → verified1.8
Summary: long running javascript using E4X crashes browser [ @ DeepCopySetInLRS] → long running javascript using E4X crashes browser [@ DeepCopySetInLRS]
Crash Signature: [@ DeepCopySetInLRS]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: