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));
         }

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-developers

Reply via email to