From Bug Helper: User-Agent: Mozilla/5.0 (Windows; N; NT4.0; en-US) Mozilla/m13 BuildID: 20000224 After setting up my first mail account, I clicked on the account name in the Mail Folders pane. Got four asserts. Reproducible: Always Steps to Reproduce: 1. Start Mozilla. Click on the Mail icon in the task bar 2. Because I had no mail accounts set up, Mozilla promped me to set one up. I set up a POP account. 3. Edited the pop account's server options (leave mail on server; check for mail every 10 minutes; save password) 4. In the Mail Window's Mail Folders pane, click on the new account. -> four asserts. Actual Results: Here are the warnings I got: In ChangeFolderByURI ###!!! ASSERTION: morkBool_kFalse: '0', file d:\mozsrc\mozilla\db\mork\src\morkConfig.cpp, line 78 Lost focus. ###!!! ASSERTION: morkBool_kFalse: '0', file d:\mozsrc\mozilla\db\mork\src\morkConfig.cpp, line 78 Lost focus. ###!!! ASSERTION: morkBool_kFalse: '0', file d:\mozsrc\mozilla\db\mork\src\morkConfig.cpp, line 78 Lost focus. ###!!! ASSERTION: morkBool_kFalse: '0', file d:\mozsrc\mozilla\db\mork\src\morkConfig.cpp, line 78 Lost focus. ###!!! ASSERTION: morkBool_kFalse: '0', file d:\mozsrc\mozilla\db\mork\src\morkConfig.cpp, line 78 Lost focus. ###!!! ASSERTION: morkBool_kFalse: '0', file d:\mozsrc\mozilla\db\mork\src\morkConfig.cpp, line 78 Lost focus.

Can you F5 past the asserts?

yeah... I just kept going. i can get a stack trace if you want, though.

All Mork asserts get funneled to the same place in morkConfig.cpp; the place in the code with the problem is several layers higher up, where someone calls a method named something like NewError(). I can try to reproduce this, and a stack crawl would be useful if somone gets one before I do. Yes... a stack crawl would help.

here it is NTDLL! 77f76274() nsDebug::Assertion(const char * 0x024ccb48, const char * 0x024cca54, const char * 0x024cca24, int 78) line 189 + 13 bytes mork_assertion_signal(const char * 0x024ccb48) line 78 + 31 bytes morkEnv::NewError(const char * 0x0338e7a0) line 369 + 19 bytes morkFile::NewFileErrnoError(morkEnv * 0x0338e8f0) line 272 morkStdioFile::new_stdio_file_fault(morkEnv * 0x0338e8f0) line 668 morkStdioFile::OpenStdio(morkEnv * 0x0338e8f0, const char * 0x0338e968, const char * 0x024ccd94) line 739 morkStdioFile::morkStdioFile(morkEnv * 0x0338e8f0, const morkUsage & {...}, nsIMdbHeap * 0x018bfb58, nsIMdbHeap * 0x018bfb58, const char * 0x0338e968, const char * 0x024ccd94) line 693 morkStdioFile::CreateNewStdioFile(morkEnv * 0x0338e8f0, nsIMdbHeap * 0x018bfb58, const char * 0x0338e968) line 393 + 61 bytes morkFile::CreateNewFile(morkEnv * 0x0338e8f0, nsIMdbHeap * 0x018bfb58, const char * 0x0338e968) line 191 + 17 bytes orkinFactory::CreateNewFile(nsIMdbEnv * 0x0338cae8, nsIMdbHeap * 0x018bfb58, const char * 0x0338e968, nsIMdbFile * * 0x0012c7c0) line 347 + 17 bytes nsMsgDatabase::OpenMDB(nsMsgDatabase * const 0x0338eb20, const char * 0x0338e968, int 1) line 643 + 30 bytes nsMailDatabase::Open(nsMailDatabase * const 0x0338d1d0, nsIFileSpec * 0x03b64860, int 1, int 0, nsIMsgDatabase * * 0x03b67ae8) line 89 + 29 bytes nsMsgLocalMailFolder::GetDatabase(nsIMsgWindow * 0x032e9a20) line 474 + 66 bytes nsMsgLocalMailFolder::UpdateFolder(nsMsgLocalMailFolder * const 0x03b67a78, nsIMsgWindow * 0x032e9a20) line 520 + 19 bytes XPTC_InvokeByIndex(nsISupports * 0x03b67a78, unsigned int 32, unsigned int 1, nsXPTCVariant * 0x0012cae4) line 139 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x02eaf750, nsXPCWrappedNative * 0x0338ff40, const XPCNativeMemberDescriptor * 0x03c2860c, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 1, long * 0x02142f90, long * 0x0012cca4) line 898 + 43 bytes WrappedNative_CallMethod(JSContext * 0x02eaf750, JSObject * 0x0214ba90, unsigned int 1, long * 0x02142f90, long * 0x0012cca4) line 200 + 34 bytes js_Invoke(JSContext * 0x02eaf750, unsigned int 1, unsigned int 0) line 665 + 26 bytes js_Interpret(JSContext * 0x02eaf750, long * 0x0012d590) line 2292 + 15 bytes js_Invoke(JSContext * 0x02eaf750, unsigned int 3, unsigned int 0) line 681 + 13 bytes js_Interpret(JSContext * 0x02eaf750, long * 0x0012de38) line 2292 + 15 bytes js_Invoke(JSContext * 0x02eaf750, unsigned int 1, unsigned int 0) line 681 + 13 bytes js_Interpret(JSContext * 0x02eaf750, long * 0x0012e6e0) line 2292 + 15 bytes js_Invoke(JSContext * 0x02eaf750, unsigned int 0, unsigned int 0) line 681 + 13 bytes js_Interpret(JSContext * 0x02eaf750, long * 0x0012ef88) line 2292 + 15 bytes js_Invoke(JSContext * 0x02eaf750, unsigned int 1, unsigned int 2) line 681 + 13 bytes js_InternalInvoke(JSContext * 0x02eaf750, JSObject * 0x0221d978, long 34912824, unsigned int 0, unsigned int 1, long * 0x0012f114, long * 0x0012f0c0) line 754 + 19 bytes JS_CallFunctionValue(JSContext * 0x02eaf750, JSObject * 0x0221d978, long 34912824, unsigned int 1, long * 0x0012f114, long * 0x0012f0c0) line 2787 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x02eaf8e0, void * 0x0221d978, void * 0x0214ba38, unsigned int 1, void * 0x0012f114, int * 0x0012f110) line 562 + 33 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x0338d874) line 128 + 57 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x030ede90, nsIDOMEvent * 0x0338d874, unsigned int 8, unsigned int 7) line 697 + 19 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x02ed9a00, nsEvent * 0x0012f670, nsIDOMEvent * * 0x0012f610, unsigned int 7, nsEventStatus * 0x0012f690) line 1191 + 35 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x030e46f0, nsIPresContext * 0x02ed9a00, nsEvent * 0x0012f670, nsIDOMEvent * * 0x0012f610, unsigned int 1, nsEventStatus * 0x0012f690) line 2987 nsXULTreeElement::FireOnSelectHandler(nsXULTreeElement * const 0x033068bc) line 556 nsXULTreeElement::SelectCell(nsXULTreeElement * const 0x033068b8, nsIDOMXULElement * 0x040fb194) line 207 nsTreeFrame::SetSelection(nsIPresContext * 0x02ed9a00, nsTreeCellFrame * 0x00ee9d48) line 144 nsTreeCellFrame::HandleMouseDownEvent(nsIPresContext * 0x02ed9a00, nsGUIEvent * 0x0012fad4, nsEventStatus * 0x0012f9e0) line 238 nsTreeCellFrame::HandleEvent(nsTreeCellFrame * const 0x00ee9d48, nsIPresContext * 0x02ed9a00, nsGUIEvent * 0x0012fad4, nsEventStatus * 0x0012f9e0) line 191 PresShell::HandleEvent(PresShell * const 0x02edae64, nsIView * 0x0319e740, nsGUIEvent * 0x0012fad4, nsEventStatus * 0x0012f9e0) line 2950 + 38 bytes nsView::HandleEvent(nsView * const 0x0319e740, nsGUIEvent * 0x0012fad4, unsigned int 8, nsEventStatus * 0x0012f9e0, int & 0) line 799 nsView::HandleEvent(nsView * const 0x02ed9440, nsGUIEvent * 0x0012fad4, unsigned int 28, nsEventStatus * 0x0012f9e0, int & 0) line 784 nsViewManager2::DispatchEvent(nsViewManager2 * const 0x02ed9700, nsGUIEvent * 0x0012fad4, nsEventStatus * 0x0012f9e0) line 1216 HandleEvent(nsGUIEvent * 0x0012fad4) line 69 nsWindow::DispatchEvent(nsWindow * const 0x02ed9324, nsGUIEvent * 0x0012fad4, nsEventStatus & nsEventStatus_eIgnore) line 493 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fad4) line 514 nsWindow::DispatchMouseEvent(unsigned int 302, nsPoint * 0x00000000) line 2938 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 302, nsPoint * 0x00000000) line 3156 nsWindow::ProcessMessage(unsigned int 513, unsigned int 1, long 6881329, long * 0x0012fd60) line 2238 + 24 bytes nsWindow::WindowProc(HWND__ * 0x01de01ba, unsigned int 513, unsigned int 1, long 6881329) line 671 + 27 bytes USER32! 77e71268()

+ morkStdioFile::new_stdio_file_fault(morkEnv * 0x0338e8f0) line 668 + morkStdioFile::OpenStdio(morkEnv * 0x0338e8f0, const char * 0x0338e968, const + char * 0x024ccd94) line 739 ... shows an attempt to open the file failed. Nine times in ten this happens because the file is already open for some reason, and someone wants to do it again. The most common reason is running more than one client instance. If you look at the value of errno as seen in NewFileErrnoError(), then we'd see what actual OS error was reported after fopen() failed.

okay, from: morkStdioFile::morkStdioFile, looks like it was trying to open d:\mozsrc\mozilla\dist\win32_d.obj\Users50\christine\Mail\server1.msf that file exists and has data in it. morkFile::NewfileErrrnoError has an errnoString property whose value is "Invalid argument". there is no errno property defined in that function.

cc David Bienvenu. Now I'm changing my story as follows (sorry for veering around): we are trying to create a new file which already exists, per + morkFile::CreateNewFile(morkEnv * 0x0338e8f0, nsIMdbHeap * 0x018bfb58, const + char * 0x0338e968) line 191 + 17 bytes + orkinFactory::CreateNewFile(nsIMdbEnv * 0x0338cae8, nsIMdbHeap * 0x018bfb58, + const char * 0x0338e968, nsIMdbFile * * 0x0012c7c0) line 347 + 17 bytes And we are doing this at the request of nsMsgDatabase::OpenMDB() which is responsible for knowing whether it should open an old db file or create a new db file. To create a new one when the file is already exists requires that the MDB client delete the old file first. MDB won't do it for you. (I usually make DB software refuse to delete files, so vanishing data is never the fault of db software, since a client has to delete files.)

No, I doubt that strongly - I only create new db's if I couldn't open the existing one. Did you actually see this happen in the debugger, or is it speculation? Since this bug is not reported on a mac, I doubt the problem is that the file is already open. Every time I've seen this bug, it's because the parent directory didn't exist.

I was working from "that file exists and has data in it" as stated by cbegle. If a file exists, and you can't open it, then the old file must be deleted (I think) before you can create new db. I should add a call to strerror() to those error methods, so the string for errno is actually on hand for folks to report.

Any progress on trying to reproduce this?

I have not tried to reproduce yet; the steps are very like the ones I followed to reproduce another bug that happened when a new account was created. But I guess I need to edit the pop account's server options to actually reproduce.

these are mine now, I guess.

Marking M16 (not M15 stopper)

accepting

Not M16 stopper. Marking M17.

moving to future.

For at least several days, I've started seeing this assertion every time I start mail/news. Resetting the target milestone, adding nsbeta3, and updating summary, since we shouldn't be hitting assertions, especially not in tasks as basic as this.

I'm seeing this on debug builds from the tip on NT4, by the way.

what's the path passed into nsMsgDatabase::OpenMDB? this assert is almost always because the parent directory doesn't exist. Is that the case? Nothing has changed in the mork code.

dbname is being passed in as "" (the null string). call stack looks like this: NTDLL! 77f7629c() nsDebug::Assertion(const char * 0x0207cb9c, const char * 0x0207caa8, const char * 0x0207ca74, int 78) line 256 + 13 bytes mork_assertion_signal(const char * 0x0207cb9c) line 78 + 31 bytes morkEnv::NewError(const char * 0x0207cdf0) line 369 + 19 bytes morkStdioFile::OpenStdio(morkEnv * 0x04337a00, const char * 0x043364e8, const char * 0x0207cde8) line 741 morkStdioFile::morkStdioFile(morkEnv * 0x04337a00, const morkUsage & {...}, nsIMdbHeap * 0x01be0688, nsIMdbHeap * 0x01be0688, const char * 0x043364e8, const char * 0x0207cde8) line 693 morkStdioFile::CreateNewStdioFile(morkEnv * 0x04337a00, nsIMdbHeap * 0x01be0688, const char * 0x043364e8) line 393 + 61 bytes morkFile::CreateNewFile(morkEnv * 0x04337a00, nsIMdbHeap * 0x01be0688, const char * 0x043364e8) line 191 + 17 bytes orkinFactory::CreateNewFile(nsIMdbEnv * 0x04335e28, nsIMdbHeap * 0x01be0688, const char * 0x043364e8, nsIMdbFile * * 0x0012dc48) line 347 + 17 bytes nsMsgDatabase::OpenMDB(nsMsgDatabase * const 0x04337a70, const char * 0x043364e8, int 1) line 968 + 30 bytes nsImapMailDatabase::Open(nsImapMailDatabase * const 0x04337ca0, nsIFileSpec * 0x04337f30, int 1, int 1, nsIMsgDatabase * * 0x043361f8) line 94 + 29 bytes nsImapMailFolder::GetDatabase(nsIMsgWindow * 0x00000000) line 436 + 66 bytes nsImapMailFolder::GetDBFolderInfoAndDB(nsImapMailFolder * const 0x0433617c, nsIDBFolderInfo * * 0x0012dee4, nsIMsgDatabase * * 0x0012dee0) line 1356 + 17 bytes nsMsgDBFolder::ReadDBFolderInfo(int 0) line 441 + 67 bytes nsMsgDBFolder::SetFlag(nsMsgDBFolder * const 0x0433617c, unsigned int 1024) line 957 nsMsgAccountManager::SetSpecialFoldersForIdentities(nsMsgAccountManager * const 0x042e8410) line 1237 + 40 bytes XPTC_InvokeByIndex(nsISupports * 0x042e8410, unsigned int 27, unsigned int 0, nsXPTCVariant * 0x0012e198) line 139 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x03df6e70, nsXPCWrappedNative * 0x042ea6f0, const XPCNativeMemberDescriptor * 0x042e9dac, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long * 0x0385b598, long * 0x0012e348) line 915 + 43 bytes WrappedNative_CallMethod(JSContext * 0x03df6e70, JSObject * 0x038b2620, unsigned int 0, long * 0x0385b598, long * 0x0012e348) line 226 + 34 bytes js_Invoke(JSContext * 0x03df6e70, unsigned int 0, unsigned int 0) line 731 + 23 bytes js_Interpret(JSContext * 0x03df6e70, long * 0x0012ecd0) line 2538 + 15 bytes js_Invoke(JSContext * 0x03df6e70, unsigned int 1, unsigned int 2) line 748 + 13 bytes js_InternalInvoke(JSContext * 0x03df6e70, JSObject * 0x02a51e50, long 13517288, unsigned int 0, unsigned int 1, long * 0x0012ee64, long * 0x0012edf4) line 821 + 19 bytes JS_CallFunctionValue(JSContext * 0x03df6e70, JSObject * 0x02a51e50, long 13517288, unsigned int 1, long * 0x0012ee64, long * 0x0012edf4) line 3175 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x03df56f0, void * 0x02a51e50, void * 0x00ce41e8, unsigned int 1, void * 0x0012ee64, int * 0x0012ee60, int 0) line 902 + 33 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x042e5704) line 154 + 64 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x034783b0, nsIDOMEvent * 0x042e5704, nsIDOMEventTarget * 0x03df5770, unsigned int 1, unsigned int 7) line 788 + 19 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x03e18b70, nsEvent * 0x0012f394, nsIDOMEvent * * 0x0012f358, nsIDOMEventTarget * 0x03df5770, unsigned int 7, nsEventStatus * 0x0012f3b8) line 1361 + 39 bytes GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x03df5760, nsIPresContext * 0x03e18b70, nsEvent * 0x0012f394, nsIDOMEvent * * 0x0012f358, unsigned int 1, nsEventStatus * 0x0012f3b8) line 456 DocumentViewerImpl::LoadComplete(DocumentViewerImpl * const 0x03df3a80, unsigned int 0) line 668 + 47 bytes nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x03df5cb8, nsIDocumentLoader * 0x03df40a0, nsIChannel * 0x03e144d0, unsigned int 0) line 974 nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x03df40a0, nsIChannel * 0x03e144d0, unsigned int 0) line 804 nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 611 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x03df40a4, nsIChannel * 0x042a94c0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100a45e8 gCommonEmptyBuffer) line 554 nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x03df5b30, nsIChannel * 0x042a94c0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100a45e8 gCommonEmptyBuffer) line 566 + 39 bytes nsJARChannel::OnStopRequest(nsJARChannel * const 0x042a94c4, nsIChannel * 0x042aa9b0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100a45e8 gCommonEmptyBuffer) line 933 nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x042ab050) line 302 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x042aba00) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x042aba00) line 589 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00b4ff90) line 526 + 9 bytes _md_EventReceiverProc(HWND__ * 0x0158026c, unsigned int 49401, unsigned int 0, long 11861904) line 1059 + 9 bytes USER32! 77e71820() 00b4ff90()

nsbeta3-, please provide information on the impact to non-debug builds if you think this is a mistake.

some of us run debug builds - this would be very annoying. Should be trivial to fix.

I see this alot too in my debug builds. David do you know what is causing these asserts and perhaps a fix. You said it should be easy to fix?

Henrik, do you have the same stack trace? This should be fixed in the caller, I think.

stacktrace: is that with visualc? I use gcc and mingw... I'm a newbie in all this self building mozilla...:)

you'd get a stack trace out of gdb or some other debugger, if you ran in the debugger.

doing some trace I can see that CreateNewStdioFile is called to create the following file: C:\DOCUMENTS AND SETTINGS\HENRIK GEMAL\APPLICATION DATA\Thunderbird\Profiles\news\fahaowii.slt\News\news.tele.dk.msf\ could the problem be the ending with "\" ?

FYI: for sql style query: sqlite is Public Domain and seems well commented http://www.hwaci.com/sw/sqlite/

Wrong bug -- please ignore

I haven't seen this in a long time. Please re-open if you have steps to reproduce.