Handling a panic when using DB_REGISTER

Question

I have just run into a problem which I think is a bug in BerkeleyDB 4.4.20. I am checking to see if there is any known work-around or patch for this.
We have a design in which two processes use one environment. Both processes employ the combination of DB_REGISTRY and DB_RUN_RECOVERY when they open the environment. The process also have a panic handler in them so that if the panic exception is thrown while they run, they close and reopen the environment with the same flags.
The use of the flags in this way achieves the benefit of the DB_REGISTER mechanism. The panic handler addresses the fact that if one process restarts after a failure and thus starts recovery, it's peer can handle the panic which ensues and will close/reopen its environment, thereby reattaching to the recovered environment. Based on the exclusive lock in the registry mechanism, there are no race conditions on recovery - the processes both end up reconnected to the recovered environment - and all of this seems to be working just fine.
However, if the two running processes experience a panic in the environment because of some other bug, I see a problem. We are concerned here for panics which could arise due to shared memory corruption, an internal BerkeleyDB bug, etc. (Anything else that might cause the panic bit to get set.) We simulated this in testing by adding a JMX control which allows us set the panic flag as the processes run. We want to make sure that in those cases, the application will at least attempt to close and recover the environment and will still be able to carry on if recovery is possible.
When the panic bit is set in this way, the panic handler is invoked, the processes both try to close the environment and reopen it. The Environment.close() call is failing in this case with a RunRecovery exception just as it does as with a process crash scenario. I think this is fine. However, when the processes try to reopen the environment, they are getting an invalid argument exception because the Registry mechanism believes that the processes both have the environment open already. The problem is that environment.close() doesn't unregister the processes when the environment is paniced.
This problem doesn't occur when a process restarts because it gets a new PID, which allows it to proceed with the open, and then the existing registry is removed as part of the recovery, which in turn allows its peer to reconnect as well without any problem.
Looking a bit deeper, it also seems that once the environment is paniced, Environment.close() doesn't clean up any resources - it doesn't unmap the regions, close file descriptors, etc, leaving the resources used by the closed Environment handle "leaked".
I think this is a bug. In 4.6.21, I noticed (from the code) that __env_close_pp() now closes file handles even when the panic bit is set, and it seems to me that there is a general need here for the Environment.close() to always properly free up resources even when the environment is paniced, so that an application noticing the panic can attempt to reopen it. i.e. __env_close should close relevant file descriptors and unmap associated files/regions from the processes address space so that they can be reclaimed by the system, even when the environment is paniced.
This behavior of Environment.close() also seems like it can cause an infinite resource leak. i.e. If process A is running along, and process B is having problems and crashes/gets restarted several times, then with each such restart of B, process A ends up with more anonymous mapped memory regions and open file descriptors attached to it which are no longer being used. (i.e. with each restart of B, which will perform recovery, A sees a panic and does a close/reopen, which allows it to attach to the new recovered region successfully, but never closes the file descriptors or attached regions of the old paniced environmet.) Only when A shuts down would it completely detach. I think this is the issue 4.6.21 was attempting to address. I may have no choice but to try to hand-code a patch for 4.4.20 which does the same.
Does any patch for this issue already exist for 4.4.20 ?? Does the code in 4.6.21 address this resource-leak issue in full?

Answer 1

Hi Samira,
Please close the duplicate thread.
Regards,
Eric