Last Comment Bug 713768 - Permanent orange | TEST-UNEXPECTED-FAIL | test_nsIMsgFolderListenerLocal.js | exception thrown from do_timeout callback nsIMsgFolder.deleteMessages (32 bit Linux & Mac)
: Permanent orange | TEST-UNEXPECTED-FAIL | test_nsIMsgFolderListenerLocal.js |...
: intermittent-failure
Product: Thunderbird
Classification: Client Software
Component: Testing Infrastructure (show other bugs)
: unspecified
: x86_64 Windows 7
-- normal (vote)
: Thunderbird 12.0
Assigned To: David :Bienvenu
Depends on: 402392
  Show dependency treegraph
Reported: 2011-12-27 15:32 PST by David :Bienvenu
Modified: 2012-11-25 19:31 PST (History)
3 users (show)
standard8: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

proposed fix (1.89 KB, patch)
2012-01-06 14:39 PST, David :Bienvenu
standard8: review+
Details | Diff | Splinter Review

Description User image David :Bienvenu 2011-12-27 15:32:48 PST
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.
Comment 1 User image Mark Banner (:standard8) 2011-12-29 06:51:26 PST
Seems a fairly frequent, but not permanent random orange.
Comment 2 User image Mark Banner (:standard8) 2011-12-29 06:58:50 PST
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.
Comment 3 User image David :Bienvenu 2011-12-29 08:30:50 PST
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?
Comment 4 User image Mark Banner (:standard8) 2011-12-29 10:42:06 PST
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"

STRIP="strip -x -S"


Comment 5 User image David :Bienvenu 2012-01-06 08:12:42 PST
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.
Comment 6 User image David :Bienvenu 2012-01-06 11:10:45 PST
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...
Comment 7 User image David :Bienvenu 2012-01-06 14:39:26 PST
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.
Comment 8 User image David :Bienvenu 2012-01-06 14:45:47 PST
results will show up here:
Comment 9 User image Mark Banner (:standard8) 2012-01-09 00:52:09 PST
Checked in:

Note You need to log in before you can comment on or make changes to this bug.