Closed Bug 128323 Opened 23 years ago Closed 23 years ago

Clicking Subject column to sort messages results in a crash

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: chrispetersen, Assigned: ftang)

References

Details

(Keywords: crash, Whiteboard: adt1)

Attachments

(3 files, 1 obsolete file)

I can reproduce the crash with this data, mails contains Korean (encoded in UTF-8 in order to isolate the problem from the Korean converter).
4.00 KB, text/plain
Details
Simple test case using the template console program. It only crashes with Korean string.
2.22 KB, text/plain
Details
refine patch to address both nhotta and sfraser's feedback
2.44 KB, patch
nhottanscp
: review+
sfraser_bugs
: superreview+
dbaron
: approval+
Details | Diff | Splinter Review
Build: 2002-02-28-08 Platform: OS X Expected Results: Messages should be sorted by subject What I got: Crash occurs Steps to reproduce: 1) Open Mail 2) Click on Subject column to sort messages 3) Crash occurs Stack trace from CrashReporter: Date/Time: 2002-02-28 12:45:21 -0800 OS Version: 10.1.3 (Build 5Q45) Host: localhost Command: Mozilla PID: 396 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000116e Thread 0 Crashed: #0 0x700033b8 in free_list_remove_ptr #1 0x70009094 in szone_calloc #2 0x70008de8 in malloc_zone_calloc #3 0x70008cfc in calloc #4 0x70243b48 in NewPtrClear #5 0x702549fc in NewHandleClear #6 0x702c4f40 in UCGetCollationKey #7 0x022d4990 in GetSortKeyLen__16nsCollationMacUCF19nsCollationStrengthRC9nsAS #8 0x04a33254 in nsMsgDatabase::CreateCollationKey(wchar_t const *, unsigned char **, unsigned int *) #9 0x04a3305c in nsMsgDatabase::RowCellColumnToCollationKey(nsIMdbRow *, unsigned int, unsigned char **) #10 0x04a3a558 in nsMsgHdr::GetSubjectCollationKey(unsigned char **, unsigned int *) #11 0x02ad71f8 in nsMsgDBView::GetCollationKey(nsIMsgHdr *, int, unsigned char **, unsigned int *) #12 0x02ad7a4c in 0x2ad7a4c #13 0x02ae213c in nsMsgThreadedDBView::Sort(int, int) #14 0x005bde1c in XPTC_InvokeByIndex #15 0x005bdd10 in XPTC_InvokeByIndex #16 0x01a81944 in 0x1a81944 #17 0x01a87e1c in XPC_WN_CallMethod(JSContext *, JSObject *, unsigned int, long *, long *) #18 0x01a0112c in js_Invoke #19 0x01a091fc in 0x1a091fc #20 0x01a01184 in js_Invoke #21 0x01a7af58 in 0x1a7af58 #22 0x01a771c4 in CallMethod__14nsXPCWrappedJSFUsPC15nsXPTMethodInfoP17nsXPTCMin #23 0x005be2ac in PrepareAndDispatch #24 0x005c229c in nsProcessConstructor(nsISupports *, nsID const &, void **) #25 0x01ee8600 in HandleEventSubType__22nsEventListenerManagerFP16nsListenerStru #26 0x01ee8d80 in 0x1ee8d80 #27 0x02112ec4 in HandleDOMEvent__12nsXULElementFP14nsIPresContextP7nsEventPP11n #28 0x02112dbc in HandleDOMEvent__12nsXULElementFP14nsIPresContextP7nsEventPP11 #29 0x02112dbc in HandleDOMEvent__12nsXULElementFP14nsIPresContextP7nsEventPP11 #30 0x027020b4 in HandleEventInternal__9PresShellFP7nsEventP7nsIViewUiP13nsEvent #31 0x02701f04 in HandleEventWithTarget__9PresShellFP7nsEventP8nsIFrameP10nsICon #32 0x01ef4b80 in CheckForAndDispatchClick__19nsEventStateManagerFP14nsIPresCont #33 0x01ef2ad0 in 0x1ef2ad0 #34 0x027021c0 in HandleEventInternal__9PresShellFP7nsEventP7nsIViewUiP13nsEvent #35 0x02701e18 in PresShell::HandleEvent(nsIView *, nsGUIEvent *, nsEventStatus *) #36 0x02987808 in nsViewManager::HandleEvent(nsView *, nsGUIEvent *, int) #37 0x0297d51c in nsView::HandleEvent(nsViewManager *, nsGUIEvent *, int) #38 0x02986b38 in 0x2986b38 #39 0x0297cba8 in HandleEvent(nsGUIEvent *) #40 0x023b8b34 in nsWindow::DispatchEvent(nsGUIEvent *, nsEventStatus &) #41 0x023b8c0c in nsWindow::DispatchWindowEvent(nsGUIEvent &) #42 0x023b8d58 in nsWindow::DispatchMouseEvent(nsMouseEvent &) #43 0x023cada8 in nsMacEventHandler::HandleMouseUpEvent(EventRecord &) #44 0x023c9154 in nsMacEventHandler::HandleOSEvent(EventRecord &) #45 0x023c8034 in nsMacWindow::DispatchEvent(void *, int *) #46 0x023cfc70 in DispatchOSEventToRaptor__16nsMacMessagePumpFR11EventRecordP15O #47 0x023cf730 in nsMacMessagePump::DoMouseUp(EventRecord &) #48 0x023cea5c in nsMacMessagePump::DispatchEvent(int, EventRecord *) #49 0x023ce720 in nsMacMessagePump::DoMessagePump(void) #50 0x023ce09c in nsAppShell::Run(void) #51 0x02382dfc in nsAppShellService::Run(void) #52 0x004cbba4 in main1(int, char **, nsISupports *) #53 0x004cc67c in main Thread 1: #0 0x7000497c in syscall #1 0x70557600 in BSD_waitevent #2 0x70554b80 in CarbonSelectThreadFunc #3 0x7002054c in _pthread_body Thread 2: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x705593ec in CarbonOperationThreadFunc #3 0x7002054c in _pthread_body Thread 3: #0 0x70044cf8 in semaphore_timedwait_signal_trap #1 0x70044cd8 in semaphore_timedwait_signal #2 0x70283ea4 in TSWaitOnConditionTimedRelative #3 0x7027d748 in TSWaitOnSemaphoreCommon #4 0x702c2078 in TimerThread #5 0x7002054c in _pthread_body Thread 4: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x70250ab0 in TSWaitOnCondition #3 0x7027d730 in TSWaitOnSemaphoreCommon #4 0x70243d14 in AsyncFileThread #5 0x7002054c in _pthread_body Thread 5: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x7055b884 in CarbonInetOperThreadFunc #3 0x7002054c in _pthread_body Thread 6: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x7017bf98 in __CFRunLoopRun #3 0x701b7100 in CFRunLoopRunSpecific #4 0x7017b8e0 in CFRunLoopRunInMode #5 0x7061be08 in XIOAudioDeviceManager::NotificationThread(XIOAudioDeviceManager *) #6 0x706141c0 in CAPThread::Entry(CAPThread *) #7 0x7002054c in _pthread_body Thread 7: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x70026a2c in _pthread_become_available #3 0x70026724 in pthread_exit #4 0x70020550 in _pthread_body PPC Thread State: srr0: 0x700033b8 srr1: 0x0200f030 vrsave: 0x00000000 xer: 0x00000020 lr: 0x700033a0 ctr: 0x70000d90 mq: 0x00000000 r0: 0x700033a0 r1: 0xbfffc450 r2: 0x7026db9c r3: 0x00000000 r4: 0x00000000 r5: 0x00000001 r6: 0x62726561 r7: 0x6b206174 r8: 0x20737a6f r9: 0x00000000 r10: 0x72726f72 r11: 0x80003704 r12: 0x70000d90 r13: 0x00000000 r14: 0x00000000 r15: 0x00000044 r16: 0x00000000 r17: 0x000e1ea8 r18: 0x02b208ec r19: 0xbfffc7b4 r20: 0x00000001 r21: 0x00000000 r22: 0x800013a4 r23: 0x800013a0 r24: 0x0004615c r25: 0x00046010 r26: 0x00005161 r27: 0x0000003f r28: 0x0435f1f0 r29: 0x00001166 r30: 0x0000110b r31: 0x70003344 **********
This doesn't occur under OS 9 (2002-02-28-08). Under the OS X, the crash occurs in either Classic or Modern theme.
QA Contact: esther → laurel
Apparently , this problem has been in the build for awhile. I can reproduce this crash on a older trunk build (2001-11-19-08). Also, the crash seems to be related to the number of inbox messages. Attinasi couldn't reproduce the crash at 1500 messages but I could at 1800+. When Mark increased his messages to 3000, he could reproduce the crash. The problem doesn't happen in 6.2.1.
Reassign to nhotta. It crashes in the API.
Assignee: sspitzer → nhotta
Keywords: crash
Status: NEW → ASSIGNED
Keywords: nsbeta1
Target Milestone: --- → mozilla1.0
I tried with 9000+ messages using my debug build but could not reproduce. It could be specific to a certain message. My test case contains bugzilla mails and some Japanese mail. I am going to try the trunk build.
i am able to reproduce this crash while sorting 3000 messages in a newsgroup on my Mac OSX system with 2002-02-28 build
to reproduce you may try de.test newsgroup, messages with accented chars in the header ( my locale is set to english)
I can only do this in news, not with any mail account even having several thousand messages. Only Subject seems to crash, whether going from Date to Subject sort or threaded to subject. Threaded to Date sort or other flat sort seems to be okay ... Used this newsgroup -- news://news.mozilla.org/netscape.public.mozilla.mail-news
I can reproduce the carsh with news://news.mozilla.org/netscape.public.mozilla.mail-news I am trying to identify the message at the crash. The debuger doesn't show me the local variables after the crash, so I am putting printf. It could be not specific to a message but number of messages.
crasher, nsbeta1+
Keywords: nsbeta1 → nsbeta1+
I copied two newsgroup to local and it also crashes as local mails. netscape.public.mozilla.mail-news netscape.public.mozilla.macosx I found it always crashes after loading our Korean converter. Those two newsgroups contain Korean messages. It stopped crashing after removing them. By moving the Korean messages into a separate folder then I don't see the crash with the Korean only folder. Need more investigatiion.
take the bug
Assignee: nhotta → ftang
Status: ASSIGNED → NEW
assign looks like a bug in UCGetCollationKey
Status: NEW → ASSIGNED
crash- p1
Priority: -- → P1
I think there are two way to work around this crash approach 1. do not use UCGetCollationKey, put the origional string as the key instead and use compare text to compare the string approach 2. detect the case of Korean string, estimate bigger length of key for it.
approach 1. - we need to know that the compare string does not call UCGetCollationKey. approach 2. - there might be more cases than Korean which cause the problem, we don't know. Other option is to use the MacOS 9 collator. I think the benefit of using the OS X collation is that it supports sorting with multiple languages mixed. Is there anything else we preffer the OS X collation?
according to apple, finder call compare text but not create key. so if the compare text have big problem, finder will crash.
When I try nhotta's test case in my debug build (see attachment ) I got the following before I crash ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 *** malloc[470]: error for object 0x4b0e510: Incorrect check sum for freed object - object was probably modified after beeing freed; break at szone_error when I crash , I crash hard inside the system.
If i run mallocdebug with mozilla, here is what I got after I click the subject and crash MallocDebug: target application trashed bytes after end of malloc buffer; buffer is at 0x4ddee50, and is of size 132 MallocDebug: target application trashed bytes after end of malloc buffer; buffer is at 0x4e64920, and is of size 148 MallocDebug: target application trashed bytes after end of malloc buffer; buffer is at 0x4e649bc, and is of size 148 MallocDebug: target application trashed bytes after end of malloc buffer; buffer is at 0x4e64884, and is of size 148 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 MallocDebug: target application trashed bytes after end of malloc buffer; buffer is at 0x36de3e0, and is of size 152 MallocDebug: target application trashed bytes after end of malloc buffer; buffer is at 0x42f4998, and is of size 152 MallocDebug: target application trashed bytes after end of malloc buffer; buffer is at 0x36de1cc, and is of size 152 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 MallocDebug: target application trashed bytes after end of malloc buffer; buffer is at 0x4dc15cc, and is of size 108 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 MallocDebug: Target application attempted to access memory at 0x00000018 with insufficient permissions. MallocDebug: MallocDebug can't do anything about this, so the app's just going to have to be terminated. MallocDebug: ************************************************* MallocDebug: THIS IS A BUG IN THE PROGRAM BEING RUN UNDER MALLOC DEBUG, MallocDebug: NOT A BUG IN MALLOC DEBUG! MallocDebug: *************************************************
mscott- somehow we hit the ###!!! ASSERTION: wow, big block: '0', file nsMsgDBView.cpp, line 2892 before crash, cc you so you know we did hit it. Still try to figure how which code "trashed bytes after end of malloc buffer"
here is what I got if I do the following 1. use LaunchCFMApp to launch the MozillDebug from MacOS X terminal LaunchCFMApp MozillaDebug 2. ps -x and find out the pid 3. gdb 4. in gdb, attach pid attach 454 5, cont in gdb cont 6. open the korean folder that nhotta attached in attachemnt 7. click on the subject header to sort in subject it crash in gdb with the follow Program received signal EXC_BAD_ACCESS, Could not access memory. 0x70004460 in szone_malloc () (gdb) bt #0 0x70004460 in szone_malloc () #1 0x700042c8 in malloc_zone_malloc () #2 0x70004204 in malloc () #3 0x70161634 in CFAllocatorAllocate () #4 0x70161440 in _CFRuntimeCreateInstance () #5 0x701662a4 in __CFArrayInit () #6 0x701664d8 in CFArrayCreateMutable () #7 0x7017b990 in __CFRunLoopDoObservers () #8 0x701b70e8 in CFRunLoopRunSpecific () #9 0x7017b8e0 in CFRunLoopRunInMode () #10 0x7312d8f4 in RunEventLoopInModeUntilEventArrives () #11 0x731c2bbc in RunEventLoopUntilEventArrives () #12 0x731a1340 in GetNextEventMatchingMask () #13 0x731232d0 in EventAvail () #14 0x0295f0cc in GetEvent__16nsMacMessagePumpFR11EventRecord () #15 0x0295ef10 in DoMessagePump__16nsMacMessagePumpFv () #16 0x0295e6f4 in Run__10nsAppShellFv () #17 0x028d9ea8 in Run__17nsAppShellServiceFv () #18 0x001eb154 in main1 () #19 0x001ed7f4 in main ()ing
here is what I got in gdb if I run the app without using LaunchCFMApp but double click on the Mozilla Program received signal EXC_BAD_ACCESS, Could not access memory. 0x7311c8cc in AVLFreeSubtree () (gdb) bt #0 0x7311c8cc in AVLFreeSubtree () #1 0x7311c8e4 in AVLFreeSubtree () #2 0x7311c90c in AVLFreeSubtree () #3 0x7311c90c in AVLFreeSubtree () #4 0x73111124 in ReleaseEvent () #5 0x73200054 in CoalesceMouseEvent () #6 0x7313b758 in ConvertPlatformEventRecordAndPost () #7 0x7314a814 in PullEventsFromWindowServer () #8 0x731631c4 in MessageHandler () #9 0x7018f508 in __CFMachPortPerform () #10 0x7018f3b0 in __CFRunLoopDoSource1 () #11 0x7017c1e0 in __CFRunLoopRun () #12 0x701b7100 in CFRunLoopRunSpecific () #13 0x7017b8e0 in CFRunLoopRunInMode () #14 0x7312d8f4 in RunEventLoopInModeUntilEventArrives () #15 0x731c2bbc in RunEventLoopUntilEventArrives () #16 0x731a144c in GetNextEventMatchingMask () #17 0x731ae408 in WNEInternal () #18 0x731c5508 in WaitNextEvent () #19 0x0296e1b0 in GetEvent__16nsMacMessagePumpFR11EventRecord () #20 0x0296df10 in DoMessagePump__16nsMacMessagePumpFv () #21 0x0296d6f4 in Run__10nsAppShellFv () #22 0x028e8ea8 in Run__17nsAppShellServiceFv () #23 0x001ac154 in main1__FiPPcP11nsISupports () #24 0x001ae7f4 in main ()
try agin as last one Program received signal EXC_BAD_ACCESS, Could not access memory. 0x70162f2c in CFRelease () (gdb) bg Undefined command: "bg". Try "help". (gdb) bt #0 0x70162f2c in CFRelease () #1 0x7016f27c in CFDictionaryRemoveAllValues () #2 0x7016f04c in __CFDictionaryDeallocate () #3 0x70162fcc in CFRelease () #4 0x70493efc in IOCFUnserialize () #5 0x704950ac in IORegistryEntryCreateCFProperties () #6 0x704a3d5c in IOHIDGetParameter () #7 0x704a4254 in NXClickTime () #8 0x731675b0 in GetDblTime () #9 0x029295d4 in ConvertOSEventToMouseEvent__17nsMacEventHandlerFR11EventRecor dR12nsMouseEventUi () #10 0x02928dd8 in HandleMouseDownEvent__17nsMacEventHandlerFR11EventRecord () #11 0x02926ee0 in HandleOSEvent__17nsMacEventHandlerFR11EventRecord () #12 0x02925108 in DispatchEvent__11nsMacWindowFPvPi () #13 0x0292ffa0 in DispatchOSEventToRaptor__16nsMacMessagePumpFR11EventRecord P15OpaqueWindowPtr () #14 0x0292e8f0 in DoMouseDown__16nsMacMessagePumpFR11EventRecord () #15 0x0292e2d0 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord () #16 0x0292df28 in DoMessagePump__16nsMacMessagePumpFv () #17 0x0292d6f4 in Run__10nsAppShellFv () #18 0x028a8ea8 in Run__17nsAppShellServiceFv () #19 0x004d1154 in main1__FiPPcP11nsISupports () #20 0x004d37f4 in main ()
Whiteboard: adt1
If I force the mozilla code not to cache the result, then I got a better stack trace- #0 0x700033b8 in free_list_remove_ptr () #1 0x70009094 in szone_calloc () #2 0x70008de8 in malloc_zone_calloc () #3 0x70008cfc in calloc () #4 0x70243b48 in NewPtrClear () #5 0x702549fc in NewHandleClear () #6 0x702c4f40 in UCGetCollationKey () #7 0x01ec2838 in CreateRawSortKey__16nsCollationMacUCF19nsCollationStrengthRC9n sAStringPUcPUi () #8 0x05061a98 in CreateCollationKey__13nsMsgDatabaseFPCwPPUcPUi () #9 0x050616f0 in RowCellColumnToCollationKey__13nsMsgDatabaseFP9nsIMdbRowUiP PUcPUi () #10 0x0506daf8 in GetSubjectCollationKey__8nsMsgHdrFPPUcPUi () #11 0x0401c874 in GetCollationKey__11nsMsgDBViewFP9nsIMsgHdriPPUcPUi () #12 0x0401da00 in Sort__11nsMsgDBViewFii () #13 0x0402edc8 in Sort__19nsMsgThreadedDBViewFii () #14 0x006535dc in _XPTC_InvokeByIndex () #15 0x006534d0 in XPTC_InvokeByIndex () #16 0x01c6609c in ?? () #17 0x01c7102c in ?? () #18 0x01ba83ac in js_Invoke () #19 0x01bb7420 in js_Interpret () #20 0x01ba8420 in js_Invoke () #21 0x01c59d28 in ?? () #22 0x01c54338 in ?? () #23 0x00653c0c in PrepareAndDispatch () #24 0x00657d38 in __traceback_Sentinel4__14nsXPTCStubBaseFv () #25 0x02217868 in HandleEventSubType__22nsEventListenerManagerFP16nsListenerStruct P11nsIDOMEventP17nsIDOMEventTargetUiUi () #26 0x02218490 in HandleEvent__22nsEventListenerManagerFP14nsIPresContextP7nsEve ntPP11nsIDOMEventP17nsIDOMEventTargetUiP13nsEventStatus () #27 0x025a18e8 in HandleDOMEvent__12nsXULElementFP14nsIPresContextP7nsEventPP 11nsIDOMEventUiP13nsEventStatus () #28 0x025a174c in HandleDOMEvent__12nsXULElementFP14nsIPresContextP7nsEventPP 11nsIDOMEventUiP13nsEventStatus () #29 0x025a174c in HandleDOMEvent__12nsXULElementFP14nsIPresContextP7nsEventPP 11nsIDOMEventUiP13nsEventStatus () #30 0x02d742b8 in HandleEventInternal__9PresShellFP7nsEventP7nsIViewUiP13nsEventSt atus () #31 0x02d740d0 in HandleEventWithTarget__9PresShellFP7nsEventP8nsIFrameP10nsICon tentUiP13nsEventStatus () #32 0x02230a84 in CheckForAndDispatchClick__19nsEventStateManagerFP14nsIPresCont extP12nsMouseEventP13nsEventStatus () #33 0x0222d2b0 in PostHandleEvent__19nsEventStateManagerFP14nsIPresContextP7nsEv entP8nsIFrameP13nsEventStatusP7nsIView () #34 0x02d743c4 in HandleEventInternal__9PresShellFP7nsEventP7nsIViewUiP13nsEventSt atus () #35 0x02d73da0 in HandleEvent__9PresShellFP7nsIViewP10nsGUIEventP13nsEventStatusi Ri () #36 0x031b507c in HandleEvent__13nsViewManagerFP6nsViewP10nsGUIEventi () #37 0x031a6980 in HandleEvent__6nsViewFP13nsViewManagerP10nsGUIEventi () #38 0x031b3e9c in DispatchEvent__13nsViewManagerFP10nsGUIEventP13nsEventStatus () #39 0x031a5b78 in HandleEvent__FP10nsGUIEvent () #40 0x029097a8 in DispatchEvent__8nsWindowFP10nsGUIEventR13nsEventStatus () #41 0x029098ac in DispatchWindowEvent__8nsWindowFR10nsGUIEvent () #42 0x02909a3c in DispatchMouseEvent__8nsWindowFR12nsMouseEvent () #43 0x029232cc in HandleMouseUpEvent__17nsMacEventHandlerFR11EventRecord () #44 0x02920f00 in HandleOSEvent__17nsMacEventHandlerFR11EventRecord () #45 0x0291f108 in DispatchEvent__11nsMacWindowFPvPi () #46 0x02929fa0 in DispatchOSEventToRaptor__16nsMacMessagePumpFR11EventRecord P15OpaqueWindowPtr () #47 0x029297f8 in DoMouseUp__16nsMacMessagePumpFR11EventRecord () #48 0x029282e4 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord () #49 0x02927f28 in DoMessagePump__16nsMacMessagePumpFv () #50 0x029276f4 in Run__10nsAppShellFv () #51 0x028a2ea8 in Run__17nsAppShellServiceFv () #52 0x001ac154 in main1__FiPPcP11nsISupports () #53 0x001ae7f4 in main ()
OK, I surrender, the crash is deep inside MacOS X and I cannot find any work around which won't crash these API with the attacehd Koean text. Let's take the MacOS 9 approach.
nhotta, please r= this .
ok, the current patch fix the crash by not using our MacOS X collation code which added after m94. The MacOS X crash in such code and we cannot find a good enough work around which won't crash it. Therefore, we decide to back up to the MacOS 9 implementation. The patch simply remove the #if TARGET_CARBON in the locale module.
Frank, could you include the memcmp length bug you fixed? http://lxr.mozilla.org/seamonkey/source/intl/locale/src/mac/nsCollationMacUC.cpp#229
Instead of just commenting out all the #ifdefs, how about making a BROKEN_UCOLLATIONKEY #define, so that we'll remember to flip it back once the OS bug is fixed?
I think we can fix this today.
Attachment #75717 - Attachment is obsolete: true
nhotta, can you r= this? sfraser, can you sr this ?
Blocks: 104148
Comment on attachment 76233 [details] [diff] [review] refine patch to address both nhotta and sfraser's feedback sr=sfraser
Attachment #76233 - Flags: superreview+
Comment on attachment 76233 [details] [diff] [review] refine patch to address both nhotta and sfraser's feedback r=nhotta please fix typo, "it is brokeon on MacOS X"
Attachment #76233 - Flags: review+
Blocks: 104060
No longer blocks: 104148
Comment on attachment 76233 [details] [diff] [review] refine patch to address both nhotta and sfraser's feedback a=dbaron for trunk checkin
Attachment #76233 - Flags: approval+
fixed and check in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Working OK for me using mar28 commercial trunk build: mac OS 10.1 If anyone finds this fix isn't working, they can reopen.
Status: RESOLVED → VERIFIED
*** Bug 134378 has been marked as a duplicate of this bug. ***
Using the attached test case, http://bugzilla.mozilla.org/attachment.cgi?id=72859&action=view it does not crash on MacOS 10.2. Looks like ::UCGetCollationKey can now be called with pre-composed Korean characters. We may enable the code conditionally for 10.2.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: