[Top][All Lists]

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

Re: [lwip-users] Timeout wraparound bug

From: Fotis Panagiotopoulos
Subject: Re: [lwip-users] Timeout wraparound bug
Date: Mon, 20 Feb 2017 10:17:35 +0200

As it seems there was a bug in my sys_now(), wrapping-around at the wrong value.

Now it works perfectly, thank you.

Fotis Panagiotopoulos

Mechatronics Engineer



Αμφιαράου 25,, Τ.Κ. 104 42, Αθήνα, Ελλάδα
Τηλ : +30 210 5907000 – ext. 28 | Fax: +30 210 5912711
e-mail: address@hidden | web: http://www.amco.gr


Please consider the environment before printing this e-mail.

On Sat, Feb 18, 2017 at 2:39 PM, Sylvain Rochet <address@hidden> wrote:
Hi Fotis,

On Sat, Feb 18, 2017 at 01:55:41PM +0200, Fotis Panagiotopoulos wrote:
> Hi,
> To begin with, I do call sys_check_timeouts() very often. I also tried
> v2.0.1, where the problem vanishes. I believe it is fixed by the following
> addition:
>         } else if (timeout->time > msecs) {
>           /* If this is the case, 'timeouts_last_time' and 'now' differs too much.
>              This can be due to sys_check_timeouts() not being called at the right
>              times, but also when stopping in a breakpoint. Anyway, let's assume
>              this is not wanted, so add the first timer's time instead of 'diff' */
>           timeout->time = msecs + next_timeout->time;
>         }
>         timeout->next = t->next;
> which looks more like a work-around for me, rather an actual fix.

You can only enter that if your main timer continue to run while your
system is suspended (eg. waiting on a breakpoint while debugging on a
desktop computer), this is a work-around to help us using debuggers.
Systems that suspend should call sys_restart_timeouts() on resume to
prevent that.

Otherwise it means you do not call sys_check_timeouts() at an acceptable
rate or your sys_now() function is buggy.


lwip-users mailing list

reply via email to

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