fix accidental corrdump
zjd5536 at 163.com
Thu Sep 29 08:30:45 UTC 2022
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 about this question.But for example, ngx_array_push maybe reuse l->alloc's address, and ngx_array_push is not memzero from the start of get memory.
So I think l->alloc=NULL after free(l-alloc) is necessary. Thanks for discussing this with me
At 2022-09-29 00:03:24, "Maxim Dounin" <mdounin at mdounin.ru> wrote:
>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
>> The ngx_reset_pool take pool->large each alloc pointer return
>> to pool, and each alloc pointer is wild pointer.
>> And When another get momery from the pool in next request or
>> next next request..., I maybe get wild pointer address and
>> access inaccessible addresses, and then coredump.
>> maybe the describe is simple in last mail.
>Ok, so from your description you are getting segfaults, and you
>don't know why.
>Note that the ngx_reset_pool() function clears pool->large, and
>also frees all the ngx_pool_large_t structures (since it resets
>all pool blocks). That is, l->alloc you are clearing in your
>patch is not expected to be used anywhere. If clearing it helps,
>this suggests that there is a bug in your module which results in
>this freed memory to be used somehow.
>While clearing l->alloc might appear to help, most likely it is
>just hiding a bug in your module. Correct solution would be to
>find the bug in your module and fix it.
>nginx mailing list -- nginx at nginx.org
>To unsubscribe send an email to nginx-leave at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx