[Top][All Lists]

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

[lwip-devel] [bug #52860] sys_timeout mishandling of gaps in polling

From: Ray Ozzie
Subject: [lwip-devel] [bug #52860] sys_timeout mishandling of gaps in polling
Date: Wed, 10 Jan 2018 14:32:54 -0500 (EST)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36


                 Summary: sys_timeout mishandling of gaps in polling
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: rozzie
            Submitted on: Wed 10 Jan 2018 07:32:52 PM UTC
                Category: None
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: 2.0.3



In my (freertos-based) port, I was noticing some extremely long timeout values
being passed to sys_arch_mbox_fetch, and the longer my app kept running, the
longer the timeout values were growing.  We're talking hundreds of seconds.

After quite a bit of debugging, I found the issue.

In my environment, there are occasional (quite harmless) gaps that occur only
during the startup phase of my app that cause some early calls to sys_timeout
to see a fairly substantial (seconds) difference between sys_now() and

After a lot of debugging, I found that there became some misordering of the
queue of timeout handlers that ultimately caused an otherwise harmless
"sys_untimeout" to add huge values to existing timeout entries, causing the
aforementioned large-and-growing mbox_fetch timeouts.

The problem turned out to be that the test to see if a new timeout entry
should be placed at the head of the queue was wrong.  It wasn't accounting
properly for the "diff" bias.

Interestingly, there is somewhat of a kludge a few lines down that implements
a workaround for "when stopping at a breakpoint", etc.  It looks as though
someone had encountered difficulty in this "high diff" situation, and didn't
seem to apply the right fix.

Once I fixed this bug AND removed this kludge, the app is working perfectly
with any/all such "high diff" situations that I could find.  


File Attachments:

Date: Wed 10 Jan 2018 07:32:53 PM UTC  Name: timeouts.c  Size: 13KiB   By:
This modified file is based on an original from 2.0.3.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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