Bugzilla – Full Text Bug Listing
| Summary: | Crash when typing in Persian using onscreen keyboard | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Babak Taraghi <babak.taraghi> | ||||
| Component: | SWT | Assignee: | Felipe Heidrich <eclipse.felipe> | ||||
| Status: | CLOSED INVALID | QA Contact: | Silenio Quarti <Silenio_Quarti> | ||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | babak.taraghi, eclipse.felipe, jacek.pospychala, skovatch | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Babak Taraghi
Moving to SWT team (In reply to comment #0) > Steps to Reproduce: > 1.Change the system language to Persian > 2.Open on screen keyboard > 3.Open a language file > 4.start typing something > BomB I'm not able to reproduce this, but maybe I'm misunderstanding some of the steps. When you say 'Change the system language to Persian' do you mean 'choose the Persian keyboard layout' or do you mean "Go to System Preferences -> Language & Text -> Language' and choose Persian as the OS language? I also need to figure out how to 'open a language file', presumably with WST given the stack trace. Created attachment 181136 [details]
Test case
Open test case or any other PHP script in EClipse,
type something like this:
$foo = 'تم';
type the exact Persian string u c as value for $foo ('j' & 'l' in U.S. keyboard layout).
Got it. I had to install the php tools to get this to crash. If you follow the steps described in the php editor you get a crash, exactly as described here. Typing the same text in the Java editor does not crash. Not sure how that will help yet, but at least it's isolated. I'm not able to reproduce this with a 3.7 M2 plus top-of-tree SWT, but I also can't find any changes in the SWT that would have fixed it. It's possible that something above the SWT changed to fix the problem. If you can get a 3.7 build and try to reproduce it there I'd appreciate it. >Got it. I had to install the php tools to get this to crash. If you follow the
>steps described in the php editor you get a crash, exactly as described here.
Yes, its all about a PDT version of Eclipse So u need to have a php editor.
I got a
Eclipse for PHP Developers
Version: Helios Release
Build id: 20100617-1415
And a
Eclipse for J2EE Developers
But this happened on PDT,
and stack trace ends on some SWT package.
Plus i dont have any idea about other builds.
For whatever reason this is a 64-bit-only bug. I can't reproduce it in 3.7m4 i386, but it does happen in x86_64. As a short-term workaround, try using the 32-bit builds until we find a fix for this. Thanks. Crash in native code: 0 libSystem.B.dylib 0x00007fffffe007c5 __memcpy + 37 1 com.apple.AppKit 0x00007fff86016a3d _NSLayoutTreeSetLocationForGlyphRange + 1121 2 com.apple.AppKit 0x00007fff86015b0a -[NSATSLineFragment saveWithGlyphOrigin:] + 2543 3 com.apple.AppKit 0x00007fff85f7d907 -[NSATSTypesetter _layoutLineFragmentStartingWithGlyphAtIndex:characterIndex:atPoint:renderingContext:] + 7236 4 com.apple.AppKit 0x00007fff8601132b -[NSATSTypesetter layoutParagraphAtPoint:] + 204 5 com.apple.AppKit 0x00007fff864b5302 -[NSTypesetter _layoutGlyphsInLayoutManager:startingAtGlyphIndex:maxNumberOfLineFragments:maxCharacterIndex:nextGlyphIndex:nextCharacterIndex:] + 2637 6 com.apple.AppKit 0x00007fff86010ada -[NSTypesetter layoutCharactersInRange:forLayoutManager:maximumNumberOfLineFragments:] + 210 7 com.apple.AppKit 0x00007fff860109c3 -[NSATSTypesetter layoutCharactersInRange:forLayoutManager:maximumNumberOfLineFragments:] + 1238 8 com.apple.AppKit 0x00007fff8600efa0 -[NSLayoutManager(NSPrivate) _fillLayoutHoleForCharacterRange:desiredNumberOfLines:isSoft:] + 1131 9 com.apple.AppKit 0x00007fff8600e968 -[NSLayoutManager(NSPrivate) _fillLayoutHoleAtIndex:desiredNumberOfLines:] + 211 10 com.apple.AppKit 0x00007fff8600d5e6 _NSFastFillAllLayoutHolesUpToEndOfContainerForGlyphIndex + 679 11 com.apple.AppKit 0x00007fff8600d15c -[NSLayoutManager textContainerForGlyphAtIndex:effectiveRange:] + 243 12 com.apple.AppKit 0x00007fff85f22ba6 -[NSLayoutManager glyphRangeForTextContainer:] + 286 13 libswt-pi-cocoa-3720.jnilib 0x000000014f34c186 Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend_1stret__Lorg_eclipse_swt_internal_cocoa_NSRange_2JJJ + 93 14 ??? 0x0000000114811c88 0 + 4638973064 15 ??? 0x0000000114e3bd28 0 + 4645436712 16 ??? 0x000000013a821f60 0 + 5276573536 I'm going to double-check this doesn't happen in 32-bit. Seems like it should, based on the trace. (In reply to comment #9) > I'm going to double-check this doesn't happen in 32-bit ....but it doesn't. Looking into some ideas to fix it, though. Thanks for your effort. why don't u try Sun virtual box www.virtualbox.org/ to reproduce on a 64-bit OS ? I can check it out on ubuntu 10.10, ill report the result ASAP. Okay, I've found the cause of the crash, but I'm not clear yet why it fails on 64 bits and not 32. You can boil this down to one line: <?phpjl where j and l were typed in via the Persian keyboard layout. Those last two characters merge into one Unicode combined character, but decompose back to two separate values when you call String.getChars(). We have two styles here. The first is range 0, 2 and the second is 2, 4. However, the attributed string we are working with has a length of 7, and those two ranges only cover 6 of the characters. When we apply font and color attributes to the attributed string the second range doesn't cover the last character in the attributed string, and when that happens, glyphRangeForTextContainer blows up. If I force the second range to be 5 via the debugger, calling glyphRangeForTextContainer doesn't crash. I think we are doing something incorrectly when we convert the Java string into the NSString. We're just lucky it doesn't blow up on 32 bits, for some reason. (In reply to comment #11) > Thanks for your effort. > why don't u try Sun virtual box www.virtualbox.org/ to reproduce on a 64-bit OS > ? > I can check it out on ubuntu 10.10, ill report the result ASAP. Thanks, but that won't help. This is strictly a Cocoa problem. I think I know what's going on now; I just need to try some things. The problem seems to be creating ranges of attributes that don't fall on the boundaries of composed character sequences. I tried to fix it with rangeOfComposedCharacterSequencesForRange but it didn't help. It looks like we're trying to do the right thing with translateOffset, but we seem to be off by a character on the ranges. I dont know if I'm doing good to suggest anything to someone as pro as you, but it will be like u teaching me something here :) First of all does this have anything todo with NSStringEncoding ? cause this only happens with Persian characters so i thought this may somehow related to the encoding. And why this cause the system to crash ?!?!? can't we try to catch some exceptions like NSParseErrorException or NSCharacterConversionException or even Exception itself and at least make the system stable ? On the other hand, Why can't we increase the second range to be 5 in program as u did through debugger ? And another thing, Can't we calculate size (length) of the given attributed string (glyphRangeForTextContainer) with something like String.length() and then create a new variable with the actual size of the string ? This is IME code, so over to Felipe. See comment #12 and #14 for analysis. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. Closing this as its not happening with newer versions anymore. |