11638 - Profile manager crashes

Status: VERIFIED FIXED

(Core Graveyard :: Profile: BackEnd, defect, P3)

Description

[Stephen P. Morse]

Pulled a fresh tree as of this morning (after M9 freeze).  Deleted moz registry.
Executed browser.  Got in profile manager.  Filled in profile name and clicked
on next.  Got an assertion failure (shown below).  Continued executing from that
failure and got a couple of more assertion failures.  Finally got a hard crash.

Fortunately, the profile manager did get far enough along as to create a profile
and new moz registry so upon re-execution of the browser the profile manager was
bypassed and the browser came up successfully.


operator delete(void * 0x09c30700) line 47 + 81 bytes
CharImpl::~CharImpl() line 215 + 20 bytes
CharImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes
BasicStringImpl::Release(BasicStringImpl * const 0x09c30990) line 327 + 98 bytes
nsCOMPtr<nsIRandomAccessStore>::~nsCOMPtr<nsIRandomAccessStore>() line 474
nsRandomAccessStoreClient::~nsRandomAccessStoreClient() line 357 + 27 bytes
nsRandomAccessOutputStream::~nsRandomAccessOutputStream() + 49 bytes
nsOutputStringStream::~nsOutputStringStream() + 15 bytes
nsProfile::SetProfileDir(nsProfile * const 0x00a85ad0, const char * 0x09c30ef0,
const nsFileSpec & {...}) line 925 + 9 bytes
nsProfile::CreateNewProfile(nsProfile * const 0x00a85ad0, char * 0x09b58f10)
line 1033 + 20 bytes
nsProfileCore::CreateNewProfile(nsProfileCore * const 0x09ba710c, const nsString
& {...}) line 165
ProfileCoreCreateNewProfile(JSContext * 0x09bb3610, JSObject * 0x00d26c10,
unsigned int 1, long * 0x00d3edd0, long * 0x0012dd78) line 181 + 16 bytes
js_Invoke(JSContext * 0x09bb3610, unsigned int 1, unsigned int 0) line 654 + 26
bytes
js_Interpret(JSContext * 0x09bb3610, long * 0x0012e5a4) line 2228 + 15 bytes
js_Invoke(JSContext * 0x09bb3610, unsigned int 0, unsigned int 0) line 670 + 13
bytes
js_Interpret(JSContext * 0x09bb3610, long * 0x0012ed8c) line 2228 + 15 bytes
js_Invoke(JSContext * 0x09bb3610, unsigned int 0, unsigned int 0) line 670 + 13
bytes
js_Interpret(JSContext * 0x09bb3610, long * 0x0012f574) line 2228 + 15 bytes
js_Invoke(JSContext * 0x09bb3610, unsigned int 1, unsigned int 2) line 670 + 13
bytes
js_InternalCall(JSContext * 0x09bb3610, JSObject * 0x00d26520, long 13788456,
unsigned int 1, long * 0x0012f6b4, long * 0x0012f6bc) line 747 + 15 bytes
JS_CallFunctionValue(JSContext * 0x09bb3610, JSObject * 0x00d26520, long
13788456, unsigned int 1, long * 0x0012f6b4, long * 0x0012f6bc) line 2643 + 29
bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x09c1c550) line 97 + 34 bytes
nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012f928, nsIDOMEvent * * 0x0012f7f4, unsigned int 3, nsEventStatus &
nsEventStatus_eIgnore) line 601 + 21 bytes
nsGenericElement::HandleDOMEvent(nsIPresContext & {...}, nsEvent * 0x0012f928,
nsIDOMEvent * * 0x0012f7f4, unsigned int 1, nsEventStatus &
nsEventStatus_eIgnore) line 784
nsHTMLButtonElement::HandleDOMEvent(nsHTMLButtonElement * const 0x09c13c7c,
nsIPresContext & {...}, nsEvent * 0x0012f928, nsIDOMEvent * * 0x00000000,
unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 398 + 31 bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const
0x09c1d170, nsIPresContext & {...}, nsMouseEvent * 0x0012fba0, nsEventStatus &
nsEventStatus_eIgnore) line 735 + 31 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x09c1d170,
nsIPresContext & {...}, nsGUIEvent * 0x0012fba0, nsIFrame * 0x09c1a100,
nsEventStatus & nsEventStatus_eIgnore, nsIView * 0x09bced00) line 261 + 24 bytes
PresShell::HandleEvent(PresShell * const 0x09bce904, nsIView * 0x09bced00,
nsGUIEvent * 0x0012fba0, nsEventStatus & nsEventStatus_eIgnore) line 1882 + 43
bytes
nsView::HandleEvent(nsView * const 0x09bced00, nsGUIEvent * 0x0012fba0, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 835
nsViewManager::DispatchEvent(nsViewManager * const 0x09bcef20, nsGUIEvent *
0x0012fba0, nsEventStatus & nsEventStatus_eIgnore) line 1611
HandleEvent(nsGUIEvent * 0x0012fba0) line 67
nsWindow::DispatchEvent(nsWindow * const 0x09bcebc4, nsGUIEvent * 0x0012fba0,
nsEventStatus & nsEventStatus_eIgnore) line 498 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fba0) line 523
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3268 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line
3463
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 917807, long *
0x0012fdd4) line 2536 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x095c03ce, unsigned int 514, unsigned int 0, long
917807) line 571 + 27 bytes
USER32! 77e71268()

Comment 1

[racham]

OutputStringStream seems to be taking the ownership of the string passed to it's
constructor. So, at the end of block scope, it does the deletion of the string
automatically. We have nsCRT::free statement before the end of the block. So, I
will confirm with Doug (who did some work on StringStrem classes) to see whether
the behavior is going to continue that way and fix the bug accordingly.

Comment 2

[racham]

Adding McAfee and Doug Turner to cc list.

Comment 3

[Stephen P. Morse]

Just thought I'd point out that this bug still has no Target Milestone assigned.
I would consider this to be an M9 showstopper since a user who is using the
browser for the first time can't even get started because of this bug.

Comment 4

[Stephen P. Morse]

Well maybe "can't even get started" was a bit too strong.  If he restarts the
browsser after the crash, things will then procede normally.  But every new user
will always get a crash on first usage.

Comment 5

[racham]

Setting severity (critical) and Target Milestone (M9).

Comment 6

[Doug Turner (:dougt)]

Ownership of the passed string should belong to CharImpl.  The reason is
simple, I need to reallocate in during writes that overrun my internal buffer.

There are two ways to solve this.  First, do not delete the buffer that you
pass to any of the stream objects based on CharImpl.  Second, don't pass a
buffer to the stream, and let it allocate it own.

For the crash, I would recommend that you simple do not delete the buffer which
you allocate for the stream.

Comment 7

[racham]

I have checked in the fix for bugs 11638, 11716.
You can simply update nsProfile.cpp on your local builds.

Also, I have added couple of printfs in nsAppRunner.cpp.
You can update this too, if you want.

They are :

Profile Manager : Command Line Options : Begin
Profile Manager : Command Line Options : End

Profile Manager : Profile Wizard and Manager activities : Begin
Profile Manager : Profile Wizard and Manager activities : End

If all the Begin and End are matched, then the problem lies with the other
compoenents, not the Profile Manager.

If One of the above Begins does not match, one of the Ends, then the the problem
is with Profile Manager or with the services it is using.

As Profile Manager is one of the very first apps that gets kicked off these
statements will be helpful. In future, these statements should help us providing
a layer of granularity in terms of identifying Profile Manager's part as a
probable/improbable cause of any problem.

Comment 8

[Grace Bush]

Aug13 build

Comment 9

[leger]

Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.