[En-Nut-Discussion] Thread stops executing after some time.
Erik L
erik.lindstein at gmail.com
Fri Mar 28 10:45:41 CET 2008
Let me describe the procedure to get the problems to occur.
Clients(Ethernuts) and PC are both connected to the LAN and the server
software is running on the PC.
Now everything works fine without any problems at all. The client connects
sends data, receives data and disconnects then runs the loop all over again.
I then go home at night and disconnect the PC to take it home with me. I let
the clients still run, now they are trying to connect to the PC/IP that
arent any longer on the LAN.
The clients now runs the same software loop but the socket never gets
connected and no data is exchanged.
Lets say i just disconnect my PC for 1h or so. Then connect it again. Now
everything works fine as usual, all clients connects as they should and im
happy.
But if i don´t connect the PC until next day, so the clients have tryed to
connect all night without success. Now i can count on that at least some of
the clients no longer tryes to connect and if i
leave them a bit longer i can count on them all not connecting any more.
And then when i connect to the clients server instead (which still works) to
list the sockets and threads i see that there is one socket is in "SYN SENT"
state and this one is stuck there and i guess thats why the thread handeling
the client-connecting-to-server commmunication is sleeping infinitly.
The PC side is pretty simple. its an .NET c# app using the TcpListener class
to create a listening socket.
The only time where i can se the PC creating this problem is at the point
when i disconnect the PC from the LAN. If that would create some strange
state for the clients. But again, the clients always still connects if i
just have the PC disconnected for a short period of time.
Its when i have it disconnected a long period of time they drop out.
There are no other hosts on the LAN than the 4-5 ethernut clients when i
disconnect the PC.
They just sit on the same switch alone.
Regards/Erik
ernstst wrote:
>
> Hi Erik!
>
> Looking up the definition of "SYN SENT" in tcp_fsm.h it says:
>
> /*
> * Warning: Do NOT change the values or the order of the TCP states.
> * Some functions in tcpsm.c rely on the the order below.
> */
> #define TCPS_CLOSED 0 /*!< \brief closed */
> #define TCPS_LISTEN 1 /*!< \brief listening for connection */
> #define TCPS_SYN_SENT 2 /*!< \brief active, have sent syn */
> #define TCPS_SYN_RECEIVED 3 /*!< \brief have sent and received syn */
> #define TCPS_ESTABLISHED 4 /*!< \brief established */
> #define TCPS_CLOSE_WAIT 5 /*!< \brief rcvd fin, waiting for close */
> #define TCPS_FIN_WAIT_1 6 /*!< \brief have closed, sent fin */
> #define TCPS_CLOSING 7 /*!< \brief closed xchd FIN; await FIN ACK
> */
> #define TCPS_LAST_ACK 8 /*!< \brief had fin and close; await FIN
> ACK
> */
> #define TCPS_FIN_WAIT_2 9 /*!< \brief have closed, fin is acked */
> #define TCPS_TIME_WAIT 10 /*!< \brief in 2*msl quiet wait after
> close
> */
>
>
> Comparing "2" and "3" I would guess in state 2 the device (Ethernut) sent
> the SYN and is waiting for an answer and in state 3 the answer to the SYN
> was received.
>
> In the thread's discussion, we are all focussing of the Ethernut side, but
> -just not to rule something out completely - may the problem be caused on
> the PC side? What would happen if the PC-app would not react to an
> incoming
> connect request any more?
>
> I looked up how a connection is established:
> Client state Server state
> Closed listen
> Syn=1 ack=0 ->
> SYN_SENT SYN_RCVD
> <- Syn=1 Ack= 1
> Established
> Syn=0 ack= 1 ->
> Established
>
>
> Can you look at the port states in the PC app?
>
> Regards
> Ernst
>
> -----Ursprüngliche Nachricht-----
> Von: en-nut-discussion-bounces at egnite.de
> [mailto:en-nut-discussion-bounces at egnite.de] Im Auftrag von Erik L
> Gesendet: Donnerstag, 27. März 2008 11:13
> An: en-nut-discussion at egnite.de
> Betreff: Re: [En-Nut-Discussion] Thread stops executing after some time.
>
>
> For some reason the client socket that should loop and try to connect to
> the
> server gets stuck.
> I left four systems running over night and now two of them are no longer
> trying to connect to the server.
> And when i connect to them and list the sockets i can se the folowing:
>
> NOT OK.
> ---------------------------------
> 222 List of sockets
> SYN SENT 394B TCP 192.168.0.105:8681
> 192.168.0.115:9050
> <<<- This one is always there.
> ESTABLISHED 3AB0 TCP 192.168.0.105:23
> 192.168.0.115:6473
> <<<- This i me connected
> ---------------------------------
>
>
> OK.
> ---------------------------------
> 222 List of sockets
> SYN SENT 397E TCP 192.168.0.102:11431
> 192.168.0.115:9050
> <<<- This one is working ESTABLISHED 3AB0 TCP 192.168.0.102:23
>
> 192.168.0.115:6477 <<<- Me connected
>
> 222 List of sockets
> ESTABLISHED 3AB0 TCP 192.168.0.102:23
> 192.168.0.115:6477
> <<<- Me connected ( Other socket removed correct... )
> ---------------------------------
>
>
> The ones that dont connect any more list two sockets ( The one ESTABLISHED
> is me connected from my PC ) The other one with SYN SENT is what i guess
> the
> last atempt from the ethernut to connect to my server software. Why it
> just
> gets stuck there i cant understand. The timeouts works fine for 24h then
> it
> just stops.
>
> Any ideas?
>
>
>
> Erik Lindstein wrote:
>>
>>>
>>>Hi,
>>>
>>>just an Idea. You seem to have two threads with very low available stack
>>>memory. "SmuTh" and "TaTh". It might be possible that those two threads
>>>produce a stack overflow and overwrite some data of another thread. I
>>>had a similar problem in one of my projects and this also lead to a
>>>hanging thread.
>>>
>>>You should try to increase the threads stack as a first try.
>>>
>>>Regards,
>>>
>>>Ole Reinhardt
>>
>> Hi Ole.
>> I don't think the problem is the stacksize ( atleast not for them
>> threads ) because I have the same problem with a minimized setup with
>> only the folowing threads:
>>
>>
>> ------Output after a couple of hours test without PC connected-------
>> 220 List of threads with name,state,prio,stack,mem,timeout follows
>> tcpsm Sleep 32 461 OK 204
>> inetd Sleep 64 2385 OK None <<<<--( DEAD )
>> rxi5 Sleep 9 603 OK 1843
>> main Run 64 650 OK None
>> idle Ready 254 356 OK None
>> -----
>>
>>
>> -----Output when PC is connected and thread running as i should -----
>> 220 List of threads with name,state,prio,stack,mem,timeout follows
>> tcpsm Sleep 32 461 OK 60
>> inetd Sleep 64 2399 OK 144 ( RUNNING )
>> rxi5 Sleep 9 603 OK 1843
>> main Run 64 650 OK None
>> idle Ready 254 356 OK None
>> -----
>>
>>
>> Regards/Erik
>>
>>> When the inetd thread stops executing i can connect to the unit and i
>>> get the output seen below:
>>>
> ----------------------------------------------------------------------------
> --------------------------------------------
>>> 220 List of threads with name,state,prio,stack,mem,timeout follows
>>> tcpsm Sleep 32 461 OK 27
>>> TcpS Run 64 2546 OK None
>>> inetd Sleep 64 2381 OK None
>>> rxi5 Sleep 9 603 OK 1392
>>> wdt Sleep 40 255 OK 8
>>> SmuTh Sleep 64 65 OK 71
>>> PcuTh Sleep 64 805 OK 1
>>> HvpsTh Sleep 64 605 OK 24
>>> IppsTh Sleep 64 965 OK 4
>>> TaTh Sleep 64 65 OK 35
>>> LcdTh Sleep 64 929 OK 34
>>> main Sleep 64 733 OK 451
>>> idle Ready 254 356 OK None
>> --
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Thread-stops-executing-after-some-time.-tp16299152p163
> 23605.html
> Sent from the MicroControllers - Ethernut mailing list archive at
> Nabble.com.
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.0/1344 - Release Date:
> 26.03.2008
> 08:52
>
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>
--
View this message in context: http://www.nabble.com/Thread-stops-executing-after-some-time.-tp16299152p16348724.html
Sent from the MicroControllers - Ethernut mailing list archive at Nabble.com.
More information about the En-Nut-Discussion
mailing list