[En-Nut-Discussion] socket closewait

[Michael Baverso]

----- Original Message -----
From: "Harald Kipp" <harald.kipp at egnite.de>
To: <en-nut-discussion at egnite.de>
Sent: Thursday, January 16, 2003 11:11 AM
Subject: Re: [En-Nut-Discussion] socket closewait


>
> >
> >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.

I am using

    for(;;)
      {
            if(NutHeapAvailable() > 8192)
                break;
            NutSleep(1000);
        }
in all threads......is this what you mean???


> 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).

I have lots of soldering experience,
just no component level electronics background

I think even I can manage this mod....thanks :)

Will move app code to UART1 tonite......

> >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.

when you say variable arguments do you mean va_list???

I modified NutPrintFormat to handle both types....renamed it PrintFormat

Interface funtion are:

int NutPrintFormat(NUTDEVICE *dev, CONST char *fmt, ...)
{
 va_list ap;
 int i;

 va_start(ap, fmt);
 i = PrintFormat(dev, 0, fmt, ap);    <======= Modified NutPrintFormat
 va_end(ap);

 return i;
}

int NutPrintFormat_P(NUTDEVICE *dev, CONST char *fmt, ...)
{
 va_list ap;
 int i;

 va_start(ap, fmt);
 i = PrintFormat(dev, PGM_FLAG, fmt, ap);<====== Modified NutPrintFormat
 va_end(ap);

 return i;
}

Is this really bad hack?....or just bad


> 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
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo/en-nut-discussion
>