Question

我写过这个与文本字段相关的简单动作方法每次我在文本字段中输入文本时，都会执行PDF搜索，PDFView会自动滚动到选区：

- (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 我认为这是一个内存管理问题..但在哪里？

enter image description here

我在一个简单的测试用例中复制了同样的问题：

  @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。显然我的代码有问题。但我一点一点地比较它，我不认为我插入内存泄漏（并且仪器没有给我任何证据）。也许是否有一些项目范围的设置？

更新从64位更改为32位内存消耗降低。当然64bit和PDFKit存在问题。 BTW在第二次搜索时仍然是EXC_BAD_ACCESS

解关键点是带有垃圾收集的PDFKit被窃听。如果我禁用GC一切正常。我有另一个问题使我的分析变得复杂：我在项目设置上禁用了GC但在目标设置上仍然启用了GC。因此Apple的示例PDFLinked2可以工作，而我的工作没有。

Answer 1

这种事情通常证明你是挂在指向已经被摧毁的物体的指针上。打开僵尸对象（使用NSZombieEnabled）以准确查看访问错误对象的位置和时间。

Answer 2

我同意您在PDFKit中发现了一个错误。

我遇到了运行测试用例的各种形式的错误（分段错误，选择器不被理解等）。将代码包装在 @ try / @ catch 中并不会阻止与此方法相关的所有错误。

我在打印日志消息时也遇到错误。

要解决这个问题，我建议你在调用-findString：fromSelection：时禁用GC，就像你已经发现的那样。

此外，在重新启用GC之前，请务必选择复制感兴趣的值。不要只复制选择。

如果您从代码中的多个位置进行搜索，我还建议您提取单独的方法来执行搜索。然后，您可以调用那个进行搜索，而无需复制GC禁用/启用嵌套。

Answer 3

根据您的屏幕截图判断，您似乎没有NSZombie开启。可能是它没有帮助你的原因。这是你打开它的方式：

How to enable NSZombie in Xcode?

您提供的屏幕截图非常有用，但您确实需要NSZombie才能找出此类错误。好吧，除非它很明显，它不是你发布的代码。

编辑：我读了你正在使用垃圾收集的评论。我是iOS开发人员，所以我在Objective-C中使用垃圾收集的经验非常有限，但据我所知NSZombie在垃圾收集环境中不起作用。

我不确定应该可以在垃圾收集环境中获取EXC_BAD_ACCESS，除非你创建自己的指针并尝试在没有创建对象的情况下调用它上面的方法，我不明白为什么你会这样做

我听说有些框架在垃圾收集方面效果不佳，但我不认为PDFKit就在其中。无论如何，解决方案可能是不使用垃圾收集。也许您应该向Apple提交错误报告。

Answer 4

在使用之前，您是否尝试保留searchview stringvalue对象？

正如您所说，当您快速键入并且异步调用发生时会发生这种情况，对象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];

}

当然，document也有可能被重新传播。你是如何申报的？是保留的财产吗？它可以在您搜索时发布吗？

编辑：

我发现您使用第二个参数NULL发布了代码，但在屏幕截图中，此值为nil。

文档说明当您想从头开始搜索时，应使用NULL。

http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Reference/QuartzFramework/Classes/PDFDocument_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40003873-RH2-DontLinkElementID_1

由于编译器以不同的方式解释nil和NULL，因此可能会在内部导致一些奇怪的行为。

Answer 5

将PDFSelection *selection保留为成员变量，并将其传递到fromSelection:而不是nil。

PDFDocument可能会保留返回的PDFSelection实例以提高性能。

奇怪的EXC_BAD_ACCESS在一个简单的PDFKit程序中

5 个答案: