lwip-devel
[Top][All Lists]
Advanced

[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

URL:
  <http://savannah.nongnu.org/bugs/?52860>

                 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

    _______________________________________________________

Details:

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
timeouts_last_time.

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:
rozzie
This modified file is based on an original from 2.0.3.
<http://savannah.nongnu.org/bugs/download.php?file_id=42884>

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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