Closed Bug 326195 Opened 19 years ago Closed 19 years ago

[10.4] 100% cpu then crash [@ libhotspot.dylib.1.0.0] when navigating page (Java, Apple bug?)

Categories

(Camino Graveyard :: Plug-ins, defect)

Product:
Camino Graveyard
Component:
Plug-ins
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED INVALID
Milestone:
Camino1.0

People

(Reporter: froodian, Assigned: mikepinkerton)

References

(
URL
)

Details

(Keywords: crash, relnote)

Crash Data

Attachments

(3 files)

Crash Log
81.06 KB, text/plain
Details
Crashes in CoreText framework
125.91 KB, text/plain
Details
Different crashes with "good" CoreText framework, in "bad" partition
143.63 KB, text/plain
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060203 Camino/1.0rc1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060203 Camino/1.0rc1 At given URL, can crash Camino by merely navigating. CPU usage spikes to 100%, and eventually crashes. Seems to be JEP, per IRC. Reproducible: Always Steps to Reproduce: 1. Navigate to URL 2. Scroll around, click on things 3. Rinse and repeat for approx. 60 seconds Actual Results: Crash Talkback crash TB14851242Z
Attached file Crash Log —
Attaching crash log
Note the size of the above crash log. ;) There are a bazillion threads spawned when going to that site. I can repro with 1.0rc1 just by going there and scrolling around for a while. Filed Talkback TB14850986H and TB14849804G on this myself. Another reporter (on the forum) says he filed TB14848301Z on it. Confirming, cc'ing Steven Michaud. cl
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → Plug-ins
Keywords: crash
WFM. For reference; 1) Delete JEP bundled with Camino (Camino.app/Contents/MacOS/plugins/) 2) Download JEP 0.9.5+c (http://sourceforge.net/projects/javaplugin/) 3) Install it to "/Library/Internet Plug-Ins/" So it seems that this is the problem of JEP bundled with Camino.
(In reply to comment #3) > WFM. > For reference; > > 1) Delete JEP bundled with Camino (Camino.app/Contents/MacOS/plugins/) > 2) Download JEP 0.9.5+c (http://sourceforge.net/projects/javaplugin/) > 3) Install it to "/Library/Internet Plug-Ins/" Confirmed as a workaround. The page didn't crash, although it slowed down the browser terribly. Tested with 1.0rc1.
So that would seem to finger some of mento's Intel fixes, since 1.0rc1 ships with JEP 0.9.5+c + Intel fixes. Philippe originally reported this on the trunk in the forum, so if all those fixes aren't on the trunk, this might help narrow things down.
To the extent that we have TB data for RC, libhotspot.dylib seems to be an early favorite as a topcrasher (and all the reports, such as they are, seem to be 10.4). There's an outside change bug 326196 might be related.
Flags: camino1.0?
Target Milestone: --- → Camino1.0
(In reply to comment #5) > So that would seem to finger some of mento's Intel fixes, since 1.0rc1 ships > with JEP 0.9.5+c + Intel fixes. I don't see how that's possible. The ppc bits in 1.0rc1's MRJPluginJEP and JEP bundle were taken straight out of 0.9.5+c and merged into the fat version without any fixes at all. The patches were only applied to the x86 bits, but your ppc won't ever see that. The JEP bundle that will ship with 1.0 final (and that is present in current 1.0 branch nightlies) does contain a rebuild of the ppc portion to fix a Rosetta crash, but it's not present in the build Philippe is using. > Philippe originally reported this on the trunk in the forum, so if all those > fixes aren't on the trunk, this might help narrow things down. Trunk builds don't have any JEP fixes for x86 either, they're vanilla JEP 0.9.5+c. The only place in CVS you'll find JEP with x86 fixes right now is the CAMINO_1_0_BRANCH.
I couldn't reproduce this crash using today's official 1.0rc1+ nightly on ppc.
I get a crashes loading this URL with Camino 1.0b2, Camino 1.0RC1, and Camino 2006-02-07-02-1.0 with my own JEP 0.9.5+c and 0.9.5+b, and the latter two also with Mark's JEP 0.9.5+c with Intel bits. (Only on OS X 10.4.4.) Mark is right -- his Intel bits can't have anything to do with this problem. It also seems that some people experience it pretty consistently, and others don't. And I'll bet the crash logs are all somewhat different. (Mine are all pretty consistent with each other, but are different from the one that's been posted here. Later, when I have time, I'll post a selection of mine.) None of the crashes are in JEP code. All (mine plus the one posted here) are in JVM code. It's conceivable that one or more bugs in Apple's JVM are involved here. I'm using Apple's (late pre-release) J2SE 5.0 Release 4 DP5, while froodiantherapy seems to be using Java 1.4.2_09 ... which makes the Apple bug theory a little less likely, though. And in my single test Safari doesn't crash on this page. I suspect it will be very difficult to find a single crashlog signature for this bug -- so Talkback is unlikely to be much help. But I also suspect that very few sites will experience this problem, and this bug isn't a topcrasher. I will look into this further when I have more time (probably later today).
FWIW, I also have Java 1.4.2_09. cl
My tests indicate that this problem only happens on Mac OS X 10.4.4, and then only with Camino -- not with Firefox or Seamonkey. Furthermore, it seems to happen with _all_ Camino versions (I tested back to 0.8.4). But I'm now quite sure that this is an Apple bug (even though Safari isn't effected), and I'm slowly accumulating evidence. I've attached a couple of my crash logs. All of them (including the ones I haven't attached) show a crash in CanonicaliseLanguage() (and above that in CreateSystemPreferredLanguages() and Java_sun_font_AppleNativeCharToGlyphMapper_nativeCharsToGlyphs[...]). CanonicaliseLanguage() and CreateSystemPreferredLanguages() are functions of the CoreText framework, which is new as of OS X 10.4 (and is (unfortunately but not surprisingly) totally undocumented). Apple has a document (http://developer.apple.com/technotes/tn2004/tn2124.html) which tantalizingly hints at certain debugging functionality that's available if you set the CFZombieLevel environment variable and uses the "_debug" version of the CoreFoundation framework. (I followed the technique mentioned in this article to use _only_ the debug version of the CoreFoundation framework, and the regular versions of all other frameworks. To get this to work with Camino I found I also needed to set a DYLD_FORCE_FLAT_NAMESPACE environment variable.) When I set CFZombieLevel to '16' (which causes the CoreFoundation framework to "never free memory used to hold CF objects"), the crashes stopped happening. Clearly CanonicaliseLanguage() sometimes operates on a "CF object" that has been deleted. I'm reasonably certain that this is because of a bug (or bugs) in the CoreText framework. But I can't find enough information about how the CFZombieLevel environment variable works to be certain. The NSZombieEnabled environment variable is much better documented. If you set that, you see warnings in the console that something has tried to send an Objective C "message" to an object that has been deleted. Furthermore you can break (in gdb) on '-[_NSZombie release]' and/or '-[_NSZombie methodSignatureForSelector:]' to find out more about why this has happened. But setting CFZombieLevel doesn't seem to cause any additional logging to happen. And I have no idea whether you can break on certain targets in gdb to get more information. Anyone out there know more about this? :-)
> But I'm now quite sure that this is an Apple bug (even though Safari isn't > effected), and I'm slowly accumulating evidence. I should have qualified this: All the crashes _I've_ seen are pretty definitely caused by one or more Apple bugs. (And no other crashes happen after I eliminate them.) Does anyone else have interesting (and interestingly different) crash logs? These need to be crashreporterd crash logs (Talkback ones don't have enough information). Apple's crashreporterd appends each new Camino crash to Camino.crash.log in the Library/Logs/CrashReporter directory under your home directory (i.e. to ~/Library/Logs/CrashReporter/Camino.crash.log).
By the way, I just realized that the Java_sun_font_AppleNativeCharToGlyphMapper_nativeCharsToGlyphs[...] symbols are only present in a Java 1.5 library (libawt.jnilib), even on OS X 10.4.4. So it's possible that people using Java 1.4.2 have encountered a _different_ Apple bug -- one that will be fixed in Apple's upcoming J2SE 5.0 Release 4. Those who haven't yet installed J2SE 5.0 Release 4 can still use the "Java Preferences" utility to switch back and forth between Java 1.4.2 and Java 1.5. I wonder if doing this makes any difference with this bug's URL. (I'd try this test myself ... but Apple doesn't let you uninstall its Java releases, so I'd have to reinstall the entire OS.)
Alright, in for a penny, in for a pound :-) I've just installed OS X 10.4 from scratch on a spare partition. Then I upgraded it to 10.4.4 and everything else Software Update wanted me to install except J2SE 5.0 Release 3 -- that is, my most recent Java installation was Java 1.3.1 and 1.4.2 Release 2. With this setup I have no crashes at all with this bug's URL -- with any version of Camino or any version of Firefox. Then I upgraded to J2SE Release 3. Still no crashes at all. Either with Java 1.4.2_09 or Java 1.5.0_05. In a few days I'll try installing J2SE Release 4 DP5 ... or whatever DP is current at that time. It's possible that the problems some people have been having with the URL have something to do with their installation history -- what they have, and the order in which it was installed. But whatever these problems are, they almost certainly have nothing to do with the Java Embedding Plugin or Camino. (I'm still interested in seeing new and different crashreporterd crash logs, though. It might be possibly to glean some information from them.)
Steven, have you been in contact with Apple about this?
Blocks: 224615
Summary: 100% cpu then crash when navigating page → [10.4] 100% cpu then crash [@ libhotspot.dylib] when navigating page (Java, Apple bug?)
*** Bug 326196 has been marked as a duplicate of this bug. ***
I'm as interested as anyone in fixing this, but I don't think we'll hold Camino 1.0 for it, unless a slick workaround surfaces soon. 1.0 final is scheduled for Tuesday. If we can come up with a list of known-good and known-bad JVMs, we can relnote this problem. The translators will be pissed, but they'll live. Steven, have you filed this at bugreporter.apple.com yet?
Flags: camino1.0? → camino1.0-
> *** Bug 326196 has been marked as a duplicate of this bug. *** I'm skeptical that bug 326196 really is a dup of this bug -- I haven't had any problems with it, even on my "bad" OS X 10.4.4 partition. > Steven, have you been in contact with Apple about this? No, I haven't. And I probably shouldn't. If I open a bug report with Apple, I'll be the only one who as access to their response(s), and any status information they provide. Once there's sufficient information in this bug to support a bug report to Apple, probably someone at Mozilla.org should use a special account to open an Apple bug report, referencing this bug (bug 326195). Then any number of Mozilla.org people, at least, will be able to see Apple's response :-)
Flags: camino1.0- → camino1.0?
I've taken the obvious next step -- I copied the CoreText framework from my "good" (freshly created) OS X 10.4.4 partition to my "bad", old one. That gets rid of the crash on startup that I originally had. But I still get crashes (on thread 0) when I access the menu after having loaded this bug's URL, or when I close the window. One of these crashes (the one I get when I access the menu) is still in CoreText's CanonicaliseLanguage() (and CreateSystemPreferredLanguages()). These crashes persist even when I copy over every framework in the thread 0 stack trace from my "good" partition to my "bad" one -- CoreFoundation, Carbon (and all it's sub-frameworks, including HIToolbox) and AppKit. They still only effect Camino (not Firefox). I still don't see anything like this in my "good" partition.
I forgot to mention that the "BuildVersion" (in Resources/version.plist) of my "good" CoreText framework (the one from my fresh installation) is '55', and the "bad" one's is '28'. All the other frameworks that I copied over from my "good" partition to my "bad" one had exactly the same version information in both partitions. But "cmp" found differences, so I copied them all anyway. Probably those differences are due only to prebinding silliness. The differences between the two CoreText frameworks seem to be genuine, though. Finally, my "bad" partition has no file-system problems -- DiskUtility gives it a clean bill of health.
I'm now heartily sick of this bug! I tried copying the "bad" CoreText framework to my "good" (recently created) OS X 10.4.4 partition. I had _one_ crash in CanonicaliseLanguage() in thread 0 (not in higher threads, as I'd seen on my "bad" partition). In at least 10 other tries, I had no problems at all. Then I installed J2SE 5.0 Release 4 DP5. Now I had a slightly increased likelihood of crashing on thread 0 (in CanonicaliseLanguage()) on accessing the menu (and a different crash, similar to the one I've already posted, on closing the browser window). But nothing like what I'd seen on my "bad" partition. And still nothing on higher threads. Finally (and now totally disgusted with the whole business) I reinstalled Apple's 10.4.4 update on my "bad" partition. This seems to have almost cleared up my problems with this bug's URL, even in my "bad" partition. Now it's on the same level (more or less) as my "good" partition has become after I've installed J2SE 5.0 Release 4 DP5 there. So, my first conclusion after all this work is that it's been a gigantic waste of time. Second, there seems to be a slightly increased likelihood of trouble if you install any of the J2SE 5.0 Release 4 DPs. Apple advises that you don't install these pre-release versions on production systems. I strongly second this, and in the future am going to follow my own advice :-) Third, the only thing definite enough in all this to report to Apple is the business with the different CoreText framework builds. I don't know where my "bad" CoreText framework came from, but Apple should be aware that there is some chance users won't have the latest (and best) version of this framework. Fourth, unless mew information comes in on this bug, it should be marked WFM or INVALID or whatever the Mozilla.org people think is appropriate.
A couple of footnotes: Installing/reinstalling the 10.4.4 update (at least the Combo update, which is what I used) does upgrade the CoreText framework to build 55 -- i.e. to the current version. I noticed that using Camino 0.8.4 increases (to some small degree) the chance of experiencing crashes at this bug's URL -- with Camino 0.8.4 and (afterwards) even with later versions. But if you delete/rename your profile (i.e. delete/rename the ~/Application Support/Camino/ directory), the crash-frequency goes back to "normal" for as long as you don't use Camino 0.8.4, but only later versions. It looks like Camino 0.8.4 somehow pollutes your profile in some way which increases your likelihood of seeing this bug. This may have something to do with the fact that I always see this message in the Console whenever I launch Camino 0.8.4: Unable to set languages - language 'zh_Hans' not a valid ISO language identifier Oddly, this message seems to be false -- as far as I can tell 'zh_Hans' _is_ valid (it means "Chinese Simplified").
Another footnote: I suppose it _is_ worthwhile telling people who experience this problem (or in fact any unexplainable problem on OS X 10.4) to reinstall the latest update. This could be added to my "conclusions" from comment #21.
How's this for a release note?: Java applets may crash randomly on Mac OS X 10.4 in certain configurations because some system updates fail to fully upgrade all components of the system. If you experience crashes on pages that use Java applets, apply the latest "combo update" from Apple to ensure that your system is up-to-date.
I think you need to convey that very few people will see this problem. And those few who do see it will get crashes pretty consistently with certain URLs, and not at all with the vast majority of URLs. (The problem, though difficult to pin down, isn't just random.) How about something like this? Some unusual configurations of Mac OS X 10.4 may crash fairly consistently on certain pages that load Java applets, but not on most others. If you experience this problem try applying (or re-applying) the latest "combo update" from Apple, even if you have already installed it. Some Apple updates fail to fully upgrade all components of the system, and others may actually downgrade components.
Smokey, Ludo, your feelings on the relnote above? Seems like something that should go into the "known issues" section.
(In reply to comment #26) > Smokey, Ludo, your feelings on the relnote above? Seems like something that > should go into the "known issues" section. > Would be nice.
I prefer the suggested relnote in comment 24. It's hard to tell how common this really is, given the limited testing time and reduced distribution of 1.0rc1, but since it's the topcrasher and we have a reasonable idea of a "cause" and a potential solution, it does seem relnote worthy. Those of you cc'd to the bug who have experienced this crash: have you tried (re-)applying the 10.4.4 combo update and visiting the sites that were causing crashes?
Summary: [10.4] 100% cpu then crash [@ libhotspot.dylib] when navigating page (Java, Apple bug?) → [10.4] 100% cpu then crash [@ libhotspot.dylib.1.0.0] when navigating page (Java, Apple bug?)
Oops! I just saw that I'm down here as requesting that this bug block Camino 1.0, just after Mark turned down a similar request. I don't quite know how that happened. And in any case I didn't intend to make that request. Sorry.
Flags: camino1.0? → camino1.0-
(In reply to comment #28) > since it's the topcrasher I doubt very much that any of the problems _I've_ seen are topcrashers, singly or all together. The conditions may have existed for months on my "bad" partition before I saw "this" problem at all. > [@ libhotspot.dylib.1.0.0] This "signature" will almost certainly find crashes that are unrelated to this bug.
Flags: camino1.0- → camino1.0?
Flags: camino1.0? → camino1.0-
Not your fault, Bugzilla's extraordinarily bad about resetting flags especially when you do things like reload bugs. If you reload without holding shift, you won't pick up the new form defaults. Anyway, you have a point. We can't be positive which of the Talkback libhotspot reports are this particular crash, although we can guess, and my best guess is that this particular issue is rare-ish relative to all libhotspot crashes, but unlike some others, fairly easily reproduced on certain pages. This should address everyone's concerns: Java applets on some web pages may crash on Mac OS X 10.4 in certain configurations. This can happen after a system update fails to fully upgrade all components of the system. If you experience crashes on pages that use Java applets, apply or reapply the latest "combo update" from Apple to ensure that your system is up to date. Doesn't say it's random, doesn't say it's consistent, doesn't say it's rare either - it doesn't say anything that we don't know for sure. I'd like to wait for feedback from others who have experienced this crash before adding the note, but even in the absence of feedback, I'll update the file by the end of the day to give translators a fair chance to do their thing.
(In reply to comment #31) Your relnote is fine with me. This gives people something reasonably specific to look for, and something to do about it, without promising too much about the results.
New relnotes in bug 326224
I can confirm this workaround/fix is effective. I can no longer get the crash on that page after re-installing the 10.4.4 Combo Update. cl
Release note update checked in to CAMINO_1_0_BRANCH. INVALIDating per comment 21. Thanks for looking into this on short notice, Steven.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
has apple been notified that their upgrades are broken?
Status: RESOLVED → VERIFIED
Someone from Apple did contact me, and I gave him all the information I've been able to gather (including all of the following). I've also continued to discover more, on my own, about the crashes I reported here (which are probably unrelated to any of the other problems reported here). By judicious use of gdb, I discovered that many of my crashes happen after the CoreText framework calls CFPreferencesCopyAppValue() with 'key' set to "AppleLanguages": The CFArray returned by CFPreferencesCopyAppValue() is fine, but the individual CFStringRefs it contains (like "en") point to deleted objects. But I no longer think Apple's new CoreText framework (any version of it) is reponsible for my crashes. Instead I suspect that there are bugs in Apple's CFPreferences/NSUserDefaults code on (at least) recent versions of Mac OS X 10.4 (including 10.4.4 and 10.4.5). My main reason for thinking this is that adding the following line to maybeCreateJavaVM (in AppletView.m), just before it launches the JVM, completely eliminated my crashes: [NSUserDefaults resetStandardUserDefaults]; I've included this change in my latest JEP release (version 0.9.5+d): http://javaplugin.sourceforge.net/ It's unlikely that anyone else has reported elsewhere the crashes I reported here. So my "resetStandardUserDefaults" fix isn't terribly likely to help anyone else. But the crashes reported at bug 325987 _might_ be related. I'll post a note there asking that bug's reporter to try my new JEP version.
Crash Signature: [@ libhotspot.dylib.1.0.0]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: