From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8319 invoked by alias); 16 Jun 2005 15:36:25 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 8071 invoked by uid 22791); 16 Jun 2005 15:35:55 -0000 Received: from snvl-smtp1.trimble.com (HELO snvl-smtp1.trimble.com) (63.251.235.20) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 16 Jun 2005 15:35:55 +0000 Received: (qmail 18083 invoked by uid 501); 16 Jun 2005 08:35:51 -0700 Received: from 10.1.184.32 by snvl-smtp1.trimble.com (envelope-from , uid 107) with qmail-scanner-1.24 (clamdscan: 0.85.1/941. trophie: 7.510-1002/691/103431. spamassassin: 3.0.3. Clear:RC:1(10.1.184.32):. Processed in 0.015899 secs); 16 Jun 2005 15:35:51 -0000 Received: from unknown (HELO uss-am-xch-02.am.trimblecorp.net) (10.1.184.32) by snvl-smtp1.trimble.com with SMTP; 16 Jun 2005 08:35:51 -0700 Received: from uss-am-xch-03.am.trimblecorp.net ([10.1.137.33]) by uss-am-xch-02.am.trimblecorp.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Jun 2005 08:35:51 -0700 Received: from 10.1.150.165 ([10.1.150.165]) by uss-am-xch-03.am.trimblecorp.net ([10.1.137.33]) via Exchange Front-End Server usd-am-web-01.am.trimblecorp.net ([10.1.1.144]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Jun 2005 15:35:51 +0000 Received: from wlentz by usd-am-web-01.am.trimblecorp.net; 16 Jun 2005 08:35:50 -0700 From: Will Lentz To: Hans =?ISO-8859-1?Q?H=FCbner?= Cc: ecos-discuss@ecos.sourceware.org In-Reply-To: <20050616083626.U69813@web.m68k.de> References: <1118875026.9020.21.camel@localhost.localdomain> <20050616083626.U69813@web.m68k.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jun 2005 15:36:00 -0000 Message-Id: <1118936150.22661.16.camel@localhost.localdomain> Mime-Version: 1.0 Subject: Re: [ECOS] uipc_socket.c (and cyg_tcp_maxidle) X-SW-Source: 2005-06/txt/msg00120.txt.bz2 Hi Hans, zfreei() is a function, and doesn't directly modify its first argument. But - it passes "so" as its second argument, and it modifies the value of so->so_zone through that. Looking at zfreei: { elem *p =3D (elem *)item; // item here is "so" log(LOG_MDEBUG, "zfreei to %s <=3D %p\n", zone->name, p); p->next =3D zone->pool; // p->next corresponds to so->so_zone in memory zone->pool =3D p; zone->free++; zone->alloc_frees++; } It's true that wakeup() doesn't care if it is passed a valid argument, but if it gets the wrong value then it doesn't wake up the correct people :-). Maybe zfreei() shouldn't be passed "so" as its second argument in sodealloc? Can anyone comment on why this is done? It looks fishy casting a "so" pointer to an "elem *" and then mucking with it... Every other example of zfreei() I can find passes the value returned from zalloci() as the second argument of zfreei(). Thanks, Will P.S. I also found that changing cyg_tcp_maxidle helps, but I still think there is some problem. On Thu, 2005-06-16 at 09:01 +0200, Hans H=FCbner wrote: > On Wed, 15 Jun 2005, Will Lentz wrote: >=20 > > I may have found a potential bug in > > packages/net/bsd_tcpip/current/src/sys/kern/uipc_socket.c (or I may be > > completely wrong :-). > > > > At the end of sodealloc(), the following code exists: > > zfreei(so->so_zone, so); > > wakeup(so->so_zone); > > The problem is that zfreei() changes so->so_zone. Shouldn't wakeup() be > > done on the original so->so_zone? I only noticed this problem by: > > 1- while(1) { > > sock =3D socket( AF_INET, SOCK_STREAM, IPPROTO_TCP ); > > connect( sock, ... ); > > close( sock ); > > } > > Eventually this pauses in socket() (in cyg_tsleep()) when you run out > > of eCos sockets. > > > > 2- After 2*MSL or so, cyg_wakeup() gets called with chan =3D=3D 0x0. W= hy? > > The zfreei() call in sodealloc() changes so->so_zone to 0 before the > > wakeup() call. >=20 > If I read the source correctly, zfreei() is a function, not a macro, and = it=20 > is passed the zone argument by value (as is default with C). Thus, zfree= i()=20 > cannot change the so structure itself and the value of so->so_zone will b= e=20 > unmodified after the call. sleep() and wakeup() take void* as argument a= nd do=20 > not interpret the value, so to them it is not of concern whether the pass= ed=20 > pointer is actually valid. >=20 > I looked into this because I had some problems with eCos and an embedded = web=20 > server. Seemingly, the server worked fine but stopped serving after some= 10=20 > requests had been processed. Looking into this, I found that the number = of=20 > sockets in our default configuration was very low (16). As TCP sockets s= tay=20 > allocated after the connection has closed until the tcp_maxidle period ha= s=20 > expired, no new connections could be accepted until that period (which is= in=20 > the minutes range in the default configuration) passed. >=20 > Not having looked at the TCP specification, I decided that reducing the=20 > tcp_maxidle parameter to a very low value combined with an increase in th= e=20 > number of sockets would help me out: >=20 > extern int cyg_tcp_maxidle; > cyg_tcp_maxidle =3D 200; >=20 > I am still not completely satisfied with the solution, because I don't re= ally=20 > know whether this change will result in bad interactions with other TCP=20 > network partners. Also, I have found the numbers reported for TCP=20 > accept/established/close do not correspond and I suspect that there are i= n=20 > fact other bugs which get triggered by hitting the socket limit very ofte= n. >=20 > I hope this is useful to some. >=20 > Regards, > Hans -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss