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)
Tracking
(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, )
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)
42.46 KB,
text/plain
|
Details | |
128.74 KB,
text/rtf
|
Details | |
52.80 KB,
text/plain
|
Details | |
9.27 KB,
text/plain
|
Details | |
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.
Comment 1•14 years ago
|
||
David, do you get a crash report id ? https://support.mozillamessaging.com/en-US/kb/Mozilla+Crash+Reporter#Viewing_crash_reports
Keywords: crash
Comment 2•14 years ago
|
||
and, did you just update from v2? or were you running some v3.x flavor?
Reporter | ||
Comment 3•14 years ago
|
||
This is the report my Mac gives me after Thunderbird crashes.
Reporter | ||
Comment 4•14 years ago
|
||
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
Reporter | ||
Comment 5•14 years ago
|
||
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?
Comment 6•14 years ago
|
||
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 ?
Reporter | ||
Comment 7•14 years ago
|
||
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!
Assignee | ||
Comment 8•14 years ago
|
||
This looks like a crash in the Carbon code see UCGetCollationKey
Assignee | ||
Comment 9•14 years ago
|
||
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...
Reporter | ||
Comment 10•14 years ago
|
||
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.
Assignee | ||
Comment 11•14 years ago
|
||
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.
Assignee | ||
Comment 12•14 years ago
|
||
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.
Assignee | ||
Comment 13•14 years ago
|
||
marking security sensitive while I continue my investigation
Group: core-security
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 14•14 years ago
|
||
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
Reporter | ||
Comment 15•14 years ago
|
||
Reporter | ||
Comment 16•14 years ago
|
||
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.
Assignee | ||
Comment 17•14 years ago
|
||
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.
Assignee | ||
Comment 18•14 years ago
|
||
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
Assignee | ||
Comment 19•14 years ago
|
||
perhaps the \n is causing grief...I can try to remove it and see if the problem goes away.
Updated•14 years ago
|
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
Comment 20•14 years ago
|
||
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.
Assignee | ||
Comment 21•14 years ago
|
||
It confuses gdb when it crashes, which makes me believe that it the stack has been crunched.
Assignee | ||
Comment 22•14 years ago
|
||
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.
Comment 23•14 years ago
|
||
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?
Assignee | ||
Comment 24•14 years ago
|
||
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.
Reporter | ||
Comment 25•14 years ago
|
||
Here is the offending message. Let me know if this does not work for you.
Comment 26•14 years ago
|
||
> 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.
Updated•14 years ago
|
Blocks: tb-NoCrashReport
Assignee | ||
Comment 27•14 years ago
|
||
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.
Reporter | ||
Comment 28•14 years ago
|
||
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.
Comment 29•14 years ago
|
||
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)
Comment 30•14 years ago
|
||
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
Comment 31•14 years ago
|
||
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.)
Comment 32•14 years ago
|
||
What version of Gcc is set to default on your system ?
Comment 33•14 years ago
|
||
> 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.
Assignee | ||
Comment 34•14 years ago
|
||
This crash happens with trunk builds as well, so you don't need to build with 1.9.2 to see the issue.
Comment 35•14 years ago
|
||
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
Comment 36•14 years ago
|
||
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 :-)
Comment 37•14 years ago
|
||
"__stack_chk_fail -- terminate a function in case of stack overflow" http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/libc---stack-chk-fail-1.html
Updated•14 years ago
|
Whiteboard: [sg:critical?]
Assignee | ||
Updated•14 years ago
|
Attachment #471152 -
Attachment mime type: message/rfc822 → text/plain
Assignee | ||
Comment 39•14 years ago
|
||
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
Assignee | ||
Comment 41•14 years ago
|
||
I've filed a bug with Apple - Problem ID: 8453081 I marked it a security sensitive bug so perhaps it will get some attention.
Comment 42•14 years ago
|
||
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?
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]
Assignee | ||
Comment 43•14 years ago
|
||
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!
Comment 47•14 years ago
|
||
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]
Assignee | ||
Comment 49•14 years ago
|
||
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
Assignee | ||
Comment 50•14 years ago
|
||
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+
Assignee | ||
Comment 51•14 years ago
|
||
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?
Comment 52•14 years ago
|
||
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
Comment 53•14 years ago
|
||
(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 54•14 years ago
|
||
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?
Assignee | ||
Comment 55•14 years ago
|
||
(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.
Comment 56•14 years ago
|
||
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?
Updated•14 years ago
|
Component: Mail Window Front End → Backend
Product: Thunderbird → MailNews Core
QA Contact: front-end → backend
Updated•14 years ago
|
blocking-thunderbird3.1: ? → .6+
Updated•14 years ago
|
Attachment #481523 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Comment 57•14 years ago
|
||
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 59•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/4723b22a829b in case people ever need to find it
OS: Windows XP → All
Assignee | ||
Updated•14 years ago
|
OS: All → Mac OS X
Assignee | ||
Comment 60•14 years ago
|
||
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 61•14 years ago
|
||
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+
Updated•14 years ago
|
status1.9.2:
--- → wanted
Assignee | ||
Comment 62•14 years ago
|
||
fixed in 1.9.2 - changeset: 34685:06e767ce03fa
status-thunderbird3.1:
--- → .6-fixed
Comment 64•14 years ago
|
||
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]
Comment 65•14 years ago
|
||
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]
Assignee | ||
Comment 66•14 years ago
|
||
(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
Comment 67•14 years ago
|
||
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.
Assignee | ||
Comment 68•14 years ago
|
||
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
Comment 69•14 years ago
|
||
Well, whether or not it works in trunk, I gave the build ID of what I tried with, which is current 1.9.2.
Comment 70•14 years ago
|
||
luca at http://getsatisfaction.com/mozilla_messaging/topics/tb_crashes_upon_startup#reply_3932821 said 3.1.7pre didn't fix his crash.
Updated•14 years ago
|
Assignee | ||
Comment 71•14 years ago
|
||
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.
Comment 72•14 years ago
|
||
Moving blocking to next release, hopefully we'll figure it out then.
blocking1.9.2: .13+ → .14+
Updated•14 years ago
|
blocking-thunderbird3.1: .7+ → .8+
Comment 73•14 years ago
|
||
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?
Assignee | ||
Comment 74•14 years ago
|
||
(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.
Comment 77•13 years ago
|
||
not fully fixed, so reopening to avoid confusion
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 78•13 years ago
|
||
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.
Comment 79•13 years ago
|
||
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
Updated•13 years ago
|
Whiteboard: [sg:vector-critical?][gs][workaround: comment 64][qa-needs-STR] → [sg:vector-critical?][gs][workaround: comment 64][qa-needs-STR][approved-patches-landed]
Assignee | ||
Comment 80•13 years ago
|
||
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.
Updated•13 years ago
|
Crash Signature: [@ UCGetCollationKey]
[@ uprv_uca_getRawFromImplicit]
[@ tiny_malloc_from_free_list | szone_malloc]
[@ szone_free | free | ucol_setVariableTop]
[@ libicucore.A.dylib@0xc43aa]
Assignee | ||
Comment 81•13 years ago
|
||
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]
Comment 82•13 years ago
|
||
Do we need to keep this closed ?
Assignee | ||
Comment 83•13 years ago
|
||
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.
Comment 84•13 years ago
|
||
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
Updated•13 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•