Hi Christopher,

That is the expected behaviour, however if you try running the sample app I 
gave you would notice the following 
After step 11, I.e initialise the os_mbuf by doing a os_mbuf_get from a 
mempool, the new value is overwritten on the previous value.

1. Accessing the mbuf after doing a free chain, om_data still holds the value.
2. Initialising it again by doing a os_mbuf_get is not getting me a clean mbuf, 
rather it holds the previous value and om_mbuf_copyinto merely overwrites it. 
So incase the new string length is smaller, om_data would return wrong value.

Am sorry if am not able to explain it properly however I would appreciate it if 
you can test the app once.

Aditya Xavier 

> On 07-Apr-2018, at 7:32 AM, Christopher Collins <ch...@runtime.io> wrote:
> Hi Aditya,
>> On Fri, Apr 06, 2018 at 07:36:41PM +0530, Aditya Xavier wrote:
>> Hi Mynewt Team,
>> Please help me understand the behavior of MBUF.
>> PFB the steps I did :-
>> 1.    os_mempool_init
>> 2.    os_mbuf_pool_init
>> 3.    Initialized a os_mbuf by os_mbuf_get
>> 4.    Triggered Console Reader.
>> 5.    os_mbuf_copyinto the console_buf into the os_mbuf
>> 6.    Did a eventq_put to get into a event callback.
>> 7.    Read os_mbuf value & os_mbuf len
>> 8.    os_mbuf_free_chain
>> 9.    Read os_mbuf value & os_mbuf len
>> 10.    Initialized a os_mbuf by os_mbuf_get
>> 11.    Repeat step 4 onwards.
>> Problem :-
>> In step 7, I read the previous string, however the length is correct.
>> In step 9, I read the previous string, however the length is 0.
> `os_mbuf_free_chain` frees the mbuf chain back to its source pool.  From
> that point, accessing the mbuf via this pointer is an error.
> This is analogous to the following example:
>    int *x = malloc(sizeof(*x));
>    *x = 99;
>    free(x);
>    printf("*x = %d\n", *x);
> In other words, don't access something after you free it! :)  You'll
> need to allocate a new mbuf if you need one after freeing the first.
> Chris

Reply via email to