Listing Display
Bug Id ?
255
Reporter ?
outis
Product/Version ?
MacGDBp / 1.5
Status ?
Closed
Severity ?
Moderate
Duplicate Of ?
- none -
Fixed in Revision ?
Mstone ?
Summary ?
"CFSocketSetAddress bind failure: 48" (EADDRINUSE) when restarting MacGDBp
Report Time ?
January 20, 2019 10:39 PM
Assignment ?
Robert
Resolution ?
Fixed
Priority ?
Normal
Dependencies ?
- none -
Mstone (old) ?


Attachments
Votes
For: 0 (0%)
Against: 0 (0%)
Total: 0

January 20, 2019 10:39 PM outis
# Description
In some circumstances, when closing and restarting MacGDBp it fails to create a listening socket, displaying the error "Could not open socket.". The error message "CFSocketSetAddress bind failure: 48" is logged. Errno 48 is to `EADDRINUSE`.

MacGDBp sets `SO_REUSEADDR` and `SO_REUSEPORT`, but, according to a bug report (http://www.openradar.me/13127171), `CFSocketCreateWithSocketSignature` is incompatible with SO_REUSEADDR (and, presumably, SO_REUSEPORT).

# Steps to reproduce
1. While a connection is open to a debug engine, quit MacGDBp.
2. Within a short time (up to a few minutes), open MacGDBp.

# Expected Result
MacGDBp starts as normal.

# Actual Result
MacGDBp can't create listening socket.

# Possible Fix
The bug reports suggests that call to `CFSocketCreateWithSocketSignature` could be decomposed into calls to `CFSocketCreate` and `CFSocketSetAddress` (and others?), so that the socket options could be called in between.

January 20, 2019 10:58 PM outis
This attempts to fix the issue by breaking call to `CFSocketCreateWithSocketSignature` into calls to `CFSocketCreate` and `CFSocketSetAddress`, with socket options set in between. Adapted from open source implementation of `CFSocketCreateWithSocketSignature` (https://github.com/opensource-apple/CF/blob/3cc41a76b1491f50813e28a4ec09954ffa359e6f/CFSocket.c#L3262).

On January 21, 2019 04:35 AM, outis changed:
January 21, 2019 04:35 AM outis
First patch had wrong `setsockopt` argument type, preventing it from working; newer patch seems to work & fix the issue. I went back and tried just changing the argument type, but that wasn't enough to resolve this issue.

The issue turned out to be a little broader. If the debug engine becomes non-responsive, stopping debugging will close the connection, leaving it in TIME_WAIT, and preventing future debug sessions until time runs out. This fixes that, though may cause other issues (the typical issues with `SO_REUSEADDR`).

September 4, 2019 01:16 PM Robert
This should be fixed on master since CFSocket is no longer used.

On September 4, 2019 01:16 PM, Robert changed: