Re: [lwip-users] Last call for 1.4.0rc1 issues

[Paul Archer]

Thanks for the response.

The sock->data was a copy/paste error.
sock->data is the same value as lSocket in the code above.

In my application I have implemented a wrapper around sockets so that
I can use lwip and other TCP/IP implementations side by side. Some
other socket implementations need to store different data, so
socket->data is just a void * ptr.

The value of the pbuf type is 176, which very much looks like a
corrupted pbuf type.

I will try to find out what I need to reproduce this with a few more
test cases and find out how to reproduce it everytime. I'll have to
wait until Monday in Australia comes around though, as its a project
at work.

Regards Paul

On Fri, Sep 17, 2010 at 6:24 PM, Kieran Mansley <address@hidden> wrote:
> On Fri, 2010-09-17 at 12:21 +1000, Paul Archer wrote:
>> Hey Kieran,
>>
>> I sent this to the list a few weeks ago, but never got a response. I
>> am not 100% sure if it is lwip's issue, or whether its something I
>> have incorrectly done. Either way its something I would raise as an
>> issue in rc1.
>
> This didn't seem to make it to the list the first time round - it's not
> in the archives at least - which explains why no response!
>
>> Regards Paul
>>
>> From: Paul Archer <address@hidden>
>> To: address@hidden
>> Date: Thu, 2 Sep 2010 12:31:50 +1000
>> Subject: 1.4.0.rc1 Assert in pbuf_free() when using lwip_close()
>> Hi all,
>>
>> I have an assert being raised in pbuf_free() from an invalid pbuf type.
>> I open a UDP socket, send threw some packets and receive some packets.
>> Then if I try to close the UDP socket I get
>> An assert in pbuf_free() with
>> pbuf_free()
>> pbuf_free: sane type
>>
>> If it helps I am running it with FreeRTOS version 6.0.2
>> I have attached my lwip system function calls (sys-arch.c) and also my
>> lwipopts.h
>>
>> I have traced the code and it seems to follow
>> lwip_close()
>> free_socket()
>> netbuf_delete()
>> pbuf_free()
>>
>> What this means is that buf->p is being either corrupted (somewhere in
>> my code of somewhere in lwip) or its being freed in the incorrect
>> order, and hence freed once in use again.
>>
>> The code I used to trigger this was:
>>
>>    struct sockaddr_in sLocalAddr;
>>    int lSocket;
>>
>>    if ((lSocket = lwip_socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
>>        free(socket);
>>        DTRACE("Unable to find a spare UDP Socket");
>>        return NULL;
>>    }
>>
>>    memset(&sLocalAddr, 0, sizeof(sLocalAddr));
>>
>>    /*Source*/
>>    sLocalAddr.sin_family = AF_INET;
>>    sLocalAddr.sin_len = sizeof(sLocalAddr);
>>    sLocalAddr.sin_addr.s_addr = htonl(INADDR_ANY);
>>    sLocalAddr.sin_port = src->port;
>>
>>    if (lwip_bind(lSocket, (struct sockaddr *)&sLocalAddr,
>> sizeof(sLocalAddr)) < 0) {
>>        lwip_close(lSocket);
>>        DTRACE("Unable to bind to port %d", ntohs(src->port));
>>        return NULL;
>>    }
>>
>> //A couple of
>> nbytes = lwip_recvfrom((int)sock->data, buf, len, flags,
>>                (struct sockaddr *)&sFromAddr, &from_len);
>>
>> //and a few
>> nbytes = lwip_sendto((int)sock->data, buf, len, 0, (struct sockaddr
>> *)&sDestAddr, sizeof(sDestAddr));
>>
>> //Then
>> lwip_close(lSocket);
>
>
> Can you give some details about what sock->data is set to?
>
> Your app is interested because it's using recvfrom and sendto on
> unconnected sockets, which I would guess is not very common and so not
> well tested.
>
> If you're able to debug this further, finding out what value the pbuf
> type has would be handy, and seeing if any changes to the above code
> make the problem go away (e.g. does it need sends and receives, or can
> you reproduce it with just one, and so on)
>
> It's certainly worth opening a bug on savannah to track this and make
> sure it doesn't get forgotten.
>
> Thanks
>
> Kieran
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>



-- 
----
Regards
Paul Archer
address@hidden