crash running filter [@ nsMsgFilterService::ApplyFilters(int, nsIArray*, nsIMsgFolder*, nsIMsgWindow*)] 3.0b4. #73 in rank. So not a strong candidate for blocking. Doesn't appear in 3.0b3, so probably regression. But no crashes in nightlies, so not possible to say if it's fixed on trunk xref recently fixed Bug 518565 [@nsMsgFilterList::LoadTextFilters(nsIInputStream*) ] (which isn't fixed in 3.0b4) bp-8b22f32b-fc9e-4ea3-97bf-79ec12090930 0 thunderbird.exe nsMsgFilterService::ApplyFilters mailnews/base/search/src/nsMsgFilterService.cpp:1012 1 xpcom_core.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101 2 thunderbird.exe XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:2295 3 thunderbird.exe XPC_WN_CallMethod js/src/xpconnect/src/xpcwrappednativejsops.cpp:1590 All available comments: - Was trying to move messages to newly created folder which used to be easy, did a search for emails containing whatever you used to create the folder, it wold then display them all, do a select all and then you could move them enamase to the new folder - was running a filter on the message - I searched messages then selected them and tried to run a message filter on them - Did a search... click show all as list... then selected all messages and clicked run filter.
Created attachment 408941 [details] [diff] [review] Rev a: ENSURE_ARG_POINTER on folder There is probably some UI issue that is calling filters in an invalid situation, but for now we should at least be able to stop the crash by doing the standard practice of checking for null pointers.
Comment on attachment 408941 [details] [diff] [review] Rev a: ENSURE_ARG_POINTER on folder thx, Kent
Comment on attachment 408941 [details] [diff] [review] Rev a: ENSURE_ARG_POINTER on folder This is pretty low risk for RC1.
Comment on attachment 408941 [details] [diff] [review] Rev a: ENSURE_ARG_POINTER on folder Checked in. http://hg.mozilla.org/comm-central/rev/df2bc1f9c011 http://hg.mozilla.org/releases/comm-1.9.1/rev/8c2a2a90a26d
crash is not seen in v3.0.0 (but is in 3.0b4) so I would say this crash is indeed gone