lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Closing netconn, application or lwip bug?


From: Szymon Tarnowski
Subject: [lwip-users] Closing netconn, application or lwip bug?
Date: Mon, 14 Jan 2013 15:38:17 +0100

Hi,

I am sorry for last message, accidently pressed send during message editing.
Please do not respond for previous topic.

I am developing a commercial application for embedded device using lwip.
My device is listening on specific tcp port for incomming message, if client
connects can send request and get response then decide if want to keep
connection or disconnect. My device is based on AVR32 processor, and
under this device application is working correct. As a part of my quality
assurance test I must recompile this application under linux and test
memory leaks and stability. Under valgrind I receive some exceptions
about invalid memory reads deep inside lwip, then application crash with
exception segmentation fault. Inside my application I have such code in
my application:

(listening task)
if (netconn_acept(listening_conn, &new_conn) == ERR_OK)
{
 add_new_client(new_conn)
}

(client support task)
for (i=0; i<clients; i++)
{
if (client_wants_close)
{
send_goodbye(netconn);
netconn_close(netconn)
}
}

This code works correctly both on linux and embedded device, but netconn
allocated during netconn_accept is not freed, so sooner or later netconn pool
will be exhausted. After reading manual I found that there is a function netconn_delete()
which is closing connection and deallocating resources. Under AVR32 machine
code with this function works correctly, but under linux generate exceptions.
Valgrind detects invalid memory read at:
if file queue.c in function xQueueGenericSend, lines 453, in my version this line
says:
if (pxQueue->uxMessagesWaiting < ...)
For tests I have patched my queue.c with addtional test
if ((pxQueue)&&(pxQueue->uxMessagesWaiting < ...)) and it is not generating exception
so problem is inside pxQueue. This modification also breaks some resource allocation,
so netconn pool will be exhausted.

My final question is what is correct procedure to close netconn connection? I have already
tried some tricks like call netconn_close(), do some sleep and then netconn_delete, but
this still does not work.
--
Szymon


reply via email to

[Prev in Thread] Current Thread [Next in Thread]