On Mar 10, 2009, at 1:17 PM, Robert Mullen wrote:
The framework is open source. It is the SM2DGraphView Framework. I
have posted on the Snowmint forum but not getting anything. I think
that is understandable as the original author built this for his own
purpose and released it to the world out of generosity. I have made
some minor mods to the code base already and don't mind making
others but not sure what the quality of the changes will be given my
inexperience. If this were .NET I would have no hesitation as I am
fluent and experienced. I simply don't have that confidence yet with
Cocoa and Objective-C. In the debugging I am doing right now I have
noticed that there is a struct with "private" data the framework
uses and one element of this struct is an NSMutableDictionary of
text attributes. This is definitely one source of problems as
reading from this element causes bad access. I insert some logging
to look at this element and it has so far contained <com.apple.disk-
imagp >, <NSCFType: 0x186f4a0>, and <NSExtraMIData: 0x186f7e0> but
not an NSMutableDictionary. Pretty clearly I am not getting the
memory that is expected but my first glance at the code exposes no
holes that are obvious to me. This was addressed once before on the
Snowmint forum with that poster exhibiting the same crash symptoms
but the thread went silent after the framework author asked specific
questions about what is not working. Any pointers (bad pun intended)
would be appreciated. I wouldn't mind debugging this myself with the
help of a few more experienced coders. I do understand the basic
tenets of memory management but am also not greatly experienced there.
Sounds like the collector has reaped the location in the struct a wee-
tad earlier than the code would like.
Try declaring the NSMutableDictionary * as __strong
{
....
__strong NSMutableDictionary *bob;
....
}
If that doesn't work, you can call CFRetain() / CFRelease() on the
dictionary reference as it goes in/out of the struct [instead of -
retain/-release].
Also -- look through the -dealloc methods in the framework. You'll
want to create a -finalize for any that do anything beyond -release of
objects/[super dealloc] (Though you don't need to unregister
notification observers).
- free()s & CFRelease()s can be copied directly to -finalize
- close() and other resource management *may* be copied, but you need
to be careful about scarce resource management in -finalize as that
can be problematic
Anything else? Depends... be careful about order dependencies. And
you really want to avoid allocating or retaining anything in your
finalizer. Avoid mucking with the object graph.
All very vague, I know, but that is in the hopes that you won't have
to dive deep. If you do, post some details and we'll see what we can
do.
b.bum
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
