h2o_spawnp mapped fds closes wrong fd #1203
Conversation
It's possible that the mapped fds have the same value (in particular for
fastcgi, where the target fd is number 5). In that case, we end up
doing:
dup2(5, 5);
close(5);
ending up with no valid fd 5. This patch prevents the dup if the mapped
fd already has the expected value.
|
Thank you for noticing the issue! Could you please check if the suggested solution works for inputs like: I think we'd need to take care of such patterns (the source fd (in the case of the example 1) appears in one of the preceding destination fds). |
Also handle the case where the mapped fd destination is found in the list of source fds to map later.
Handled the case in 4cbf9bb, thanks for pointing it out. |
|
I'm very sorry but it seems that we don't actually need 4cbf9bb, since
I will cherry-pick 817da3e once the CI succeeds. |
It's possible that the mapped fds have the same value (in particular for
fastcgi, where the target fd is number 5). In that case, we end up
doing:
dup2(5, 5);
close(5);
ending up with no valid fd 5. This patch prevents the dup if the mapped
fd already has the expected value.
It's possible that the mapped fds have the same value (in particular for
fastcgi, where the target fd is number 5). In that case, we end up
doing:
ending up with no valid fd 5. This patch prevents the dup if the mapped
fd already has the expected value.