NDK Error

I would agree that this sounds like low resources, though I am not really familiar with the error I would guess OOM means out of memory. To investiate further I would be intersted to know if you can make the system stay up longer (or indefinitely) by increasing heap and/or stack sizes.

I have a large heap in my application. I tried increasing and decreasing the size of the heap in 128kb increments. After exactly 57 connections, this error message comes up.Looks like heap size doesn't matter. I also tried increasing the stack size. Still only 57 connections.

Could you direct this question to someone who develops the NDK, or who has access to the source? I'd like to find out what could cause this error.

I just upgraded NDK 1.94 to 2.00 in my application to see if it will help.

Now, instead of rebooting the DSP after 57 connections, it allows more connections, but prints the "TcpPrAttach: OOM" error message three times for each connect.

FYI, I am using NDK server daemons. I had my application print a count of how many times the daemon was spawned. The daemon function is not executed when the TcpPrAttach error occurs.

Here is some of the output:

ServerConnectCount: 1
ServerConnectCount: 2
ServerConnectCount: 3
ServerConnectCount: 4
ServerConnectCount: 5
ServerConnectCount: 6
...
ServerConnectCount: 53
ServerConnectCount: 54
ServerConnectCount: 55
ServerConnectCount: 56
ServerConnectCount: 57
00265.209 TcpPrAttach: OOM
00265.851 TcpPrAttach: OOM
00266.351 TcpPrAttach: OOM
00268.166 TcpPrAttach: OOM
00268.776 TcpPrAttach: OOM
00269.165 TcpPrAttach: OOM
00271.096 TcpPrAttach: OOM
00271.480 TcpPrAttach: OOM
00271.980 TcpPrAttach: OOM
00274.039 TcpPrAttach: OOM
00274.514 TcpPrAttach: OOM
00274.905 TcpPrAttach: OOM

I did some more digging on this and it looks like the NDK is using its own internal memory pool management system, so it can run out of memory regardless of stack/heap size, I apologize for the confusion there.

What we believe is happening is that you have TCP sockets being created and closed too quickly for the stack to keep up with the freeing of the memory pools for each new socket, thus leading to a failure after n connections, this is actually mentioned at the very end of section 3.4.1 of SPRU523 on page 53. This being said, to validate that this is the situation, if you lower the rate that your client connects/disconnects does the number of connections before the OOM message increase? If this is the case than the general fix to this would be to use the SO_LINGER socket option, such that the stack does not wait as long to free the memory pool for each new socket.

I tried the SO_LINGER option:

    ling.l_onoff = 1;
    ling.l_linger = 0; // also tried longer time (this should be in seconds?)
    setsockopt(s, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));

Didn't help. Also tried delaying the time between connecting from the client. Customers using the development version of the product are not performing operations that often, but eventually (after that specific number of connects) it fails.

I also tested the number of connections issue on an OMAP-L137/TMS320C6747 Floating Point Starter Kit, and there was not a problem. I used the same library versions, and the same functions & parameters to boot the network and create a daemon. Only difference is the ethernet driver.

Are there any other reasons causing the OOM message to occur?

Other than this issue, the NDK works very well getting data to/from the client.