Work around a macOS 10.12 bug involving objects with weak delegates

Work around a macOS 10.12 bug involving objects with weak delegates

NSNetService and NSNetServiceBrowser each have non-owned delegates. In
10.12, Apple appears to have updated them to maintain their delegate
references as zeroing weak pointers. Unfortunately, they seem to have
done this by hand instead of using the compiler's support for it, and
they left something out. When objects of either of these classes are
deallocated, they fail to unregister their weak interest in their
delegates. When the delegates subsequently are deallocated, they will
attempt to clear the pointers to themselves in objects that no longer
exist. This manifests itself in messages like:

Google Chrome[29616]: objc[29616]: __weak variable at 0x600002654890
holds 0x2121212121212121 instead of 0x60000263f8e0. This is probably
incorrect use of objc_storeWeak() and objc_loadWeak(). Break on
objc_weak_error to debug.

This bug has been filed with Apple as
http://openradar.appspot.com/28943305. As a workaround, set these
objects' delegates to nil when destroying them. This removes their weak
interest in their delegates.

BUG=657495
Committed: https://crrev.com/97de983007388a7a537ad8c1e5fbbd1bb20f4305
Cr-Commit-Position: refs/heads/master@{#427736}

[Mark Mentovai, 2016-10-26 16:10:45]

The CQ bit was checked by mark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 16:11:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mark Mentovai, 2016-10-26 16:11:39]

mark@chromium.org changed reviewers:
+ avi@chromium.org

[Avi (use Gerrit), 2016-10-26 16:16:28]

Description was changed from

==========
Work around a macOS 10.12 bug involving objects with weak delegates

NSNetService and NSNetServiceBrowser each have non-owned delegates. In
10.12, Apple appears to have updated them to maintain their delegate
references as zeroing weak pointers. Unfortunately, they seem to have
done this by hand instead of using the compiler's support for it, and
they left something out. When objects of either of these classes are
deallocated, they fail to unregister their weak interest in their
delegates. When the delegates subsequently are deallocated, they will
attempt to clear the pointers to themselves in objects that no longer
exist. This manifests itself in messages like:

Google Chrome[29616]: objc[29616]: __weak variable at 0x600002654890
holds 0x2121212121212121 instead of 0x60000263f8e0. This is probably
incorrect use of objc_storeWeak() and objc_loadWeak(). Break on
objc_weak_error to debug.

This bug has been filed with Apple as
http://openradar.appspot.com/28943305. As a workaround, set these
objects' delegates to nil when destroying them. This removes their weak
interst in their delegates.

BUG=657495
==========

to

==========
Work around a macOS 10.12 bug involving objects with weak delegates

NSNetService and NSNetServiceBrowser each have non-owned delegates. In
10.12, Apple appears to have updated them to maintain their delegate
references as zeroing weak pointers. Unfortunately, they seem to have
done this by hand instead of using the compiler's support for it, and
they left something out. When objects of either of these classes are
deallocated, they fail to unregister their weak interest in their
delegates. When the delegates subsequently are deallocated, they will
attempt to clear the pointers to themselves in objects that no longer
exist. This manifests itself in messages like:

Google Chrome[29616]: objc[29616]: __weak variable at 0x600002654890
holds 0x2121212121212121 instead of 0x60000263f8e0. This is probably
incorrect use of objc_storeWeak() and objc_loadWeak(). Break on
objc_weak_error to debug.

This bug has been filed with Apple as
http://openradar.appspot.com/28943305. As a workaround, set these
objects' delegates to nil when destroying them. This removes their weak
interest in their delegates.

BUG=657495
==========

[Avi (use Gerrit), 2016-10-26 16:16:53]

lgtm

[commit-bot: I haz the power, 2016-10-26 16:44:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-26 16:44:35]

Dry run: This issue passed the CQ dry run.

[Mark Mentovai, 2016-10-26 17:28:47]

The CQ bit was checked by mark@chromium.org

[commit-bot: I haz the power, 2016-10-26 17:29:25]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-26 17:39:32]

Description was changed from

==========
Work around a macOS 10.12 bug involving objects with weak delegates

NSNetService and NSNetServiceBrowser each have non-owned delegates. In
10.12, Apple appears to have updated them to maintain their delegate
references as zeroing weak pointers. Unfortunately, they seem to have
done this by hand instead of using the compiler's support for it, and
they left something out. When objects of either of these classes are
deallocated, they fail to unregister their weak interest in their
delegates. When the delegates subsequently are deallocated, they will
attempt to clear the pointers to themselves in objects that no longer
exist. This manifests itself in messages like:

Google Chrome[29616]: objc[29616]: __weak variable at 0x600002654890
holds 0x2121212121212121 instead of 0x60000263f8e0. This is probably
incorrect use of objc_storeWeak() and objc_loadWeak(). Break on
objc_weak_error to debug.

This bug has been filed with Apple as
http://openradar.appspot.com/28943305. As a workaround, set these
objects' delegates to nil when destroying them. This removes their weak
interest in their delegates.

BUG=657495
==========

to

==========
Work around a macOS 10.12 bug involving objects with weak delegates

NSNetService and NSNetServiceBrowser each have non-owned delegates. In
10.12, Apple appears to have updated them to maintain their delegate
references as zeroing weak pointers. Unfortunately, they seem to have
done this by hand instead of using the compiler's support for it, and
they left something out. When objects of either of these classes are
deallocated, they fail to unregister their weak interest in their
delegates. When the delegates subsequently are deallocated, they will
attempt to clear the pointers to themselves in objects that no longer
exist. This manifests itself in messages like:

Google Chrome[29616]: objc[29616]: __weak variable at 0x600002654890
holds 0x2121212121212121 instead of 0x60000263f8e0. This is probably
incorrect use of objc_storeWeak() and objc_loadWeak(). Break on
objc_weak_error to debug.

This bug has been filed with Apple as
http://openradar.appspot.com/28943305. As a workaround, set these
objects' delegates to nil when destroying them. This removes their weak
interest in their delegates.

BUG=657495
==========

[commit-bot: I haz the power, 2016-10-26 17:39:33]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-10-26 17:51:05]

Description was changed from

==========
Work around a macOS 10.12 bug involving objects with weak delegates

NSNetService and NSNetServiceBrowser each have non-owned delegates. In
10.12, Apple appears to have updated them to maintain their delegate
references as zeroing weak pointers. Unfortunately, they seem to have
done this by hand instead of using the compiler's support for it, and
they left something out. When objects of either of these classes are
deallocated, they fail to unregister their weak interest in their
delegates. When the delegates subsequently are deallocated, they will
attempt to clear the pointers to themselves in objects that no longer
exist. This manifests itself in messages like:

Google Chrome[29616]: objc[29616]: __weak variable at 0x600002654890
holds 0x2121212121212121 instead of 0x60000263f8e0. This is probably
incorrect use of objc_storeWeak() and objc_loadWeak(). Break on
objc_weak_error to debug.

This bug has been filed with Apple as
http://openradar.appspot.com/28943305. As a workaround, set these
objects' delegates to nil when destroying them. This removes their weak
interest in their delegates.

BUG=657495
==========

to

==========
Work around a macOS 10.12 bug involving objects with weak delegates

NSNetService and NSNetServiceBrowser each have non-owned delegates. In
10.12, Apple appears to have updated them to maintain their delegate
references as zeroing weak pointers. Unfortunately, they seem to have
done this by hand instead of using the compiler's support for it, and
they left something out. When objects of either of these classes are
deallocated, they fail to unregister their weak interest in their
delegates. When the delegates subsequently are deallocated, they will
attempt to clear the pointers to themselves in objects that no longer
exist. This manifests itself in messages like:

Google Chrome[29616]: objc[29616]: __weak variable at 0x600002654890
holds 0x2121212121212121 instead of 0x60000263f8e0. This is probably
incorrect use of objc_storeWeak() and objc_loadWeak(). Break on
objc_weak_error to debug.

This bug has been filed with Apple as
http://openradar.appspot.com/28943305. As a workaround, set these
objects' delegates to nil when destroying them. This removes their weak
interest in their delegates.

BUG=657495

Committed: https://crrev.com/97de983007388a7a537ad8c1e5fbbd1bb20f4305
Cr-Commit-Position: refs/heads/master@{#427736}
==========

[commit-bot: I haz the power, 2016-10-26 17:51:06]

Patchset 1 (id:??) landed as
https://crrev.com/97de983007388a7a537ad8c1e5fbbd1bb20f4305
Cr-Commit-Position: refs/heads/master@{#427736}