Re: PDFKit and 64-bit bugs

On Sep 6, 2009, at 10:31, Christiaan Hofman wrote:

>
> On Sep 6, 2009, at 5:19, Bill Bumgarner wrote:
>
>> Please send me bug #s for any PDFKit crashes while running under GC.
>>
>> thanks,
>> b.bum
>>
>> On Sep 5, 2009, at 5:40 PM, Antonio Nunes wrote:
>>
>>> On 5 Sep 2009, at 23:10, Christiaan Hofman wrote:
>>>
>>>> I've finally moved to upgrade a PDFKit app to 64-bits. However,  
>>>> it's giving me all kinds of crashers which I'm pretty sure are  
>>>> bugs in PDFKit. It seems that whenever I call -[PDFBorder  
>>>> dashPattern] or -[PDFPage attributedString] it crashes, and on  
>>>> 10.5.8 also -[PDFView areaOfInterestForMouse:] (though that seems  
>>>> to originate in -[PDFPage loadTextChars]). I've found some ugly  
>>>> workarounds for the first two, but the last one remains illusive.
>>>
>>> I've had no issues with any of these methods. Not on 10.5.any in  
>>> 32 bit,
>
> I am talking about 64 bit, there is no problem on 32 bit.
>
>>> and not on 10.6 in 64 bit. My app is garbage collected, so if your  
>>> is not, that might explain the lack of issues for these particular  
>>> methods (although that would surprise me: non-GCd PDFKit seems to  
>>> be noticeably better tested than GCd PDFKit).
>>>
>>> What's with loadTextChars? That is not a PDFKit method, probably a  
>>> brew of your own :-)
>
> No, an internal brew of PDFKit that turns up at the top of the trace.
>
>>>
>>> (There are definitely bugs in PDFKit though, including some new  
>>> ones in 10.6, which fortunately also fixes some old ones.)
>>>
>>> -António
>>>
>>> -----
>
> I'm not using GC.
>
> Without GC the attributedString bug is not there for sure, because  
> that's an over-release inside the method. On 32 bit I get an  
> autorelease warning, on 64 bit I get a crash, both without GC, and   
> I can fix the bug by explicitly retaining the result (though that  
> will give a leak once the bug will be fixed).
>
> As for the dashPattern bug, I doubt very much that it's not there  
> for GC, because it's a typing issue. An internal ivar is declared as  
> unsigned int rather than NSUInteger, and I am very sure from looking  
> at the internals and the crash report that it's accessed /using  
> addresses/ as an NSUInteger. I can fix it by overriding the relevant  
> accessor method.
>
> To reproduce, the following line of code crashes very reliably for me:
>
> [[[[PDFBorder alloc] init] autorelease] dashPattern];
>
> Christiaan

Update, this does not crash with GC, but it does give ominous warnings  
about free and auto malloc.

Christiaan