- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am testing a modified tcp_server snip I have configured the device as WICED_AP_INTERFACE. While the connected client sends a TCP packet every 1ms, after some time (in a period of 10 seconds) the application hangs up. You cant even connect to the access point anymore. No Hard fault or error message is received, the rest of my application is still running fine.
Here is the simplified source for demonstartion:
static void tcp_server_thread_main(uint32_t arg)
{
tcp_server_handle_t* server = (tcp_server_handle_t*) arg;
while ( quit != WICED_TRUE )
{
wiced_packet_t* temp_packet = NULL;
/* Wait for a connection */
wiced_result_t result = wiced_tcp_accept( &server->socket );
#ifdef TCP_KEEPALIVE_ENABLED
result = wiced_tcp_enable_keepalive(&server->socket, TCP_SERVER_KEEP_ALIVE_INTERVAL, TCP_SERVER_KEEP_ALIVE_PROBES, TCP_SERVER_KEEP_ALIVE_TIME );
if( result != WICED_SUCCESS )
{
uartDebugString(("Keep alive initialization failed \r\n"));
}
#endif /* TCP_KEEPALIVE_ENABLED */
if ( result == WICED_SUCCESS )
{
/* Receive the query from the TCP client */
if (wiced_tcp_receive( &server->socket, &temp_packet, WICED_WAIT_FOREVER ) == WICED_SUCCESS)
{
/* Process the client request */
tcp_server_process( server, temp_packet );
/* Delete the packet, we're done with it */
wiced_packet_delete( temp_packet );
#ifdef TCP_KEEPALIVE_ENABLED
uartDebugString(("Waiting for data on a socket\r\n"));
/* Check keepalive: wait to see whether the keepalive protocol has commenced */
/* This is achieved by waiting forever for a packet to be received on the TCP connection*/
while(1)
{
if (wiced_tcp_receive( &server->socket, &temp_packet, WICED_WAIT_FOREVER ) == WICED_SUCCESS)
{
tcp_server_process( server, temp_packet );
/* Release the packet, we don't need it any more */
wiced_packet_delete( temp_packet );
}
else
{
uartDebugString(("Connection has been dropped by networking stack\r\n\r\n"));
break;
}
}
#endif /* TCP_KEEPALIVE_ENABLED */
}
else
{
/* Send failed or connection has been lost, close the existing connection and */
/* get ready to accept the next one */
wiced_tcp_disconnect( &server->socket );
}
}
}
uartDebugString(("Disconnect\r\n"));
wiced_tcp_disconnect( &server->socket );
WICED_END_OF_THREAD(tcp_thread);
}
static wiced_result_t tcp_server_process( tcp_server_handle_t* server, wiced_packet_t* rx_packet )
{
char* request;
uint16_t request_length;
uint16_t available_data_length;
wiced_packet_t* tx_packet;
char* tx_data;
char dbg[64];
wiced_packet_get_data( rx_packet, 0, (uint8_t**) &request, &request_length, &available_data_length );
/* Null terminate the received string */
request[request_length] = '\x0';
/* Send echo back */
if (wiced_packet_create_tcp(&server->socket, TCP_PACKET_MAX_DATA_LENGTH, &tx_packet, (uint8_t**)&tx_data, &available_data_length) != WICED_SUCCESS)
{
uartDebugString(("TCP packet creation failed\r\n"));
return WICED_ERROR;
}
/* Write the message into tx_data" */
tx_data[request_length] = '\x0';
memcpy(tx_data, request, request_length);
/* Set the end of the data portion */
wiced_packet_set_data_end(tx_packet, (uint8_t*)tx_data + request_length);
/* Send the TCP packet */
if (wiced_tcp_send_packet(&server->socket, tx_packet) != WICED_SUCCESS)
{
uartDebugString(("TCP packet send failed\r\n"));
/* Delete packet, since the send failed */
wiced_packet_delete(tx_packet);
server->quit=WICED_TRUE;
return WICED_ERROR;
}
uartDebugString(("Echo data: %s\r\n"));
return WICED_SUCCESS;
}
I am using: Wiced SDK 2.4.1 + LwIP + FreeRTOS.
I also tried the tcp_server_async snipped with the same results.
Is this a known issue? At this point of our development it would be expensive to change to the newer SDK. Would the SDK 3.x solve this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Suggest first try the ThreadX NetX_Duo combination to see if you can reproduce.
Second use the debugger and see if you are running out of memory somewhere or there is a memory leak
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi ,
I'm a newbie to broadcom and I'm facing similar issue ..
How can I check memory leak / out of memory ?
Please help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can run in debug mode and enable the malloc_debug
Or you can call mallinfo() function from gdb when you hang
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
$(NAME)_COMPONENTS += test/malloc_debug
Enable this in any of the component or application makefiles
Then build with debugging enabled and you will get an assert if there is any memory corruption or memory leaks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I just tried as you mentioned I got in the tcp_server example in SDK 3.1.0 (The fresh source code)
But I my program got asserted in malloc_error() ,
error_message = 0x8047de0 "Memory leak"
So It indicated of "Memory leak" , but why this is showing even in the fresh code from Wiced ? Or am I missing something?
Please pardon, I new this SDK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey nsankar - this sounds extremely useful.
Does the source come with the SDK, or do I download this separately?
I can't seem to find 'malloc_debug' in /test
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
libraries/test/malloc_debug
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Karolis ,
Did you managed to solve the issue , me too facing the same even running the tcp_server example
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey karolis,
Not sure if this explains the behaviour you're seeing, but one limitation we've encountered with the provided TCP socket server code is that once the number of listening sockets are all consumed, no new connections are handled. This is particularly noticeable when it is running beneath the webserver, and random background applications from (perhaps) multiple clients consume all of the port 80 sockets preventing a user from accessing the webserver in their browser. I believe our workaround has been to close 'stale' sockets to ensure at least one unused socket is always listening.
Cheers!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi everyone,
Sorry for the late post. When I switched to SDK 3.1 everything seems to work now.