Re: [lwip-users] Retransmission of a already acknowlegded package

[Sergio R. Caprile]

Well, Christian, I don't have any expertise on the NO_SYS=0 world, but I
can tell you that you normally don't "implemented the port function".
You don't port lwIP to an OS unless you know exactly what you are doing,
you normally get a port for your OS and ask your OS port maintainers
when you have trouble.
You should get a known good FreeRTOS port of lwIP first.
If you have to port it yourself, then by all means try a known working
lwIP app first !

> [...] LWIP ASSERT "pbuf_free: p->ref > 0" message. I don't understand
> what this means and how I can find the reason.

Well, if you read the documentation and explore the source code, you
will learn what pbufs are and how they have a reference count to track
the number of referers.

If you do a search on pbuf.c in lwIP code, you'll see that string
appearing only once, inside function pbuf_free(struct pbuf *p), at line
650 in the official 1.4.1 release, and it is in the following context:

  /* de-allocate all consecutive pbufs from the head of the chain that
   * obtain a zero reference count after decrementing*/
  while (p != NULL) {
    u16_t ref;
    SYS_ARCH_DECL_PROTECT(old_level);
    /* Since decrementing ref cannot be guaranteed to be a single
machine operation
     * we must protect it. We put the new ref into a local variable to
prevent
     * further protection. */
    SYS_ARCH_PROTECT(old_level);
    /* all pbufs in a chain are referenced at least once */
    LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0);
    ref = --(p->ref);
    SYS_ARCH_UNPROTECT(old_level);

You'll see that this is decrementing the number of references to a pbuf
when called, and when that is 0, the pbuf will be freed.
The assertion inside the SYS_ARCH_PROTECT/SYS_ARCH_UNPROTECT is checking
that p->ref is indeed >0, so you don't try to free a pbuf that was
already freed, and it checks this while trying to avoid other tasks to
screw things up.
So, even though I have no experience on NO_SYS=0 and I might be
overlooking something, I can tell you that:
- either your port is not good and it is messing things up,
- you are not calling the stack from a single thread as requested,
- or your application is broken and is trying to free an already freed pbuf.

You can try to log p->ref before and after the lock to check if things
are being screwed up, and you can track the pbuf_free caller to check if
someone is passing a freed pbuf.