linux xpcshell tinderbox builds are showing a failure in test_nsIMsgFolderListenerLocal.js - I can't reproduce the failure on mac or windows builds locally. This seems to have started after the landing of pluggable stores, bug 402392.
Seems a fairly frequent, but not permanent random orange.
Summary: xpcshell test failure in base/test/test_nsIMsgFolderListenerLocal.js → Random orange | TEST-UNEXPECTED-FAIL | test_nsIMsgFolderListenerLocal.js | exception thrown from do_timeout callback nsIMsgFolder.deleteMessages
Actually, could this be a 32 versus 64 bit issue? It has been hidden a bit, but the test is failing on Linux 32, and OS X 10.5 (aka 32 bit). It doesn't fail on the 64 bit versions of those. The only confusing bit here is the 32 bit windows builds aren't failing.
Summary: Random orange | TEST-UNEXPECTED-FAIL | test_nsIMsgFolderListenerLocal.js | exception thrown from do_timeout callback nsIMsgFolder.deleteMessages → Permanent orange | TEST-UNEXPECTED-FAIL | test_nsIMsgFolderListenerLocal.js | exception thrown from do_timeout callback nsIMsgFolder.deleteMessages (32 bit Linux & Mac)
I suspect it's more of a timing issue than a 32 bit issue, but I could be wrong. Do we support generating and running an os/x 32 bit build on OS X 10.8 or 9 so I could try it here?
I added this to my mozconfig on 10.6, but couldn't reproduce locally: ac_add_app_options i386 --target=i386-apple-darwin10 ac_add_app_options i386 --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk CC="gcc -arch i386" CXX="g++ -arch i386" RANLIB=ranlib AR=ar AS=$CC LD=ld STRIP="strip -x -S" CROSS_COMPILE=1 export CC CXX RANLIB AR AS LD STRIP
I spent an afternoon setting up an old mac to do builds, and did a 32 bit build, but couldn't reproduce the test failure with a debug build. I'll try doing a release build next.
ah, success, in that it fails on a release build on my old mac - I'll have to use dumps and printfs to figure out why...
Created attachment 586574 [details] [diff] [review] proposed fix I've requested a try server build with this fix. The issue had to do with a cached db having the wrong folder pointer, which made subsequent db opens get the wrong folder, and we then tried to open a db for a folder that no longer existed. I'm not sure why it works for most platforms, but this fixes the issue on 32 bit mac, and I've requested a try server build to make sure everything still works on the other platforms.
Attachment #586574 - Flags: review?(mbanner)
results will show up here: http://build.mozillamessaging.com/tinderboxpushlog?tree=ThunderbirdTry&rev=929323ca3c74
Status: NEW → ASSIGNED
Attachment #586574 - Flags: review?(mbanner) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 12.0
You need to log in before you can comment on or make changes to this bug.