On 2012-05-07 at 17:22 +0700, Janne Snabb wrote: > However if my dlfunc is called from acl_smtp_connect the current default > "store_pool" is set to POOL_MAIN and likewise if it is called from > acl_smtp_rcvd.
What are you doing with the result? If you're setting an $acl_c_* variable, then the pool will be set to POOL_PERM. What variable are you seeing be referred to, from another ACL, in a different generation of the POOL_MAIN contents? If your library needs to persist internal state across calls, you should stash the value of store_pool away, set it to POOL_PERM, then reset store_pool back to the stashed values. It's possible that the default pool should change for some ACLs, but I don't have enough context to know what problem you're encountering. > If I always set store_pool to POOL_PERM will my dlfunc cause memory > leaks, or is POOL_PERM memory also recycled but only at the end of the > complete SMTP transaction? POOL_PERM lasts for the lifetime of the process, but Exim is a forking server, so each connection is handled in one process, and deliveries get fork/exec'd. There's a lot of process splitting going on, so if you care about the lifetime of memory beyond a narrow scope, you need to handle that carefully. > Or is this a bug in Exim? Should Exim take care of setting "store_pool" > to POOL_PERM when running a dlfunc in the connect ACL? Possibly, if I can see what variable the result is being stored away in and why it's being referred to later, after the lifetime of the pool generation it's in. > Or should my dlfunc do some magic on its own to determine what > "store_pool" it should use, depending on which ACL is calling it? Almost certainly not; but it's possible that you should be temporarily setting the pool to POOL_PERM for your particular use-case, always. -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
