rtems_message_queue_receive / rtems_event_receive issues

[Sebastian Huber]

On 11/10/2018 09:52, Catalin Demergian wrote:
> Hi,
> I don't use malloc myself in the code I added, but I see it is used a 
> lot in the networking code.
>
> I printed state and Wait.flags for SCrx task
> * when all is ok *
> in _Event_Seize, after _Thread_Dispatch_enable
> state = 0x100 = STATES_WAITING_FOR_EVENT
> Wait.flags = 0x102 = THREAD_WAIT_CLASS_EVENT | THREAD_WAIT_STATE_BLOCKED
> in _Event_Surrender at the beginning
> state = 0x100
> Wait.flags = 0x102
>
> * when SCrx is not scheduled any more *
> in _Event_Seize, after _Thread_Dispatch_enable
> state = 0x0 = STATES_READY
> Wait.flags = 0x02 = THREAD_WAIT_STATE_BLOCKED
> in _Event_Surrender at the beginning
> state = 0x0
> Wait.flags = 0x02
>
> do these look like valid values ? I mean in _Event_Seize the state 
> should have been blocked, right ?
> can these values be caused by a corruption ?

A thread wait flags value of 0x02 indicates that this thread used 
rtems_task_wake_after() recently (at least in RTEMS 5, but very likely 
also in RTEMS 4.11.2).

>
> -> Did you check the task stacks with the stack checker?
> I'm afraid I don't know how to use it in RTEMS. any link to 
> information on how to detect/analyze a data coruption in RTEMS can be 
> useful.

It is a configuration option

#define CONFIGURE_STACK_CHECKER_ENABLED

In the RTEMS shell you can obtain the task stack information with the 
"stackuse" command.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.