RTEMS scheduler bug ?

[Catalin Demergian]

I did more tests. it seems not the same type of error happens every time. I
got the  _Configuration_Scheduler_priority_dflt  a few times, but also
the 'enabled interrupts when they suppposed to be disabled' happened as
well

RTEMS_INLINE_ROUTINE void _Scheduler_priority_Ready_queue_enqueue(
  Chain_Node                     *node,
  Scheduler_priority_Ready_queue *ready_queue,
  Priority_bit_map_Control       *bit_map
)
{
  Chain_Control *ready_chain = ready_queue->ready_chain;
  //_Assert(_ISR_Get_level() != 0);
  if(_ISR_Get_level() == 0)
    gIntrErrs++;

  cnt_before = _Chain_Node_count_unprotected(ready_chain);
  _Chain_Append_unprotected( ready_chain, node );
  cnt_after = _Chain_Node_count_unprotected(ready_chain);

  if(cnt_after != cnt_before + 1)
gIntrErrs++;

  _Priority_bit_map_Add( bit_map, &ready_queue->Priority_map );
}

.. and I modified the cpuuse command to display gIntrErrs

# cpuuse
-------------------------------------------------------------------------------
                              CPU USAGE BY THREAD
------------+----------------------------------------+---------------+---------
 ID         | NAME                                   | SECONDS       |
PERCENT
------------+----------------------------------------+---------------+---------
*cdemergian build 10.40 am gIntrErrs=3*
 0x09010001 | IDLE                                   |    391.115963 |
99.323
 0x0a010001 | UI1                                    |      1.059489 |
 0.269
 0x0a010002 | ntwk                                   |      0.229622 |
 0.058
 0x0a010003 | SCtx                                   |      0.167826 |
 0.042
 0x0a010004 | SCrx                                   |      0.224951 |
 0.057
 0x0a010005 | eRPC                                   |      0.000049 |
 0.000
 0x0a010006 | SHLL                                   |      0.868036 |
 0.220
 0x0b010001 |                                        |      0.000096 |
 0.000
 0x0b010002 |                                        |      0.114388 |
 0.029
------------+----------------------------------------+---------------+---------
 TIME SINCE LAST CPU USAGE RESET IN SECONDS:
393.836064
-------------------------------------------------------------------------------
[/] #

It seems it's 3. (I've seen values as 2 or 4 at other test runs)

Catalin

On Tue, Apr 2, 2019 at 4:37 AM Catalin Demergian <demergian at gmail.com>
wrote:

> 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/4f9cddcb/attachment-0002.html>