[dpdk-dev] [PATCH] rte_mempool_dump() crashes with NULL rte_mempool pointer.

Wiles, Roger Keith keith.wiles at windriver.com
Sun Sep 28 03:14:05 CEST 2014


On Sep 27, 2014, at 7:37 PM, Neil Horman <nhorman at tuxdriver.com> wrote:

> On Sat, Sep 27, 2014 at 06:35:01PM +0000, Wiles, Roger Keith wrote:
>> 
>> Check the FILE *f and rte_mempool *mp pointers for NULL and
>> return plus print out a message if RTE_LIBRTE_MEMPOOL_DEBUG is enabled.
>> 
>> Signed-off-by: Keith Wiles <keith.wiles at windriver.com>
>> ---
>> lib/librte_mempool/rte_mempool.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>> 
>> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
>> index 332f469..efa6a6c 100644
>> --- a/lib/librte_mempool/rte_mempool.c
>> +++ b/lib/librte_mempool/rte_mempool.c
>> @@ -765,6 +765,12 @@ rte_mempool_dump(FILE *f, const struct rte_mempool *mp)
>>    unsigned common_count;
>>    unsigned cache_count;
>> 
>> +   if ( (f == NULL) || (mp == NULL) ) {
>> +#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
>> +       fprintf(stderr, "*** Called rte_mempool_dump(%p, %p) with NULL argument\n", f, mp);
>> +#endif /* RTE_LIBRTE_MEMPOOL_DEBUG */
>> +       return;
>> +   }
>>    fprintf(f, "mempool <%s>@%p\n", mp->name, mp);
>>    fprintf(f, "  flags=%x\n", mp->flags);
>>    fprintf(f, "  ring=<%s>@%p\n", mp->ring->name, mp->ring);
>> -- 
>> 2.1.0
>> 
>> 
> Maybe use RTE_VERIFY instead?
> Neil
> 
I did not think it needs to panic as it is just a debug function and returning would be fine by me, comments?
Do we have a similar RTE_VERIFY like function that does not panic?

Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-213-5533



More information about the dev mailing list