This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Memory issues using NDK2

Hello,

I am developing a simple TCP/IP application using SYS/BIOS 6.30.02.42 and NDK 2.20.2.22. The client (Scientific Linux) connects to the server's (C6474 EVM) listening port and sends data which is processed and sent back. After a (high) number of subsequent connections, the server runs out of memory.

I assume this is because of accept() allocating the Tx/Rx Buffers which are not freed by closing a socket using shutdown(). How can i free the buffers allocated with accept()?

Best regards

  • Max,

    Can I ask how many subsequent connections till you run out of memory? And are all the connections valid, because if they are, freeing the memory allocated by the accept will not be useful. Also how large are your socket(send and receive) buffers?

    Moses

  • Hello Moses,

    Thanks for your answer. The first 59 connections work fine. What do you mean by valid? The connection is established, data is exchanged, and the socket closed on both sides (via shutdown() on the board). My send and receive buffers are 8192 Byte each.

    How do i free the memory?

    Best regards

  • Max,

    I meant a valid connection, like an expected connection performing a useful transaction. If it's valid then you can't free the buffers till after the socket has closed. You can use malloc to dynamically create the buffers when the socket is opened and use free before the socket shutdown to recover memory. Are the 59 connections simultaneous?

    Moses

  • Hello Moses,

    All of the connections are valid, they perform as expected and the sockets are then closed. How can i hand over my manually allocated buffers to the NDK2? And how do i prevent accept() to automatically allocate and use a buffer? All of the connection are sequential, so a single buffer would be sufficient.

    Regards

  • Max,

    We confused ourselves I believe. You can't manually allocate the memory that accept uses. When you close the socket, that memory should be freed. I wanted you to make sure that you're freeing the memory you create in your application for  send and receive buffers. This isn't created by accept.

    Also are you creating a task to handle each socket connection? If you are, make sure to delete the tasks when you're done to ensure that you're not leaking memory. If you have a task for each socket connection, make sure that you call fdOpenSession(TaskSelf()) at the beginning of your task and fdCloseSession(TaskSelf()) at the end.

    Let me know if this helps

    Moses

  • Hello Moses,

    we indeed confused ourselves. The buffers i hand to send() and recv() are reused for each connection. Also, i am not creating a separate task for each connection. My applications consists of a single task looping over the accept() calls and serving the connections.

    It seems that the shutdown() call does not free the memory allocated with accept(). Maybe this is a bug in the NDK?

    Best regards

  • Max,

    We can test this. Open ROV, select HeapMem and send me a screen capture before and after a connection(after socket shutdown() ). Assuming there is no leak, the totalFreeSize should not change.

    HeapMem:

    Moses

  • Hello Moses,

    there is indeed something fishy there. Immediately before accept(), totalFreeSize tells me 0xec898. After returning from accept 0xe8888, before shutdown() 0xe8888 unchanged and after shutdown returns, 0xea890.

    The allocation makes sense for send/receive buffers of 8192 Byte each. However, only half of the space is freed by shutdown().

  • Max,

    Can I see the snippet of code where you call accept(), shutdown() and where you allocate your send and receive buffers?

    Moses

  • It turned out while shutdown() frees some of the memory (the actual Rx/Tx buffers, i guess), an additional call of fdClose() is necessary to free all of the memory allocated by accept().

    Best regards and thanks for your assistance!