Closed Bug 14377 Opened 26 years ago Closed 26 years ago

Crash in msgbsutil.dll

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: ppandit, Assigned: warrensomebody)

References

Details

(Whiteboard: BLOCKER)

Using a debug build on Windows NT. Pull tree around 2:00 p.m. today (9/20) 1) Started apprunner 2) Opened messenger 3) Open IMAP account Inbox 4) Start scrolling -> crash (see trace below) 5) Stop debugging 6) Restart - apprunner and messenger 7) Open Inbox and scroll downward no problem 8) View new message - no problem 9) Do File->Exit ==> crash (same trace as before) nsRDFResource::~nsRDFResource() line 45 + 10 bytes nsMessage::~nsMessage() line 33 + 19 bytes nsImapMessage::~nsImapMessage() line 39 + 9 bytes nsImapMessage::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsRDFResource::Release(nsRDFResource * const 0x0417f3a0) line 58 + 96 bytes nsMessage::Release(nsMessage * const 0x0417f3a0) line 36 + 12 bytes nsImapMessage::Release(nsImapMessage * const 0x0417f3a0) line 41 + 13 bytes nsCOMPtr<nsIRDFResource>::StartAssignment() line 618 nsGetterAddRefs<nsIRDFResource>::operator nsIRDFResource * *() line 729 RDFElementImpl::SetDocument(RDFElementImpl * const 0x0417f1f0, nsIDocument * 0x00000000, int 1) line 1708 + 26 bytes RDFElementImpl::SetDocument(RDFElementImpl * const 0x03ea51d0, nsIDocument * 0x00000000, int 1) line 1802 RDFElementImpl::SetDocument(RDFElementImpl * const 0x03537e30, nsIDocument * 0x00000000, int 1) line 1802 nsGenericElement::SetDocumentInChildrenOf(nsIContent * 0x0353605c, nsIDocument * 0x00000000) line 661 nsGenericElement::SetDocument(nsIDocument * 0x00000000, int 1) line 713 + 19 bytes nsGenericHTMLElement::SetDocument(nsIDocument * 0x00000000, int 1) line 438 + 16 bytes nsHTMLDivElement::SetDocument(nsHTMLDivElement * const 0x0353605c, nsIDocument * 0x00000000, int 1) line 67 + 22 bytes RDFElementImpl::SetDocument(RDFElementImpl * const 0x0352d900, nsIDocument * 0x00000000, int 1) line 1802 RDFElementImpl::SetDocument(RDFElementImpl * const 0x0352c2e0, nsIDocument * 0x00000000, int 1) line 1802 RDFElementImpl::SetDocument(RDFElementImpl * const 0x034428a0, nsIDocument * 0x00000000, int 1) line 1802 XULDocumentImpl::SetScriptContextOwner(nsIScriptContextOwner * 0x00000000) line 1962 DocumentViewerImpl::~DocumentViewerImpl() line 288 DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes DocumentViewerImpl::Release(DocumentViewerImpl * const 0x02a82d10) line 237 + 99 bytes nsWebShell::Destroy(nsWebShell * const 0x02a58e10) line 1142 + 27 bytes nsWebShellWindow::Close(nsWebShellWindow * const 0x02a56bc0) line 456 GlobalWindowImpl::Close(GlobalWindowImpl * const 0x023af248) line 1313 nsAppShellService::Quit(nsAppShellService * const 0x00aab4e0) line 488 XPTC_InvokeByIndex(nsISupports * 0x00aab4e0, unsigned int 5, unsigned int 0, nsXPTCVariant * 0x0012e2bc) line 135 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x023afd50, nsXPCWrappedNative * 0x04afeb60, const XPCNativeMemberDescriptor * 0x04afd39c, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long * 0x02dad6a0, long * 0x0012e45c) line 751 + 44 bytes WrappedNative_CallMethod(JSContext * 0x023afd50, JSObject * 0x02edccb8, unsigned int 0, long * 0x02dad6a0, long * 0x0012e45c) line 170 + 34 bytes js_Invoke(JSContext * 0x023afd50, unsigned int 0, unsigned int 0) line 654 + 26 bytes js_Interpret(JSContext * 0x023afd50, long * 0x0012ec8c) line 2228 + 15 bytes js_Invoke(JSContext * 0x023afd50, unsigned int 0, unsigned int 0) line 670 + 13 bytes js_Interpret(JSContext * 0x023afd50, long * 0x0012f478) line 2228 + 15 bytes js_Invoke(JSContext * 0x023afd50, unsigned int 1, unsigned int 2) line 670 + 13 bytes js_InternalCall(JSContext * 0x023afd50, JSObject * 0x01db45f8, long 31147520, unsigned int 1, long * 0x0012f5f8, long * 0x0012f5b0) line 747 + 15 bytes JS_CallFunction(JSContext * 0x023afd50, JSObject * 0x01db45f8, JSFunction * 0x03469850, unsigned int 1, long * 0x0012f5f8, long * 0x0012f5b0) line 2630 + 32 bytes nsJSContext::CallFunction(nsJSContext * const 0x023aa1f0, void * 0x01db45f8, void * 0x03469850, unsigned int 1, void * 0x0012f5f8, int * 0x0012f5f4) line 231 + 39 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x04afa2f0) line 103 + 48 bytes nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent * 0x0012f8f8, nsIDOMEvent * * 0x0012f8c0, unsigned int 7, nsEventStatus & nsEventStatus_eIgnore) line 1158 + 27 bytes RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x034685a0, nsIPresContext & {...}, nsEvent * 0x0012f8f8, nsIDOMEvent * * 0x0012f8c0, unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 2872 nsMenuFrame::Execute() line 953 nsMenuFrame::HandleEvent(nsMenuFrame * const 0x02e46c90, nsIPresContext & {...}, nsGUIEvent * 0x0012fbe8, nsEventStatus & nsEventStatus_eConsumeDoDefault) line 239 PresShell::HandleEvent(PresShell * const 0x02a841c4, nsIView * 0x04427930, nsGUIEvent * 0x0012fbe8, nsEventStatus & nsEventStatus_eConsumeDoDefault) line 2052 + 38 bytes nsView::HandleEvent(nsView * const 0x04427930, nsGUIEvent * 0x0012fbe8, unsigned int 8, nsEventStatus & nsEventStatus_eConsumeDoDefault, int & 0) line 828 nsView::HandleEvent(nsView * const 0x02a84620, nsGUIEvent * 0x0012fbe8, unsigned int 28, nsEventStatus & nsEventStatus_eConsumeDoDefault, int & 0) line 813 nsViewManager::DispatchEvent(nsViewManager * const 0x02a84700, nsGUIEvent * 0x0012fbe8, nsEventStatus & nsEventStatus_eConsumeDoDefault) line 1667 HandleEvent(nsGUIEvent * 0x0012fbe8) line 63 nsWindow::DispatchEvent(nsWindow * const 0x044277f4, nsGUIEvent * 0x0012fbe8, nsEventStatus & nsEventStatus_eIgnore) line 332 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fbe8) line 353 nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3160 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3378 nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 29294651, long * 0x0012fe08) line 2394 + 24 bytes nsWindow::WindowProc(HWND__ * 0x00250780, unsigned int 514, unsigned int 0, long 29294651) line 401 + 27 bytes USER32! DispatchMessageWorker@8 + 135 bytes USER32! DispatchMessageA@4 + 11 bytes nsAppShell::Run() line 74 nsAppShellService::Run(nsAppShellService * const 0x00aab4e0) line 462 main1(int 1, char * * 0x00a41600) line 591 + 12 bytes main(int 1, char * * 0x00a41600) line 702 + 13 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! BaseProcessStart@4 + 64 bytes
QA Contact: lchiang → ppandit
Forgot to mention the error: Unhandled exception (MSGBSUTIL.DLL): 0xC0000005 Access Violation Make ppandit the QA contact
I've yet to pull a tree, and probably won't until tomorrow morning, but looking at Warren's changes to nsRDFResource* right before Par pulled the tree, I'm wondering if this could be the same problem we've always had when trying to make a similar change. I bet it is.
Assignee: putterman → warren
Yes, it is. Warren: the problem is that several people statically link with librdfutil_s, and the gRDF symbol gets defined in multiple places, but for some god-foresaken reason, initialized in only one place. I wish we could do what you tried to do, but so far, nobody has been able to figure out how to make it work.
Post B1 we have talked about using aggregation instead of subclassing nsRDFResource. Assuming we do that this problem will go away and we can do what we've been trying to do here.
*** Bug 14434 has been marked as a duplicate of this bug. ***
Whiteboard: BLOCKER
This is a complete blocker for mail/news. We need to get this fixed and respin builds. Mail/news is completely unuseable now.
OK. I've got a build. I will verify this works without these changes and then get approval to back it out. I'm taking silence on this bug to mean that backing out the changes won't break anything else. After I back it out, I will work on my idea to make this work within mailnews. Basically, this lib is being linked into multiple dll's which also happen to hold the base and subclasses of nsMessage and nsMsgFolder. For reasons I'm not sure of now, the call to Init is going through on dll and the destructor is going through another and therefore the gRDFService's are different. So, here's my guess as to what is happening. The Init call is going through the subclass and the destructor is going through the base class. So I will attempt to fix this by making the base classes implement Init and thereby force init to go through the base class. This way they should be using the same gRDFService. This is all theory and why I don't want to try this before the tree opens today.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
I've checked in the fix for this by backing out the nsRDFResource changes.
Making the change I mentioned to mailnews seems to solve the problem. Aggregation is still probably the better way to go since we shouldn't have to be thinking about these issues, but I think this will work and allow us to speed up nsRDFResource.
I don't see how statically linking copies of this code can be the problem. Is it a thread-safety issue? If so, we can make the change and just put locks around the manipulation of the global service variable.
Well, I checked in my changes and checked back in Warren's changes and now everything seems to work.
Status: RESOLVED → VERIFIED
I no longer see this particular problem. I have opened 15474 for a new problem regarding scrolling. VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.