[MacPorts] #59498: openssh @8.1p1_2: __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug

[MacPorts]

#59498: openssh @8.1p1_2: __NSCFString autoreleased with no pool in place - just
leaking - break on objc_autoreleaseNoPool() to debug
----------------------+--------------------
  Reporter:  iEFdev   |      Owner:  Ionic
      Type:  defect   |     Status:  closed
  Priority:  Low      |  Milestone:
 Component:  ports    |    Version:  2.6.2
Resolution:  fixed    |   Keywords:
      Port:  openssh  |
----------------------+--------------------
Changes (by Mihai Moldovan <ionic@…>):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 In [changeset:"439a81a91ea103342b41c8a4b091843615e540b2/macports-ports"
 439a81a91ea103342b41c8a4b091843615e540b2/macports-ports] (master):
 {{{
 #!ConfigurableCommitTicketReference repository="macports-ports"
 revision="439a81a91ea103342b41c8a4b091843615e540b2"
 net/openssh: potentially fix memory leaks on 10.7-.

 Users on 10.7- experienced a set of messages along those lines while
 executing ssh-add:

 objc[<bumber>]: Object <address> of class __NSCFString autoreleased with
 no pool in place - just leaking - break on objc_autoreleaseNoPool() to
 debug

 Such messages scare users, even though, strictly speaking, memory leaks
 in ssh-add should be benign. This application has a short life time and
 (almost never) processes large amounts of data, so even if memory is
 leaked, the impact of these leaks should be ignorable.

 The *reason* for this message is mystifying me, since I cannot reproduce
 this on 10.9.

 Generally, Cocoa only creates one global autorelease pool for the main
 thread, but not other threads. ssh-add itself shouldn't be
 multi-threaded as far as I could see (which might be wrong), so this
 can't be the correct explanation.

 It looks like global autorelease pools are also not generated for
 Foundation-only applications, which essentially is happening here.

 The mystery is that at least 10.7 should already have proper ARC support
 and hence applications should not use NSAutoreleasePool directly anyway,
 but let ARC handle this stuff or only use local
 @autoreleasepool { blocks }, which are equally handled by ARC.

 For some reason, this doesn't seem to happen here.

 Let's work around this issue by creating an NSAutoreleasePool instance
 at the top of each function in keychain.m (the easy part) and drain the
 pool before exiting the function (the not-so-easy part, because most
 functions have multiple exit points).

 The code looks a bit ugly that way, but it should rid us of the nasty
 leak message that is confusing users.

 Fixes: https://trac.macports.org/ticket/59498
 }}}

-- 
Ticket URL: <https://trac.macports.org/ticket/59498#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS