This test started to fail on SeaMonkey MacOSX as soon as it landed: http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1221015625.1221019798.9504.gz MacOSX 10.4 comm-central dep unit test on 2008/09/09 20:00:25 NEXT ERROR TEST-UNEXPECTED-FAIL | ../../_tests/xpcshell-simple/test_necko/unit/test_redirect_caching.js | test failed, see log ../../_tests/xpcshell-simple/test_necko/unit/test_redirect_caching.js.log: >>>>>>> *** test pending *** test pending *** test finished *** running event loop *** exiting NEXT ERROR *** TEST-UNEXPECTED-FAIL | ../../_tests/xpcshell-simple/test_necko/unit/head_channels.js | Failed to load URL: 804b0046 JS frame :: /builds/slave/comm-central-macosx/build/mozilla/tools/test-harness/xpcshell-simple/head.js :: do_throw :: line 101 JS frame :: ../../_tests/xpcshell-simple/test_necko/unit/head_channels.js :: anonymous :: line 96 *** FAIL *** <<<<<<<

Sounds like that test setup has a broken (memory) cache. Something to look into on the test machine, for sure.

I can look at the disk cache, but memory cache is created new with every launch of the app, i.e. every test cycle, so it can't stay broken across cycles, right? Note that the huge difference to the Firefox unit test machine is that SeaMonkey has OS X 10.4 while FF only tests on 10.5.

Those tests probably don't have a disk cache set up at all, since that requires a preference pointing to a disk cache directory... If you have access to the machine and can run the tests manually, you could take a look at the cache service setup in the debugger and see what's going on, perhaps. I did have symptomps similar to this on my 10.5 machine, by the way, but a rebuild of the whole tree (not just necko) seemed to fix it...

OK, the box does dep builds all time, so I'll try clobbering the objdir to see if that fixes it.

Clobbering the objdir and rebuilding the whole tree didn't fix this. I have access to the machine but I'm very inexperienced on debugger stuff.

The clobber didn't help :-(

Considering bug 454878, we should disable this test on MacOSX SeaMonkey in the meantime.

KaiRo, can you test if this patch fixes the bug?

Comment on attachment 338204 [details] [diff] [review] patch I'd prefer a size guaranteed to make sense on all our platforms, including handhelds. Perhaps 32MB (which gives us our minimal cache size) instead of 512?

http://hg.mozilla.org/mozilla-central/rev/91493f716bdf bitrotted that patch, but I'm testing it for a cycle on the SeaMonkey unit test machine now, modified to use 32 MB as bz suggested.

OK, test was successful, this patch works on getting this test to pass, I'll revert the machine to pristine code for the next cycle.

OK. Using a small size like this does mean that we penalize a lot of mac users, until that NSPR bug gets fixed...

Should I add a unit test specifically to make sure that we have a nonzero memory cache size? It's not strictly needed since clearly test_redirect_caching.js will find that out, too :)

Comment on attachment 338359 [details] [diff] [review] patch We just need to fix the NSPR bug for 1.9.1. If we don't for some reason, we can revisit the size here.

Oh, and probably no need for a separate test.

V.Fixed between http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1221432031.1221436911.4838.gz MacOSX 10.4 comm-central dep unit test on 2008/09/14 15:40:31 and http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1221436631.1221441588.15500.gz MacOSX 10.4 comm-central dep unit test on 2008/09/14 16:57:11

Comment on attachment 338359 [details] [diff] [review] patch We should take this on branch. It fixes the memory cache being disabled on Mac in a lot of cases, which hurts users in addition to randomly oranging tests we want to check in on branch..

Comment on attachment 338359 [details] [diff] [review] patch Actually, the NSPR fix landed on branch, so scratch this.

It looks like we backed out the nspr version bump on branch, so I'm re-requesting approval to land this on the branch, with the rationale from comment #18

Comment on attachment 338359 [details] [diff] [review] patch And we re-checked in the NSPR version bump, so this patch should no longer be needed, right? Please renominate if that's not the case.