Crash selecting profile folder in profile manager

VERIFIED FIXED in M14

Status

()

P1
critical
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: judas, Assigned: eric)

Tracking

({crash})

Trunk
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] 2/24/00 Have fix testing.)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
While attempting to create a profile, I browse to a directory (doesn't matter 
where it is, hard drive, removable, ram disk) click ok and boom.

I'd consider this kinda major?  =)

This was using the build available Sunday evening ~4:00AM CST.

Thanks, ttfn!  

Judas

MOZILLA caused an invalid page fault in
module GKHTML.DLL at 0167:60188838.
Registers:
EAX=00000000 CS=0167 EIP=60188838 EFLGS=00010206
EBX=0068d6c4 SS=016f ESP=0068d644 EBP=0068d668
ECX=0068d680 DS=016f ESI=00000000 FS=5e17
EDX=013ea0e0 ES=016f EDI=00726214 GS=0000
Bytes at CS:EIP:
ff 50 28 85 c0 75 67 8b 45 18 3b c6 74 60 8b 08 
Stack dump:
00726214 0068d680 0068da0c 007261a8 0068d6c4 007261a8 00000004 00000000 007261a8 
0068d844 60188590 013c17e0 013e9480 0068da0c 0068d86c 00000000

Comment 1

19 years ago
*** Bug 27597 has been marked as a duplicate of this bug. ***

Comment 2

19 years ago
Created attachment 5228 [details]
log from crash

Comment 3

19 years ago
Here is the stack trace.  Reassigning to troy since no more kipp...

We appear to be calling GetContent through a valid frame pointer.

<C0...... something was here, but I didn't get it in the cut/paste>
nsTextFrame::ComputeTotalWordWidth(nsIPresContext * 0x032ad4a0, nsILineBreaker * 
0x03344ac0, nsLineLayout
& {...}, const nsHTMLReflowState & {...}, nsIFrame * 0x03080958, int 120, 
unsigned short * 0x00128a7c, unsigned
int 2, unsigned int 100) line 3421 + 16 bytes 
nsTextFrame::Reflow(nsTextFrame * const 0x030808e4, nsIPresContext * 0x032ad4a0, 
nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 1216088) line 3181 + 64 
bytes 
nsLineLayout::ReflowFrame(nsIFrame * 0x030808e4, nsIFrame * * 0x00129b70, 
unsigned int & 1216088,
nsHTMLReflowMetrics * 0x00000000, int & 0) line 992 
nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & {...}, nsLineLayout & 
{...}, nsLineBox * 0x0335c4a0,
nsIFrame * 0x030808e4, unsigned char * 0x00128e0c) line 3966 + 32 bytes 
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & {...}, nsLineLayout & 
{...}, nsLineBox * 0x0335c4a0,
int * 0x001296b4, unsigned char * 0x00129528, int 0) line 3850 + 28 bytes 
nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState & {...}, nsLineBox * 
0x0335c4a0, int * 0x001296b4,
unsigned char * 0x00129528, int 0) line 3791 + 38 bytes 
nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & {...}, nsLineBox * 
0x0335c4a0, int * 0x001296b4, int 0)
line 3736 + 28 bytes 
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x0335c4a0, int 
* 0x001296b4, int 0) line 2909
+ 25 bytes 
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2618 + 27 bytes 
nsBlockFrame::Reflow(nsBlockFrame * const 0x0308089c, nsIPresContext * 
0x032ad4a0, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1562 + 15 bytes 
nsBoxFrameInner::FlowChildAt(nsIFrame * 0x0308089c, nsIPresContext * 0x032ad4a0, 
nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0, nsCalculatedBoxInfo & 
{...}, int 0, int 0, int 0, nsIFrame *
& 0x00000000, int & 268448316, const nsString & {...}) line 2033 
nsBoxFrame::GetChildBoxInfo(nsIPresContext * 0x032ad4a0, const nsHTMLReflowState 
& {...}, nsIFrame *
0x0308089c, nsCalculatedBoxInfo & {...}) line 773 
nsBoxFrame::GetBoxInfo(nsBoxFrame * const 0x03080520, nsIPresContext * 
0x032ad4a0, const
nsHTMLReflowState & {...}, nsBoxInfo & {...}) line 2600 + 37 bytes 
nsBoxFrame::Reflow(nsBoxFrame * const 0x030804e8, nsIPresContext * 0x032ad4a0, 
nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1028 
nsContainerFrame::ReflowChild(nsIFrame * 0x030804e8, nsIPresContext * 
0x032ad4a0, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned 
int & 0) line 638 + 31 bytes 
RootFrame::Reflow(RootFrame * const 0x030804ac, nsIPresContext * 0x032ad4a0, 
nsHTMLReflowMetrics & {...},
const nsHTMLReflowState & {...}, unsigned int & 0) line 331 
nsContainerFrame::ReflowChild(nsIFrame * 0x030804ac, nsIPresContext * 
0x032ad4a0, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned 
int & 0) line 638 + 31 bytes 
ViewportFrame::Reflow(ViewportFrame * const 0x03080470, nsIPresContext * 
0x032ad4a0, nsHTMLReflowMetrics
& {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 531 
nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x033b5f00, 
nsIPresContext * 0x032ad4a0,
nsHTMLReflowMetrics & {...}, const nsSize & {...}, nsIRenderingContext & {...}) 
line 145 
PresShell::ProcessReflowCommands(PresShell * const 0x032f2b10, int 0) line 2031 
PresShell::FlushPendingNotifications(PresShell * const 0x032f2b10) line 2496 
nsXULDocument::FlushPendingNotifications(nsXULDocument * const 0x032a13f0) line 
1734 
nsGenericHTMLElement::GetPrimaryFrame(nsIHTMLContent * 0x032c9360, 
nsIFormControlFrame * &
0x00000000, int 1) line 1735 
nsHTMLInputElement::GetValue(nsHTMLInputElement * const 0x032c9350, nsString & 
{...}) line 417 + 48 bytes 
GetHTMLInputElementProperty(JSContext * 0x032afda0, JSObject * 0x00f2e5a8, long 
-35, long * 0x0012b7d8) line
397 + 22 bytes 
js_GetProperty(JSContext * 0x032afda0, JSObject * 0x00f2e5a8, long 37379440, 
long * 0x0012b7d8) line 1837 +
125 bytes 
js_Interpret(JSContext * 0x032afda0, long * 0x0012b96c) line 2248 + 1446 bytes 
js_Invoke(JSContext * 0x032afda0, unsigned int 1, unsigned int 0) line 681 + 13 
bytes 
js_Interpret(JSContext * 0x032afda0, long * 0x0012c214) line 2292 + 15 bytes 
js_Invoke(JSContext * 0x032afda0, unsigned int 2, unsigned int 0) line 681 + 13 
bytes 
js_Interpret(JSContext * 0x032afda0, long * 0x0012cabc) line 2292 + 15 bytes 
js_Invoke(JSContext * 0x032afda0, unsigned int 1, unsigned int 2) line 681 + 13 
bytes 
js_InternalInvoke(JSContext * 0x032afda0, JSObject * 0x00f4d1e0, long 16044576, 
unsigned int 0, unsigned int 1,
long * 0x0012cc48, long * 0x0012cbf4) line 754 + 19 bytes 
JS_CallFunctionValue(JSContext * 0x032afda0, JSObject * 0x00f4d1e0, long 
16044576, unsigned int 1, long *
0x0012cc48, long * 0x0012cbf4) line 2787 + 31 bytes 
nsJSContext::CallEventHandler(nsJSContext * const 0x032ae080, void * 0x00f4d1e0, 
void * 0x00f4d220, unsigned int
1, void * 0x0012cc48, int * 0x0012cc44) line 562 + 33 bytes 
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x033be764) line 128 + 57 bytes 
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x032cb3f0, 
nsIDOMEvent * 0x033be764,
unsigned int 4) line 677 + 19 bytes 
nsEventListenerManager::HandleEvent(nsIPresContext * 0x032ad4a0, nsEvent * 
0x0012d178, nsIDOMEvent * *
0x0012d140, unsigned int 7, nsEventStatus * 0x0012d43c) line 817 + 25 bytes 
nsXULElement::HandleDOMEvent(nsXULElement * const 0x032cb520, nsIPresContext * 
0x032ad4a0, nsEvent *
0x0012d178, nsIDOMEvent * * 0x0012d140, unsigned int 1, nsEventStatus * 
0x0012d43c) line 2972 
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 
0x0335d8d0, nsIPresContext *
0x032ad4a0, nsMouseEvent * 0x0012d530, nsEventStatus * 0x0012d43c) line 1636 + 
42 bytes 
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x0335d8d0, 
nsIPresContext * 0x032ad4a0,
nsGUIEvent * 0x0012d530, nsIFrame * 0x00eff740, nsEventStatus * 0x0012d43c, 
nsIView * 0x032f14b0) line 854 +
24 bytes 
PresShell::HandleEvent(PresShell * const 0x032f2b14, nsIView * 0x032f14b0, 
nsGUIEvent * 0x0012d530,
nsEventStatus * 0x0012d43c) line 2955 + 43 bytes 
nsView::HandleEvent(nsView * const 0x032f14b0, nsGUIEvent * 0x0012d530, unsigned 
int 28, nsEventStatus *
0x0012d43c, int & 0) line 799 
nsViewManager::DispatchEvent(nsViewManager * const 0x032f1bd0, nsGUIEvent * 
0x0012d530, nsEventStatus *
0x0012d43c) line 1704 
HandleEvent(nsGUIEvent * 0x0012d530) line 69 
nsWindow::DispatchEvent(nsWindow * const 0x032f1394, nsGUIEvent * 0x0012d530, 
nsEventStatus &
nsEventStatus_eIgnore) line 493 + 10 bytes 
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012d530) line 514 
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 2932 + 
21 bytes 
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 
3150 
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 8126761, long * 
0x0012d7bc) line 2237 + 24 bytes 
nsWindow::WindowProc(HWND__ * 0x07f40328, unsigned int 514, unsigned int 0, long 
8126761) line 673 + 27 bytes

USER32! 77e 
Assignee: selmer → troy

Comment 4

19 years ago
This is happening to me on winNT build 2000021509. I also deleted my 
mozregistry.dat and the Users50 directory before attempting to launch mozilla. 
It didn't matter what directory I select.
Keywords: beta1

Comment 5

19 years ago
*** Bug 27916 has been marked as a duplicate of this bug. ***

Comment 6

19 years ago
Re-assigning to Kipp's bug list
Assignee: troy → kipp

Comment 7

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]

Comment 8

19 years ago
I'll take a look.
Assignee: kipp → buster
Priority: P3 → P1
Target Milestone: M14

Comment 9

19 years ago
I think it crases in the "function removeChildren(which)" in newProfile1_2.js 

Comment 10

19 years ago
Ben, is this related to some frontend change you made?  (see gemal's comment.)
I dont know when this started happening but I do not believe I changed the code 
wrt the directory picker. I see this crash also. I don't think it coincides with 
my changes... (it shows up in the 02/13 build, before I landed my changes..)

Updated

19 years ago
Status: NEW → ASSIGNED
Keywords: crash
Summary: Profile CANNOT be created → Crash creating profile using prof. mgr.

Comment 12

19 years ago
If i change the following line in removeChildren:
    for(var i = 0; i < which.childNodes.length; i++)
to:
    for(var i = 0; i < which.childNodes.length-1; i++)

I dont crash but get some other text mix up... 

Comment 13

19 years ago
I'm pretty sure this is a box layout bug.
What's happening is the text content node a getting deleted via javascript.  In 
response to this deletion, an incremental reflow is getting generated.  The box 
layout code is transforming the reflow reason from incremental to resize.  This 
is illegal.  The block code must get an incremental reflow in response to the 
deleted content in order to set it's state properly.  
The actual crash is occuring because the block caches text frames in an 
nsTextRun object, and does not update this object (potentially expensive) in 
response to resize reflows, because resize reflow guarantees that nothing about 
the content has changed.

Incidentally, rod is seeing a similar problem with combo boxes not getting 
incremental reflows when they are needed inside of box layout.  I'll leave it to 
him to decide if it's the same problem or not.

Here's the relevant part of my debug output from the test case:

*** rootFolder = S:\profile\              <--- deletion of text node here
box frame 0135F870 reflow reason incr.    <--- box gets incr. reflow   
block frame 0135FC24 reflow reason resize <--- but block gets resize reflow
nsLineLayout reflowing frame 0135FC6C reflow reason resize
nsTextFrame 0135FC6C reflow reason resize
[crash]
Assignee: buster → evaughan
Status: ASSIGNED → NEW
OS: Windows 98 → All

Comment 14

19 years ago
I have a couple of questions
- what is the type of the incremental reflow command that box is getting?
- is the reflow command targeted at box? If not, who is it targeted at?

It does seem odd that box is reflowing the block frame with a resize reflow. If 
the reflow command is targeted at the box, then I would expect it to be 
reflowing the block with eReflowReason_Dirty.

Comment 15

19 years ago
the incremental reflow is targeted at the block, not the block.
the reflow type is ReflowDirty (aReflowState->reflowCommand->mType)
(Assignee)

Comment 16

19 years ago
I have not idea. Boxes should guarentee you get the reflow. I'll be on vacation 
until the 23. So I'm assigning it to Hyatt to look at. Hyatt reassign it back to 
me on the 23 when I get back.
Assignee: evaughan → hyatt

Comment 17

19 years ago
*** Bug 28339 has been marked as a duplicate of this bug. ***

Comment 18

19 years ago
This is not a profile manager backend bug.  If it's also not layout, please 
correct it.
Component: Profile Manager BackEnd → Layout

Updated

19 years ago
Hardware: PC → All

Comment 19

19 years ago
Oh boy, oh boy.  A box bug!  (Not.)
Status: NEW → ASSIGNED
Component: Layout → XP Toolkit/Widgets: XUL

Comment 20

19 years ago
Since this is no longer in a Profile Manager category, resummarizing to help 
prevent dups being reported.
Summary: Crash creating profile using prof. mgr. → Crash selecting profile folder in profile manager

Comment 21

19 years ago
Re-assigning back to Eric.  It would be foolish for me to hazard a fix here, 
when I don't know exactly what Eric intended.
Assignee: hyatt → evaughan
Status: ASSIGNED → NEW

Comment 22

19 years ago
*** Bug 28582 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+]UNKNOWN- on vacation
(Assignee)

Comment 23

19 years ago
1) Ok when content is added to the block frame it generates a incremental 
reflow. 
2) When the box containing the block frame gets the reflow it realizes that the 
block's preferred size my have changed so it reflows the block with a intrinsic 
width and height and a reason of ResizeReflow to get its preferred size.
3) Once the pref size is aquited the box determines the blocks size based on its 
constaints such as flex, min, max and pref size.
4) The box then flows the block with the incremental reflow. 

So it look like the problem is with the reason Resize. I could use style change 
or whatever but I need a reason that will allow me to get you size given an 
infinite canvas. Would StyleChange work?

-E
Status: NEW → ASSIGNED

Comment 24

19 years ago
No, I don't think StyleChange or any other reflow reason will work here.
My understanding is that if an incremental reflow is generated, the layout 
system must guarantee that the incremental reflow is the *next* reflow that the 
target frame will get.  
To the target, "incremental reflow" means "something significant has changed 
about you, deal with it", and one important effect is that a frame (the block, 
in this case) will recompute interesting cached information in response to an 
incremental reflow.  
To all the ancestors betweeen the root and the target, "incremental reflow" 
means "something interesting has happened to one of your children, deal with 
it."
In this particular case, what has happened is a text frame has been deleted, and 
the block frame needs an incremental reflow to recompute it's cache of text 
frames (a "text run").  This cache is not recomputed for any other reflow type 
because the semantics of the system **guarantees** that nothing can have changed 
with respect to the block's child list until it gets an incremental reflow.  If 
this invariant is violated, the results are undefined, and in the case mentioned 
in this bug you get a crash.  If we change the semantics of this invariant, a 
LOT of frame code (not just block) will have to be changed, and that would be 
very, very bad at this stage.
So, I believe box is required to send down the incremental reflow first, and 
then ask whatever other questions it needs to afterwards.  I heard you and rod 
talking and it sounds like there might be some simple API extentions to nsIFrame 
that could help you out here, but that's a somewhat separate issue.

Comment 25

19 years ago
Like Steve said, if the box code gets reflowed with a reason that says it is an 
incremental reflow, then you need to check whether you're the target of the 
reflow command.

In this case it sounds like you're not, and so you need to get the next 
frame in the reflow chain and reflow it. It also gets a 
eReflowReason_Incremental reflow reason

Comment 26

19 years ago
evaughn, back from vacation?  Can you provide a ETA fix date in Status 
Summary please?
(Assignee)

Comment 27

19 years ago
Ok I think I have a fix for this. I restructured things in box so now this 
happens:

1) Ok when content is added to the block frame it generates a incremental 
reflow. 
2) When the box containing the block frame gets the reflow it realizes that the 
block's preferred size my have changed so it reflows the block with a intrinsic 
width and height and a reason of INCREMENTAL REFLOW to get its preferred size.
3) Once the pref size is aquired the box determines the blocks size based on its 
constaints such as flex, min, max and pref size.
4) The box then flows the block with a RESIZE REFLOW with the actual size

This seems to fix all the quirky things that have been happening. And will 
always give you the incremental reflow FIRST. I'm going to test it out a little 
then I will send you guys a patch to double check it does indeed fix the 
problem for you. 

Comment 28

19 years ago
great news, eric.  waiting for the patch...
(Assignee)

Comment 29

19 years ago
Have fix testing.
Whiteboard: [PDT+]UNKNOWN- on vacation → [PDT+] 2/24/00 Have fix testing.
(Assignee)

Comment 30

19 years ago
fixed
(Assignee)

Comment 31

19 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 32

19 years ago
all  platforms 20000225 builds
Status: RESOLVED → VERIFIED

Comment 33

19 years ago
this didn't make it into M14... but is working on M15 builds.
tested on WINNT M14 release 2000022820 and M15 build 2000022908.

Comment 34

19 years ago
*** Bug 29976 has been marked as a duplicate of this bug. ***

Comment 35

19 years ago
*** Bug 30034 has been marked as a duplicate of this bug. ***

Comment 36

19 years ago
*** Bug 30085 has been marked as a duplicate of this bug. ***

Comment 37

19 years ago
*** Bug 29878 has been marked as a duplicate of this bug. ***
*** Bug 30194 has been marked as a duplicate of this bug. ***

Comment 39

19 years ago
*** Bug 30229 has been marked as a duplicate of this bug. ***
*** Bug 30330 has been marked as a duplicate of this bug. ***

Comment 41

19 years ago
*** Bug 30315 has been marked as a duplicate of this bug. ***

Comment 42

19 years ago
*** Bug 30272 has been marked as a duplicate of this bug. ***

Comment 43

19 years ago
*** Bug 30716 has been marked as a duplicate of this bug. ***
*** Bug 28125 has been marked as a duplicate of this bug. ***

Comment 45

19 years ago
*** Bug 30908 has been marked as a duplicate of this bug. ***

Comment 46

19 years ago
*** Bug 29889 has been marked as a duplicate of this bug. ***
*** Bug 31279 has been marked as a duplicate of this bug. ***
*** Bug 31321 has been marked as a duplicate of this bug. ***

Comment 49

19 years ago
*** Bug 32530 has been marked as a duplicate of this bug. ***
*** Bug 32858 has been marked as a duplicate of this bug. ***
*** Bug 33366 has been marked as a duplicate of this bug. ***

Comment 52

19 years ago
*** Bug 32876 has been marked as a duplicate of this bug. ***
*** Bug 33807 has been marked as a duplicate of this bug. ***

Comment 54

19 years ago
*** Bug 35436 has been marked as a duplicate of this bug. ***

Comment 55

19 years ago
*** Bug 36176 has been marked as a duplicate of this bug. ***

Comment 56

19 years ago
*** Bug 33167 has been marked as a duplicate of this bug. ***
*** Bug 31200 has been marked as a duplicate of this bug. ***

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: agracebush → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.