lwip-users
[Top][All Lists]
Advanced

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

AW: AW: [lwip-users] WG: select timeout


From: Mathias Zenger
Subject: AW: AW: [lwip-users] WG: select timeout
Date: Wed, 3 Feb 2010 15:12:43 +0100

Kieran: Sorry for the CC I sent to your direct address.

As discussed I contacted the ATMEL technical support and placed my question
in the AVRFreaks forum (no replies so far).

Meanwhile I was debugging my project (more and more desperate).
Unfortunately I never managed to activate the debug outputs for this port.
That's why I am kind of blind. However, I saw that the allocation of the
timeout structure in sys_timeout(u32_t msecs, sys_timeout_handler h, void
*arg) seemes to fail.

... // Breakpoint reached
timeout = memp_malloc(MEMP_SYS_TIMEOUT);
if (timeout == NULL) {
  LWIP_ASSERT("sys_timeout: timeout != NULL", timeout != NULL);
  return;
}
timeout->next = NULL;
... // Breakpoint never reached

There is a thread in lwIP devel
(http://old.nabble.com/Memory-leak-for-timeouts-td13602845.html#a13603364)
which talks about system threads and application threads and difficulties
regarding per-thread data. Also select() is mentioned in this context which
I am using in my FreeRTOS task. Can anybody help me to get the clue?

I haven't updated from 1.3.0 to 1.3.2 so far. Perhaps this could help but I
guess the system specific parts of the ATMEL port are not up to date.

Mathias

-----Ursprüngliche Nachricht-----
Von: Kieran Mansley [mailto:address@hidden
Gesendet: Dienstag, 2. Februar 2010 15:16
An: address@hidden
Betreff: Re: AW: [lwip-users] WG: select timeout


On Tue, 2010-02-02 at 14:08 +0100, Mathias Zenger wrote:

> I am a bit lost and would appreciate your help. Where shall I dig? :)

First I'd keep this sort of thing on the mailing list rather than by
direct mail - there are lots more knowledgeable people besides me, so
you'll stand a better chance of getting a good answer, and there might
be other people with the same question who would benefit from your
results.

It sounds like the port is using this code that should invoke a callback
after the required timeout that will signal the semaphore and wake it
from the sys_sem_wait:

  ...
if (timeout > 0) {
   /* Create a timer and pass it the address of our flag */
   sys_timeout(timeout, sswt_handler, &sswt_cb);
}
sys_sem_wait(sem);
...

After that, like you I feel a bit lost, particularly as I don't have the
port to hand to look at the code.  Might be a good idea to contact ATMEL
at this point to see if they know what's wrong.

Kieran






reply via email to

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