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.hu...@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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
