You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not hard to trace control-flow paths to this line from execution of while(data) { ... ; data = data->next; } loops. I was considering the situation where curl has no fds (curlfds) and there's extrafds-- but at a glance I think this can be triggered even when no extra fd's are used.
I haven't tried building things to force the issue, apologies if this can't happen, but thought I'd share "just in case".
If someone's enabled debugging the last thing they need is extra crashing behavior that doesn't occur otherwise :P.
The text was updated successfully, but these errors were encountered:
Nice catch, thanks! I think I can just remove that line as I don't think it helps us much with anything these days! Update: infof() actually checks for a NULL pointer so it will just not do anything in that case. I still think we can remove the output.
Well, I assume "debug build" is what
DEBUGF
macro is for.Anyway, just spotted this while debugging my application....
Look at:
curl/lib/multi.c
Line 1086 in 6d8c628
(current master, and I think at least 7.60)
It's not hard to trace control-flow paths to this line from execution of
while(data) { ... ; data = data->next; }
loops. I was considering the situation where curl has no fds (curlfds
) and there's extrafds-- but at a glance I think this can be triggered even when no extra fd's are used.I haven't tried building things to force the issue, apologies if this can't happen, but thought I'd share "just in case".
If someone's enabled debugging the last thing they need is extra crashing behavior that doesn't occur otherwise :P.
The text was updated successfully, but these errors were encountered: