test_askuser.js fails on all platforms. Example log: http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1281272587.1281273215.5505.gz Last good build on Linux: rev:8b1b4701dbab / moz:a9501fcd9c25 First bad build on Linux: rev:af73207d80c1 / moz:f298567cdf2c Last good build on Mac: rev:8b1b4701dbab / moz:a9501fcd9c25 First bad build on Mac: rev:af73207d80c1 / moz:2625ed42ed89 Last good build on Windows: rev:8b1b4701dbab / moz:0e0e2516f04e First bad build on Windows: rev:af73207d80c1 / moz:4980d2c1252c

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1281333772.1281335988.14398.gz#err4 WINNT 5.2 comm-central-trunk debug test xpcshell on 2010/08/08 23:02:52 { TEST-INFO | e:\builds\slave\comm-central-trunk-win32-debug-unittest-xpcshell\build\xpcshell\tests\test_mdn\unit\test_askuser.js | running test ... TEST-UNEXPECTED-FAIL | e:\builds\slave\comm-central-trunk-win32-debug-unittest-xpcshell\build\xpcshell\tests\test_mdn\unit\test_askuser.js | test failed (with xpcshell return code: -2147483645), see following log: >>>>>>> ### XPCOM_MEM_LEAK_LOG defined -- logging leaks to c:\docume~1\seabld\locals~1\temp\tmpdjxsgc\runxpcshelltests_leaks.log pldhash: for the table at address 019111A8, the given entrySize of 48 probably favors chaining over double hashing. Directory request for: SysD that we (mailDirService.js) are not handling, leaving it to another handler. Directory request for: MailD that we (mailDirService.js) are not handling, leaving it to another handler. Directory request for: MFCaF that we (mailDirService.js) are not handling, leaving it to another handler. Directory request for: DefRt that we (mailDirService.js) are not handling, leaving it to another handler. nsNativeModuleLoader::LoadModule("e:\builds\slave\comm-central-trunk-win32-debug-unittest-xpcshell\build\seamonkey\components\gkdebug.dll") - load FAILED, rv: 80520012, error: <unknown; can't get error from NSPR> nsNativeModuleLoader::LoadModule("e:\builds\slave\comm-central-trunk-win32-debug-unittest-xpcshell\build\seamonkey\components\jsperf.dll") - load FAILED, rv: 80520012, error: <unknown; can't get error from NSPR> nsNativeModuleLoader::LoadModule("e:\builds\slave\comm-central-trunk-win32-debug-unittest-xpcshell\build\seamonkey\components\xpcomsample.dll") - load FAILED, rv: 80520012, error: <unknown; can't get error from NSPR> nsNativeModuleLoader::LoadModule("e:\builds\slave\comm-central-trunk-win32-debug-unittest-xpcshell\build\seamonkey\components\xpctest.dll") - load FAILED, rv: 80520012, error: <unknown; can't get error from NSPR> WARNING: No valid default account found, just using first (FIXME): file e:/builds/slave/comm-central-trunk-win32-debug/build/mailnews/base/src/nsMsgAccountManager.cpp, line 776 TEST-INFO | (xpcshell/head.js) | test 1 pending bob@t2.exemple.net ###!!! ASSERTION: StoreMDNSentFlag failed: 'NS_SUCCEEDED(rv)', file e:/builds/slave/comm-central-trunk-win32-debug/build/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp, line 1097 nsStringStats => mAllocCount: 4252 => mReallocCount: 437 => mFreeCount: 2303 -- LEAKED 1949 !!! => mShareCount: 8859 => mAdoptCount: 173 => mAdoptFreeCount: 169 -- LEAKED 4 !!! 0x00000000063D679B 0x00000000063D660F 0x00000000063D6748 xpcom_core!mozilla::CallStack::`default constructor closure'+0x00000000000CD8AA gklayout!DumpJSStack+0x0000000000C37A83 gklayout!DumpJSStack+0x0000000000C355B8 gklayout!DumpJSStack+0x0000000000C35249 gklayout!DumpJSStack+0x0000000000C44B81 mozjs!JS_GetPropertyDescriptorById+0x00000000000BEFE1 mozjs!JS_GetPropertyDescriptorById+0x00000000000BED28 mozjs!JS_GetPropertyDescriptorById+0x000000000009B909 mozjs!JS_GetPropertyDescriptorById+0x00000000000AC9E8 mozjs!JS_GetPropertyDescriptorById+0x000000000009C92F mozjs!JS_GetPropertyDescriptorById+0x0000000000028E3C mozjs!JS_GetPropertyDescriptorById+0x0000000000028F5F 0x0000000000405B58 0x00000000004049F9 0x0000000000412136 0x0000000000411F8D kernel32!ProcessIdToSessionId+0x0000000000000209 ###!!! ASSERTION: StoreMDNSentFlag failed: 'NS_SUCCEEDED(rv)', file e:/builds/slave/comm-central-trunk-win32-debug/build/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp, line 1097 <<<<<<< }

Not that this log explains anything. And given our current look at tests, i.e. almost everything in perma-organe, no test failure is major unless we _know_ that it's caused by an actual functionality problem.

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1281340078.1281340840.991.gz&fulltext=1#err0 Linux comm-central-trunk debug test xpcshell on 2010/08/09 00:47:58 { TEST-INFO | /builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/xpcshell/tests/test_mdn/unit/test_askuser.js | running test ... TEST-UNEXPECTED-FAIL | /builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/xpcshell/tests/test_mdn/unit/test_askuser.js | test failed (with xpcshell return code: -6), see following log: >>>>>>> ### XPCOM_MEM_LEAK_LOG defined -- logging leaks to /tmp/tmpKl53F2/runxpcshelltests_leaks.log nsNativeModuleLoader::LoadModule("/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libgkdebug.so") - load FAILED, rv: 80004005, error: /builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libgkdebug.so: cannot open shared object file: No such file or directory nsNativeModuleLoader::LoadModule("/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libjsperf.so") - load FAILED, rv: 80004005, error: /builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libjsperf.so: cannot open shared object file: No such file or directory nsNativeModuleLoader::LoadModule("/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libxpcomsample.so") - load FAILED, rv: 80004005, error: /builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libxpcomsample.so: cannot open shared object file: No such file or directory nsNativeModuleLoader::LoadModule("/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libxpctest.so") - load FAILED, rv: 80004005, error: /builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libxpctest.so: cannot open shared object file: No such file or directory pldhash: for the table at address 0x9baa8b0, the given entrySize of 48 probably favors chaining over double hashing. Directory request for: MailD that we (mailDirService.js) are not handling, leaving it to another handler. Directory request for: MFCaF that we (mailDirService.js) are not handling, leaving it to another handler. Directory request for: DefRt that we (mailDirService.js) are not handling, leaving it to another handler. TEST-INFO | (xpcshell/head.js) | test 1 pending bob@t2.exemple.net ###!!! ASSERTION: StoreMDNSentFlag failed: 'NS_SUCCEEDED(rv)', file /builds/slave/comm-central-trunk-linux-debug/build/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp, line 1097 UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libmsgmdn.so +0x00001F19] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libmsgmdn.so +0x000051FD] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libmsgmdn.so +0x000066BE] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libmsgmdn.so +0x00006888] NS_InvokeByIndex_P+0x0000002F [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/libxpcom_core.so +0x000DC873] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libgklayout.so +0x00D4B28C] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libgklayout.so +0x00D4D989] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libgklayout.so +0x00D48E40] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/components/libgklayout.so +0x00D5302D] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/libmozjs.so +0x000D48D3] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/libmozjs.so +0x000D0770] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/libmozjs.so +0x000D345D] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/libmozjs.so +0x000BE2EF] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/libmozjs.so +0x000D2A76] JS_EvaluateUCScriptForPrincipals+0x00000135 [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/libmozjs.so +0x00025C43] JS_EvaluateScriptForPrincipals+0x0000007F [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/libmozjs.so +0x00025D06] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/xpcshell +0x00005E3E] UNKNOWN [/builds/slave/comm-central-trunk-linux-debug-unittest-xpcshell/build/seamonkey/xpcshell +0x00006A0D] __libc_start_main+0x000000DC [/lib/libc.so.6 +0x00015DEC] ###!!! ASSERTION: StoreMDNSentFlag failed: 'NS_SUCCEEDED(rv)', file /builds/slave/comm-central-trunk-linux-debug/build/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp, line 1097 <<<<<<< }

(In reply to comment #2) Sorry to have disturbed you: I'll get back to my own business :-/

No disturbance if you work on actually fixing this failures (I'll cheer a lot for that!) - or if someone else doing it can really figure out what the massive amount of cryptic stuff you have posted in here. I pondered looking into the cause of this, but after that dump of non-understable stuff that looks like garbage to me at a first glance, though surely there's something useful in it, I'll first look into things that are cleaner to me. I intentionally only did link the logs in comment #0 and pasted log stuff in comments is more unreadable than the logs themselves, in 80% of all cases I have looked into, the log messages were unhelpful at best, irritating at the worst, and on-hands debugging was needed to find out the the hell was up anyhow. The linked logs won't expire anyhow, AFAIK.

The test has been added in bug 151244 on 2010-04-08, it started to fail when bug 558543 landed at 2010-06-29, adding the second test in this dir.

Our MDN bar landed 2010-05-10 from bug 539066. Still, bienvenu landed the patch that happened to break this test for us - any idea what's going on there?

assertions in debug builds will kill xpcshell tests, though I don't know why you're seeing an assertion.

(In reply to comment #8) > assertions in debug builds will kill xpcshell tests, though I don't know why > you're seeing an assertion. Hmm, right. Are you implying that this just doesn't show up as a failure in Thunderbird because you guys don't test on debug?

I run all the xpcshell tests with my debug builds very frequently and I don't see this problem. So it's not that simple - I'm just telling you a little bit more about why the test seemed to fail for SM.

I guess the question is why we are running into the assertion at all - and possibly a lead could be that we didn't before bug 558543 landed. The test passed correctly before that MDN patch landed - interestingly that one did only touch mailnews/ though.

(In reply to comment #6) > The test has been added in bug 151244 on 2010-04-08, it started to fail when > bug 558543 landed at 2010-06-29, adding the second test in this dir. (In reply to comment #7) > Our MDN bar landed 2010-05-10 from bug 539066. Fwiw, http://brasstacks.mozilla.com/topfails/test/SeaMonkey?name=chrome://mochikit/content/browser/toolkit/content/tests/browser/browser_Services.js "2010-05-08 02:30": oldest report (in the db) though the error may have changed in the meantime... "2010-06-29 11:55": was already failing until 2010-06-24 22:03, I would assume the test suite just didn't run in that 5 days timeframe.

Correct URL: http://brasstacks.mozilla.com/topfails/test/SeaMonkey?name=xpcshell/tests/test_mdn/unit/test_askuser.js

I don't feel comfortable blocking on this perma-orange until we know if its an actually issue in the application, or if its an issue in the test. That said, I wholehartedly want to devote resources to getting our tests green and this fixed.

What happens is the following: http://mxr.mozilla.org/comm-central/source/mailnews/extensions/mdn/test/unit/test_askuser.js?mark=46-46,54-55 There we have an undefined key, which results in a null key used as parameter for the call of StoreMDNSentFlag: http://mxr.mozilla.org/comm-central/source/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp?mark=173-174,181-181#173 The MarkMDNSent call fails of course with a null key, so we hit the assertion at http://mxr.mozilla.org/comm-central/source/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp?mark=1096-1097#1094

Could that test be expecting that msgHdr.messageKey gets set to 0?

Forgot to mention that Thunderbird debug also hits that assertion. (In reply to comment #16) > Could that test be expecting that msgHdr.messageKey gets set to 0? Setting this explicitly in the test also results in a null key and thus the assertion gets triggered.

Now I understood comment #16, the test needs to add a message to the local mail folder, just as test_mdnFlags.js does.

Pushed: http://hg.mozilla.org/comm-central/rev/50cab7663d15