lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #37166] memp_sanity check loops itself


From: Artem Pisarenko
Subject: [lwip-devel] [bug #37166] memp_sanity check loops itself
Date: Wed, 22 Aug 2012 13:06:13 +0000
User-agent: Opera/9.80 (Windows NT 6.1; WOW64; U; ru) Presto/2.10.289 Version/12.01

Follow-up Comment #2, bug #37166 (project lwip):

>> primary (which caused memp-lists to form a circle) 

>This is most often a threading problem in the way lwIP is used, rather than
an actual bug in lwIP.

Maybe. But I don't expect incorrect usage in my code. Because:
1. Application-level usage is only tcpecho from contribs.
2. Functions of system layer of my port (NO_SYS == 0) call
memp_alloc()/memp_free() only, which are allowed to use and are simple enough
to not misuse them.
3. My ethernet driver designed with reference to ethernetif.c in terms of how
driver should iteract with lwip safely. ethernetif_input() contents are
executed from driver thread context. low_level_output() directly fills dma
transmit buffers but blocks thread to wait them to be available (if they still
owned by dma after previous transmit start)

>> Author of this code caught in a trap of tricky and cruel '&&' short-circuit
operator ;) 

> I don't think I get what you want to say here. Can you suggest a fix?

Seems like my english isn't good enough to explain such complex statements :)
I'll try once more.
Fragment

if (n == m && --c < 0)


is not the same as

if (n == m & --c < 0)


but is equivalent to

if (n == m)
  if (--c < 0)


Maybe author considered that or maybe not.
Anyway this means that if memp_sanity encounters with so called "circle"
(pointers loop) then cycle condition in for(;;) statement will never be false.
The only way for memp_sanity to rescue own ass from endless loop is to
decrement 'c' variable two times. But it decrements only when 'n' become equal
to 'm'. This happens only one time in first iteration of for(;;) cycle. In
subsequent iterations 'n' values are become cycled in some range. There are no
guarantee that 'm' value will be in that range.
And I can not suggest a fix. I already tired to explain and it's time to go
home. :) Maybe tomorrow.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?37166>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]