Closed Bug 591143 Opened 14 years ago Closed 13 years ago

Mac Crash [@ UCGetCollationKey] sorting long subject, [@ uprv_uca_getRawFromImplicit], [@ tiny_malloc_from_free_list | szone_malloc], [@ szone_free | free | ucol_setVariableTop], [@ libicucore.A.dylib@0xc43aa]

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(blocking1.9.2 needed, status1.9.2 .13-fixed, blocking-thunderbird3.1 needed, thunderbird3.1 .7-fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking1.9.2 --- needed
status1.9.2 --- .13-fixed
blocking-thunderbird3.1 --- needed
thunderbird3.1 --- .7-fixed

People

(Reporter: dvdmgsr, Assigned: Bienvenu)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: crash, topcrash, verified1.9.2, Whiteboard: [sg:vector-critical?][gs][workaround: comment 64][fixed in OS/X 10.6.8])

Crash Data

Attachments

(5 files)

Thunderbird Crash Report for Bug 591143
42.46 KB, text/plain
Details
Message that caused me not to be able to sort by subject or sender
128.74 KB, text/rtf
Details
Email message that causes crashes.
52.80 KB, text/plain
Details
Gdb trace of "crash" on OS X 10.6, in comm-1.9.2 code
9.27 KB, text/plain
Details
possible workaround
572 bytes, patch
jaas
: review+
beltzner
: approval2.0+
christian
: approval1.9.2.13+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-us) AppleWebKit/533.17.8 (KHTML, like Gecko) Version/5.0.1 Safari/533.17.8
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

The software crashes every time I try to sort by Subject or From in the Inbox.

Reproducible: Always

Steps to Reproduce:
1.Start Thunderbird
2.Go to Inbox
3.Hit the top of the Subject or From column to sort.
Actual Results:  
Crash.

Expected Results:  
Sorted the column.
and, did you just update from v2? or were you running some v3.x flavor?
This is the report my Mac gives me after Thunderbird crashes.
Hi Wayne --  Thanks!  I attached the report my Mac gives me after Thunderbird crashes.  The only crash report I see when I hit the link below is something from March 2010.

(In reply to comment #1)
> David, do you get a crash report id ? 
> 
> https://support.mozillamessaging.com/en-US/kb/Mozilla+Crash+Reporter#Viewing_crash_reports
I recently updated from a previous version of 3.0 to 3.1.  I've got 3.1.2.

If going back to a previous version will solve the problem, I'm happy to do that, if I can figure out how.

Thanks!

(In reply to comment #2)
> and, did you just update from v2? or were you running some v3.x flavor?
Hugh this looks like a crash in the memory handling routine. Can you try to start Thunderbird in -safe-mode  http://support.mozillamessaging.com/en-US/kb/Safe+Mode ?
I started Thunderbird while holding the Option key  (which looks exactly like it does in normal mode, so I guess I'm not sure I was in safe mode), and the problem persists.

Thanks!
This looks like a crash in the Carbon code 

see UCGetCollationKey
David, if you want to send me your Inbox.msf file, I can try to reproduce the crash here, to see which message its crashing on. Inbox.msf will have the senders and subjects of the mail in your inbox, but not the message contents.

I don't think our sort code has changed, but maybe the collation routines underneath have changed...
Thanks, David.  I sent it to the reply-to email in your message.  Let me know if you need it attached here.

I really appreciate this.
Windows trunk build and 3.1.2 are both fine with sorting that data, but I'd be willing to bet that the crash has to do with the messages that appear at the end when I sort by sender. I'll try it on the mac now.
It does crash on the mac, when I sort by subject, but not by sender. I'll try to narrow down the crashing message(s). Unfortunately, the crash seems to corrupt the stack as well so I can't get a stack trace when I crash.
marking security sensitive while I continue my investigation
Group: core-security
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I've figured out which message caused this issue, and I'm pretty sure the issue is in ::UCGetCollationKey, which I believe is a MacOS function.
Assignee: nobody → bienvenu
That's it!  I removed the message and now I can sort by subject or sender.  The message is in Russian or some language that uses cyrillic characters.  I've attached it here.  Thanks for all of your help.
Josh, do we have a contact at Apple to report this crash to? It's a crash in ::UCGetCollationKey. We're passing in a 155 char string, with a 4K output buffer, and asking for the collation key. I'll try to get the exact string we're passing in.
The subject is something like the following, which seems fairly innocuous, even if it's long:

IV INTERNATIONAL SCIENTIFIC - PRACTICAL CONFERENCE "GEOPOLITICS, GEOECONOMICS AND INTERNATIONAL RELATIONS PROBLEMS" 22-23 June\n 2010, St. Petersburg, Russia
perhaps the \n is causing grief...I can try to remove it and see if the problem goes away.
OS: Mac OS X → Windows XP
Summary: Crash every time I try to sort by Subject or From in the Inbox → Crash [@ UCGetCollationKey] sorting inbox if a message subject contains a line break
Is this an exploitable crash, or something safe like a null deref?

I suppose at the very least it's terrible that you could potentially spam out a DoS-ing mail message and knock lots of thunderbird users out of commission.
It confuses gdb when it crashes, which makes me believe that it the stack has been crunched.
But, since I can't see the code for the OS/X function, I can't say definitively how exploitable it is. But it's not a null deref.
David Geiser:  Please save your "bad message" in *.eml format and
attach it here.  "Save As" should do the trick.  I need a format that
I can "open" in Thunderbird.

David Bienvenu:  I assume that the following steps are enough to
reproduce the crash:

1) Open the "bad message" in Thunderbird.

2) Copy it to a mailbox, then try to sort it.

Is this correct?
Steven, not quite, since we don't implement move/copy from a .eml file. So, you would take the .eml file, add a line starting with "From " at the top to make it a Berkeley mailbox, move the resulting file into the Local Folders dir of your user profile, restart TB, select the folder corresponding to the .eml file in the Local Folders account, then copy another message into the .eml file folder, and then try sorting.

Or, if I get a chance, I could create a simple test folder that reproduces the crash and attach it here.
Here is the offending message.  Let me know if this does not work for you.
> Here is the offending message.  Let me know if this does not work
> for you.

It does ... though only on OS X 10.6.X (I don't crash on (OS X
10.5.8).

Which tends to confirm that this is an OS bug.

Thanks!

Crash Reporter doesn't appear when I crash.  So I'll need to do an opt
build with debug symbols, so that I can get an accurate crash stack
from gdb.  (Gdb stacks for standard distros are useless, since they
have their debug symbols stripped.)

And thank-you, David Bienvenu, for your advice in comment #24 -- it
worked perfectly.
Steven, glad you were able to reproduce this. I'm not sure you'll get a stack trace from gdb - I didn't get one with my full debug build with symbols, because I think the OS/X code crunched the stack somewhat.

I'm crashing on OS/X 10.5.8, which is unfortunate, if the bug still occurs on 10.6.
I tend to update my system software usually within a few days after new versions are released, and Thunderbird as well.  The problem did not show until the most recent Thunderbird update, but that message is months old, so it's been there through several OS and Thunderbird versions without causing any problems I noticed.
If this is related to these crashes
 uprv_uca_getRawFromImplicit
 tiny_malloc_from_free_list | szone_malloc
 libicucore.A.dylib@0xc43aa
 szone_free | free | ucol_setVariableTop
 ucol_setVariableTop
 szone_free | free | libicucore.A.dylib@0xcb74e
 szone_free | szone_realloc
 szone_realloc
 ucol_isTailored

and if it's not strictly tied to a Mac version, then I think we can safely call this a regression. All the above crashes are v3.1 only. And many crash comments say this happened when the user updated to v3.1.x (mostly 3.1.2)

I only looked at the first signature [@ uprv_uca_getRawFromImplicit ]  ranks #7 in Mac-only crashes for v3.1.2
bp-1990abef-70d1-4c3f-b631-3d2c72100825 "Clicked on the Sort by Date field in a large gmail imap folder. Hey Gerv! Congrats!"
0		@0xffff0f32	
1	libicucore.A.dylib	uprv_uca_getRawFromImplicit	
2	libicucore.A.dylib	ucol_setVariableTop	
3	libicucore.A.dylib	ucol_getSortKey	
4	CarbonCore	UCGetCollationKey	
5	thunderbird-bin	nsCollationMacUC::AllocateRawSortKey	intl/locale/src/mac/nsCollationMacUC.cpp:176
6	thunderbird-bin	nsMsgDatabase::CreateCollationKey	mailnews/db/msgdb/src/nsMsgDatabase.cpp:3522
7	thunderbird-bin	nsMsgDatabase::RowCellColumnToCollationKey	mailnews/db/msgdb/src/nsMsgDatabase.cpp:3497
8	thunderbird-bin	nsMsgHdr::GetSubjectCollationKey	mailnews/db/msgdb/src/nsMsgHdr.cpp:743
9	thunderbird-bin	nsMsgDBView::GetCollationKey	mailnews/base/src/nsMsgDBView.cpp:3910
10	thunderbird-bin	nsMsgDBView::GetInsertIndexHelper	mailnews/base/src/nsMsgDBView.cpp:5008
11	thunderbird-bin	nsMsgDBView::GetInsertIndex	mailnews/base/src/nsMsgDBView.cpp:5052
12	thunderbird-bin	nsMsgDBView::AddHdr	mailnews/base/src/nsMsgDBView.cpp:5092
13	thunderbird-bin	nsMsgThreadedDBView::OnNewHeader	mailnews/base/src/nsMsgThreadedDBView.cpp:613
14	thunderbird-bin	nsMsgDatabase::NotifyHdrAddedAll	mailnews/db/msgdb/src/nsMsgDatabase.cpp:736
15	thunderbird-bin	nsMsgDatabase::AddNewHdrToDB	mailnews/db/msgdb/src/nsMsgDatabase.cpp:3281
16	thunderbird-bin	nsImapMailDatabase::AddNewHdrToDB	mailnews/db/msgdb/src/nsImapMailDatabase.cpp:154 

these two crashes have english speaking reporters:
bp-eb95ae74-3a09-4b83-a9ad-a2bd02100817 "crashed when asked to sort by subject" (gstearns)
bp-6231b0ae-4e30-447f-82a9-42b962100809 opening newsgroup fails (bob)
p.s. Mac versions:
Mac OS X 10.5.6 9G55
Mac OS X 10.5.7 9J61
Mac OS X 10.5.8 9L30
I haven't built comm-1.9.2 in a long time, and my current setup no
longer works.  I get the following error while configure is running:

configure: error: Your compiler does not follow the C++
  specification for temporary object destruction order.

Can anyone tell me what's up?  (I'm building on OS X 10.5.8.)
What version of Gcc is set to default on your system ?
> What version of Gcc is set to default on your system?

It's gcc-4.0.  But the build process has used gcc-4.2 (and g++-4.2)
for months now, and did when I built comm-1.9.2.  So (presumably)
that's not the problem.

My comm-1.9.2 repo might have gotten corrupted (when I updated just
now, for the first time ever I had to deal with merge conflicts by
hand).  I'm re-cloning and will try again.
This crash happens with trunk builds as well, so you don't need to build with 1.9.2 to see the issue.
ludo asked me a fair question 
a) why this might be a v3.1 regression - IMO if the OS changed, and exposes a problem in version B, but didn't in version A, then it's probably not unkind nor inaccurate to say there is a regression in version B - if nothing else, (to my way of thinking) it is a regression in the *user's* eyes and fair game in bugzilla
b) why I think comment 29 crashes are the same issue. I'm not asserting they are, because I didn't thoroughly check the stacks. But I think the odds are good they are the same issue because:

* all have nsCollationMacUC::AllocateRawSortKey in the top 10 frames of the stack, in fact very near the top [1]
* David didn't see crash prior to v3.1
* the stacks I provided at least partially match (but anyone is welcome to check them in more detail than I did) and didn't start until v3.1
* crash comments that I quoted indicate collation issue is involved

all too much coincidence to not consider these might be the same issue. On the other hand, one can't rule out a v3.1 regression for some of these.


[1] libicucore.A.dylib@0xc43aa example bp-ac73b87c-f6c3-4bdc-bc0f-9931e2100901
0		@0xffff0959	
1	libicucore.A.dylib	libicucore.A.dylib@0xc43aa	
2	libicucore.A.dylib	libicucore.A.dylib@0xcaf99	
3	libicucore.A.dylib	libicucore.A.dylib@0xc45ed	
4	CarbonCore	UCGetCollationKey	
5	thunderbird-bin	nsCollationMacUC::AllocateRawSortKey	intl/locale/src/mac/nsCollationMacUC.cpp:176
6	thunderbird-bin	nsMsgDatabase::CreateCollationKey	mailnews/db/msgdb/src/nsMsgDatabase.cpp:3522
7	thunderbird-bin	nsMsgDatabase::RowCellColumnToCollationKey	mailnews/db/msgdb/src/nsMsgDatabase.cpp:3497
8	thunderbird-bin	nsMsgHdr::GetSubjectCollationKey	mailnews/db/msgdb/src/nsMsgHdr.cpp:743
9	thunderbird-bin	nsMsgDBView::GetCollationKey	mailnews/base/src/nsMsgDBView.cpp:3910
10	thunderbird-bin	nsMsgDBView::Sort	mailnews/base/src/nsMsgDBView.cpp:4221
11	thunderbird-bin	nsMsgThreadedDBView::Sort	mailnews/base/src/nsMsgThreadedDBView.cpp:387
Here's a gdb stack trace of the crash on OS X 10.6, in current
comm-1.9.2 code.  (I had no problem building it after I recloned it --
I suspect some autoconf files in my old build hadn't been properly
updated.)

Note that this isn't a conventional crash, or even a crash at all.
Instead, something in OS code actually kills (aborts) the process.
That explains why Crash Reporter doesn't appear.

Once again I didn't crash at all on OS X 10.5.8.

This is almost certainly an OS bug.  But it might be possible to work
around it by massaging the input to :UCGetCollationKey().  It'll need
to be someone else who figures that out, though :-)
Blocks: 593132
Whiteboard: [sg:critical?]
Attachment #471152 - Attachment mime type: message/rfc822 → text/plain
I hadn't confirmed that a linebreak was the issue, and I don't think it is. I saw one in the .msf file, but it wasn't in the string that got passed to the mac collation method. In fact, I can fix the crash by change the case of the last uppercase word, i.e., if PROBLEMS" is changed to problems", the crash goes away. My suspicion is that the mac collation method DOES NOT LIKE LONG STRINGS THAT ARE ALL UPPERCASE, though that's just a guess. I tried removing the quotes from the string, and that didn't help. I think we really need to get in contact with someone in that group at Apple to make progress here.
Summary: Crash [@ UCGetCollationKey] sorting inbox if a message subject contains a line break → Crash [@ UCGetCollationKey] sorting long subject
I've filed a bug with Apple - Problem ID: 8453081  I marked it a security sensitive bug so perhaps it will get some attention.
bp-1df00333-70f6-40c9-bbc7-5c20b2100922 reporter is http://gsfn.us/t/1hd6m with crash sig @ tiny_malloc_from_free_list | szone_malloc (#163 crash for v3.1.4)

more signatures:
uprv_uca_getRawFromImplicit bp-aac9c09e-306b-4137-acec-800c92100920 #39 for v3.1.4
szone_free | free | ucol_setVariableTop bp-3bdb89d1-e29d-4cb4-a14f-341a52100920

crashes with reporter addresses:
bp-58e556d3-9a9e-4b8f-9d6e-2e9212100919
bp-e0cd7c01-263b-40a3-bbef-4c8162100918
bp-9ec7efd4-34da-4c48-bc6b-c5b012100919
selected comments:
Cannot start thunderbird. It crashes immediately as it comes up....
Follow up to previous report: I also tried using Disk Utility to repair disk permissions. Some permissions were fixed but it did not help the problem. TB 3.1.4 still crashes on startup.
Crashes when I attempt to view my "Inbox"
I need to be able to get to my read emails, but can't! This is a serious deadline problem! [plus a phone number :)]

aggregating the numbers, this is easily a topcrash.
do we need a workaround process or patch?
or is Apple likely to come through quickly?
URL: http://getsatisfaction.com/mozilla_me...
blocking-thunderbird3.1: --- → ?
Keywords: topcrash
Summary: Crash [@ UCGetCollationKey] sorting long subject → Crash [@ UCGetCollationKey] sorting long subject [@ uprv_uca_getRawFromImplicit]
Whiteboard: [sg:critical?] → [sg:critical?][gs]
Apple won't do anything until I write a test program that shows the crash. Presumably they think this is a bug in Thunderbird. I don't know when I'll be able to get to that. Even if I do, I'm not sure they'll explain how to work around the crash. The joys of closed source!
We don't think there's anything we can fix here, waiting for Apple to fix. Changing to [sg:vector]
Whiteboard: [sg:critical?][gs] → [sg:vector-critical?][gs]
Blocks: 597878
changing kCollationValueSizeFactor to 6 from 5 does fix the test case I have, so that might be a workaround. The API takes an output buffer length so we shouldn't need to do this, but perhaps the error handling in the case of too small a buffer is broken.

http://mxr.mozilla.org/comm-central/source/mozilla/intl/locale/src/mac/nsCollationMacUC.h#51
Attached patch possible workaround — — Splinter Review 
this is a wildly popular crash for Thunderbird on OS/X, and once it happens, it's very hard for users to recover and use the app.
Attachment #481523 - Flags: review?(joshmoz)
Attachment #481523 - Flags: review?(joshmoz) → review+
Comment on attachment 481523 [details] [diff] [review]
possible workaround

we'd like this for Thunderbird, ideally for a 3.1.6 release, but I think the first step would be landing on the trunk.
Attachment #481523 - Flags: approval2.0?
Attachment #481523 - Flags: approval1.9.2.11?
to summarize the topcrash picture, in follow up to comment 29 and comment 42, 
aggregating 4 crash sigs below makes this at least a top 9 crash. There are likely more than a dozen signatures. And, this may be a bold statement, but once  CFHash / bug 548480 is shipped, I'd be very much surprised if the numbers didn't go up by at least 20%.

uprv_uca_getRawFromImplicit
szone_free | free | ucol_setVariableTop
tiny_malloc_from_free_list | szone_malloc
libicucore.A.dylib@0xc43aa
(In reply to comment #52)

> szone_free | free | ucol_setVariableTop
> tiny_malloc_from_free_list | szone_malloc

Note: these two seem to have a mixture of crashes related to this one, and to others.
Comment on attachment 481523 [details] [diff] [review]
possible workaround

I assume this missed Tbird 3.1.5 which is based on 1.9.2.11, so moving the request to the next build.

Is this a problem in Tbird 3.0 that can be fixed with the same patch?
Attachment #481523 - Flags: approval1.9.2.11? → approval1.9.2.12?
(In reply to comment #54)

> I assume this missed Tbird 3.1.5 which is based on 1.9.2.11, so moving the
> request to the next build.
thx.
> 
> Is this a problem in Tbird 3.0 that can be fixed with the same patch?

I don't think so - from the TB P.O.V., this is a regression from bug 488320, which I don't think is in mozilla 1.9.1.
We'll approve this once it has landed on trunk and baked a bit and if it is indeed marked as a TB blocker (as it looks like it will be). Please renominate when those two conditions are met.
Attachment #481523 - Flags: approval1.9.2.12?
Component: Mail Window Front End → Backend
Product: Thunderbird → MailNews Core
QA Contact: front-end → backend
blocking-thunderbird3.1: ? → .6+
Attachment #481523 - Flags: approval2.0? → approval2.0+
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
http://hg.mozilla.org/mozilla-central/rev/4723b22a829b in case people ever need to find it
OS: Windows XP → All
OS: All → Mac OS X
Comment on attachment 481523 [details] [diff] [review]
possible workaround

requesting 1.9.12 approval - the fix just allocates a 20% bigger buffer to pass to the OS/X collation routine, which seems to prevent it from crashing.
Attachment #481523 - Flags: approval1.9.2.12?
Comment on attachment 481523 [details] [diff] [review]
possible workaround

a=LegNeato for 1.9.2.12. Please land on mozilla-1.9.2 default.
Attachment #481523 - Flags: approval1.9.2.12? → approval1.9.2.12+
blocking1.9.2: --- → .12+
fixed in 1.9.2 - changeset:   34685:06e767ce03fa
status1.9.2: wanted → .12-fixed
status-thunderbird3.1: --- → .6-fixed
User workarounds until TB 3.1.7 ships:
1. don't sort on subject
2. if you crash on startup, delete the .msf file from the account's profile directory for the message folder that is sorted by subject and was last open in the 3-pane UI, or the stand-alone message window (often this is the inbox, junk or trash folder)
 - account directory is in profile's Mail\Local Folders or ImapMail directory
 - instructions to find profile: http://support.mozillamessaging.com/en-US/kb/Profiles
3. run 3.1.7pre from ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-1.9.2/


(In reply to comment #53)
> > szone_free | free | ucol_setVariableTop
> > tiny_malloc_from_free_list | szone_malloc
> 
> Note: these two seem to have a mixture of crashes related to this one, and to
> others.

indeed there is mixture, but all the startup crashes I checked of tiny_malloc_from_free_list | szone_malloc appear likely to be this bug
Summary: Crash [@ UCGetCollationKey] sorting long subject [@ uprv_uca_getRawFromImplicit] → Mac Crash [@ UCGetCollationKey] sorting long subject, [@ uprv_uca_getRawFromImplicit], [@ tiny_malloc_from_free_list | szone_malloc], [@ szone_free | free | ucol_setVariableTop], [@ libicucore.A.dylib@0xc43aa]
Whiteboard: [sg:vector-critical?][gs] → [sg:vector-critical?][gs][workaround: comment 64]
What are the repro steps here for 1.9.2 verification? Opening the attached .eml doesn't do it as you cannot sort it at that point.
Keywords: verified1.9.2
Whiteboard: [sg:vector-critical?][gs][workaround: comment 64] → [sg:vector-critical?][gs][workaround: comment 64][qa-needs-STR]
(In reply to comment #65)
> What are the repro steps here for 1.9.2 verification? Opening the attached .eml
> doesn't do it as you cannot sort it at that point.

Al, see comment #24
Yes, I read that. As it turns out, I have to sort by subject specifically. Sorting on other fields does nothing. 

When I do so, I get a crash in TB 3.1.6.

Unfortunately, I *also* get a crash in last night's TB build: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13pre) Gecko/20101118 Lanikai/3.1.7pre.

The only crash data I get is from OS X. See http://mozilla.pastebin.com/MPGX1X4i for it.

This doesn't look fixed.
status1.9.2: .13-fixed → ?
what about trunk Thunderbird builds? I may have only tried the fix in debug builds; I don't remember for sure...the change is definitely in mozilla-1.9.2
Well, whether or not it works in trunk, I gave the build ID of what I tried with, which is current 1.9.2.
I tried this with 10.6, which I just installed, and it crashed. I'm pretty sure this worked with 10.5.8, but I no longer have that OS. We may just be stuck waiting for Apple to fix the crash.
status1.9.2: .13-fixed → ?
Moving blocking to next release, hopefully we'll figure it out then.
blocking1.9.2: .13+ → .14+
status-thunderbird3.1: .7-fixed → ?
blocking-thunderbird3.1: .7+ → .8+
David, I'm hoping we can assume you are on the right track. What do you think about doing a try server build with a different (less conservative) size factor for luca to test?
(In reply to comment #73)
> David, I'm hoping we can assume you are on the right track. What do you think
> about doing a try server build with a different (less conservative) size factor
> for luca to test?

I tried changing the allocation size to 7x the source buffer and it didn't help. I don't know what to think at this point, and I haven't heard a peep from the Apple folks, but I suspect they're going to need to fix the issue. I could try allocating a 7x buffer but telling the OS/X call the length is only 6x, but I doubt that will help.
not fully fixed, so reopening to avoid confusion
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Update from Apple - they've recreated the crash, in 32 bit mode. So there's some progress on that front. I've asked for any info they can give about fixing the crash on our end, but haven't heard back yet.
Moving to needed from blocking a specific release as this is currently depending on Apple.
blocking-thunderbird3.1: .8+ → needed
blocking1.9.2: .14+ → needed
status1.9.2: ? → wanted
Whiteboard: [sg:vector-critical?][gs][workaround: comment 64][qa-needs-STR] → [sg:vector-critical?][gs][workaround: comment 64][qa-needs-STR][approved-patches-landed]
there seems to be some movement on the Apple side for fixing this bug, so it's possible that it will be fixed in an upcoming security release.
Crash Signature: [@ UCGetCollationKey] [@ uprv_uca_getRawFromImplicit] [@ tiny_malloc_from_free_list | szone_malloc] [@ szone_free | free | ucol_setVariableTop] [@ libicucore.A.dylib@0xc43aa]
fixed by updgrading to os/x 10.6.8
Status: REOPENED → RESOLVED
Crash Signature: [@ UCGetCollationKey] [@ uprv_uca_getRawFromImplicit] [@ tiny_malloc_from_free_list | szone_malloc] [@ szone_free | free | ucol_setVariableTop] [@ libicucore.A.dylib@0xc43aa] → [@ UCGetCollationKey] [@ uprv_uca_getRawFromImplicit] [@ tiny_malloc_from_free_list | szone_malloc] [@ szone_free | free | ucol_setVariableTop] [@ libicucore.A.dylib@0xc43aa]
Closed: 14 years ago → 13 years ago
Resolution: --- → FIXED
Whiteboard: [sg:vector-critical?][gs][workaround: comment 64][qa-needs-STR][approved-patches-landed] → [sg:vector-critical?][gs][workaround: comment 64][fixed in OS/X 10.6.8]
Do we need to keep this closed ?
It's not exactly our security vulnerability (i.e., I don't know what other apps it can be exploited in), so I'm not sure what our policy on opening it up is.
Just to clean up the queries I'll set it back to 1.9.2.13-fixed to represent our patch being checked. Although that didn't fully fix the problem, the end result of the Apple update means it's fixed.
Group: core-security
status1.9.2: wanted → .13-fixed
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: