RTEMS scheduler bug ?

[Catalin Demergian]

it's just the way Eclipse shows it, it's part of the call stack, but not
the name of a normal function.


On Tue, Apr 2, 2019 at 2:02 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

>
>
> On 02/04/2019 12:59, Catalin Demergian wrote:
> > Hi,
> > I was able to reproduce the issue again, but it doesn't look like the
> > interrupts are enabled
> > in the functions where you added Asserts in the patch. So, my changes
> > don't fix the problem.
> > My analysis would have been correct if the interrupts were enabled,
> > but it looks it's not the case.
> >
> > Still, a problem exists somewhere .. _Chain_Append_unprotected fails
> > and the task starves as a result.
> > If it's not interrupts, I have to think again what could produce the
> > failure. (any idea/hint here is welcome :) )
> >
> > Also, during my tests I even saw a crash (probably not related to this
> > issue). Call stack looks like this
> > Thread #1 (Suspended:Signal:SIGINT:Interrupt)
> >  _ARMV7M_Exception_default() at armv7m-exception-default.c:25 0x805aff0
> >  <signal_handler_called>() at 0xfffffffd
> >  _Configuration_Scheduler_priority_dflt() at 0x2400063c
>
> What is signal_handler_called()?
>
> --
> 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/20190402/7030d061/attachment.html>