Closed Bug 27573 Opened 25 years ago Closed 25 years ago

Crash selecting profile folder in profile manager

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: judas, Assigned: eric)

References

Details

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

Attachments

(1 file)

log from crash
23.51 KB, text/plain
Details
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
*** Bug 27597 has been marked as a duplicate of this bug. ***
Attached file log from crash —
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
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
*** Bug 27916 has been marked as a duplicate of this bug. ***
Re-assigning to Kipp's bug list
Assignee: troy → kipp
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
I'll take a look.
Assignee: kipp → buster
Priority: P3 → P1
Target Milestone: M14
I think it crases in the "function removeChildren(which)" in newProfile1_2.js
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..)
Status: NEW → ASSIGNED
Keywords: crash
Summary: Profile CANNOT be created → Crash creating profile using prof. mgr.
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...
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
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.
the incremental reflow is targeted at the block, not the block. the reflow type is ReflowDirty (aReflowState->reflowCommand->mType)
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
*** Bug 28339 has been marked as a duplicate of this bug. ***
This is not a profile manager backend bug. If it's also not layout, please correct it.
Component: Profile Manager BackEnd → Layout
Hardware: PC → All
Oh boy, oh boy. A box bug! (Not.)
Status: NEW → ASSIGNED
Component: Layout → XP Toolkit/Widgets: XUL
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
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
*** Bug 28582 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT+] → [PDT+]UNKNOWN- on vacation
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
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.
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
evaughn, back from vacation? Can you provide a ETA fix date in Status Summary please?
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.
great news, eric. waiting for the patch...
Have fix testing.
Whiteboard: [PDT+]UNKNOWN- on vacation → [PDT+] 2/24/00 Have fix testing.
fixed
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
all platforms 20000225 builds
Status: RESOLVED → VERIFIED
this didn't make it into M14... but is working on M15 builds. tested on WINNT M14 release 2000022820 and M15 build 2000022908.
*** Bug 29976 has been marked as a duplicate of this bug. ***
*** Bug 30034 has been marked as a duplicate of this bug. ***
*** Bug 30085 has been marked as a duplicate of this bug. ***
*** Bug 29878 has been marked as a duplicate of this bug. ***
*** Bug 30194 has been marked as a duplicate of this bug. ***
*** Bug 30229 has been marked as a duplicate of this bug. ***
*** Bug 30330 has been marked as a duplicate of this bug. ***
*** Bug 30315 has been marked as a duplicate of this bug. ***
*** Bug 30272 has been marked as a duplicate of this bug. ***
*** Bug 30716 has been marked as a duplicate of this bug. ***
*** Bug 28125 has been marked as a duplicate of this bug. ***
*** Bug 30908 has been marked as a duplicate of this bug. ***
*** 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. ***
*** 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. ***
*** Bug 32876 has been marked as a duplicate of this bug. ***
*** Bug 33807 has been marked as a duplicate of this bug. ***
*** Bug 35436 has been marked as a duplicate of this bug. ***
*** Bug 36176 has been marked as a duplicate of this bug. ***
*** Bug 33167 has been marked as a duplicate of this bug. ***
*** Bug 31200 has been marked as a duplicate of this bug. ***
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.

Attachment

General

Creator:
Created:
Updated:
Size: