Last Comment Bug 490196 - Firefox crashes when click the spinarrow button to increment and then decrement [@ nsButtonBoxFrame::DoMouseClick]
: Firefox crashes when click the spinarrow button to increment and then decreme...
: crash, testcase, verified1.9.0.14, verified1.9.1
Product: Core
Classification: Components
Component: XP Toolkit/Widgets: XUL (show other bugs)
: 1.9.0 Branch
: All All
: -- critical with 1 vote (vote)
: mozilla1.9.2a1
Assigned To: Olli Pettay [:smaug]
: Neil Deakin
: 496190 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2009-04-25 23:49 PDT by toshi
Modified: 2011-06-13 10:01 PDT (History)
7 users (show)
samuel.sidler+old: wanted1.9.1.x+
dveditz: blocking1.9.0.14+
samuel.sidler+old: wanted1.9.0.x+
hskupin: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Stack (11.27 KB, text/plain)
2009-07-02 01:57 PDT, Henrik Skupin (:whimboo)
no flags Details
patch (794 bytes, patch)
2009-07-02 04:16 PDT, Olli Pettay [:smaug]
roc: review+
roc: superreview+
samuel.sidler+old: approval1.9.1.2+
dveditz: approval1.9.0.14+
Details | Diff | Splinter Review

Description toshi 2009-04-25 23:49:25 PDT
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv: Gecko/2009040821 Firefox/3.0.9

Firefox crashes when remember visited pages is set to 0

Reproducible: Always

Steps to Reproduce:
1. Go to Tool->Option->Privacy setting page.
2. In the history area "Remember visited pages for the last xxx days",
click the up-arrow button to increment the value, and decrement it.
When the value decreased to "0", Firefox crashes.

I have sent 2 crash reports.
Comment 1 timeless 2009-04-26 00:11:07 PDT

UUID	57c34c31-3365-4c85-87bb-35dfe2090425
Crash Address	0x0
nsButtonBoxFrame::DoMouseClick	 mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp:143
nsAutoRepeatBoxFrame::Notify	mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp:191
nsAutoRepeatBoxFrame::Notify	mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp:89
nsRepeatService::Notify	mozilla/layout/xul/base/src/nsRepeatService.cpp:116
nsTimerImpl::Fire	mozilla/xpcom/threads/nsTimerImpl.cpp:443
nsXULWindow::ShowModal	mozilla/xpfe/appshell/src/nsXULWindow.cpp:401
nsContentTreeOwner::ShowAsModal	mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp:524
nsWindowWatcher::OpenWindowJS	mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp:484 

some frame things null check mContent, this file doesn't,
Comment 2 timeless 2009-06-03 14:41:10 PDT
*** Bug 496190 has been marked as a duplicate of this bug. ***
Comment 3 Achim Töpfl 2009-06-11 16:22:03 PDT
Same in Firefox 3.0.11 (the new official version):
Comment 4 Achim Töpfl 2009-07-01 12:38:13 PDT
New Version, same problem (v3.5) and still unconfirmed :/
Report for v3.5
Comment 5 Nochum Sossonko [:Natch] 2009-07-01 12:43:44 PDT
Confirming. qawanted: can someone confirm this?
Comment 6 Henrik Skupin (:whimboo) 2009-07-01 17:06:08 PDT
Achim, normally the down arrow should be disabled after you clicked it and the box has a value of 1. Don't you see that?

Can you please further run Firefox in Safe Mode? So we can check if an extension is causing this crash:
Comment 7 Achim Töpfl 2009-07-01 18:10:43 PDT
I can click the arrows (from the cache) down from 1 to 0 and than it crash.

I started Firefox in Safe-Mode and didn't disable anything at the start.
Result: No crash when i lower the cache with the arrows to 0 MB

Lowering the cache with the arrows to 0MB -> Crash
Lowering the cash with Mouse and Keybord (not the arrows) to 0 MB -> No Crash
Comment 8 Achim Töpfl 2009-07-01 18:17:12 PDT
I found the failure...
With Noia2.0 (extreme) Theme = Crash
With normal standard Theme = no crash

Omg ^^
Comment 9 Henrik Skupin (:whimboo) 2009-07-02 01:44:37 PDT
Thanks Achim! That looks good and I'm able to reproduce the crash. Let's see what is causing this crash. I'll come up with an analysis shortly.
Comment 10 Henrik Skupin (:whimboo) 2009-07-02 01:57:12 PDT
Created attachment 386470 [details]

The member mContent is somehow warped and points to an invalid address:

gdb) frame 0
#0  0x1338b360 in nsButtonBoxFrame::DoMouseClick (this=0x1d3645a8, aEvent=0x0, aTrustEvent=221) at /data/build/shiretoko/layout/xul/base/src/nsButtonBoxFrame.cpp:142
142	  if (mContent->AttrValueIs(kNameSpaceID_None, nsGkAtoms::disabled,
(gdb) l
138	void 
139	nsButtonBoxFrame::DoMouseClick(nsGUIEvent* aEvent, PRBool aTrustEvent) 
140	{
141	  // Don't execute if we're disabled.
142	  if (mContent->AttrValueIs(kNameSpaceID_None, nsGkAtoms::disabled,
143	                            nsGkAtoms::_true, eCaseMatters))
144	    return;
146	  // Execute the oncommand event handler.
(gdb) p mContent
$1 = (class nsIContent *) 0xdddddddd
(gdb) p *mContent
Cannot access memory at address 0xdddddddd
Comment 11 Henrik Skupin (:whimboo) 2009-07-02 01:59:20 PDT
Olli, would you have time to have a look at this?
Comment 12 Olli Pettay [:smaug] 2009-07-02 02:57:48 PDT
Can't reproduce on linux. Testing now on OSX.
Comment 13 Olli Pettay [:smaug] 2009-07-02 04:16:39 PDT
Created attachment 386487 [details] [diff] [review]

a bit tricky to debug, but simple fix.
Comment 14 Olli Pettay [:smaug] 2009-07-02 08:04:56 PDT
Comment 15 Daniel Veditz [:dveditz] 2009-07-02 08:33:04 PDT
Even though the initial description would not amount to a "critical" bug (manual UI fiddling with non-default theme) I'm guessing this could be reproduced with the right web content. We'll want a crashtest for the regression-testing suite and verifying on branches anyway.
Comment 18 Henrik Skupin (:whimboo) 2009-07-03 07:27:05 PDT
Verified fixed on trunk with builds on OS X and Windows:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090703 Minefield/3.6a1pre
Comment 19 Samuel Sidler (old account; do not CC) 2009-07-13 15:26:08 PDT
Not for, but we'll block on this for
Comment 20 Mike Beltzner [:beltzner, not reading bugmail] 2009-07-21 17:21:39 PDT
Is this ready to land? If so, can we get it on mozilla-1.9.1?
Comment 21 Olli Pettay [:smaug] 2009-07-21 23:18:55 PDT
Comment on attachment 386487 [details] [diff] [review]

Applies to branches with some fuzz.
Comment 22 Samuel Sidler (old account; do not CC) 2009-07-22 11:21:26 PDT
Comment on attachment 386487 [details] [diff] [review]

Approved for a=ss for release-drivers

(We'll be back to approve for
Comment 24 Daniel Veditz [:dveditz] 2009-07-24 15:47:31 PDT
Comment on attachment 386487 [details] [diff] [review]

Approved for, a=dveditz for release-drivers
Comment 25 Henrik Skupin (:whimboo) 2009-07-29 07:05:22 PDT
Verified fixed on 1.9.1 with builds on all platforms like Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090729 Shiretoko/3.5.2pre (.NET CLR 3.5.30729) ID:20090729045022
Comment 26 Olli Pettay [:smaug] 2009-08-08 07:12:36 PDT
Checking in layout/xul/base/src/nsScrollBoxFrame.cpp;
/cvsroot/mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp,v  <--  nsScrollBoxFrame.cpp
new revision: 1.78; previous revision: 1.77
Comment 27 Henrik Skupin (:whimboo) 2009-08-10 07:43:42 PDT
Verified on 1.9.0 with builds on Windows and OS X like: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2009081004 GranParadiso/3.0.14pre ID:2009081004

Note You need to log in before you can comment on or make changes to this bug.