AW: [En-Nut-Discussion] Is this a bug or a 'Feature' ?

[Robert Hildebrand]

Hi Ralph,

I have an application running since 11/2002. It is a HTTP-Server with very
low traffic, typically 4-10 connetions per week, controlling a device over
the UART. (www.inhaus-duisburg.de)

Robert

-----Ursprüngliche Nachricht-----
Von: en-nut-discussion-admin at egnite.de
[mailto:en-nut-discussion-admin at egnite.de]Im Auftrag von Ralph Mason
Gesendet: Donnerstag, 3. April 2003 10:13
An: en-nut-discussion at egnite.de
Betreff: RE: [En-Nut-Discussion] Is this a bug or a 'Feature' ?



If the thread that allocates the memory also frees the memory then it should
be possible here (in debug) to track memory usage per thread.  Combine that
with the thread kill I did and I think there is a way to put in checks for
this kind of stuff.

Basically I am thinking of a memory pointer in the thread structure and the
allocate allocating another pointer size with each allocation and chaining
these up as memory is allocated, freeing as it is freed.  When the thread
exits is traces left over memory blocks somewhere (and possibly frees them?)

On this note - has anyone had nut application that have run for months on
end?

Ralph

> -----Original Message-----
> From: en-nut-discussion-admin at egnite.de
> [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Mike Cornelius
> Sent: Thursday, 3 April 2003 5:41
> To: en-nut-discussion at egnite.de
> Subject: [En-Nut-Discussion] Is this a bug or a 'Feature' ?
>
>
> Hi All,
>
> I've found that the following code:-
>
> while (1)
> {
> 	addr = inet_addr("192.168.1.117");
>
> 	loc_sock = NutTcpCreateSocket();
> 	loc_sock->so_read_to = 1000;
>
> 	if(NutTcpConnect(loc_sock, addr, MODBUS_PORT) == 0)
> 	{
> 		// Stuff that doesn't matter
> 	}
>
> 	NutTcpCloseSocket(loc_sock);
> }
>
> Does not actually free the memory associated with the socket if
> NutTcpConnect() fails, particularly in the case where I disconnect the
> ethernet cable.
>
> NutTcpCloseSocket() calls NutTcpStateCloseEvent() and if sock->so_state ==
> TCPS_CLOSED at that time NutTcpStateCloseEvent() sets:-
>
> sock->so_last_error = ENOTCONN;
>
> Which sort of makes sense but requires the application to check the
> NutTcpCloseSocket() return value and 'manually' call NutTcpDestroySocket()
> otherwise we've got a memory leak.
>
> To me it makes sense to modify NutTcpStateCloseEvent() as follows: -
>     case TCPS_CLOSED: // <-New Case
>     case TCPS_LISTEN:
>     case TCPS_SYN_SENT:
>         /*
>          * No connection yet, immediately destroy the socket.
>          */
>         NutTcpDestroySocket(sock);
>         break;
>
> I wonder what others (Particularly Harald) think...
>
>
> Regards,
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mike Cornelius                      Internet: mikec at calldirect.com.au
> Call Direct Cellular Solutions      Phone:    +61 2 99-65-75-85
> Level 1 8-22 West St North Sydney   FAX:      +61 2 99-65-75-90
> NSW 2060 Australia                  URL:      http://www.calldirect.com.au
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo/en-nut-discussion
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo/en-nut-discussion