NSString 转换为小写崩溃 [英] NSString conversion to lowercase crashes

问题描述

xcode 4.6 (4H127)、xcode 4.6.3 (4H1503):根据部署目标的设置，带有重音字符的字符串的简单小写/大写转换会崩溃.代码片段:

NSString *lc1 = @"波斯尼亚-黑塞哥维那";NSString *lc2 = [lc1小写字符串];NSString *uc3 = [lc1 uppercaseString];NSLog(@"\nlc1=%@\nlc2=%@\nuc3=%@", lc1,lc2,uc3);

ë"简单地输入为opt-u e"，源代码文件是常规的 UTF Unicode.

lc1 在调试器中看起来如预期.但是，lc2 和 uc3 字符串的末尾附加了中文"字符，部署目标 <;6.1.选择 6.1 后，汉字消失了.所有这一切可能只是调试器的 UTF 兼容性，但是对于部署目标 5.0-5.1，代码片段甚至会崩溃，如下所示，这就是我的问题；我实际应用程序中的字符串不在源代码中，而是来自 SQLite 数据库.那么，目前我只能为部署目标 6.0+ 构建我的应用程序?我错过了什么吗?

0x1c49a20: 包括 %eax0x1c49a21:jmp 0x1c499fb；CFUniCharMapCaseTo + 12750x1c49a23: movl 12(%ebp), %eax0x1c49a26: movw $105, (%eax)0x1c49a2b: movw $775, 2(%eax)0x1c49a31: movl $2, %eax0x1c49a36:jmp 0x1c49dac；CFUniCharMapCaseTo + 22200x1c49a3b: movl 12(%ebp), %eax0x1c49a3e: movw $105, (%eax)0x1c49a43: movw $775, 2(%eax)0x1c49a49: movw $771, 4(%eax)0x1c49a4f: movl $3, %eax0x1c49a54:jmp 0x1c49dac；CFUniCharMapCaseTo + 22200x1c49a59: movl %eax, %edi0x1c49a5b: movl 1264482(%edi), %eax0x1c49a61: movl (%eax), %eax0x1c49a63: movl %eax, (%esp)0x1c49a66: movl $0, 8(%esp)0x1c49a6e: movl $48, 4(%esp)0x1c49a76:调用 0x1bd9980；CFAllocatorAllocate0x1c49a7b: leal 16(%eax), %ecx0x1c49a7e: movl %ecx, 1379418(%edi)0x1c49a84: leal 32(%eax), %ecx0x1c49a87: movl %ecx, 1379422(%edi)0x1c49a8d: movl 1379410(%edi), %ecx0x1c49a93: movl (%ecx), %ecx <-- EXC_BAD_ACCESS (code=1,..0x1c49a95: movl (%ecx), %ecx

我尝试最小化项目以显示此问题，然后......它消失了.我有一些使用 malloc、free、freed、memmove 等东西的旧式 C 代码.如果这个位只是存在，甚至没有被调用，就会出现所描述的问题.我现在的猜测是一些例程是从它不应该加载的库中加载的.进一步挖掘.

解决方案

嗯，我的预感是从库加载有问题，或者加载顺序让我更改了框架的顺序，包括:在构建阶段" 我发现CoreText.framework"是最后的条目之一.我把它移到了首位，现在所有部署目标都可以正常工作，5.0、5.1、6.0、6.1

我实际上查看了加载映射，您可以通过将 LD_GENERATE_MAP_FILE 设置为 yes 来生成它，但无济于事.

另一个指针是通过编辑方案"并打开日志库加载"和日志 API 使用"来提供的，因为您可以看到这些内容是从各种库加载的，其中之一是:CoreText.framework

最终将 CoreText.framework 移至列表顶部，一切都奏效了.

使用部署目标 5.0-6.0 时，您仍然可以在调试器中看到中文"字符.6.1 甚至它们都不见了.我猜他们现在解决了这个问题.

xcode 4.6 (4H127), xcode 4.6.3 (4H1503): A simple lower/uppercase conversion of a string with an accented char crashes, depending on the setting of Deployment Target. Code snippet:

NSString *lc1 = @"Bosnië-Herzegovina";
NSString *lc2 = [lc1 lowercaseString];
NSString *uc3 = [lc1 uppercaseString];
NSLog( @"\nlc1=%@\nlc2=%@\nuc3=%@ ", lc1,lc2,uc3);

The "ë" is simply typed as "opt-u e", the source code file is regular UTF Unicode.

lc1 looks as expected in the debugger. But, lc2 and uc3 strings have "chinese" characters appended at the end, with Deployment Target < 6.1. With 6.1 selected the chinese characters are gone. All that may simply be the UTF compatibility of the debugger, but with deployment target 5.0-5.1 the code snippet crashes even, as shown below, and that is my problem; the strings in my actual application are not in source code but from an SQLite database. So, at this moment I can only build my app for deployment target 6.0+? Am I missing something?

0x1c49a20:  incl   %eax
0x1c49a21:  jmp    0x1c499fb                 ; CFUniCharMapCaseTo + 1275
0x1c49a23:  movl   12(%ebp), %eax
0x1c49a26:  movw   $105, (%eax)
0x1c49a2b:  movw   $775, 2(%eax)
0x1c49a31:  movl   $2, %eax
0x1c49a36:  jmp    0x1c49dac                 ; CFUniCharMapCaseTo + 2220
0x1c49a3b:  movl   12(%ebp), %eax
0x1c49a3e:  movw   $105, (%eax)
0x1c49a43:  movw   $775, 2(%eax)
0x1c49a49:  movw   $771, 4(%eax)
0x1c49a4f:  movl   $3, %eax
0x1c49a54:  jmp    0x1c49dac                 ; CFUniCharMapCaseTo + 2220
0x1c49a59:  movl   %eax, %edi
0x1c49a5b:  movl   1264482(%edi), %eax
0x1c49a61:  movl   (%eax), %eax
0x1c49a63:  movl   %eax, (%esp)
0x1c49a66:  movl   $0, 8(%esp)
0x1c49a6e:  movl   $48, 4(%esp)
0x1c49a76:  calll  0x1bd9980                 ; CFAllocatorAllocate
0x1c49a7b:  leal   16(%eax), %ecx
0x1c49a7e:  movl   %ecx, 1379418(%edi)
0x1c49a84:  leal   32(%eax), %ecx
0x1c49a87:  movl   %ecx, 1379422(%edi)
0x1c49a8d:  movl   1379410(%edi), %ecx
0x1c49a93:  movl   (%ecx), %ecx  <-- EXC_BAD_ACCESS (code=1,..
0x1c49a95:  movl   (%ecx), %ecx

Edit: I tried minimizing the project to show this problem, and... it disappeared. I have a bit of old-style C-code that uses things like malloc, free, freed, memmove, etc. If this bit is simply present, not even called, the problems described occur. My guess now is that some routines are loaded from a library it should not load from. Digging further.

解决方案

Well, my hunch that there was a problem with loading from libraries, or the order of loading made me change the order of the frameworks included: under "Build Phases" I spotted "CoreText.framework" as one of the last entries. I moved it to the top spot, and now all works fine for all Deployment Targets, 5.0, 5.1, 6.0, 6.1

I actually looked at the loadmap, that you can generate by setting LD_GENERATE_MAP_FILE to yes, to no avail.

Another pointer was supplied by editing the "Scheme" and switching on "Log library loads" and "Log API Usage", in that you can see that stuff is loaded from various libraries, one of them: CoreText.framework

In the end moving CoreText.framework to the top of the list made it all work.

The "chinese" characters you can still see in the debugger when using Deployment Target 5.0-6.0. With 6.1 even they are gone. I guess they fixed that now.

这篇关于NSString 转换为小写崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！