Issue 104525 - OSX has severe problem with some filenames, a workaround could help
Summary: OSX has severe problem with some filenames, a workaround could help
Status: CLOSED FIXED
Alias: None
Product: porting
Classification: Code
Component: code (show other issues)
Version: DEV300m56
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: h.ilter
QA Contact: issues@porting
URL:
Keywords: aqua
Depends on:
Blocks:
 
Reported: 2009-08-26 17:00 UTC by hdu@apache.org
Modified: 2010-07-26 19:47 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Zip container with a problematic file name (5.88 KB, application/x-compressed)
2009-08-26 17:02 UTC, hdu@apache.org
no flags Details
ZIP with different file types (9.03 KB, application/x-compressed)
2009-08-26 17:34 UTC, hdu@apache.org
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description hdu@apache.org 2009-08-26 17:00:55 UTC
Many applications on OSX 10.5.8 and probably also on most older versions crash when a problematic file 
name is used. The problem seems to be in the code that updates the "Recent Items" list. If it can be 
detected that the file name probably causes a crash OOo should avoid to notify OSX of this item use.
Comment 1 hdu@apache.org 2009-08-26 17:02:37 UTC
Created attachment 64393 [details]
Zip container with a problematic file name
Comment 2 hdu@apache.org 2009-08-26 17:18:25 UTC
To reproduce the problem one just needs to unpack the attached ZIP file. Then open it with e.g. 
TextEdit, which will result in a crash. Also OpenOffice.org is affected.

The root cause of the problem is probably that the 0xFC byte in the filename is misinterpreted as an 
UTF-8 six-byte sequence leading byte. Since such overlong sequences are illegal (since RFC3629) and 
also the following bytes of the file name don't follow the UTF-8 convention of having their MSBs==10 
this might explain why the CFStringGetLength function crashes.

Here is a typical stack for this problem (for TextEdit):
0   com.apple.CoreFoundation      	0x90e59947 CFStringGetLength + 39
1   com.apple.Metadata            	0x96d322bb _MDItemMarkAsUsedForPath + 191
2   com.apple.LaunchServices      	0x90cb8b70 _LSAddRecentItem + 368
3   com.apple.AppKit              	0x9166a716 -[NSDocumentController 
_notePendingRecentDocumentURLsForKey:] + 1419
4   com.apple.Foundation          	0x9326d88e __NSFireDelayedPerform + 382
5   com.apple.CoreFoundation      	0x90e428f5 CFRunLoopRunSpecific + 4469
6   com.apple.CoreFoundation      	0x90e42aa8 CFRunLoopRunInMode + 88
7   com.apple.HIToolbox           	0x91df42ac RunCurrentEventLoopInMode + 283
8   com.apple.HIToolbox           	0x91df40c5 ReceiveNextEventCommon + 374
9   com.apple.HIToolbox           	0x91df3f39 BlockUntilNextEventMatchingListInMode + 106
10  com.apple.AppKit              	0x913556d5 _DPSNextEvent + 657
11  com.apple.AppKit              	0x91354f88 -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
12  com.apple.AppKit              	0x9134df9f -[NSApplication run] + 795
13  com.apple.AppKit              	0x9131b1d8 NSApplicationMain + 574
14  com.apple.TextEdit            	0x00001df6 0x1000 + 3574

Comment 3 hdu@apache.org 2009-08-26 17:34:57 UTC
Created attachment 64394 [details]
ZIP with different file types
Comment 4 hdu@apache.org 2009-08-27 10:28:19 UTC
The workaround I commited into CWS vcl105 avoids that any of the problematic URLs get registered into 
the RecentItems List.
Comment 5 hdu@apache.org 2009-09-07 14:35:18 UTC
@hi: please verify in CWS vcl105
Comment 6 h.ilter 2009-09-10 14:47:34 UTC
Verified with cws vcl105 = ok
Comment 7 Martin Hollmichel 2010-07-26 19:47:42 UTC
close issue