[En-Nut-Discussion] socket closewait

[Mike Baverso]

>In the first place most apps get blocked because one thread
>misses to call NutThreadYield() while running in an endless
>loop. More infos are in

http://www.ethernut.de/pdf/entet100.pdf

All of my threads use NutThreadYield.....I changed this particular one to NutSleep just to look for activity in the Threads Page. 


>Also note, that 2.6.0 fixes a bug in the event handling.
>This bug is typically no problem unless the application
>depends on no SIGNALED state getting lost.

>Finally thread may override the heap, destroying any
>kind of internal structure. See

http://www.ethernut.de/pdf/enmem100.pdf

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?

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

>Tracing with JTAG is not very helpful with sporadic errors.
>Better rebuild Nut/OS with NUTDEBUG (see Makedefs) defined.

>Call at least NutKHeapTrace(1) at the start of your app.
>This will add some extra security bytes to each allocated
>block to detect overrides. Use a terminal program to store
>UART0 outputs. Also look to os/osdebug.c for more useful
>debugging routines, specially NutKDumpThreadList().

>Harald

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.
 I am not a hardware person at all....not sure how to do this......learning though.....thanks to Ethernut :)

All other (4) threads (2) for HTTP, (1)for xmit serial data, (1)for rx serial data........remain active and functional except for the occassional 
HTTP socket ESTABLISHED problem. 

The ModbusTCP thread works for hundreds of thousands of segments, I have it being polled from my PC
at 250ms(just for test....pushing limits)....it fails sporadically.

However, I can force the Modbus thread to fail when I do refreshes of the webpages in fast succession(pushing limits again). 
I am testing it this way because this will go into an environment where people will, intentionally or not push the limits. 
You know.....the whole 'Let me see if I can break this' syndrome.

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



As a side note I modified(hacked) NutPrintFormat into a more generic routine which can be called with NutPrintFormat for format strings in RAM or NutPrintFormat_P for format strings in FLASH. I am creating alot of dynamic content in my pages....was killing the 4k memory.
I did see your (Harald) question regarding vprintf on the GCC list. 
Were you considering incorporating a NutPrintFormat_P in a future release to replace my hacked version:)

At 00:26 16.01.2003 -0500, you wrote:
>I thought this went away but it is back....not sure why. I have a socket 
>that stays in the closewait state. I was debugging and the thread that 
>creates and closes the socket stops running, I verified this by calling 
>nutsleep in the thread and watching its activity from an web page. It 
>stays in SLP and the event queue never changes. What would cause 
>this....what am I doing wrong??

Regards,

Mike Baverso
Elcon Technologies, Inc.
106 Rochester Road
Pittsburgh, PA 15229

Phone:412 931 8250
Fax:    412 931 8254
Cell:    412 559 4865
mbaverso at elcontech.com
www.elcontech.com

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.