Mac OS X 10.5 Macbook Pro I haven't tried to reproduce this yet. 1. Install Shredder.app from prior to 2011-07-08. 2. Update to 2011-07-08 and restart. 3. Update to 2011-07-09 and fail to restart. 4. Attempt to start Shredder and fail. From the command line $ open Shredder.broken.app/ LSOpenFromURLSpec() failed with error -10810 for the file /Applications/Shredder.broken.app. I think this is due to jemalloc $ diff -ur Shredder.broken.app Shredder.app/ Only in Shredder.broken.app/Contents/MacOS: active-update.xml Only in Shredder.app/Contents/MacOS: libjemalloc.dylib Only in Shredder.broken.app/Contents/MacOS: updates Only in Shredder.broken.app/Contents/MacOS: updates.xml Downloading a fresh Shredder build and installing it works fine. I think this would be a possible issue when upgrading to a jemalloc enabled build. I did not see this problem with today's Firefox Nightly build.

Please attach the last-update.log and backup-update.log from the broken version's Contents/MacOS/updates directory.

Very strange. The update log shows that Contents/MacOS/libjemalloc.dylib was added successfully. Those files were from Shredder.broken.app?

Yes, the Shredder.app directory doesn't contain any log files. I added updates/0/update.log since that includes a removal of libjemalloc.dylib.

Please attach the updates.xml from the broken copy of shredder. Also, do you know the Thunderbird bug where they turned on jemalloc?

I highly suspect this is due to turning on jemalloc and not adding the correct entries in package.manifest (possibly in removed-files as well).

I don't see any Mac Thunderbird specific bugs with jemalloc.

In last-update.log (attachment #545021 [details]) there are the following lines UPDATE TYPE partial ... PREPARE ADD Contents/MacOS/libjemalloc.dylib This means that the libjemalloc.dylib file was added in the update previous to the one shown in update.log (attachment #545022 [details]). So, the libjemalloc.dylib file was added in the previous update and removed by the next update. This line is the most likely cause http://mxr.mozilla.org/comm-central/source/mail/installer/removed-files.in#287

jemalloc has been disabled for now: http://hg.mozilla.org/comm-central/rev/5a568e874b0f I'll fix the packaging issue later.

I'd like to get jemalloc relanded soon. Does this block it? What do I need to do to fix it? (I don't know what Shredder is, or the difference between comm-central and mozilla-central is, or what the UPDATE TYPE, PREPARE ADD, etc, refer to).

Shredder is the trunk version of Thunderbird while comm-central is what I would call the integration repo for trunk Thunderbird and mozilla-central. If this isn't fixed, I would expect that around the time Firefox 8 is released when Thunderbird users update to Thunderbird 8, they will break Thunderbird and require a complete download and reinstall. I would consider that a blocker.

(In reply to comment #12) > I'd like to get jemalloc relanded soon. Does this block it? What do I need > to do to fix it? > > (I don't know what Shredder is, or the difference between comm-central and > mozilla-central is, or what the UPDATE TYPE, PREPARE ADD, etc, refer to). This will likely need the file referenced in comment #10 reworked and the best people to rework that are people that work on Thunderbird.

OK, I'm happy to leave it with you guys :) The plan is to turn jemalloc back on pretty soon, so let me know if you need any help from me to get this bug fixed.

jemalloc is fixed and tryserver is green. I'm assuming, as far as this bug goes, that it's OK for me to land jemalloc and you guys will pick up the installer pieces? Please correct me if I'm wrong.

If you can, please hold off until someone from Thunderbird comments. I've cc'd David Bienvenu and Mark Banner since one of them will be the most likely person to fix this.

Sorry for the delay, I think this is the right patch - don't remove jemalloc library if we're on Mac and we've been built with jemalloc enabled. Rob, can you take a quick look please?

Sure, I'm going to hold off landing until friday I think. Let me know if you need more time, or if you want to do this some other way.

Comment on attachment 545806 [details] [diff] [review] Proposed fix This looks fine but it isn't clear to me why @DLL_PREFIX@jemalloc@DLL_SUFFIX@ is needed for the non mac case. Since that was added in bug 496683 by philor I'd feel more comfortable if he also took a look.

Comment on attachment 545806 [details] [diff] [review] Proposed fix Contextually, in some 3.0 beta, we must have accidentally shipped some jemalloc, probably libjemalloc.so, then in the intervening time it went elsewhere (mozcrt19.dll/mozcpp19.dll in the case of WIN32_OLD_STYLE_JEMALLOC which we apparently do on Windows, dunno where on Linux). make package-compare on Windows and Linux says we aren't currently creating a @DLL_PREFIX@jemalloc@DLL_SUFFIX@, the fact that I added it to removed-files.in while I was diffing releases and trunk-at-the-time says we once did, so continuing to remove it seems to be the right thing to do.

Checked in: http://hg.mozilla.org/comm-central/rev/20e0368c597a Apologies to those waiting on this for it having taken so long.