Crash [@ nsBlockFrame::AddFrames ]




15 years ago
3 years ago


(Reporter: rstrong, Unassigned)


({crash, testcase})

Windows XP
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox47 affected, firefox48 affected, firefox49 affected)


(Whiteboard: [sg:fix], crash signature)


(2 attachments)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041024 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041024 Firefox/1.0

The soon to be attached simplified testcase causes a crash @
nsBlockFrame::AddFrames. TB1499754Y

Reproducible: Always
Steps to Reproduce:
1. Open testcase

Actual Results:  
Crash or hang

Expected Results:  
No crash or hang

UA's affected:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041024 Firefox/1.0
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041023

Stack Signature	 nsBlockFrame::AddFrames 7ffbba8f
Source File, Line No.
line 4598
Adding keywords crash and testcase
Keywords: crash, testcase
Confirming, setting status to NEW.
Ever confirmed: true
Assignee: general → nobody
Component: Browser-General → Layout: Block and Inline
QA Contact: general → core.layout.block-and-inline
This worksforme with a current trunk build on Linux...
Windows goes all wonky on me on a trunk debug build, but doesn't crash
immediately. I can create new tabs, but I can't load anything in them, and the
history dropdown isn't coming up. Throbber is stuck mid-throb, reload and stop
buttons are enabled, menus stay depressed, can't load JS Console, etc. Some kind
of memory corruption I guess.

Odd that bz found a whole bunch of these aren't repro on Linux. Different
compiler options that protect against memory issues?
Whiteboard: [sg:fix]
Same result as dveditz with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8a5) Gecko/20041025 with one additional comment in that closing the window
doesn't shut down the mozilla.exe process so the process has to be killed manually.
I noticed that both this bug and bug 266360 end in disassembly at:
697: nsIFrame* GetNextSibling() const { return mNextSibling; }

Perhaps one should be duped to the other even though this is with
nsBlockFrame::AddFrames and bug 266360 is with nsBlockFrame::DoRemoveFrame
> Perhaps one should be duped to the other

Only if they're caused by the same underlying problem....

Comment 9

15 years ago
this is wfm winxp 2004111204 on load and multiple reload
Testcase caused a hang for me using winxp pro sp2 and 20041112. The mozilla.exe
process had to killed using taskmgr.
Tried the testcase again with a current nightly in case the fix for bug 268119
fixed this crash as well but it still crashed. Talkback TB2539230Z.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041213
This is now WFM - perhaps the checkin for bug 263825 has fixed this.
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
WFM, too (Firefox 1.0.2 pl-PL on Linux)


Comment 14

10 years ago
changeset:   25010:b0337b6287f3
user:        Jesse Ruderman <>
date:        Fri Feb 13 14:54:17 2009 -0800
summary:     Add crashtests
Flags: in-testsuite+
Crash Signature: [@ nsBlockFrame::AddFrames ]
Crash volume for signature 'nsBlockFrame::AddFrames':
 - nightly(version 50):0 crashes from 2016-06-06.
 - aurora (version 49):1 crash from 2016-06-07.
 - beta   (version 48):7 crashes from 2016-06-06.
 - release(version 47):36 crashes from 2016-05-31.
 - esr    (version 45):0 crashes from 2016-04-07.

Crash volume on the last weeks:
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0       0       0       0       0       0       0
 - aurora        0       0       0       1       0       0       0
 - beta          1       3       0       0       2       0       1
 - release       4       3       5       3       6       8       4
 - esr           0       0       0       0       0       0       0

Affected platforms: Windows, Linux
You need to log in before you can comment on or make changes to this bug.