Hello!
On Tue, Sep 08, 2020 at 10:49:44PM -0400, allenhe wrote:
> I found most times using "r" after ngx_http_free_request() won't have any
> problem. the core dump would happen once for a while in the high load.
That's because use-after-free errors not always result in
segmentation faults as l
Hi,
I found most times using "r" after ngx_http_free_request() won't have any
problem. the core dump would happen once for a while in the high load.
I am wondering if the "ngx.pfree" does not return the memory back to the os
when it's called?
Posted at Nginx Forum:
https://forum.nginx.org/read.p
Hello!
On Thu, Sep 03, 2020 at 07:19:08AM -0400, allenhe wrote:
> to be more self assurance,
> can somebody confirm that the "r" is no longer accessable after this?
>ngx_http_free_request(r, 0);
The ngx_http_free_request() function frees the request, and using
"r" after the
to be more self assurance,
can somebody confirm that the "r" is no longer accessable after this?
ngx_http_free_request(r, 0);
thank you in advance!
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,289296,289299#msg-289299
___
I was wrong, the request object was created on the fly with the pool
object.
here the pool was detroyed before the r was referenced which caused the core
dump.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,289296,289298#msg-289298
___
nginx
version: 1.17.8
debug log:
2020/09/03 14:09:21 [error] 320#320: *873195 upstream timed out (110:
Connection timed out) wh
