Hello!
On Fri, Sep 30, 2022 at 12:07:47PM +0800, zjd wrote:
> If disturb everyone, I'm sorry.
>
> l->alloc itself address(&l->alloc) in the pool can be reused
> rather than l->alloc pointer to wild address, &l->alloc return
> to pool.
> And I try only use large memory with Maxim's way, but it
If disturb everyone, I'm sorry.
l->alloc itself address(&l->alloc) in the pool can be reused rather than
l->alloc pointer to wild address, &l->alloc return to pool.
And I try only use large memory with Maxim's way, but it's not coredump.
Because coredump is accident, not coredump maybe be reaso
Hello!
On Thu, Sep 29, 2022 at 04:37:24PM -0400, Frank Swasey wrote:
> This is getting quite tiresome. You are both stuck in your point of view
> and refusing to hear what the other one is saying.
>
> Maxim - you keep repeating " l->alloc is not used after free(). " Clearly,
> that is not true
This is getting quite tiresome. You are both stuck in your point of view
and refusing to hear what the other one is saying.
Maxim - you keep repeating " l->alloc is not used after free(). " Clearly,
that is not true if setting it to NULL prevents the segfault. What is true
is that NGINX core co
Hello!
On Thu, Sep 29, 2022 at 04:30:45PM +0800, zjd wrote:
> Actually, I'm not sure where is coredump; So I think
> l->alloc=NULL after free(l-alloc) is reasonable, because
> l->alloc's address can be reused in the pool. Of course,
> memzero after get mem from the pool can be solved abo
Hello!
On Wed, Sep 28, 2022 at 10:56:15AM +0800, zjd wrote:
> my module is such:
> The pool is created with ngx_create_pool in
> module_init_process; I get momery from the pool in the start of
> each request, and then use ngx_reset_pool in the end of each
> request.
> The ngx_reset_pool tak
