From: Swen Schillig [mailto:s...@vnet.ibm.com] > Regardless of what's decided on how to react to out of mem conditions, we > must check and detect them, fast and reliable, always. > It is not acceptable to silently accept such a condition and risk to crash or > modify other memory areas.
Yes, we should check them. My idea is in gsh_alloc and friends, to test for NULL return from malloc and friends, and if they fail, to then log a message and abort(). Then ANY code that calls gsh_alloc and friends need not (and should not) check for NULL return (checking for NULL return would thus just be wasted code that will never be executed). There are other library calls that also allocate memory, and we DO need to make sure we check in all of those places. > Besides, the argument that an early abort would be advantageous for > memory leak conditions is hopefully a joke. > Memory leaks must be "closed" regardless of whether we abort or try to > recover. > I think the major goal must be system stability and reliability. > It is not a sign of a reliable system if it's restarted for every little > unusual > situation. It's not a joke... The reality is any complex system probably has a memory leak. We must fix them. But loading up the code with attempts to keep running in the face of ENOMEM caused by a memory leak will just HIDE the memleak by being mostly stable (or causing a more obscure error as the system tries to limp along). Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
