Unexpected CURL_POLL_REMOVE for unknown socket (possibly from internal admin handle)

[yaoy6]

I did this

Since curl 8.13.0, CURLMOPT_SOCKETFUNCTION may receive a CURL_POLL_REMOVE callback for a socket that was not previously registered via CURL_POLL_IN or CURL_POLL_OUT.

This appears to be caused by the internal multi->admin easy handle, introduced for maintenance tasks. The socket used by this handle is not exposed to application code but still triggers callback events.

If this behavior is expected, it would help to document it clearly or provide a way to identify such callbacks. Thanks in advance!

Example backtrace when CURL_POLL_REMOVE is received for an unexpected socket:

(gdb) bt
#0 socket_callback ()
#1 mev_forget_socket ()
#2 socket_close ()
#3 cf_socket_close ()
#4 cf_he_close ()
#5 ssl_cf_close ()
#6 cf_setup_close ()
#7 cf_hc_close ()
#8 Curl_conn_close ()
#9 Curl_cshutdn_terminate ()
#10 cshutdn_perform ()
#11 multi_socket ()

I expected the following

No response

curl/libcurl version

curl 8.13.0

operating system

FreeBSD

[icing]

Thanks for the report. I agree that curl should only inform about removal if it had previously announced the socket.

I thought the code already did that, but I seem to be missing a case here. It would be interesting to learn more about what made this happen. Can you produce a trace with such a situation?

As a double-safe stopgap for this, I made #17950. It would be nice if you could verify that this fixes your problem.

[yaoy6]

Thanks for the quick reply and the fix. I’ll try to reproduce it with a trace and verify the fix. But the issue occurred during integration testing, which takes a few days to complete, it may take some time before I can follow up.

[icing]

That's fine. Some things take time.