assertion "first != _Chain_Tail( &ready_queues[ index ] )"

[Gedare Bloom]

This just covers up some bug. When the system overhead increased to check
the stack contents, it might modify the timing enough to obscure a race
condition. Since the stack checker didn't report anything, you probably
don't have a blown task stack. (But you could still have a function stack
overflow.)


On Fri, May 17, 2019, 4:21 AM Jython <googcheng at gmail.com> wrote:

> thanks a lot!
> when i add #define CONFIGURE_STACK_CHECKER_ENABLED
> problem disappeared, but i still dont understand how it happend
>
> On Fri, May 17, 2019 at 6:00 PM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
>
>> On 17/05/2019 11:58, Jython wrote:
>> > hi, Huber!  how to debug general stack corruption?
>>
>> The first thing is to turn on the stack checker.
>>
>> --
>> 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.
>>
>> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20190521/4536d84d/attachment.html>