[Top][All Lists]

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

Re: [lwip-users] Infinite hang in tcp_slowtmr()

From: Enrico Murador - Research & Development - CET
Subject: Re: [lwip-users] Infinite hang in tcp_slowtmr()
Date: Wed, 14 Oct 2015 17:17:55 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Hi Stephen,
Unfortunately I'm not using Atmel Studio. Anyway, one thing that comes to my mind is that maybe at some point (e.g. in your ftpd code) there is a call to tcp_abort() from a TCP callback that does not return ERR_ABRT (see the tcp_abort() description). Not sure if this could cause the problem your are facing, though.


On 14/10/2015 16:13, Stephen Cowell wrote:
Hey Enrico,
I'm using GNU toolchain/compiler, supplied with Atmel Studio 6.1.
Since I've added the code I've had no other problems; I really don't
have much time to research this, what with other pressures at work.

It seems the issue is not unknown... sometimes the pdb ends up pointing
to itself.  These times appear to be correlated to high-stress I/O.

Obviously the last pdb should point to null... and it should never point
to itself.  It is easy enough to catch it pointing to itself and make that
null.  I verified that this was the first pdb, that we weren't going to
have a memory leak when we just terminated the list.  I did not have
the resources to chase down when the pointer to self happened...
I only know that it does, and that the pdb that this happens to is
at the first allocated pdb address.  The obvious thing to do was to
correct the pointer to break the endless loop... seems to work.

As Sylvain wrote, the Atmel port has some serious differences from
what he's used to seeing... I'm assuming this has something to do
with it.  As I get more time (the product ships soon) I'll be able to
spend some more time on this issue.  I'm just glad to get it out there
and let others know it's happening.

On 10/14/2015 3:22 AM, Enrico Murador - Research & Development - CET wrote:
Hi Stephen,
Maybe your workaround is not a safe way to overcome the problem: at that point the pcb chain is already corrupted (and probably unrecoverable?).

What compiler/toolchain are you using?


On 13/10/2015 11:48, Sylvain Rochet wrote:
Hi Stephen,

On Tue, Oct 13, 2015 at 10:15:42AM +0200, Sylvain Rochet wrote:
On Mon, Oct 12, 2015 at 04:59:19PM -0500, Stephen Cowell wrote:
On 10/12/2015 3:41 PM, Sylvain Rochet wrote:
On Mon, Oct 12, 2015 at 02:51:14PM -0500, Stephen Cowell wrote:
I find that I sometimes get an infinite loop when stepping to
I didn't have to read further. As usual, it looks like a broken port or
usage which violate lwIP threading model.


- Do *NOT* call anything in interrupt context, nothing, never,
absolutely never, use your OS semaphore signaling to an
Ethernet/serial/… RX thread
I don't think I'm doing that, Sylvain... this is non-OS, so there
are no 'threads'.   Atmel wrote the port.  I'm running sntp and ftpd, they
hook in using their own _init() routines that have not been
But there are probably interrupts, which is even worse. Could you first 
check that no lwIP functions are called in interrupts contexts ? 
Probably around the macb driver.

If I have time I will fetch the Atmel port for SAM4E/bare-metal and 
take a short look at it.
It looks sane from a quick look. I don't really understand why there are 
not using sys_check_timeouts() and rewrote everything in the ethernet.c 
"static timers_info_t gs_timers_table[]" stuff. Since you are having 
issue in timers context could you check this part is ok ? Removing all 
the Atmel timers stuff and calling sys_check_timeouts() in the main loop 
could be an easy check.


lwip-users mailing list

Enrico Murador

CET Electronics logo CET Electronics snc
via E. Fermi, 1
31050 Zenson di Piave (TV) Italy
Phone: +39 0421 344100
Fax: +39 0421 464042
PI/VAT IT01780330260
Web: http://www.cet-electronics.com/

lwip-users mailing list

lwip-users mailing list

reply via email to

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