So I submitted a patch to bug 436880, with some innocuous-looking tests. There were a couple of fixes needed to make the test work (and in general), but nothing major. All the tests passed on my Windows build like a charm. All was well, until Standard8 tried out the test on his Mac and found that it failed with:
It isn’t. Again, this happens on OS X but not on Windows. Bah. Seems like I’ll go through this all over again. :(
###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->()Yes, a null pointer. After some initial shots in the dark (Time gaps before the next test? Line endings?), it was time for some debugging. It later turned out that when an instruction was given for multiple messages to be moved or copied, only the first one was actually being copied. As any further messages were not copied at all, we got a null pointer when we tried to retrieve them. It was utterly surprising for me to see
- such a problem being platform dependent.
- such a basic operation having trouble – except for the fact that this only happened in tests. (Don’t worry Mac Thunderbird users – your messages are safe ;) )
- the problem happening only when multiple messages were moved or copied in one go.
foo/bar/baz/../../quux. Ideally, this path should have simply been
foo/quux. Most of the time, both are equivalent. When they are not, as in this case on OS X, bad things happen.) The fix was simple, just one line long. All’s (finally) well again with the world.