Home/ Questions/Q 6051629
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T07:50:23+00:00

I have written this trivial action method associated to a textfield. Every time I

  • 0

I have written this trivial action method associated to a textfield.
Every time I enter text into a textfield a search in a PDF is performed and PDFView automatically scroll to selection:

- (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];
    } 
}

Problem is that after 3 or 4 searches I get EXC_BAD_ACCESS on row (i).
If I debug I see that query contains an NSCFString and not an NSString.
I think it is a memory management problem..but where?

enter image description here

I replicated the same issue inside a trivial testcase:

  @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);
    }
}

Update:

1) It seems that it happens also if I use asynchronous search (method beginFindString: withOptions) every time I perform second search.

2) I found a similar problem to mine in MacRuby Issue Tracking: http://www.macruby.org/trac/ticket/1029

3) It seems that if I disable temporarily garbage collection it works but memory goes up.
I wrote something like:

[[NSGarbageCollector defaultCollector] disable];
[[NSGarbageCollector defaultCollector] enable];

surrounding search code

Another Update

Very weird thing is that sometimes all works. Than I clean and Rebuild and problem arises again. From a certain point of view is is not 100% reproducible. I suspect a bug in PDFKit or some compiler setting I have to do

Update Again

Dears it seems very crazy. I’d concentrate on testcase which is very trivial and which replicates easily the problem. What’s wrong with it? This testcase works only if I disable (by code or by project setting) GC

Another Update

Boys it seems a bug but I downloaded an example called PDFLinker from Apple website (http://developer.apple.com/library/mac/#samplecode/PDFKitLinker2/Introduction/Intro.html#//apple_ref/doc/uid/DTS10003594). This example implements a PDFViewer. Code of my app and this example are quite similars. For the same search action on same PDF, my memory rises at 300/400 MB while PDFLinker rises at 190MB. Clearly there is something wrong in my code. But I am comparing it bit by bit and I don’t think I am inserting memory leaks (and Instrument doesn’t give me any evidence). Maybe is there some project-wide setting ?

Update Yet
Changing from 64 bit to 32 bit memory consumption lowered. Surely there is a problem with 64bit and PDFKit. BTW still EXC_BAD_ACCESS on second search

SOLUTION
Crucial point is that PDFKit with Garbage collection is bugged.
If I disable GC all works correctly.
I had another issue that had complicated my analysis: I disabled GC on Project Setting but GC remained enabled on Target Settings. So Apple’s example PDFLinked2 worked while mine not.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I agree you have found a bug in PDFKit.

    I got various forms of errors (segmentation fault, selector not understood, etc) running your test case. Wrapping the code in @try/@catch doesn’t prevent all errors associated with this method.

    I also got errors printing the log message.

    To work around the bug(s), I suggest you disable GC during your invocation of -findString:fromSelection:, as you’ve already discovered.

    Also, be sure to make copies of the values of interest from selection before re-enabling GC. Don’t just copy selection either.

    If you conduct searches from multiple places in your code I also suggest you extract a separate method to perform the search. Then you can invoke that one to conduct the searches for you without duplicating the GC disable/enable nesting.

    • 0