Lack of allocation failure checking in C code gen

[Jake Scott <Ja...@morganstanley.com>]

Hi.

We are using version 1.6.2 of the Axis2/Java framework to generate C
code for use with Axis2/C, from some WSDL service descriptions.  We have
noticed that the generated code does not always check the return value
of memory allocations, and there is therefore a risk of null pointer
de-references in low memory situations.

For example :

    p_prefix = (axis2_char_t*)AXIS2_MALLOC(env->allocator, sizeof
(axis2_char_t) * ADB_DEFAULT_NAMESPACE_PREFIX_LIMIT);
    sprintf(p_prefix, "n%d", (*next_ns_index)++);

It seems to be generally related to allocations before a call to
sprintf.  Other times the return value is checked :

   _AuthResponse = (adb_AuthResponse_t *) AXIS2_MALLOC(env->allocator,
sizeof(adb_AuthResponse_t));
   if(NULL == _AuthResponse)
   {
     AXIS2_ERROR_SET(env->error, AXIS2_ERROR_NO_MEMORY, AXIS2_FAILURE);
     return NULL;
   }


We are certainly willing to patch this and submit back the code, but
before embarking on this effort I'd like to validate this with the
list.  Is this something that would be accepted, and any hints at the
best way to tackle this would be much appreciated.


Thanks

Jake Scott




---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

RE: Lack of allocation failure checking in C code gen

[Martin Gainty <mg...@hotmail.com>]

Jake

 

I think you've touched upon a common ailment for all software deployables..exhausting resources
There have been a few ideas kicked around..most notably


check if requested_allocation <=available_heap
the problem is determining available heap varies with each OS and ARCH type so..

a comprehensive testcase matrix would need to incorporate every OS/ARCH permutation 

if this is important to you file a JIRA and submit a patch (with appropriate testcases)

and as long as you can prove that all testcases pass ..I am sure the patch will be approved


https://issues.apache.org/jira/browse/AXIS2C


Looking forward to seeing your patch

 

Thanks,
Martin Gainty 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.

  


> Date: Wed, 9 Oct 2013 15:07:05 -0400
> From: Jacob.Scott@morganstanley.com
> To: java-dev@axis.apache.org
> Subject: Lack of allocation failure checking in C code gen
> 
> 
> Hi.
> 
> We are using version 1.6.2 of the Axis2/Java framework to generate C
> code for use with Axis2/C, from some WSDL service descriptions. We have
> noticed that the generated code does not always check the return value
> of memory allocations, and there is therefore a risk of null pointer
> de-references in low memory situations.
> 
> For example :
> 
> p_prefix = (axis2_char_t*)AXIS2_MALLOC(env->allocator, sizeof
> (axis2_char_t) * ADB_DEFAULT_NAMESPACE_PREFIX_LIMIT);
> sprintf(p_prefix, "n%d", (*next_ns_index)++);
> 
> It seems to be generally related to allocations before a call to
> sprintf. Other times the return value is checked :
> 
> _AuthResponse = (adb_AuthResponse_t *) AXIS2_MALLOC(env->allocator,
> sizeof(adb_AuthResponse_t));
> if(NULL == _AuthResponse)
> {
> AXIS2_ERROR_SET(env->error, AXIS2_ERROR_NO_MEMORY, AXIS2_FAILURE);
> return NULL;
> }
> 
> 
> We are certainly willing to patch this and submit back the code, but
> before embarking on this effort I'd like to validate this with the
> list. Is this something that would be accepted, and any hints at the
> best way to tackle this would be much appreciated.
> 
> 
> Thanks
> 
> Jake Scott
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>