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 <googch...@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.hu...@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.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
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
