On 10/29/15 10:52 AM, Matt W. Benjamin wrote: > I think this is probably the best approach for now, ++. > > Matt > > ----- "Frank Filz" <ffilz...@mindspring.com> wrote: > >> 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. >> Actually there is a lot of code that never checks for NULL, hoping that a SegFault will give a trace.
We need to find these. And ensure we're using a proper gsh_alloc (and friends). >> 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. >> Agreed. Also (as we agreed during the call) gsh_alloc should generate and log a trace, so we know exactly where these rare crashes occur. In many cases, we don't get a dump. Even with a dump, and with a lot of threads, it's hard to guess which thread to trace in gdb. Also, we'll need to do a sweep for all gsh_alloc calls and rip out any NULL test. We can assign that to a newbie? For memory pools, we'll just rely on the gsh_alloc failure trace, rather than some extra logging. Again, we'll need a sweep. ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
