Closed Bug 444506 Opened 17 years ago Closed 17 years ago

NSArray enumeration exception on quit

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: phiw2, Assigned: ishermandom+bugs)

References

Details

This has happened twice now. Quit Camino. Everything seems peachy. Launch Camino, and be greeted with the 'Restore previous pages?' dialog, indicating a crash of sort. No crash report was generated. The only thing I have to offer is this entry in the log (logged when I quit Camino.): 7/10/08 12:20:05 AM Camino[25371] *** Collection <NSCFArray: 0x105110f0> was mutated while being enumerated. Both occurrences of this crash happened on 10.5.4. Flash 10b2 player UNCO given the vagueness of the report.
I wonder if that's an error in the session-saving code, since failure there could potentially cause |previousSessionTerminatedNormally| to be false without there being a crash. Stuart, any ideas on that?
I think I've nailed this down. This currently does not (yet) happen with an official nightly build (I first thought it did, but I must have mixed up my builds). But: 1. This 'crash' happens with a build that includes Steven's patch for bug 357670 (IME doesn't work on the text field of flash with Cocoa build), which is supposed to land for Gecko 1.9.0.x – Camino 2.0a.x. 2. For this 'crash' to happen the following must be true: set 'Downloads' to be deleted automatically on Quit. If no files are listed in the download window/manager, 'Quit' works correctly.
> 1. This 'crash' happens with a build that includes Steven's patch > for bug 357670 (IME doesn't work on the text field of flash with > Cocoa build), which is supposed to land for Gecko 1.9.0.x – Camino > 2.0a.x. My patch for bug 357670 hasn't yet landed on the 1.9.0 branch -- only on mozilla-central. So you're using a mozilla-central build of Camino? If so, how do you make such a build?
Philippe, please respond as soon as possible. The patch for bug 357670 needs to land soon, and if it's going to cause trouble I need to find the trouble (and fix it) quickly.
Presumably it's a normal Camino (cvs) trunk build with your patch applied. I seriously doubt it's possible to make a Camino build with what's in mozilla-central. Someone who can reproduce this will need to catch it in a debugger with a breakpoint on -[NSException raise] to see what the array is.
(In reply to comment #3) Steven, as Stuart says, it is a normal CVS build with your patch applied.
(In reply to comment #6) Thanks, Philippe. Tomorrow I'll do a build like that and try to get it to crash.
This doesn't sound like it's actually a crash. Much more likely given the description is an exception during the handling of applicationWillTerminate:
This could be WFM after all. Building with Xcode 3.1/gcc-4.2.1/10.5SDK, I can't reproduce it anymore. Building with Xcode 3.1/gcc-4.0.1/10.4uSDK works equally well. I don't have Xcode 3.0 installed anywhere to test if 'something' in there would cause this to happen.
OK, I've now done a build of 1.9.0-branch Camino using code pulled on Monday (2008-07-14) plus my rev7 patch for bug 357670. It's an opt build with debug symbols, done using XCode 3.0 on OS X 10.5.4 with the 10.4u SDK. I don't see Philippe's crash. But I also find that, even though I've set Camino to download to the Downloads folder and to remove successful downloads when Camino quits, the downloads don't in fact get deleted when Camino quits. This is true for my build, for a recent 1.9.0-branch nightly, and for Camino 1.6.1. What's going on? (The file I downloaded, for testing purposes, is ftp://ftp.mozilla.org/pub/mozilla.org/ls-lR.gz.)
(Following up comment #10) Tried a fresh profile. Makes no difference.
philippe, can you try comment 5 and see what you get? Steven, I assume you tried comment 5 and weren't able to get anything?
> Steven, I assume you tried comment 5 and weren't able to get anything? Correct. See comment #10.
(In reply to comment #12) > philippe, can you try comment 5 and see what you get? No, I haven't had time, yet (and unlikely till mid-september). On the other hand, in a quick set of tests, I couldn't reproduce this anymore. Not with the official builds, nor with a home made build (10.5.2 SDK). But back when I noticed this issue, my son was often playing Shockwave games on this machine. Possibly the problem is related to those games or to the Shockwave plugin. I'll need to wait for him to get back from a week of sports camp to be sure.
(In reply to comment #10) > I don't see Philippe's crash. But I also find that, even though I've > set Camino to download to the Downloads folder and to remove > successful downloads when Camino quits, the downloads don't in fact > get deleted when Camino quits. Did you check the console for exception messages? This is not a crash, it's some portion of Camino's shutdown code not executing because of an exception, so what you are seeing may well be the same thing. Updating the summary to reduce confusion.
Summary: mysterious 'crash' on quit → NSArray enumeration exception on quit
I think I've found what triggers this. Required: Shockwave Flash installed So far I've only repo'd this with builds made using the 10.5 SDK. The GCC version (4.0.1 or 4.2.1) doesn't seem to matter. Now I need to see this with a debug build. 1. set download manager to clear on quit 2a. download something, and in the Finder, move it to somewhere else (but don't remove it from the download manager) or 2b. download something and cancel it halfway. 3. head over to play a jigsaw puzzle: http://www.shockwave.com/contentPlay/shockwave.jsp?id=jigsawpuzzles&dwin=1&memberStatus=NotSignedIn&year=08&month=9&day=28 Move a few pieces around, you do not need to complete the game 4. do some more surfing. 5. Quit. Console logs all the below [1]. Download manager is not cleared and won't be cleared on successive quits as long as you don't remove the moved file manually (or all files ?). [1] - All the ***Font stuff is also logged by Fx/Minefield/WebKit/Safari 9/28/08 9:22:31 PM Camino[74462] *** Collection <NSCFArray: 0x11343870> was mutated while being enumerated. 9/28/08 9:22:31 PM [0x0-0x7ed7ed].org.mozilla.camino[74462] InstallTrueTypeFont: 0x100a70b0 9/28/08 9:22:31 PM [0x0-0x7ed7ed].org.mozilla.camino[74462] Temp file TempFonts-9894983860 9/28/08 9:22:31 PM [0x0-0x7ed7ed].org.mozilla.camino[74462] InstallTrueTypeFont: dest1059 9/28/08 9:22:31 PM [0x0-0x7ed7ed].org.mozilla.camino[74462] ActivateTemporaryFontFile: 0x100a70b0 9/28/08 9:22:31 PM [0x0-0x7ed7ed].org.mozilla.camino[74462] InstallTrueTypeFont: 0x10556ba0 9/28/08 9:22:31 PM [0x0-0x7ed7ed].org.mozilla.camino[74462] Temp file TempFonts-9894983861 9/28/08 9:22:31 PM [0x0-0x7ed7ed].org.mozilla.camino[74462] InstallTrueTypeFont: dest1061 9/28/08 9:22:31 PM [0x0-0x7ed7ed].org.mozilla.camino[74462] ActivateTemporaryFontFile: 0x10556ba0 9/28/08 9:22:31 PM [0x0-0x7ed7ed].org.mozilla.camino[74462] ActivateTemporaryFontFile: 0x100a70b0 9/28/08 9:22:31 PM [0x0-0x7ed7ed].org.mozilla.camino[74462] ActivateTemporaryFontFile: 0x10556ba0
I strongly suspect the problem is this code: http://mxr.mozilla.org/mozilla/source/camino/src/download/ProgressDlgController.mm#800 We're iterating over an NSMutableArray at the same time we're removing stuff from it. That's all kinds of bad, right?
Depends on: 465242
Ilya just pointed out that bug 465242 will fix the enumerating-while-modifying thing. I'm gonna confirm this in the meantime.
Status: UNCONFIRMED → NEW
Ever confirmed: true
philippe, can you confirm this exception is gone after bug 465242?
(In reply to comment #19) > philippe, can you confirm this exception is gone after bug 465242? I started testing 5 minutes after you checked in the patch :-) Anyway: after various downloads/quits/moving downloaded files/... etc, a trip around that shockwave mentioned in comment 16 (wonder why that one didn't cause problems in a debug build), I haven't been able to trigger that exception anymore. --> fixed by bug 465242.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Assignee: nobody → ishermandom+bugs
You need to log in before you can comment on or make changes to this bug.