rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
I eliminated the theory of memory corruption. I debugged and found we set
Wait.flags = 0x104 with a function call.
The USB interrupt can arrive at any time, so Wait.flags can be either
INTEND_TO_BLOCK, BLOCKED or READY_AGAIN.

Following the logic in _Event_Surrender:
If it arrives when Wait.flags = INTEND_TO_BLOCK
then _Thread_Wait_flags_try_change_critical will return TRUE, Wait.flags
will be set to READY_AGAIN,
unblock = FALSE so _Thread_Unblock will not be called.
Then all the other USB interrupts will catch Wait.flags = READY_AGAIN and
in this case_Event_Surrender doesn't do anything because unblock = FALSE

.. so the task never runs again, but state remains marked as READY.
is this a bug ? or I'm not understanding correctly?

regards,
Catalin

On Wed, Oct 3, 2018 at 2:42 PM Catalin Demergian <demergian at gmail.com>
wrote:

> ok, I understand. The code in _Event_Is_blocking_on_event is correct, it
> just verifies if the thread is in wait state or not.
> The only thing that varies is what _Thread_Wait_flags_get returns. In my
> case, it returned 0x102 for 5401 times,
> but 5402th time it returned 0x104; because of that, ( wait_flags &
> wait_mask ) == wait_class didn't hold true anymore.
> 0x104 means the thread is ready .. why is marked as ready instead of
> blocked is another problem. could it be a memory
> corruption, possibly, but I doubt it, a memory corruption would set it
> most likely to a value without meaning, but in my case it's
> exactly 0x104.
> I think one of the functions
> _Thread_Wait_flags_set/_Thread_Wait_flags_try_change may set this value.
> I will check this theory.
>
> regards,
> Catalin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20181004/e099d589/attachment-0002.html>