Closed Bug 925489 Opened 11 years ago Closed 11 years ago

Perma-fail: test_bug155172.js | test failed (with xpcshell return code: 0) and a bunch more

Categories

(Thunderbird :: Testing Infrastructure, defect)

Product:
Thunderbird
Component:
Testing Infrastructure
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 27.0

People

(Reporter: RyanVM, Assigned: hiro)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure, regression)

Attachments

(3 files, 2 obsolete files)

wip2
32.27 KB, patch
Details | Diff | Splinter Review
The script for generating files
2.90 KB, application/javascript
Details
Update Magnus's patch with correct key3.db
43.97 KB, patch
standard8
: review+
Details | Diff | Splinter Review
Looks like this bustage comes from m-c. Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=aa986b6ce882&tochange=c7cd2a9b50a7 https://tbpl.mozilla.org/php/getParsedLog.php?id=28939824&tree=Thunderbird-Trunk TEST-UNEXPECTED-FAIL | C:\slave\test\build\xpcshell\tests\mailnews\compose\test\unit\test_bug155172.js | test failed (with xpcshell return code: 0), see following log: >>>>>>> TEST-INFO | (xpcshell/head.js) | test MAIN run_test pending (1) WARNING: No valid default account found.: file e:/builds/moz2_slave/tb-c-cen-w32-d-000000000000000/build/mailnews/base/src/nsMsgAccountManager.cpp, line 791 WARNING: Just using the first one (FIXME).: file e:/builds/moz2_slave/tb-c-cen-w32-d-000000000000000/build/mailnews/base/src/nsMsgAccountManager.cpp, line 793 WARNING: NS_ENSURE_TRUE(m_callbacks) failed: file e:/builds/moz2_slave/tb-c-cen-w32-d-000000000000000/build/mailnews/compose/src/nsSmtpUrl.cpp, line 731 Received Connection from 127.0.0.1:55993 RECV: EHLO test Received command EHLO SEND: 250-fakeserver greets you SEND: 250-8BITMIME SEND: 250-SIZE SEND: 250-AUTH PLAIN LOGIN SEND: 250 HELP SEND: WARNING: This method is lossy. Use GetCanonicalPath !: file e:/builds/moz2_slave/tb-c-cen-w32-d-000000000000000/build/mozilla/xpcom/io/nsLocalFileWin.cpp, line 3261 RECV: AUTH PLAIN AHRlc3Quc210cEBmYWtlc2VydmVyAHdyb25n Received command AUTH Starting AUTH PLAIN AUTH PLAIN line -AHRlc3Quc210cEBmYWtlc2VydmVyAHdyb25n- authorize-id: --, username: -test.smtp@fakeserver-, password: -wrong- SEND: 235 2.7.0 Hello friend! Friends give friends good advice: Next time, use CRAM-MD5 SEND: RECV: MAIL FROM:<from@foo.invalid> SIZE=155 Received command MAIL SEND: 250 ok SEND: RECV: RCPT TO:<to@foo.invalid> Received command RCPT SEND: 250 ok SEND: RECV: DATA Received command DATA SEND: 354 ok SEND: RECV: From: from@foo.invalid RECV: To: to@foo.invalid RECV: Subject: test mail RECV: RECV: this email is in dos format because that is what the interface requires RECV: RECV: test message RECV: . SEND: 250 Wonderful article, your style is gorgeous! SEND: RECV: QUIT Received command QUIT SEND: 221 done SEND: TEST-UNEXPECTED-FAIL | C:/slave/test/build/xpcshell/tests/mailnews/compose/test/unit/head_compose.js | "EHLO test,AUTH PLAIN AHRlc3Quc210cEBmYWtlc2VydmVyAHdyb25n,MAIL FROM:<from@foo.invalid> SIZE=155,RCPT TO:<to@foo.invalid>,DATA" == "EHLO test,AUTH PLAIN AHRlc3Quc210cEBmYWtlc2VydmVyAHNtdHB0ZXN0,AUTH LOGIN,AUTH PLAIN AHRlc3Quc210cEBmYWtlc2VydmVyAHdyb25n,MAIL FROM:<from@foo.invalid> SIZE=155,RCPT TO:<to@foo.invalid>,DATA" - See following stack: JS frame :: C:/slave/test/build/xpcshell/tests/mailnews/compose/test/unit/head_compose.js :: do_check_transaction :: line 65 JS frame :: C:/slave/test/build/xpcshell/tests/mailnews/compose/test/unit/test_bug155172.js :: run_test :: line 94 JS frame :: C:\slave\test\build\xpcshell\head.js :: _execute_test :: line 348 JS frame :: -e :: <TOP_LEVEL> :: line 1 native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0 TEST-INFO | (xpcshell/head.js) | exiting test TEST-UNEXPECTED-FAIL | C:/slave/test/build/xpcshell/tests/mailnews/compose/test/unit/test_bug155172.js | 2147500036 - See following stack: JS frame :: C:/slave/test/build/xpcshell/tests/mailnews/compose/test/unit/test_bug155172.js :: run_test :: line 97 JS frame :: C:\slave\test\build\xpcshell\head.js :: _execute_test :: line 348 JS frame :: -e :: <TOP_LEVEL> :: line 1 native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0 TEST-INFO | (xpcshell/head.js) | exiting test Connection Lost 2152398850 WARNING: NS_ENSURE_TRUE(compMgr) failed: file e:/builds/moz2_slave/tb-c-cen-w32-d-000000000000000/build/mozilla/xpcom/glue/nsComponentManagerUtils.cpp, line 58 WARNING: OOPDeinit() without successful OOPInit(): file e:/builds/moz2_slave/tb-c-cen-w32-d-000000000000000/build/mozilla/toolkit/crashreporter/nsExceptionHandler.cpp, line 2305 nsStringStats => mAllocCount: 3947 => mReallocCount: 439 => mFreeCount: 3947 => mShareCount: 9219 => mAdoptCount: 430 => mAdoptFreeCount: 430 <<<<<<<
This is probably an issue following bug 717490... Our tests rely on the old text-based password manager storage, and either a) need to be updated to the sqlite form, or b) removed, as they aren't relevant now we don't have the old storage form to upgrade form and won't hit the issues they were testing. Probably a good starting point is that these files need adjusting: http://mxr.mozilla.org/comm-central/find?text=&string=mailnews.*signons I suspect the easiest way to do this is to run each test in check-one mode, after the test has run look in the profile dir (listed at the start of the test run), and find the sqlite file. Then replace the original text based file with that sqlite one and update the tests accordingly.
(In reply to Mark Banner (:standard8) from comment #3) So I've got c-c closed over this for the time-being. Your call if you want to deal with this on an open tree or not.
Blocks: 717490
Keywords: regression
Standard8, do you mean running the test with a TB version a bit old so that it still has the format conversion support in?
(In reply to :aceman from comment #7) > Standard8, do you mean running the test with a TB version a bit old so that > it still has the format conversion support in? Yep, precisely.
Did how to run xpcshell-tests individually change recently? What i used to use doesn't seem to work.
Ok, so the new working syntax is like make -C mozilla xpcshell-tests TEST_PATH=mailnews/compose/test/test_bug155172.js
Attached patch possible fix (obsolete) — — Splinter Review
This might work, but i don't have time to try it out before late tomorrow or tuesday. Did something like rm -rf /tmp/xpcshell/xpcshellprofile make -C mozilla xpcshell-tests TEST_PATH=mailnews/compose/test/test_bug155172.js cp /tmp/xpcshell/xpcshellprofile/signons.sqlite /opt/comm-central/src/mailnews/compose/test/unit/data/signons-smtp.sqlite rm -rf /tmp/xpcshell/xpcshellprofile make -C mozilla xpcshell-tests TEST_PATH=mailnews/compose/test/test_smtpPasswordFailure1.js cp /tmp/xpcshell/xpcshellprofile/signons.sqlite /opt/comm-central/src/mailnews/compose/test/unit/data/signons-mailnews1.8.sqlite rm -rf /tmp/xpcshell/xpcshellprofile make -C mozilla xpcshell-tests TEST_PATH=mailnews/local/test/unit/test_pop3Password2.js cp /tmp/xpcshell/xpcshellprofile/signons.sqlite /opt/comm-central/src/mailnews/compose/test/unit/data/signons-mailnews1.8-alt.sqlite
I was doing almost the same, but somehow it went wrong, the resulting signons.sqlite file did not contain the necessary passwords. Maybe I was missing some of the cleanup before the run. This patch does not work for me either. Also, it seems you placed the *-mailnews.1.8 files into the wrong dir.
Yeah this is extremely untested (not even locally), but i wanted to get the data recorded in case someone have the time to finish it. Also all the old signon-foo.txt files should be removed.
Attached patch wip2 — — Splinter Review
Here should be the correct paths and such. But it doesn't work. Indeed the generated sqlite database holds no data. $ sqlite3 signons-smtp.sqlite sqlite> .tables moz_deleted_logins moz_disabledHosts moz_logins sqlite> select * from moz_disabledHosts; sqlite> select * from moz_deleted_logins; sqlite> select * from moz_logins; --- rm -rf /tmp/xpcshell/xpcshellprofile make -C mozilla xpcshell-tests TEST_PATH=mailnews/compose/test/test_bug155172.js cp /tmp/xpcshell/xpcshellprofile/signons.sqlite /opt/comm-central/src/mailnews/compose/test/unit/data/signons-smtp.sqlite rm -rf /tmp/xpcshell/xpcshellprofile make -C mozilla xpcshell-tests TEST_PATH=mailnews/compose/test/unit/test_smtpPasswordFailure1.js cp /tmp/xpcshell/xpcshellprofile/signons.sqlite /opt/comm-central/src/mailnews/test/data/signons-mailnews1.8.sqlite rm -rf /tmp/xpcshell/xpcshellprofile make -C mozilla xpcshell-tests TEST_PATH=mailnews/local/test/unit/test_pop3Password2.js cp /tmp/xpcshell/xpcshellprofile/signons.sqlite /opt/comm-central/src/mailnews/test/data/signons-mailnews1.8-alt.sqlite rm -rf /tmp/xpcshell/xpcshellprofile make -C mozilla xpcshell-tests TEST_PATH=mailnews/imap/test/unit/test_imapPasswordFailure.js cp /tmp/xpcshell/xpcshellprofile/signons.sqlite /opt/comm-central/src/mailnews/test/data/signons-mailnews1.8-imap.sqlite # NOTE: had to enable in xpcshell.ini + the test fails rm -rf /tmp/xpcshell/xpcshellprofile make -C mozilla xpcshell-tests TEST_PATH=mailnews/compose/test/unit/test_smtpPassword2.js cp /tmp/xpcshell/xpcshellprofile/signons.sqlite /opt/comm-central/src/mailnews/test/data/signons-mailnews1.8-multiple.sqlite # NOTE: had to enable in xpcshell.ini + the test fails
Attachment #816379 - Attachment is obsolete: true
I also tried to put the signons.txt into a real TB profile. The resulting signons.sqlite did contain an entry for the test server. But the file was still not working. Maybe it was encoded with some key (key3.db, etc) from the profile, that did not match the key files that are used when tests are executing.
Maybe we need to preserve some of the key files so that we can setup the test profile everytime with them so that the keys and the encryption in signons.sqlite matches?
Yes, I think so, like this file does: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/test/unit/head_common.js#233 And I am suspecting there is another regression other than bug 717490, because test_smtpPassword.js is still crashing without the fix for bug 717490.
Well the key3.db should already be in the thinderbox profile. Tried copying key3.db to a normal profile too, but running the test, the password is still not as expected. --- rm -f ~/.thunderbird/333spc0f.testing9/signons.sqlite cp /opt/comm-central/src/mailnews/test/data/db-tinderbox-invalid/*.db ~/.thunderbird/333spc0f.testing9/ cp /opt/comm-central/src/mailnews/compose/test/unit/data/signons-smtp.txt ~/.thunderbird/333spc0f.testing9/signons.txt ## Run tb, have it as for password but give none. Close. cp ~/.thunderbird/333spc0f.testing9/signons.sqlite /opt/comm-central/src/mailnews/compose/test/unit/data/signons-smtp.sqlite ---
key3.db and all of sqlite files are generated by a script. I will attach the script soon.
I am sorry this is very ugly. This script can be run in mailnews/base/test/unit/.
The previous patch did not include an important file named passwordStorage.js.
Attachment #817594 - Attachment is obsolete: true
Attachment #817650 - Flags: review?(mbanner)
try server results: https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=d87693bf28b2 Tests in mailnews seemed to be passed, but some tests in mozilla-central still failed.
Thanks, looks nice. I would much rather like if the password is generated in the test file like in the attachment "The script for generating files", not hardcoded in the signons.sqlite file where it can be changed only very difficultly.
I am sorry I can not understand what you want. Please feel free to modify the patch.
Has anybody investigated the failures of tests in mozilla-central?
(In reply to Hiroyuki Ikezoe (:hiro) from comment #26) > Has anybody investigated the failures of tests in mozilla-central? Mark did it; https://hg.mozilla.org/comm-central/rev/10a084ae60a8
I meant if we could generate the singons file on the fly from inside the test (the code you have demonstrated) instead of pre-generating the signons file and storing it in the test data hierarchy (as done today). But that is up to standard8 to decide. Depends on how often we would want to change the passwords or at least know what they are. With this encrypted signons.sqlite file, I would just feel uneasy editing such a test and debugging why the authentication failed.
(In reply to :aceman from comment #28) > I meant if we could generate the singons file on the fly from inside the > test (the code you have demonstrated) instead of pre-generating the signons > file and storing it in the test data hierarchy (as done today). Part of the intent here was to test the upgrade from the old format databases, but we no longer have that code. Hence I think adding the logins on the fly is probably reasonable (now you suggest it), I can't think of a reason to not do this on the fly. Sorry for the miss-direction here.
Thanks for the explanations. Now I could understand it and it sounds reasonable to me. Actually I am not sure the key db can work on the fly because I am not familiar with it, so I would like to modify such fix on another bug.
I don't think need to generate sqlite/keydb on the fly. You can just do the equivalent of add_login in your script at the start of the tests.
Yes, keep the key3.db as a file (as is), but call add_login from the test files to create signons files on the fly.
(In reply to :aceman from comment #32) > Yes, keep the key3.db as a file (as is), but call add_login from the test > files to create signons files on the fly. I guess it won't work.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #33) > (In reply to :aceman from comment #32) > > Yes, keep the key3.db as a file (as is), but call add_login from the test > > files to create signons files on the fly. > > I guess it won't work. If you're doing add_login, you won't need to manage the key3.db file - just let the xpcshell tests manage that.
Comment on attachment 817650 [details] [diff] [review] Update Magnus's patch with correct key3.db So having just thought about this a bit, I think this actually good enough that we can land it to fix the bustage and re-open the tree. We can then look at replacing what's here with manually adding logins in slow time.
Attachment #817650 - Flags: review?(mbanner) → review+
Sure, I'll file the new bug.
Assignee: nobody → hiikezoe
Status: NEW → ASSIGNED
I see this landed - https://hg.mozilla.org/comm-central/rev/8ae9cf95cb40 Good job, Hiro!! The tree is almost completely green.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 27.0
(In reply to Magnus Melin from comment #37) > I see this landed - https://hg.mozilla.org/comm-central/rev/8ae9cf95cb40 > > Good job, Hiro!! The tree is almost completely green. Yay! That is what I was waiting for! aceman, please paste the new bug here or CCing me to the new bug. Thanks.
Blocks: 927859
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: