atom feed20 messages in net.java.dev.rococoa.usersRe: "Invalid memory access" in NSAuto...
FromSent OnAttachments
Duncan McGregorJul 27, 2009 8:48 am 
Michael NagelJul 27, 2009 9:29 am 
Duncan McGregorJul 27, 2009 12:44 pm 
David KocherJul 27, 2009 3:35 pm 
Duncan McGregorJul 27, 2009 3:43 pm 
David KocherJul 27, 2009 4:08 pm 
Andrew ThompsonJul 27, 2009 7:02 pm 
Michael NagelJul 27, 2009 9:28 pm 
Duncan McGregorJul 28, 2009 1:29 am 
Duncan McGregorJul 28, 2009 3:42 am 
Duncan McGregorJul 28, 2009 4:07 am 
Duncan McGregorJul 28, 2009 4:33 am 
Andrew ThompsonJul 28, 2009 4:41 am 
Duncan McGregorJul 28, 2009 5:01 am 
Duncan McGregorJul 28, 2009 11:55 am 
Andrew ThompsonJul 28, 2009 6:17 pm 
Duncan McGregorAug 10, 2009 3:28 am 
Andrew ThompsonAug 10, 2009 8:56 pm 
Duncan McGregorSep 1, 2009 7:59 am 
Andrew ThompsonSep 1, 2009 6:12 pm 
Subject:Re: "Invalid memory access" in NSAutoreleasePool.finalize
From:Duncan McGregor (dun@oneeyedmen.com)
Date:Jul 27, 2009 8:48:48 am
List:net.java.dev.rococoa.users

I know that I said that I knew how to fix this, but now that I come to try, it turns out that I can't reproduce it!

I've just checked in NSAutoreleasePoolTest

@Test public void drainDoesntLeadToCrashInFinalize() { NSAutoreleasePool pool = NSAutoreleasePool.new_(); RococoaTestCase.assertRetainCount(1, pool); pool.drain(); pool.release(); Foundation.cfRelease(pool.id()); RococoaTestCase.assertRetainCount(1, pool);

// wait until object has been GC'd WeakReference<Object> reference = new WeakReference<Object>(pool); pool = null; while (reference.get() != null) { RococoaTestCase.gc(); }

for (int i = 0; i < 20; i++) { RococoaTestCase.gc(); } }

Notwithstanding my previous theories, none of drain, release or CFRelease seem to dent the pool's retain count, so that it is fine to be CFReleased again in finalize.

Can anyone confirm my findings please, and / or provide a failing test case?

Cheers

Duncan