2014-12-19 72 views
5

我與我之前的移植應用到arm64 achitecture這是正在運行就好了一個PDF導出方法掙扎。UIGraphicsBeginPDFPage()隨機崩潰在64位器件(CGPDFSecurityManagerCreateDecryptor())

Bacisally,該方法打開現有的PDF,它會創建一個新的PDF文件,並添加更多的內容頁面之前繪製的第一個PDF的內容到新創建的一個。

當該方法嘗試創建一個新的pdf頁面到文檔(在第一個pdf被整合到新的pdf之後),該應用程序在UIGraphicsBeginPDFPage()上出現EXC_BAD_ACCESS警告;打電話。

它只是一些PDF文件,並不是所有的只有64臺設備發生。

下面是其中顯示了CGPDFSecurityManagerCreateDecryptor()調用,我找不到它做什麼的堆棧跟蹤。

Thread 14Queue : NSOperationQueue 0x14f6dd3a0 :: NSOperation 0x17504a470 (serial) 
#0  0x00000001838aeee4 in CGPDFSecurityManagerCreateDecryptor() 
#1  0x00000001838d1004 in pdf_filter_chain_create() 
#2  0x0000000183831e00 in CGPDFStreamCreateFilterChain() 
#3  0x000000018383226c in chain_get_bytes() 
#4  0x0000000183b5e0ac in unpackImageRow() 
#5  0x0000000183b5dfd4 in PDFImageEmitData() 
#6  0x0000000183b5f684 in emit_image() 
#7  0x0000000183b5ef9c in PDFImageEmitDefinition() 
#8  0x0000000183464584 in __CFSetApplyFunction_block_invoke() 
#9  0x00000001834643bc in CFBasicHashApply() 
#10  0x00000001834642e4 in CFSetApplyFunction() 
#11  0x0000000183b5fa9c in PDFImageSetEmitDefinitions() 
#12  0x0000000183b590c0 in emit_page_resources(PDFDocument*)() 
#13  0x0000000183b5904c in PDFDocumentEndPage() 
#14  0x0000000183b57cf0 in pdf_EndPage() 
#15  0x0000000187fda904 in UIGraphicsBeginPDFPageWithInfo() 
#16  0x00000001002093e8 in -[ExportTools renderPdfContentToContext:forPlanVersion:] 
#17  0x00000001001fba60 in -[ExportTools generatePdfReportWithOptions:] 
#18  0x00000001000f7eb4 in -[DetailViewController generatePdfAndShowModalOpenWithAppWithOptions:] 
#19  0x00000001835883c0 in __invoking___() 
#20  0x0000000183486138 in -[NSInvocation invoke]() 
#21  0x000000018443ba20 in -[NSInvocationOperation main]() 
#22  0x000000018437c61c in -[__NSOperationInternal _start:]() 
#23  0x000000018443e26c in __NSOQSchedule_f() 
#24  0x000000010105cdf0 in _dispatch_client_callout() 
#25  0x0000000101067854 in _dispatch_queue_drain() 
#26  0x0000000101060120 in _dispatch_queue_invoke() 
#27  0x000000010106975c in _dispatch_root_queue_drain() 
#28  0x000000010106af18 in _dispatch_worker_thread3() 
#29  0x00000001945012e4 in _pthread_wqthread() 

如果你有關於這個崩潰的任何想法,您的幫助將不勝感激,在1天內亂投醫解決這一問題,並beggening懷疑,如果它不是一個錯誤的UIKit ...

感謝

+0

我在同一個函數中看到相同的崩潰,但是使用了不同的堆棧跟蹤。儘管我沒有寫出有問題的軟件,但我可以驗證它是否正在使用PDF文檔並在OS X 10.10上運行,因此它的64位 – HairOfTheDog

回答

1

我不得不在64設備上的CGPDFSecurityManagerCreateDecryptor方法碰撞只用下面的代碼:

CGPDFDocumentRelease(pdf); 
CGDataProviderRelease(provider); 
UIGraphicsEndPDFContext(); 

CGPDFSecurityManagerCreateDecryptor WO在結束上下文時會被調用。當我在發佈文檔和提供者之前結束上下文時,崩潰消失了。

UIGraphicsEndPDFContext(); 
CGPDFDocumentRelease(pdf); 
CGDataProviderRelease(provider); 
0

我一直在掙扎與此相同的問題太多,雖然比爾的回答給我的線索,我不得不做不同的那麼一點點。在我的情況有一些被複制到目標PDF,所以我不能只是簡單CGPDFDocumentRelease之前移動UIGraphicsEndContext源PDF文件數量可變的。該代碼結構看起來大致是這樣的:

UIGraphicsBeginPDFContextToFile(...); 
// ... 
for each attachment pdf { 
    srcPdf = CGPDFDocumentCreateWithURL(...); // open source PDF 
    // ... 
    UIGraphicsBeginPDFPageWithInfo(...); // new page in target PDF, this randomly crashes 
    // ... 
    CGPDFDocumentRelease(srcPdf); // close source PDF 
} 
// ... 
UIGraphicsEndPDFContext(); 

所以不是我試圖捕捉引用它使用的所有來源的PDF文件和目標PDF的休息後,釋放所有這些完成後,在代碼中要晚得多。這是一種醜惡的,因爲它移動的責任遠,並擁有所有的記憶,直到最後,而不是每一個被渲染後釋放...但它確實出現了工作!這很難說明確,因爲它是一次隨機崩潰,但我從未見過它,而且我一直在仔細研究它,試圖讓它再次發生。

pdfRefs = [[NSPointerArray alloc] init]; 
UIGraphicsBeginPDFContextToFile(...); 
// ... 
for each attachment pdf { 
    srcPdf = CGPDFDocumentCreateWithURL(...); // open source PDF 
    // ... 
    UIGraphicsBeginPDFPageWithInfo(...); // new page in target PDF, this randomly crashes 
    // ... 
    [pdfRefs addPointer:srcPdf]; // store for later closing 
} 
// ... 
UIGraphicsEndPDFContext(); 
for each srcPdf in pdfRefs { 
    CGPDFDocumentRelease(srcPdf); // close it here 
}