Geoff Levner wrote:
| Problem solved (no thanks to you guys!).
| The solution is to allocate Cocoa data structures on the AppKit
| exclusively, if they need to be deallocated later.
This probably isn't doing anything more than hiding the real problem...
| The AppKit thread allocates its own NSData, copies the PDF data into
| it, then signals the Swing thread that its copy of the data is no
| longer needed. And the AppKit thread releases its own data later.
Data-sharing bugs tend to be very timing dependent. A change as
you describe could easily reorder the thread execution enough to drive
data-trampling into hiding. For now.
| Is this a JVM bug? An AppKit bug?
Most likely, an application bug.
Yes, it was indeed an application bug: a Cocoa object that was not
retained. Many thanks to Greg Parker for bringing NSZombie to our
attention in the "Hopelessly bad GC crash question" thread!
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden