Closed
Bug 211462
Opened 21 years ago
Closed 21 years ago
Crash turning on JA IME on Mac 10.1 [@ Kotoeri]
Categories
(Core :: Internationalization, defect, P1)
Tracking
()
RESOLVED
FIXED
People
(Reporter: marina, Assigned: lordpixel)
References
Details
(5 keywords)
Crash Data
Attachments
(2 files)
13.26 KB,
text/html
|
Details | |
1.76 KB,
patch
|
Brade
:
review+
sfraser_bugs
:
superreview+
|
Details | Diff | Splinter Review |
seen with 7.1 rtm build on JA locale on MacOS10.1.5 (does NOT happen with other IME neither on 10.2 steps to reproduce: - launch 7.1 on JA locale; - go to Composer; - JA IME will be a default IME; - type something into the Composer; - no need to save; - restart/reopen the application; - open Composer; //note: cursor is not blinking at the beginning of the line; - try to input something in JA, crash
here is the stack: Call Stack: (Signature = Kotoeri + 0x4d958 (0x029a9958) d260ee2d) Kotoeri + 0x4d958 (0x029a9958) Kotoeri + 0x4d91c (0x029a991c) Kotoeri + 0x41ae0 (0x0299dae0) Kotoeri + 0x20308 (0x0297c308) Kotoeri + 0x5ffe4 (0x029bbfe4) Kotoeri + 0x6bbe4 (0x029c7be4) Kotoeri + 0x5ec88 (0x029bac88) Kotoeri + 0x65304 (0x029c1304) Kotoeri + 0x3edf8 (0x0299adf8) Kotoeri + 0x3e75c (0x0299a75c) CarbonCore.315.0.0 + 0x9530 (0x70249530) CarbonCore.315.0.0 + 0x53624 (0x70293624) Kotoeri + 0x3d0f8 (0x029990f8) Kotoeri + 0x3d880 (0x02999880) CarbonCore.315.0.0 + 0xcc1c (0x7024cc1c) HIToolbox.75.0.0 + 0x1cf938 (0x732cf938) HIToolbox.75.0.0 + 0x5ede8 (0x7315ede8) HIToolbox.75.0.0 + 0x20d3a0 (0x7330d3a0) HIToolbox.75.0.0 + 0x62598 (0x73162598) HIToolbox.75.0.0 + 0x25eb4 (0x73125eb4) HIToolbox.75.0.0 + 0x2ad48 (0x7312ad48) HIToolbox.75.0.0 + 0xb30b0 (0x731b30b0) HIToolbox.75.0.0 + 0x18fe0 (0x73118fe0) HIToolbox.75.0.0 + 0x21bc (0x731021bc) HIToolbox.75.0.0 + 0x50348 (0x73150348) HIToolbox.75.0.0 + 0x16e0cc (0x7326e0cc) HIToolbox.75.0.0 + 0xac598 (0x731ac598) HIToolbox.75.0.0 + 0x1908c (0x7311908c) HIToolbox.75.0.0 + 0x21bc (0x731021bc) HIToolbox.75.0.0 + 0xb6c58 (0x731b6c58) HIToolbox.75.0.0 + 0xd3884 (0x731d3884) HIToolbox.75.0.0 + 0xd0c28 (0x731d0c28) HIToolbox.75.0.0 + 0x79d64 (0x73179d64) HIToolbox.75.0.0 + 0xa1864 (0x731a1864) HIToolbox.75.0.0 + 0xae988 (0x731ae988) HIToolbox.75.0.0 + 0xc6508 (0x731c6508) nsMacMessagePump::GetEvent() [/builds/nightly/seamonkey/1.4/mozilla/widget/src/mac/nsMacMessagePump.cpp, line 408] nsMacMessagePump::DoMessagePump() [/builds/nightly/seamonkey/1.4/mozilla/widget/src/mac/nsMacMessagePump.cpp, line 313] nsAppShell::Run() [/builds/nightly/seamonkey/1.4/mozilla/widget/src/mac/nsAppShell.cpp, line 114] main1() [/builds/nightly/seamonkey/1.4/mozilla/xpfe/bootstrap/../../dist/include/xpcom/nsCOMPtr.h, line 690] _main() [/builds/nightly/seamonkey/1.4/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1650] _start() [/SourceCache/Csu/Csu-45//SourceCache/Csu/Csu-45/crt.c, line 267] start()
Comment 3•21 years ago
|
||
it crash deep inside the OS when we call ::WaitNextEvent it looks like a kotoeri bug instead of a mozilla bug. With 36 levels deep inside the OS when crash, I don't think we can figure out what happen easily. Do you always need to restart / relaunch the application to see this happen? What will happen if you, instead of relaunch the app afte quite, open TextEdit and type japanese there. Will that crash the TextEdit?
Comment 4•21 years ago
|
||
can you reproduce the very same bug with mozilla build? can we narrow down when does this happen by binary search and find out when (which date) this problem first appeared?
Updated•21 years ago
|
Hardware: Macintosh → PC
Summary: Crash turning on JA IME → Crash turning on JA IME on Mac 10.1
Comment 5•21 years ago
|
||
Also realize that we can't build mozilla with OS 10.1 anymore so this will be difficult to debug.
Hardware: PC → Macintosh
Summary: Crash turning on JA IME on Mac 10.1 → Crash turning on JA IME on Mac 10.1 (10.1.5)
Comment 7•21 years ago
|
||
It turn out to reproduce this we don't need to restart or relaunch the app. Just make sure switch to JA input method before launch it. Here is more detail stack trace Date/Time: 2003-07-02 13:42:20 -0700 OS Version: 10.1 (Build 5L17b) Command: mozilla-bin PID: 277 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0: #0 0x02be1958 in GetText__C29TJapaneseKeypressTextTreeNodeR14TUnicharBufferRC19TTextTypeComparitor #1 0x02be31bc in __24TJapaneseRawTextTreeNodeP13TTextTreeNodesUcUl #2 0x02bd5ae0 in GenerateTextTreeNodeForKey__24TJapaneseInputControllerRC14TUnicharBufferUss #3 0x02bb4308 in GenerateTextTreeNodeForKey__13TInputHandlerRC14TUnicharBufferUss #4 0x02bf3fe4 in ServiceKeyPress__19TInputMethodSessionP11EventRecordRC14TUnicharBuffer #5 0x02bffbe4 in ServiceKeyPress__15TKotoeriSessionP11EventRecordRC14TUnicharBuffer #6 0x02bf2c88 in ServiceKeyPress__23TInputMethodEnvironmentP19TInputMethodSessionP11EventRecordRC14TUnicharBuffer #7 0x02bf9304 in ServiceKeyPress__19TKotoeriEnvironmentP19TInputMethodSessionP11EventRecordRC14TUnicharBuffer #8 0x02bd2df8 in _UCTextServiceEvent__FPP13SessionRecordP14OpaqueEventRefPUsUl #9 0x02bd275c in _TextServiceEvent__FPP13SessionRecordP14OpaqueEventRef #10 0x70249530 in CallComponentFunctionCommon #11 0x70293624 in CallComponentFunctionWithStorage #12 0x02bd10f8 in CallCFNWithStorage__FPPcP19ComponentParametersPFe_ll #13 0x02bd1880 in KotoeriComponentDispatch #14 0x7024cc1c in CallComponent #15 0x732cf938 in TextServiceEventRef #16 0x7315ede8 in TSMEventToInputMethod #17 0x7330d3a0 in utDeliverTSMEvent #18 0x73162598 in TSMKeyEvent #19 0x73125eb4 in TSMProcessRawKeyEvent #20 0x7312ad48 in HandleCompatibilityKeyEvent #21 0x731b30b0 in CompatibilityEventHandler #22 0x73118fe0 in DispatchEventToHandlers #23 0x731021bc in SendEventToEventTargetInternal #24 0x73150348 in SendEventToEventTargetWithOptions #25 0x7326e0cc in HandleKeyboardEvent #26 0x731ac598 in ToolboxEventDispatcherHandler #27 0x7311908c in DispatchEventToHandlers #28 0x731021bc in SendEventToEventTargetInternal #29 0x731b6c58 in SendEventToEventTarget #30 0x731d3884 in ToolboxEventDispatcher #31 0x731d0c28 in CallEventDispatchHook #32 0x73179d64 in GetOrPeekEvent #33 0x731a1864 in GetNextEventMatchingMask #34 0x731ae988 in WNEInternal #35 0x731c6508 in WaitNextEvent #36 0x00eed360 in _ZN16nsMacMessagePump8GetEventER11EventRecord #37 0x00eed23c in _ZN16nsMacMessagePump13DoMessagePumpEv #38 0x00ee0d00 in _ZN10nsAppShell3RunEv #39 0x000053cc in _Z5main1iPPcP11nsISupports #40 0x00005928 in main #41 0x00002250 in _start #42 0x000020d0 in start
Summary: Crash turning on JA IME on Mac 10.1 (10.1.5) → Crash turning on JA IME on Mac 10.1
Comment 8•21 years ago
|
||
There is a similar bug in Japanese Bugzilla. http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=3241 There it is mentioned that the crash occurs with trunk builds after 2003-05-27. (The bug is about Firebird but the date may apply to Mozilla also.) There is also a BBS log from 2003-06-28 that the user can reproduce this crash 100% when using Mac OS 10.1.5 + Mozilla 1.4rc3 + Kotoeri. http://www.mozilla.gr.jp/tools/cbbs/cbbs.cgi?mode=one&namber=5914&type=5881&space=45&no=0
Comment 9•21 years ago
|
||
Additional fact: You don't need to even open the composer to induce an IME crash. If JA IME is selected when the browser comes up, just by changing the status of IME from half-width Roman to full-width Hiragana or the reverse (from full-width Hiragana to half-wdith Roman), it crashes on the browser window.
Comment 10•21 years ago
|
||
I'm atatching a file rather than pasting in the dump because it is quite from the one being dicsussed in this bug -- it does involve IME mode change and occurs on 10.1.5 but not on 10.2.6.
Comment 11•21 years ago
|
||
Tested the build mentioned by the Japanese report above. The crash problem occurs with 2003-05-27 trunk build on Mac OS X 10.1.5 but not on the 2003-05-26 build. Can anyone check what checkins occurred on 05-26?
Comment 12•21 years ago
|
||
There is another problem when Kotoeri is ON when the browser starts up. I had Kotoeri in half-width Roman mode and tried to input URL into the URL bar, and it crashed also.
Comment 13•21 years ago
|
||
I take a look at bonsai about the change during 05 the following two changes look specious to me: for bug 204005 http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/layout/base/src&command=DIFF_FRAMESET&file=nsCaret.cpp&rev1=1.110&rev2=1.111&root=/cvsroot and for bug 78363 http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/widget/src/mac&command=DIFF_FRAMESET&file=nsWindow.cpp&rev1=1.200&rev2=1.201&root=/cvsroot
Comment 14•21 years ago
|
||
CC'ed sfraser and leon.zhang.
Comment 15•21 years ago
|
||
My changes which might be related to JA IME: 1)patch (http://bugzilla.mozilla.org/attachment.cgi?id=123950&action=view)for bug 204434 just initialize the mIMECursorPosition, and this should not be related to this bug. 2) bug 204005 is related to caret's timer, we are doing something in bug 208446, this is related to caret's stop blinking, should not related to this crash.
Comment 16•21 years ago
|
||
Cranked up the Priority and Severity to P1/critical. Assigning to ftang for now.
Severity: normal → critical
Priority: -- → P1
Comment 18•21 years ago
|
||
Frank doesn't have a current Mac build. Can someone with a current Mac build, try creating 2 private builds that have each of the 2 fixes mentioned in comment #13 backed out? Then we can have someone try these builds on 10.1.
Comment 19•21 years ago
|
||
I found that since 2003-06-12, there are over 80 crashes in Talback database all having the call stack signature of Kotoeri, and almost all occuring with Darwin 5.5 OS. They seem to be the same crash as this one.
Comment 20•21 years ago
|
||
leon: the crash is deep inside the MacOSX. It could be a MacOS bug deep inside the OS and hard to surface untill your change make it happen. It does not mean your patch have bug . It only mean it is possible that your change surface a problem inside the OS. (And we saw those kind of thing before- one of our change surface a crash deep inside MacOS Unicode Utility about one year ago.)
Comment 21•21 years ago
|
||
Dose this bug happen in mozilla1.4(ns7.1) or later trunk?
Comment 22•21 years ago
|
||
Leon, the crash happens with either branch or trunk build as long as it is later than 2003-05-26 running on Mac OS X 10.1.x. (You need to meet all these conditions.)
Comment 23•21 years ago
|
||
so, following in comment #15: 1) patch for bug 204434 is in mozilla1.4 and trunk, which only initialize mIMECursorPosition. 2) patch for 204005 is NOT in mozilla1.4, just in trunk, so it is not related to this crash. I think we should find other tracing point.
Comment 24•21 years ago
|
||
*** Bug 214052 has been marked as a duplicate of this bug. ***
Keywords: topcrash
Summary: Crash turning on JA IME on Mac 10.1 → Crash turning on JA IME on Mac 10.1 [@ Kotoeri]
Comment 25•21 years ago
|
||
Seems like this is caused by the patch for bug 78363. A Japanese reporter says that no crash occurs on OS 10.1 if the fix for bug 78363 is backed out. test build: http://www.bekkoame.ne.jp/~h-sek/firebird.dmg.bz2
Assignee | ||
Comment 26•21 years ago
|
||
While I wrote the patch for 78363, I'm not sure I can help you debug this. I don't have any copies of 10.1 installed anywhere. (In any case Is it necessary to have the whole OS in JA mode or just to enable Koterei?) There's nothing in the stack trace to indicate any cursor related code directly, and the way this is confined to 10.1 suggests a subtle side effect is exercising an OS bug. To my mind, a sensible step to take would be to comment out these two lines: ::SetCursor(*cursHandle); ::SetThemeCursor(aCursorResourceNum); from nsWindows. That'd leave the rest of the patch in place but ensure that it doesn't do anything. If that fixes the symptoms then we can try to figure out how to proceed. Unfortunately I lack a 10.1 machine. Is it necessary to compile on 10.1 or could anyone with Mac OS X build this and make it available to someone with 10.1 to test? We can probably figure a way to have this code not active on 10.1 only.
Comment 27•21 years ago
|
||
Is it possible that we're being called at interrupt time? SetThemeCursor should not be called during interrupts. Is there someone who is able to test this bug if a build were made (developers have to build with 10.2 system so testing isn't easy unless the developer has multiple computers)?
Keywords: helpwanted
Comment 28•21 years ago
|
||
I don't think this is related to setting cursors at all. Maybe the calls to nsMacResources::OpenLocalResourceFile(); are messing with the resource chain?
Assignee | ||
Comment 29•21 years ago
|
||
brade: re: interupt time: that had occurred to me, and it might still be true, but 2 counterpoints: * I believe all "interrupt time" callbacks on OS X actually just run in Mach thread(s) that simulates the callbacks, so the environment, whilst still multi-threaded, is a lot less restrictive * I was concerned that we sometimes set the cursor in a VBL handler (see nsWatchTask.cpp) but I checked it the other day and it just calls ::SetCursor directly, it doesn't use this code. Still a possibility though... sfraser: we looked at OpenLocalResourceFile() quite closely when you super reviews the bug, and we decided it looked pretty OK. Again, always a possibility. To be honest I'd kind of decided to come up with a patch that does a (cached!) Gestalt check for 10.1 or below and disables the animation for those version. Seems like a reasonable solution to me. I'll try to make it happen soonish.
Assignee | ||
Comment 30•21 years ago
|
||
So here's a patch that disables the animation on pre-jaguar systems. This should enable us to determine whether this is the problem, and we could then check it in. Since the diff is hard to read, here are the highlights: // Return true if we are on Mac OS X 10.2 or later, caching the result after the first call PRBool OnJaguarOrLater() { static PRBool gInitVer = PR_FALSE; static PRBool gOnJaguarOrLater = PR_FALSE; if(! gInitVer) { long version; OSErr err = ::Gestalt(gestaltSystemVersion, &version); gOnJaguarOrLater = (err == noErr && version >= 0x00001020); gInitVer = PR_TRUE; } return gOnJaguarOrLater; } // // SetCursor // // Override to set the cursor on the mac // NS_METHOD nsWindow::SetCursor(nsCursor aCursor) { nsBaseWidget::SetCursor(aCursor); // allow the cursor to be set internally if we're in the bg, but // don't actually set it. if ( !nsToolkit::IsAppInForeground() ) { return NS_OK; } if ( gCursorSpinner == nsnull && OnJaguarOrLater()) { gCursorSpinner = new CursorSpinner(); } // mac specific cursor manipulation short cursor = -1; switch (aCursor) { // SNIP } //animated cursors cause crash on Mac OS X 10.1 when Japanese Kotorei input method is enabled if ( OnJaguarOrLater() ) { if (aCursor == eCursor_spinning) { gCursorSpinner->StartSpinCursor(); } else { gCursorSpinner->StopSpinCursor(); nsWindow::SetCursorResource(cursor); } } else { nsWindow::SetCursorResource(cursor); } return NS_OK; } // nsWindow::SetCursor I only build debug... can I just turn the 'dist' directory into a .dmg file and put it up somewhere so people with 10.1 can try it? Trouble is debug builds are so slow that the bug might not show up. Perhaps I'll build it both ways so people can compare... So, can I package a debug build?
Comment 31•21 years ago
|
||
Comment on attachment 131642 [details] [diff] [review] Disable animation on pre-Jaguar systems I assume you tested this code by temporarily changing the OS version and seeing that the animation didn't function. I'm ok with this patch if it tests ok. I would like to see the comment be very clear (explicit) that Jaguar == 10.2 since someone 3 or 4 years from now may not get the connection (or non-Mac people)--ideally I'd see "jaguar" and "10.2" in the same line (for those using lxr).
Attachment #131642 -
Flags: review+
Assignee | ||
Comment 32•21 years ago
|
||
>I assume you tested this code by temporarily changing the OS version and seeing >that the animation didn't function. Precisely. >I'm ok with this patch if it tests ok. I >would like to see the comment be very clear (explicit) that Jaguar == 10.2 >since someone 3 or 4 years from now may not get the connection (or non-Mac >people)--ideally I'd see "jaguar" and "10.2" in the same line (for those using >lxr). I'll do that if I check it in, though I note Jaguar is the actual name of the product, not just the code name (unlike say 10.1 = Puma). I'm not really looking to check in this as its a bit ugly: I want someone to suggest a way we can test this without checking it in. We have no idea if this is the actual cause of the crash, really.
Comment 33•21 years ago
|
||
test build with the patch: http://www.bekkoame.ne.jp/~h-sek/firebird_20030918.dmg.gz A Japanese tester reports that no crash occurs on OS 10.1.
Assignee | ||
Comment 34•21 years ago
|
||
Comment on attachment 131642 [details] [diff] [review] Disable animation on pre-Jaguar systems Well, if it does the job... I have some much cleaner cursor code for Camino that I'll try to check in at some point. Once that's done I'll backport it to Mozilla and think of a more elegant way to do this check.
Attachment #131642 -
Flags: superreview?(sfraser)
Updated•21 years ago
|
Attachment #131642 -
Flags: superreview?(sfraser) → superreview+
Assignee | ||
Comment 35•21 years ago
|
||
Comment on attachment 131642 [details] [diff] [review] Disable animation on pre-Jaguar systems Should try to put this in 1.5 as its topcrash
Attachment #131642 -
Flags: approval1.5?
Assignee | ||
Comment 36•21 years ago
|
||
Checked in on Trunk.
Assignee | ||
Comment 37•21 years ago
|
||
Taking, and asking if it blocks 1.5
Assignee: ftang → lordpixel
Flags: blocking1.5?
Updated•21 years ago
|
Flags: blocking1.5?
Comment 38•21 years ago
|
||
Comment on attachment 131642 [details] [diff] [review] Disable animation on pre-Jaguar systems 1.5 shipped. removing obsolete request.
Attachment #131642 -
Flags: approval1.5?
Assignee | ||
Comment 39•21 years ago
|
||
Fixed on the trunk
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Keywords: inputmethod
Updated•13 years ago
|
Crash Signature: [@ Kotoeri]
You need to log in
before you can comment on or make changes to this bug.
Description
•