问题描述
|
我已经编写了与文本字段关联的这种琐碎的操作方法。
每次我在文本字段中输入文本时,都会执行PDF搜索,and0ѭ会自动滚动至所选内容:
- (IBAction) search:(id)id
{
Nsstring *query = [self.searchView stringValue]; // get from textfield
selection = [document findString: query fromSelection:NULL withOptions:NSCaseInsensitiveSearch];
if (selection != nil)
{
[self.pdfView setCurrentSelection:selection];
[self.pdfView scrollSelectionToVisible:self.searchView];
}
}
问题是经过3或4次搜索后,我在第(i)行中得到EXC_BAD_ACCESS
。
如果我进行调试,则会看到该查询包含NSCFString
而不是Nsstring
。
我认为这是内存管理问题。但是在哪里?
我在一个简单的测试用例中复制了相同的问题:
@interface PDFRef_protoTests : SenTestCase {
@private
PDFDocument *document;
}
........
- (void)setUp
{
[super setUp];
document = [[PDFDocument alloc] initWithURL: @\"a local url ...\"];
}
- (void)test_exc_bad_access_in_pdfdocument
{
for (int i =0 ;i<100; i++)
{
Nsstring *temp;
if (i % 2 == 0) temp = @\"home\";
else if (i % 3 ==0) temp = @\"cocoa\";
else temp=@\"apple\";
PDFSelection *selection = [document findString: temp
fromSelection:nil
withOptions:NSCaseInsensitiveSearch];
NSLog(@\"Find=%@,iteration=%d\",selection,i);
}
}
更新:
1)如果我每次执行第二次搜索时都使用异步搜索(beginFindString:withOptions方法),似乎也会发生这种情况。
2)我在MacRuby问题跟踪中发现了与我类似的问题:http://www.macruby.org/trac/ticket/1029
3)看来,如果我暂时禁用垃圾收集,它可以工作,但内存会增加。
我写了类似的东西:
[[NSGarbageCollector defaultCollector] disable];
[[NSGarbageCollector defaultCollector] enable];
周围的搜索代码
另一个更新
非常奇怪的是,有时候所有的东西都起作用。比我清理并重建,问题再次出现。从某些角度来看不是100%可复制的。我怀疑PDFKit或我必须执行的某些编译器设置中的错误
再次更新
亲爱的,看来非常疯狂。我将专注于非常简单的测试用例,它可以轻松地复制问题。它出什么问题了?仅当我禁用(通过代码或项目设置)GC时,此测试用例才有效
另一个更新
男孩,这似乎是一个错误,但我从Apple网站(http://developer.apple.com/library/mac/#samplecode/PDFKitLinker2/Introduction/Intro.html#//apple_ref/doc/uid/DTS10003594)下载了一个名为PDFLinker的示例)。本示例实现了PDFViewer。我的应用程序代码和此示例非常相似。对于同一PDF的相同搜索操作,我的内存增加到300/400 MB,而PDFLinker增加到190MB。显然,我的代码有问题。但是我正在一点一点地比较它,我不认为我正在插入内存泄漏(并且Instrument没有提供任何证据)。也许有一些项目范围的设置?
更新
从64位更改为32位,降低了内存消耗。当然,64位和PDFKit存在问题。顺便说一句,第二次搜索时BTW仍为EXC_BAD_ACCESS
解
关键是带有垃圾回收的PDFKit被窃听了。
如果我禁用GC,则所有工作正常。
我还有另一个使我的分析复杂的问题:我在项目设置上禁用了GC,但在“目标设置”上仍启用了GC。因此,Apple的示例PDFLinked2可以工作,而我的则不能。
解决方法
我同意您在PDFKit中发现了一个错误。
我在运行您的测试用例时遇到了各种形式的错误(细分错误,选择器无法理解等)。在@ try / @ catch中包装代码并不能防止与此方法相关的所有错误。
打印日志消息时也出现错误。
要解决该错误,建议您在调用-findString:fromSelection:的过程中禁用GC,因为您已经发现了。
另外,在重新启用GC之前,请确保从选择中复制感兴趣的值。也不要只复制选择内容。
如果您从代码中的多个位置进行搜索,我还建议您提取一种单独的方法来执行搜索。然后,您可以调用该选项来为您执行搜索,而无需重复GC禁用/启用嵌套。
, 这种事情通常可以证明您正挂在指向已被破坏的对象的指针上。打开僵尸对象(使用
NSZombieEnabled
),以准确查看正在访问不良对象的位置和时间。
,从屏幕截图来看,好像没有打开NSZombie
。可能对您没有帮助的原因。这是打开方式:
如何在Xcode中启用NSZombie?
您提供的屏幕截图在其他方面非常有用,但是您确实需要ѭ8才能找出此类错误。好吧,除非很明显,否则不是来自您发布的代码。
编辑:我读到您正在使用垃圾回收的注释。我是iOS开发人员,因此我在Objective-C中进行垃圾收集的经验非常有限,但据我了解,ѭ8在垃圾收集环境中不起作用。
我不确定是否可以在垃圾回收环境中获得EXC_BAD_ACCESS,除非您创建自己的指针并尝试在不创建对象的情况下对其调用方法,但我不知道为什么要这样做。
我听说有些框架在垃圾回收方面不能很好地工作,但是我认为PDFKit不在其中。无论如何,解决方案可能是不使用垃圾回收。也许您应该向Apple提交错误报告。
, 保留PDFSelection *selection
作为成员变量,并将其传递给fromSelection:
而不是nil
。
PDFDocument
可能保留返回的PDFSelection
实例以提高性能。
, 在使用它之前,您是否尝试过保留searchview字符串值对象?
就像您说的那样,当您快速键入并在异步调用中发生时,对象stringValue
指向的对象可能在您的对象query
指向它的时间与在搜索中使用它的时间之间被释放。
您可以尝试执行以下操作以查看问题是否仍然存在:
- (IBAction) search:(id)id
{
NSString *query = [[self.searchView stringValue] retain]; // get from textfield
selection = [document findString: query fromSelection:NULL withOptions:NSCaseInsensitiveSearch];
if (selection != nil)
{
[self.pdfView setCurrentSelection:selection];
[self.pdfView scrollSelectionToVisible:self.searchView];
}
[query release];
}
当然,也有可能会ѭ19。您如何申报?有保留权的财产吗?可以在搜索时将其释放吗?
编辑:
我看到您发布的代码的第二个参数是NULL
,但是在屏幕快照中,该值是nil
。
文档说,当您要从头开始搜索时,应使用ѭ20。
http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Reference/QuartzFramework/Classes/PDFDocument_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40003873-RH2-DontLinkElementID_1
而且,由于编译器对ѭ13和ѭ20的解释不同,这可能会导致内部出现一些奇怪的行为。