Re: [Monetdb-developers] [Monetdb-checkins] MonetDB5/src/mal mal_authorize.mx, Nov2009, 1.82.4.1, 1.82.4.2 mal_box.mx, Nov2009, 1.98.4.1, 1.98.4.2 mal_factory.mx, Nov2009, 1.89.6.1, 1.89.6.2 mal_session.mx, Nov2009, 1.200.2.1, 1.200.2.2
On 31-10-2009 09:06:11 +0000, Martin Kersten wrote: [snip]
obj->name= GDKstrdup(name);
what if the GDKstrdup fails here?
obj->sym= newMalBlk(MAXVARS,STMT_INCREMENT); obj->val = newGlobalStack(MAXVARS);
- if ( obj->val == NULL)
showException(MAL,"box.new", MAL_MALLOC_FAIL);
I've been looking at mal_sabaoth to deal with GDKmalloc failures, and there is a question to me in cases like this.
malloc failed, now the only right way to communicate that to the caller is to throw an exception. However, doing that requires memory too (it GDKmallocs too), so that will most probably fail too. Hence, the throw will die, crash, or even worse, return NULL, which happens to mean MAL_SUCCEED.
What should we do here? define a MAL_MALLOC_FAIL constant that we can always return and that's recognised (and hence never freed), or do we redefine MAL_SUCCEED to be non-NULL such that a real NULL means real trouble, and thus an out of memory condition?
On 31-10-2009 10:12:23 +0100, Fabian Groffen wrote:
On 31-10-2009 09:06:11 +0000, Martin Kersten wrote: [snip]
obj->name= GDKstrdup(name);
what if the GDKstrdup fails here?
obj->sym= newMalBlk(MAXVARS,STMT_INCREMENT); obj->val = newGlobalStack(MAXVARS);
- if ( obj->val == NULL)
showException(MAL,"box.new", MAL_MALLOC_FAIL);I've been looking at mal_sabaoth to deal with GDKmalloc failures, and there is a question to me in cases like this.
malloc failed, now the only right way to communicate that to the caller is to throw an exception. However, doing that requires memory too (it GDKmallocs too), so that will most probably fail too. Hence, the throw will die, crash, or even worse, return NULL, which happens to mean MAL_SUCCEED.
What should we do here? define a MAL_MALLOC_FAIL constant that we can always return and that's recognised (and hence never freed), or do we redefine MAL_SUCCEED to be non-NULL such that a real NULL means real trouble, and thus an out of memory condition?
example:
diff -u -r1.66 mal_sabaoth.mx --- mal_sabaoth.mx 24 Sep 2009 09:59:58 -0000 1.66 +++ mal_sabaoth.mx 31 Oct 2009 09:19:11 -0000 @@ -522,6 +522,13 @@
if (sdb == NULL) { top = sdb = GDKmalloc(sizeof(sabdb)); + if (top == NULL) { + (void)closedir(d); + /* malloc failed, throwing an exception will fail too, + * as it takes even more memory, how to signal the + * caller now? */ + throw(MAL, "sabaoth.getStatus", "out of memory"); + } } else { sdb = sdb->next = GDKmalloc(sizeof(sabdb)); }
Fabian Groffen wrote:
On 31-10-2009 09:06:11 +0000, Martin Kersten wrote: [snip]
obj->name= GDKstrdup(name);
what if the GDKstrdup fails here?
obj->sym= newMalBlk(MAXVARS,STMT_INCREMENT); obj->val = newGlobalStack(MAXVARS);
- if ( obj->val == NULL)
showException(MAL,"box.new", MAL_MALLOC_FAIL);
Indeed, hardening against all (non) foreseeable MALLOC errors is hard with the 1.8M lines of code at hand. Malloc can fail for many reasons.
The first line of defense, focused on now, is to avoid hard errors by recovering at upper layers and deal with malloc errors as seems fit in the context. In places it can be transferred into a MAL exception in other places it is turned into a no-op (which with proper notification can be dealt with)
In this particular example, the exception is meant to be delivered. (next phase is to adjust modules/mal/box)
I've been looking at mal_sabaoth to deal with GDKmalloc failures, and there is a question to me in cases like this.
malloc failed, now the only right way to communicate that to the caller is to throw an exception. However, doing that requires memory too (it
There are several communication schemes deployed in the code base. From returning INT status, NULL references to objects, and MAL_exceptions. Furthermore, the GDKerror buffer may contain information about an error detected deep in the kernel and turned into a MAL exception in the interpreter.
GDKmallocs too), so that will most probably fail too. Hence, the throw will die, crash, or even worse, return NULL, which happens to mean MAL_SUCCEED.
What should we do here? define a MAL_MALLOC_FAIL constant that we can always return and that's recognised (and hence never freed), or do we
showException should deliver it regardless the state.
redefine MAL_SUCCEED to be non-NULL such that a real NULL means real trouble, and thus an out of memory condition?
Not an option, due to the pervasive use of MAL_SUCCEED (and friends GDK_FAIL, GDK_SUCCEED)
The steps taken behind mal_errors was also to see if the number of exception messages could be trimmed without loosing too much information. It it works, then ideally most exceptions messages (templates) could be pre-cooked. This would also facilitate the option sketched above.
Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
participants (2)
-
Fabian Groffen -
Martin Kersten