207617 - This URL crashes Mozilla every time [@ js_CompareStrings]

Status: RESOLVED FIXED

(Core :: XBL, defect)

Description

[Jan D.]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030529

Go to this URL -> Mozilla crash (tried 5 times in a row).

Reproducible: Always

Steps to Reproduce:
1. Goto
http://slashdot.org/article.pl?sid=03/05/29/2245236&mode=nested&tid=109&tid=120&tid=187

Actual Results:  
Mozilla crashes.

Expected Results:  
Display the page

Comment 1

[k b]

does not crash in
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529

how about plugins?
perhaps a plugin generates the crash?

i only have the followin plugins
File name: libflashplayer.so  Shockwave Flash 6.0 r69
File name: libnullplugin.so   The default plugin ...
File name: libjavaplugin_oji.so Java(TM) Plug-in1.4.1_02

of course i do not run mac, this is just a comment that it works on my linux system

Comment 2

[Patrick]

I think a lot of Mozilla users may have read that page ;-). 
Haven't got any other crash reports about it though.

WFM on Linux, Moz 2003052922

Comment 3

[Marco Perez [:mpk]]

The test URL didn't crash Moz1.4-rc1 (build 2003052908) on my PC running Win98.

Comment 4

[Jan D.]

It is only Mac OS X that has some bug.  I should have mentioned that, sorry.

FWIW, 1.4 beta displays another behaviour which I've seen from time to time, but
can not reproduce reliably.   Mozilla stops responding to clicks on links, and
is generally sluggish.  You can Quit, but it only removes the window, Mozilla
keeps on running and has to be killed by Forced Quit.

Also only seen on Mac OS X.

Comment 5

[Matthias Versen [:Matti]]

Can you please attach the OS X Crash log from this crash ?

Comment 6

[Greg K.]

WorksForMe using FizzillaMach/2003-05-29-08-trunk and 1.4 RC1
(FizzillaMach/2003-05-29-05-1.4). Jan, does TalkBack run after this crash? If
so, please provide a representative incident ID.

Other suggestions: can you reproduce this problem using another Mozilla user
profile? What version of the Flash plug-in do you have installed?

Comment 7

[Jan D.]

Attachment: Compressed crashlog

Comment 8

[Jan D.]

Crash log attached.  Talkback does not start.  Version of Flash is 6.0r29.

Using a fresh profile gives the "non-responsive, have to force quit" behaviour
of 1.4 beta described above.  Also, the URL displays OK, unless I am logged in
in Slashdot.  Apparently some combination of my settings makes the page take on
some appearance Mozilla does not like.  I realize this makes it very hard for
anyone els to reproduce.  Pity.

Comment 9

[Matthias Versen [:Matti]]

Please upgrade your flash plugin (it's a bug in the plugin)


*** This bug has been marked as a duplicate of 200511 ***

*** This bug has been marked as a duplicate of 200511 ***

Comment 10

[Jan D.]

With all due respect, this can not be an old flash plugin.

I upgraded to version 6.0r79, still craches.
Removed the flash plugin (verified with about:plugins), still crashes.
Removed all (except default, verified with about:plugins) plugins, still crashes.

Comment 11

[Matthias Versen [:Matti]]

Please attach a new OS X crash log (removed plugin, verified that with
about:plugins).

You stack from comment#7 shows that this is a dupe of bug 200511

Comment 12

[Jan D.]

Attachment: Crash log, no plugins.

Comment 13

[Matthias Versen [:Matti]]

You still have a plugin there :

#0   0x91a7f524 in GetQDGlobalsBlack
 #1   0x06c16d70 in 0x6c16d70
 #2   0x06c83ea8 in 0x6c83ea8
 #3   0x06c83964 in 0x6c83964
 #4   0x06c8b938 in 0x6c8b938
 #5   0x06c175f0 in 0x6c175f0
 #6   0x06c0bd3c in 0x6c0bd3c
 #7   0x06c0b920 in 0x6c0b920
 #8   0x0229784c in ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)
 #9   0x00fee058 in nsPluginInstanceOwner::Notify(nsITimer*)
 #10  0x001b1494 in nsTimerImpl::Fire()
 #11  0x001b15a0 in handleTimerEvent(TimerEventType*)

Are you sure that there is no plugin enabled ?

Comment 14

[Jan D.]

Attachment: Crash report, no plug-ins

I didn't realize the log was appended to.  Here is one with just one crash.

Comment 15

[David Bradley]

FWIW this crash appears to be reported in Talkback. Talkback ID 20378804 has s
very similar stack. It comes in from js_CompileFunctionBody and then crashes in
js_CompareStrings. Has the same get token/atom/hastable sequence as well. It's a
much short stack, though and was on a Win32 build. Most of the crashes in
js_CompareStrings I've seen appear to be accessing dead or corrupted strings in
the JS atom hash table. 20378804, tough, is hard to know for sure, as the
instruction pointer is null for the crashes coming from js_CompileFunctionBody.

Comment 16

[Greg K.]

Parts of the stack repeat. Is Mozilla getting stuck in a loop somewhere?

 #486 0x0010124c in js_InternalInvoke
 #487 0x000dfc24 in JS_CallFunctionValue
 #488 0x021eaf0c in nsJSContext::CallEventHandler(void*, void*, unsigned, void*,
int*, int)
 #489 0x0221abbc in nsJSEventListener::HandleEvent(nsIDOMEvent*)
 #490 0x0110031c in nsXBLPrototypeHandler::ExecuteHandler(nsIDOMEventReceiver*,
nsIDOMEvent*)
 #491 0x0110058c in nsXBLPrototypeHandler::BindingAttached(nsIDOMEventReceiver*)
 #492 0x010f1110 in nsXBLBinding::ExecuteAttachedHandler()
 #493 0x01109f48 in nsBindingManager::ProcessAttachedQueue()
 #494 0x00ed2418 in nsCSSFrameConstructor::ContentInserted(nsIPresContext*,
nsIContent*, nsIFrame*, nsIContent*, int, nsILayoutHistoryState*, int)
 #495 0x00ed7af8 in
nsCSSFrameConstructor::RecreateFramesForContent(nsIPresContext*, nsIContent*)
 #496 0x00ed5064 in nsCSSFrameConstructor::AttributeChanged(nsIPresContext*,
nsIContent*, int, nsIAtom*, int, nsChangeHint)
 #497 0x00e85560 in PresShell::AttributeChanged(nsIDocument*, nsIContent*, int,
nsIAtom*, int, nsChangeHint)
 #498 0x00f82234 in nsDocument::AttributeChanged(nsIContent*, int, nsIAtom*,
int, nsChangeHint)
 #499 0x0106fba8 in nsHTMLDocument::AttributeChanged(nsIContent*, int, nsIAtom*,
int, nsChangeHint)
 #500 0x01159560 in nsXULElement::SetAttr(nsINodeInfo*, nsAString const&, int)
 #501 0x011561bc in nsXULElement::SetAttribute(nsAString const&, nsAString const&)
 #502 0x001c2584 in _XPTC_InvokeByIndex
 #503 0x00528de8 in XPCWrappedNative::CallMethod(XPCCallContext&,
XPCWrappedNative::CallMode)
 #504 0x0052ed14 in XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*, long*)
 #505 0x00101000 in js_Invoke
 #506 0x001086fc in js_Interpret
 #507 0x00101040 in js_Invoke
 #508 0x0010124c in js_InternalInvoke

...and so on.

If this isn't plug-ins, what is it? Reassigning to General for now.

Comment 17

[Matthias Versen [:Matti]]

*** Bug 208455 has been marked as a duplicate of this bug. ***

Comment 18

[Matthias Versen [:Matti]]

someone must find a component for this. I don't know what to do with this.
confirming based on the dupe

Comment 19

[Eric Lawrence]

Attachment: crash log from debug build

Comment 20

[Eric Lawrence]

From what I can tell, this crash happens when viewing slashdot comment pages
with moderator privileges.  So, in addition to ugly table code, about 200
dropdown boxes are also present.  Pages that had less than 90 comments or so
would render fine, but more than that they would crash.  Viewing the pages
logged out, or logged in without moderator privileges works.

I captured a comments page w/ moderator boxes and posted it at

http://www.reed.edu/~lawrence/bug207617-orig.html (!may crash!)

and a slightly reduced version (so only the comments are shown) at

http://www.reed.edu/~lawrence/bug207617.html (!may crash!)

These pages crash OS X build 20030602 every time.

I still haven't been able to generate a successful testcase from scratch.

Judging from attachment 125320 [details], maybe this should go to DOM to see what they
think?  Maybe we are recursing too much and overflowing the stack?

Comment 21

[timeless]

*** Bug 212332 has been marked as a duplicate of this bug. ***

Comment 22

[timeless]

I blame nsBindingManager::ProcessAttachedQueue

Comment 23

[Simon Fraser [no longer active]]

I'd say we were running out of stack. Why does it recurse when there is > 1
select on the page?

Comment 24

[timeless]

Attachment: favor iteration over foolish recursion

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 127644 [details] [diff] [review]
favor iteration over foolish recursion

>Index: nsBindingManager.cpp
>   nsCOMPtr<nsISupportsArray> mAttachedQueue;
>+  PRBool mBusy;

How about mProcessingAttachedQueue?

>+: mAttachedQueue(nsnull),

No need; it's an nsCOMPtr (yes, the code you removed did it too; it should not
have).

sr=me with those nits.

Comment 26

[Sean McGovern]

does not crash for me on 20030714

Comment 27

[Brian Ryner (not reading)]

Comment on attachment 127644 [details] [diff] [review]
favor iteration over foolish recursion

In addition to bz's comments, how about just looping until GetElementAt(0, ...)
returns null, instead of checking the count?  It's a bit less work.

Comment 28

[timeless]

bryner: i don't mind, but someone (e.g. you) would have to assert that it's ok
to do that. do you want a new patch? it and your stipulation are both simple...

Comment 29

[timeless]

oops i'm not awake you weren't suggesting going backwards which was an
optimization bz and i suggested.

just skipping the count well. bz or others would kill me. getelementat has
undefined behavior for out of bounds.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Actually, on nsISupportsArray it in fact does not.

But I'd still rather not rely on that, esp. since I think this code should be
using nsCOMArray once all is said and done.

Comment 31

[Brian Ryner (not reading)]

Comment on attachment 127644 [details] [diff] [review]
favor iteration over foolish recursion

Right, I checked on the ElementAt() behavior before I suggested that.  Anyway,
if you'd rather avoid relying on that behavior, that's fine.  r=me.

Comment 32

[timeless]

checked in

Comment 33

[Philip K. Warren]

The fix for this bug caused a regression in the Mail/News Account Wizard (Bug
215325).