<div dir="ltr"><div><div><div><div>Hi Maxim,<br></div>Thank you for the detailed explanation.<br></div>I expected the solution woun´t be easy.<br><br></div>Thanks.<br><br></div>Ranier<br></div><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br> <table style="border-top:1px solid #d3d4de">
        <tr>
      <td style="width:55px;padding-top:18px"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;"></a></td>
                <td style="width:470px;padding-top:17px;color:#41424e;font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">Livre de vírus. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank" style="color:#4453ea">www.avast.com</a>.             </td>
        </tr>
</table>
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div><div class="gmail_extra"><br><div class="gmail_quote">2017-12-04 12:22 GMT-02:00 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Fri, Dec 01, 2017 at 09:42:37PM -0200, Ranier Vf wrote:<br>
<br>
> Coverity report dereference after null check in<br>
> /src/http/ngx_http_upstream.c<br>
><br>
> CID 400852 (#1 of 1): Dereference after null check (FORWARD_NULL)22.<br>
> var_deref_op: Dereferencing null pointer u->pipe.<br>
><br>
> line 4356: ngx_http_file_cache_free(r-><wbr>cache, u->pipe->temp_file);<br>
><br>
> Required add check u->pipe?<br>
<br>
</span>It's complicated.<br>
<br>
Simply adding a check in a particular place is certainly wrong, as<br>
r->cache is only expected to exist only if u->pipe exists as well.<br>
<br>
On the other hand, in theory it is possible for r->cache to be not<br>
in sync with "u" in a very specific case of filter finalization<br>
(combined with caching, and also combined with error_page<br>
redirection to a different location with upstream), when "u" comes<br>
from an old upstream connection, and r->cache was already updated<br>
to work with a new one.  Additional u->pipe checks won't help here<br>
though, as almost every thing done with r->cache in such a case is<br>
likely wrong.<br>
<br>
One of the possible fixes I've suggested several years ago is to<br>
move r->cache to upstream structure, so the old "u" will be<br>
self-consistent, though Igor disagree with such approach.  Not<br>
sure there are other good solutions though.<br>
<br>
The problem is mostly theoretical though, as all practical cases<br>
work fine.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
______________________________<wbr>_________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-devel</a><br>
</font></span></blockquote></div><br></div>