Opened 14 years ago

Closed 13 years ago

#133 closed defect (fixed)

cocoa bridge leaks NSString instances when converting lisp strings to NSStrings

Reported by: rme Owned by: gb
Priority: minor Milestone:
Component: Foreign Function Interface Version: 1.1
Keywords: Cc:


(We already know this, but might as well put it on a ticket to annoy and shame us.)

The Cocoa bridge tries to be helpful by turning lisp strings into NSStrings when passing them to methods that expect an Objective-C object. These strings are never released.

Just as an initial thought, suppose we put these NSString instances into an nsstring-wrapper class. We could then keep these wrappers in a weak-key hash table (using the lisp string as the key), and use OpenMCL's termination mechanism to arrange for the NSString to be released before the nsstring-wrapper value gets it in the neck from the GC.

Change History (3)

comment:1 Changed 14 years ago by gb

I don't really like the whole string->NSString coercion idea; I don't think that I'd be too upset if we deprecated it and dropped it.

In a lot of calls to methods that take some flavor of NSString as an argument, that argument is a constant:

  (#/setTitle: window #@"You Lose!")

In cases where the string isn't a constant, it's often something that's autoreleased:

  (#/setTitle: window (#/stringWithFormat: ns:ns-string #@"window %d" (next-window-number)))

If we wanted to keep the string coercion in the bridge, I think that I'd vote for using #/autorelease as the finalization mechanism. It might be tempting to try to use finalization for this, but that's very hard: it's very hard to tell whether lisp is referencing a foreign address and even harder for us to tell whether foreign code is. (Of course finalization can tell us whether or not there are strong references to a given MACPTR, but that's not the same thing.)

comment:2 Changed 14 years ago by rme

Right after I wrote this ticket suggesting this complicated solution, it occurred to me that #/autorelease would probably be better in this circumstance. Figures.

I agree, though, that it would be best not to do any coercion of lisp strings to NSStrings, and that we should make the bridge stop doing it as soon as we can.

I don't know what the best way to do that is. Put a WARN in %COERCE-TO-ADDRESS for now, and stop converting at the next release, maybe?

The Python guys have been wrestling with the issue of bridging strings for a while now. See, e.g.,

comment:3 Changed 13 years ago by rme

  • Resolution set to fixed
  • Status changed from new to closed

I took out automatic coercion of lisp strings to NSString instances in r10781.

Note: See TracTickets for help on using tickets.