ASF GitHub Bot commented on PROTON-727:

GitHub user dcristoloveanu opened a pull request:


    Add some NULL checks and fix some realloc leaks

    Along the lines of PROTON-727, added NULL checks for some malloc/realloc 
calls that were either ignoring the result or leaking in the case of realloc.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/dcristoloveanu/qpid-proton FixCodeAnalysis

Alternatively you can review and apply these changes as the patch at:


To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #27
commit c31b068656579b3b6e47a44bd97b40001f2a66ca
Author: dcristoloveanu <dcri...@microsoft.com>
Date:   2015-04-30T00:15:51Z

    Add some NULL checks and fix some realloc leaks


> Add a NULL-pointer checks to malloc() and realloc() calls
> ---------------------------------------------------------
>                 Key: PROTON-727
>                 URL: https://issues.apache.org/jira/browse/PROTON-727
>             Project: Qpid Proton
>          Issue Type: Wish
>          Components: proton-c
>    Affects Versions: 0.8
>            Reporter: German Shepherd (PrE)
>            Priority: Minor
> As we are running the ProtonC project on memory constrained systems, it is 
> possible for malloc() or realloc() to return a NULL, when there is no more 
> free heap to allocate the memory from.
> Obviously, we might have a specific optimizations in the ProtonC code, which 
> deeply minimize the amount of a total heap required, but this is not what 
> this ticket is referring to.
> In any case where there is no more free heap, or in a case where there is any 
> other issue with the allocators, the memory allocation functions return NULL.
> The ProtonC code at this state, does not check for such a situation, and it 
> always expects the malloc() and realloc() to work and to return a valid 
> pointer.
> I would like the developers to add a specific test to each place, where 
> memory allocation takes place, and to act upon an error properly (ideally - 
> with a graceful closure of the connection to broker, if possible).
> Also, a proper signalization path to the user's application (which runs the 
> ProtonC client) would be a great addition.
> If nothing fancy is planned, I would, at least, ask for adding the simple {{ 
> if (x == NULL) { do something }; }} tests to each every place where memory 
> allocation is handled.

This message was sent by Atlassian JIRA

Reply via email to