I hope we can convince people to make these assertion failures less fatal in debug builds. NTDLL! 77f76148() nsDebug::Assertion(const char * 0x0184e1b4, const char * 0x0184e0c0, const char * 0x0184e090, int 72) line 140 + 13 bytes mork_assertion_signal(const char * 0x0184e1b4) line 72 + 31 bytes morkEnv::NewWarning(const char * 0x0184e618) line 294 + 19 bytes morkRow::OnZeroTableUse(morkEnv * 0x01889590) line 288 morkTable::CutRow(morkEnv * 0x01889590, morkRow * 0x01d9d750) line 279 orkinTable::CutRow(nsIMdbEnv * 0x018894f8, nsIMdbRow * 0x01dddbe8) line 559 nsMsgDatabase::RemoveHeaderFromDB(nsMsgHdr * 0x01938980) line 795 + 35 bytes nsMsgDatabase::DeleteHeader(nsMsgDatabase * const 0x01889730, nsIMessage * 0x0193898c, nsIDBChangeListener * 0x00000000, int 1, int 1) line 775 nsMsgLocalMailFolder::DeleteMessage(nsMsgLocalMailFolder * const 0x017a814c, nsIMessage * 0x0193898c) line 917 + 31 bytes nsMSGFolderDataSource::DoCommand(nsMSGFolderDataSource * const 0x01781da0, nsISupportsArray * 0x00c552d0, nsIRDFResource * 0x01781510, nsISupportsArray * 0x00000000) line 727 + 19 bytes CompositeDataSourceImpl::DoCommand(CompositeDataSourceImpl * const 0x018cacc0, nsISupportsArray * 0x00c552d0, nsIRDFResource * 0x01781510, nsISupportsArray * 0x00000000) line 950 + 24 bytes nsMsgAppCore::DeleteMessage(nsMsgAppCore * const 0x01f52a10, nsIDOMXULTreeElement * 0x018ccf08, nsIDOMNodeList * 0x01f52930) line 530 + 22 bytes MsgAppCoreDeleteMessage(JSContext * 0x00c35520, JSObject * 0x0148f790, unsigned int 2, long * 0x01b03020, long * 0x0012e69c) line 314 + 26 bytes js_Invoke(JSContext * 0x00c35520, unsigned int 2, int 0) line 650 + 26 bytes js_Interpret(JSContext * 0x00c35520, long * 0x0012ee74) line 2183 + 15 bytes js_Invoke(JSContext * 0x00c35520, unsigned int 0, int 0) line 666 + 13 bytes js_Interpret(JSContext * 0x00c35520, long * 0x0012f608) line 2183 + 15 bytes js_Invoke(JSContext * 0x00c35520, unsigned int 1, int 0) line 666 + 13 bytes js_CallFunctionValue(JSContext * 0x00c35520, JSObject * 0x014244a8, long 21120176, unsigned int 1, long * 0x0012f724, long * 0x0012f72c) line 735 + 15 bytes JS_CallFunctionValue(JSContext * 0x00c35520, JSObject * 0x014244a8, long 21120176, unsigned int 1, long * 0x0012f724, long * 0x0012f72c) line 2371 + 29 bytes nsJSEventListener::ProcessEvent(nsIDOMEvent * 0x01de1c80) line 97 + 34 bytes nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent * 0x0012f844, nsIDOMEvent * * 0x0012f814, nsEventStatus & nsEventStatus_eIgnore) line 320 + 17 bytes RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x01634cd0, nsIPresContext & {...}, nsEvent * 0x0012f844, nsIDOMEvent * * 0x0012f814, unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 2159 nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 0x01f50330, nsIPresContext & {...}, nsMouseEvent * 0x0012fb70, nsEventStatus & nsEventStatus_eIgnore) line 394 + 31 bytes nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x01f50330, nsIPresContext & {...}, nsGUIEvent * 0x0012fb70, nsIFrame * 0x0163d5d0, nsEventStatus & nsEventStatus_eIgnore) line 143 + 24 bytes PresShell::HandleEvent(PresShell * const 0x00c83f94, nsIView * 0x0162b3d0, nsGUIEvent * 0x0012fb70, nsEventStatus & nsEventStatus_eIgnore) line 1942 + 34 bytes nsView::HandleEvent(nsView * const 0x0162b3d0, nsGUIEvent * 0x0012fb70, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore) line 825 nsView::HandleEvent(nsView * const 0x0162bc80, nsGUIEvent * 0x0012fb70, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore) line 808 nsView::HandleEvent(nsView * const 0x0162bd20, nsGUIEvent * 0x0012fb70, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore) line 808 nsScrollingView::HandleEvent(nsScrollingView * const 0x0162bd20, nsGUIEvent * 0x0012fb70, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore) line 875 nsView::HandleEvent(nsView * const 0x00c7de00, nsGUIEvent * 0x0012fb70, unsigned int 28, nsEventStatus & nsEventStatus_eIgnore) line 808 nsViewManager::DispatchEvent(nsViewManager * const 0x00c7c040, nsGUIEvent * 0x0012fb70, nsEventStatus & nsEventStatus_eIgnore) line 1709 HandleEvent(nsGUIEvent * 0x0012fb70) line 64 nsWindow::DispatchEvent(nsWindow * const 0x0162bb90, nsGUIEvent * 0x0012fb70, nsEventStatus & nsEventStatus_eIgnore) line 399 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fb70) line 415 nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 2343 + 15 bytes ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 2492 nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 1245370, long * 0x0012fe64) line 1798 + 24 bytes nsWindow::WindowProc(HWND__ * 0x000804bc, unsigned int 514, unsigned int 0, long 1245370) line 458 + 27 bytes USER32! 77e71250()

putting on M3 radar

Moving to a P1

qa assign to esther. What behavior would we expect to see in the release build on this? A crash?

No, it should just work in release mode, no problem.

It's just a warning that the method needs an implementation. It's not supposed to be fatal. Here's the implementation of that method: void morkRow::OnZeroTableUse(morkEnv* ev) // OnZeroTableUse() is called when CutTableUse() returns zero. { ev->NewWarning("need to implement OnZeroTableUse"); } It can be fixed by commenting it out, which I'll do right now. However, I need a way to break into the debugger in debug builds in a non-lethal fashion. I suppose I can use platform defines to cause asssertions to do nothing on platforms which an assertion is lethal.

cc: ppandit and scurtis since they're using the debug builds for Win32.

I have a reviewed fix for this (commenting out the assert) that I will check in now.

Per Lisa, changing QA assigned to Par since he will be checking the debug builds.

Checked the code - it has been commented out. Tested on 3/17 build - tried to a delete message. No assertion error. But message still exists. Verified for this specific assertion error. Par