Crash on Fedex.com

VERIFIED FIXED in mozilla0.9.2

Status

()

Core
Networking: Cache
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Pierre Saslawsky, Assigned: Simon Fraser)

Tracking

({crash})

Trunk
mozilla0.9.2
PowerPC
Mac System 8.5
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
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

Comment 1

17 years ago
Yup. I can reproduce this in my debug build as well.  Setting target to 0.9.1.  
Thanks Pierre.
Target Milestone: --- → mozilla0.9.1

Comment 2

17 years ago
gordon is investigating this.
Keywords: crash, nsbeta1+

Comment 3

17 years ago
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.

Comment 4

17 years ago
Patrick and I verified this is fixed in MSL 6.
(Assignee)

Comment 5

17 years ago
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.
(Assignee)

Comment 6

17 years ago
See bug 41360.

Comment 7

17 years ago
Confirming. both verif. build macs have the patch in.

Comment 8

17 years ago
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.

Comment 9

17 years ago
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
(Assignee)

Comment 10

17 years ago
I just updated the build instructions.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 11

16 years ago
verified:

mac os8.6 2001080108
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.