rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
we ran those tests and they all passed.

I was debugging to follow what's going on with the state of the task in
_Event_Seize and
when trying to step over _Thread_Dispatch_enable( cpu_self ) call at the
end of the function I got this in the debugger


0x80acf38->_Heap_Walk->_Heap_Walk_check_control->_Heap_Walk_check_free_list->_Thread_Handler->_CPU_Thread_Idle_body

heapwalk.c:331->heapwalk.c:240->heapwalk.c:105->threadhandler.c:95->armv7-thread-idle.c:33



     if ( free_block->prev != prev_block ) {

      (*printer)(

        source,

        true,

        "free block 0x%08x: invalid previous block 0x%08x\n",

        free_block,

        free_block->prev

      );



      return false;

    }


what does that mean? is this a memory corruption of some kind ?

it seems the message "free block 0x%08x: invalid previous block 0x%08x\n"
is printed somewhere, but I don't know

how to see these messages in RTEMS, is there a command like dmesg in Linux ?


regards,
Catalin


On Tue, Oct 9, 2018 at 10:00 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 09/10/2018 08:48, Catalin Demergian wrote:
> > Hi,
> > I put more debugging effort into this.
> >
> > I think it's all about the Wait.flags value when the ISR is arriving.
> > For Wait.flags=BLOCKED or Wait.flags=INTEND_TO_BLOCK things are working
> > (yes, _Thread_Unblock is called from _Event_Seize properly), but when
> > Wait.flags=READY
> > things don't work because the conditions in if block
> > from _Event_Surrender are not met and
> > nobody calls _Thread_Unblock; even if more ISRs arrive, Wait.flags
> > remains READY and the
> > thread is not put on the CPU anymore.
> >
> > 1. how can Wait.flags be READY before the ISR is arriving ?
>
> The wait flag name is THREAD_WAIT_STATE_READY_AGAIN. This is a state
> after a blocking operation. Such a thread is ready and either executes
> or the scheduler decided that it is not important enough and a higher
> priority thread executes.
>
> > 2. on the else of the if block I tried to put unblock=true to unblock
> > my task
> >   if (
> >     _Event_Is_blocking_on_event( the_thread, wait_class )
> >       && _Event_Is_satisfied( the_thread, pending_events, &seized_events
> )
> >   ) {
> > , I did see _Thread_Unblock called, but in _Thread_Clear_state
> > _Scheduler_Unblock was not called
> > because the_thread->current_state = 0.
> > do I have to set something else besides unblock=true to unblock my task ?
>
> I am not sure if this is really the problem area indicated by the failed
> assertion in one of your previous e-mails:
>
> assertion "first != _Chain_Tail( &ready_queues[ index ] )" failed: file
> "../../cpukit/../../../stm32f7/lib/include/rtems/score/schedulerpriorityimpl.h",
>
> line 166, function: _Scheduler_priority_Ready_queue_first
>
> This assertion tells you that the scheduler data structures are corrupt.
> The thread wait flags are a different domain.
>
> There are tests which specifically test the event send/receive conditions:
>
> testsuites/sptests/spintrcritical10
> testsuites/sptests/spintrcritical11
> testsuites/sptests/spintrcritical18
> testsuites/sptests/spintrcritical21
>
> I would run at least these tests on your board. I normally run all tests
> during a BSP development.
>
> --
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20181010/c38501ae/attachment-0002.html>