Error: Invalid buffer assert in host_buffer_release()

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

When running WICED 6.0.1 code in the debugger that was checking the RSSI and noise of a connection I ran into problems with an "Error: Invalid buffer" assert when I took down the access point to which I was connecting. To make sure it wasn't a bug in the very complicated code that I was working with, I reproduced the problem using snip.udp_transmit. The bug is in wwd_wifi_get_ioctl_buffer() [43xxx_Wi-Fi/WICED/WWD/internal/wwd_wifi.c]. When WWD_TIMEOUT is returned, the "response" buffer is NULL, but it gets released in spite of that. It shouldn't be released, because it doesn't exist.

wwd_result_t wwd_wifi_get_ioctl_buffer( uint32_t ioctl, uint8_t* out_buffer, uint16_t out_length, wwd_interface_t interface )

{

    wiced_buffer_t buffer;

    uint32_t*      data;

    wiced_buffer_t response;

    wwd_result_t result;

    data = (uint32_t*) wwd_sdpcm_get_ioctl_buffer( &buffer, out_length );

    CHECK_IOCTL_BUFFER( data );

    result = wwd_sdpcm_send_ioctl( SDPCM_GET, ioctl, buffer, &response, interface );/*Are there any cases where an error would be returned where response would be non-NULL?*/

    /* it worked: copy the result to the output buffer */

    if ( WWD_SUCCESS == result )

    {

        data = (uint32_t*) host_buffer_get_current_piece_data_pointer( response );

        memcpy( out_buffer, data, out_length );

    }

    host_buffer_release( response, WWD_NETWORK_RX ); /*Should this line be only executed on WWD_SUCCESS?*/

    return result;

}

To generate this error I made some minor changes to udp_transmit.c and used my CLIENT_AP_SSID & PASSPHRASE in wifi_config_dct.h. Then I built and ran the snip according to the instructions. While it was running I unplugged the access point. After a minute or so the assert occurred. I have attached a copy of the udp_transmit.c code I modified.

pastedImage_2.png

0 Likes
1 Solution
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

Thanks for bringing it to our notice. We are evaluating these issues internally and raised a ticket for the same. This issue should be resolved in the upcoming release of WICED Studio (6.2 most likely).

View solution in original post

0 Likes
6 Replies
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

I was able to transmit the data using your modified version of udp_transmit app when the AP came back up. I hope our understandings are aligned tll this part. The implementation issue about ioctl failure is already taken care by the wwd_sdpcm_send_ioctl() API call; but the SIGTRAP error that you are receiving is for a different reason. Please make the proper debug configuration settings before going into debug mode

  1. Click on Debug Configurations
  2. On the left window please choose 43xx-Wi-Fi_Debug_Window
  3. switch to Startup page, add below instruction into the area below Halt option: add-symbol-file build/eclipse_debug/last_built.elf 0x80000000
  4. In the same Startup page,  clear Run Commands area, default is like the phrase "stepi "
  5. Switch to common page, click the "Launch in background" option

Removing the stepi command should solve the SIGTRAP error and you should be able to debug your application. Please let us know if this does not solve your issue.

0 Likes
Anonymous
Not applicable

It doesn't matter how you have your debugger set up. If you get an assert there is a logical check that has failed in the code. In this case a NULL was passed to host_buffer_release() and NULL is invalid input to this function. The solution is to write logic in wwd_wifi_get_ioctl_buffer() that will prevent NULL from ever being sent to host_buffer_release(). My questions are about how best to do that. If every time wwd_sdpcm_send_ioctl() returns an unsuccessful non-zero result the "response" buffer is NULL, then you should only release that buffer when wwd_sdpcm_send_ioctl() is successful. If there are cases where wwd_sdpcm_send_ioctl() would return an unsuccessful, non-zero result along with a partial "response" buffer, then failing to release that partial buffer would be a memory leak.

I think the best solution is to always release "response" when wwd_sdpcm_send_ioctl() is successful, but when it is unsuccessful only release "response" if it is non NULL.

0 Likes

Your report is very clear to me.

(It's a regression because older sdk does not has such issue).

0 Likes
Anonymous
Not applicable

I looked through the rest of 43xxx_Wi-Fi/WICED/WWD/internal/wwd_wifi.c for other cases where wwd_sdpcm_send_ioctl() returns a response buffer and I found two more cases of the same problem in:

wwd_wifi_get_iovar_buffer()

wwd_mesh_status()

In addition there is a memory leak where the response buffer is allocated by wwd_sdpcm_send_ioctl() and searched for an ID. When the ID is found the buffer is released, but in the event that the buffer is not found, the response buffer does not get released. See:

wwd_wifi_get_packet_filter_mask_and_pattern()

0 Likes
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

Thanks for bringing it to our notice. We are evaluating these issues internally and raised a ticket for the same. This issue should be resolved in the upcoming release of WICED Studio (6.2 most likely).

0 Likes

Raktim Roy wrote:

Thanks for bringing it to our notice. We are evaluating these issues internally and raised a ticket for the same. This issue should be resolved in the upcoming release of WICED Studio (6.2 most likely).

FYI, sdk-6.1 does not include the fix.

0 Likes