[En-Nut-Discussion] socket closewait

[Harald Kipp]

>
>I incorporated the Show Threads web page in my app....Because the problem 
>causes the Thread to fail wouldn't I  expect to see stack corruption if it 
>were a heap problem?

Should. However:

foo(void)
{
   large_array[999];
   int i = 5;
}

may spoil the heap without corruption being detected, if large_array
was never used. So, the 0xDEADBEEF marked areas do not help in any
case to detect stack overflow.


>I also incorporated the Show Sockets web page in my app....I also saw an 
>HTTP socket stuck in the ESTABLISHED state,
>this only happend with Nut OS 2.6

I see. There had been a change in the state machine. In 2.5.2
connection may get stuck in low mem situations. I'll look into
it once more.

I guess, that your problem is related to low mem situations.
At several points, when NutHeapAlloc fails, Nut/OS gives up,
not able to recover. For example, if you're sending many
small TCP packets, memory got used up by NETBUFs. Lower level
(ARP for example) are not able to get the heap space they
need to work. Packets never get send, memory never get
released. The system gets stuck.

Take this as an example of what could happen, I'm not sure
if its really within ARP. Best thing I can imagine would be
to avoid low mem in the application by simply delaying
certain parts during low mem.

Imagine an app reading characters from the UART sending them
to a TCP connection. When running at 9600 Baud, this will
create around 900 NETBUFS per second! When collecting, let's
say 32 characters first (or UART receive timeout) before
sending them to TCP, everything works fine.


>The unfortunate thing with debugging is I am using UART0 for my app,
>the Ethernut is basically acting as a protocol converter.....any 
>alternatives for debug output??......I guess I could implement debug on 
>UART1????.....That would require hardware/software changes/additions.

Often asked, more often ignored by me. :-( Can you switch
your app to UART1?

Easiest mod: Try to get someone with solder experience and
connect PD2 and PD3 to PIN9 and PIN 10 resp. of the MAX202
and make a special adapter for the DSUB with a second port
at PIN 7 (RX) and 8 (TX).


>The reason for all the info is perhaps someone can tell me where I should 
>focus debug efforts and what to look for:)

That's how I understand it.


>Were you considering incorporating a NutPrintFormat_P in a future release 
>to replace my hacked version:)

Do you use variable arguments? If not, scrap it. Too much
duplicate code.

Yes, I'm investigating the possibility to use standard fprintf
for all devices. Unfortunately avr-libc only supports the three
standard devices stdin, stdout and stderr. And it's totally
incomatible with the ICCAVR approach.

Harald