You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug was initially reported by Vasiliy Yashkov [email protected]. When running a lot of attachments on valgrind enabled built a message arrived:
Memcheck: the 'impossible' happened:
MC_(create_mempool): duplicate pool creation
After analysis of provided simple test case it was found that this happens always with request's pools. The reason is recursive use of AutoCacheRequest - there can be >1 instance of AutoCacheRequest n the stack and outer one overwrites statement, already created by deeper instance.
That was not too dangerous until "Compiled statement cache" implementation, which added dedicated pool for each request, because requests were deleted "by pool" in the end of attachment's life. Currently it may cause memory leak in each attachment - pools are destroyed together with parent pool but memory allocated by them is never freed. (Duplicate pool creation is just visible in valgrind effect of this bug).
The text was updated successfully, but these errors were encountered:
Bug was initially reported by Vasiliy Yashkov [email protected]. When running a lot of attachments on valgrind enabled built a message arrived:
Memcheck: the 'impossible' happened:
MC_(create_mempool): duplicate pool creation
After analysis of provided simple test case it was found that this happens always with request's pools. The reason is recursive use of AutoCacheRequest - there can be >1 instance of AutoCacheRequest n the stack and outer one overwrites statement, already created by deeper instance.
That was not too dangerous until "Compiled statement cache" implementation, which added dedicated pool for each request, because requests were deleted "by pool" in the end of attachment's life. Currently it may cause memory leak in each attachment - pools are destroyed together with parent pool but memory allocated by them is never freed. (Duplicate pool creation is just visible in valgrind effect of this bug).
The text was updated successfully, but these errors were encountered: