Hello,
The attached patch destroys ACLs in the reverse order of creation to
avoid destruction segfaults during reconfiguration. I could reproduce
segfaults in v3.3-based code. I saw access to the already destroyed ACL
memory in trunk; I suspect trunk did not segfault by luck as the bug
appears to be there.
Group ACLs created later may use other ACLs created earlier. A group ACL
must be deleted first so that its AclDeleter can safely access
registration status (and avoid double deletion) of the ACLs it uses.
Since ACLs are remembered (in Config.aclList) using a singly-linked
list, it is difficult to change their deletion order. Instead, we
changed their listing order from FIFO to LIFO.
As far as I can tell, the ACL storage order is not important for the
rest of the code but please let me know if I missed any cases.
Thank you,
Alex.
This archive was generated by hypermail 2.2.0 : Sat Nov 30 2013 - 12:00:11 MST