[lwip-users] LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0);

[Mumtaz Ahmad]

Dear all

When i use multiple threads sending on 2 different sockets i sometimes get
this assert
LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0);
I have tried to make the stack thread safe . Any body who could comment?


Regards


----- Original Message ----- 
From: "Kieran Mansley" <address@hidden>
To: "Mailing list for lwIP users" <address@hidden>
Sent: Thursday, September 21, 2006 12:49 PM
Subject: Re: [lwip-users] Handling sudden disappearance of network i/f


> On Wed, 2006-09-20 at 23:51 +0100, Clive Wilson wrote:
> > If the serial link
> > that LwIP's PPP layer depends upon suddenly disappears, then on this
event
> > I call pppSigHUP to inform PPP of the low-level link's absence. This in
> > turn calls netif_remove as you mention. However, if a socket call such
as
> > read(), write() etc is made after the serial link dies, I don't see
these
> > calls returning with an error to indicate a timeout waiting for
response.
>
> OK, I understand your problem better now, but I'm afraid I'm not 100%
> sure what the correct behaviour is in this case either.  I just tried it
> with linux by establishing an ssh connection across an ethernet
> interface, then taking that interface down.  The connection didn't
> immediately terminate, and when I brought the interface back up, the
> connection resumed where it had left off - the data I had tried to send
> while the interface was down was then sent.
>
> I think the connection would eventually time out (once the right number
> of retransmission timeouts had passed without it getting a response, it
> would give up).
>
> So, looks like lwIP is doing approximately the right thing.  Socket
> calls aren't made aware that the physical network has gone away.
>
> Kieran
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
> -- 
> This message has been scanned for viruses and
> dangerous content by Streaming Networks, and is
> believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by Streaming Networks, and is
believed to be clean.