Tested with a fresh pull from tonight on the Mac. - Make sure you have no history at all (ie. new profile) - Go to http://www.fedex.com - It starts to display the "Select your country" page ==> Just after showing the background image, it crashes in nsDiskCacheDevice Here is the log: PowerPC unmapped memory exception at 2DE512C0 find_temp_info+0000C Calling chain using A6/R1 links Caller 2FC40768 2FC2BFE8 main+00130 2FC2B1CC main1(int, char**, nsISupports*)+009F8 2F28BE64 nsAppShellService::Run()+00018 2EEBA00C nsAppShell::Run()+00048 2EEBA9F4 nsMacMessagePump::DoMessagePump()+0003C 2EEBB028 nsMacMessagePump::DispatchEvent(int, EventRecord*)+00170 2EECECBC Repeater::DoRepeaters(const EventRecord&)+00030 2EEA6CCC nsMacNSPREventQueueHandler::RepeatAction(const EventRecord&)+0000C 2EEA6DE4 nsMacNSPREventQueueHandler::ProcessPLEventQueue()+000B0 2DD68B08 nsEventQueueImpl::ProcessPendingEvents()+00038 2DDBBB54 PL_ProcessPendingEvents+00078 2DDBBCD8 PL_HandleEvent+00020 2C9C55F8 nsARequestObserverEvent::HandlePLEvent(PLEvent*)+00020 2C9C6240 nsOnStopRequestEvent::HandleEvent()+000B4 2C9A1460 nsHTTPServerListener::OnStopRequest(nsIRequest*, nsISupports*, unsigned int)+00164 2C996D98 nsHTTPChannel::ResponseCompleted(nsIStreamListener*, unsigned int)+ 00110 2DD57DCC nsCOMPtr_base::assign_with_AddRef(nsISupports*)+00048 2E7CD534 nsCacheEntryDescriptor::Release()+00040 2E7CD9CC nsCacheEntryDescriptor::~nsCacheEntryDescriptor()+00044 2E7CE93C nsCacheEntryDescriptor::Close()+00038 2E7D47C8 nsCacheService::CloseDescriptor(nsCacheEntryDescriptor*)+0008C 2E7D4A24 nsCacheService::DeactivateEntry(nsCacheEntry*)+000B0 2E7D866C nsDiskCacheDevice::DeactivateEntry(nsCacheEntry*)+00060 2E7DA60C nsDiskCacheDevice::updateDiskCacheEntry(nsDiskCacheEntry*)+00248 2E7E12DC nsANSIOutputStream::Close()+00020 2DE50B9C fclose+0004C Closing log
Yup. I can reproduce this in my debug build as well. Setting target to 0.9.1. Thanks Pierre.
Target Milestone: --- → mozilla0.9.1
gordon is investigating this.
Keywords: crash, nsbeta1+
This is a bug in MSL:MSL_C:MSL_MacOS:Src:file_io.mac.c __open_temp_file() :-( The jpeg library uses tmpfile() for decoding certain (all?) images. MSL keeps a reference number and FSSpec for each open temp file in what appears intended to be a double linked list off of temp_info_anchor; __close_file() contains these lines: if ((p = info->next_struct) != NULL) /* mm 981009 */ p->prev_struct = info->prev_struct; /* mm 981009 */ (info->prev_struct)->next_struct = info->next_struct; /* mm 981009 */ ...and then they call free(info), which would be great, except that there is no corresponding code: if (temp_info_anchor) temp_info_anchor->prev_struct = info; ...in __open_temp_file(), so the prev_struct is always NULL. NULL is the correct value for the head of the list, so as long there is only a single temp file open at a time, there is no problem. However, if there are multiple temp files open, and a temp file other than the head gets closed, a list element gets freed without being removed from the list. Since every fclose() checks this list to see if it's closing a temp file, the first flose() after closing a non-head temp file can result in a crash. In the case Pierre found, it happened to be the disk cache closing a metadata file. Possible solutions: 1) change the jpeg library to use something other than tmpfile(). 2) check newer MSL to see if the bug has been fixed, and use it. 3) tell everyone not to browse www.fedex.com 4) another bright idea from someone cc'd on this bug.
Patrick and I verified this is fixed in MSL 6.
We already fixed this once. I believe that the verification machine has the fix in its MSL, and that I fixed the MSL on the build env. server.
See bug 41360.
Confirming. both verif. build macs have the patch in.
I did a quick check of mozilla.org, but I didn't find any reference to updating file_io.mac.c in the build instructions. Simon, would you like this bug as a reminder to do that? We could probably downgrade the target milestone, since this doesn't appear to be a problem for our build/release machines.
We can close this as soon as the mozilla build instructions for Mac have been updated to explain this problem. Changing target milestone because it won't affect the 0.9.1 builds.
Assignee: gordon → sfraser
Target Milestone: mozilla0.9.1 → mozilla0.9.2
I just updated the build instructions.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verified: mac os8.6 2001080108
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.