Fix GH-13891: memleak and segfault when using ini_set with session.trans_sid_hosts #13892
Conversation
….trans_sid_hosts The hash tables used are allocated via the persistent allocator. When using ini_set, the allocation happens via the non-persistent allocator. When the table is then freed in GSHUTDOWN, we get a crash because the allocators are mismatched. As a side note, it is strange that this is designed this way, because it means that ini_sets persist between requests... Test credits go to Kamil Tekiela.
|
According to the documentation:
Why is the hash table persistent then? Isn't that the bug? |
I also thought about that, and I could fix that up. EDIT: wait, let me double check |
|
Okay, I double checked with Apache and I see that my claim that this is persisted between requests is false. Sorry for the mess. EDIT: to clarify why this is: this is because the ini message handler first clears the hash table, so when resetting the ini values this will clean up whatever was set in the previous request. However, the hashtable has to be persistent though because the ini message handler can be called outside of a request, so the strings should be persistent as well. (e.g. it can be called in ZEND_INI_STAGE_STARTUP) |
Co-authored-by: Kamil Tekiela <tekiela246@gmail.com>
|
Side note: shouldn't it be possible to trigger this bug not during runtime? |
I think so, because you're using request memory outside of request context. |
The hash tables used are allocated via the persistent allocator. When using ini_set, the allocation happens via the non-persistent allocator. When the table is then freed in GSHUTDOWN, we get a crash because the allocators are mismatched.
As a side note, it is strange that this is designed this way, because it means that ini_sets persist between requests...Test credits go to Kamil Tekiela.