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).
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).