Mutex possible bug.

[Anubirux]

I'm using ChibiOS from svn "chibios-svn-8219-trunk" on stm32f7 disco board. I have two threads: main for GUI and second for touch panel polling. Touch panel thread has +1 prio. After a some period of time (seconds to minutes) system stops in chSysUnlock() called from chMtxUnlock(). Inserting chSchRescheduleS(); before chSysUnlock(); solves the problem, but i guess its not the real problem. I put the same asseration before chMtxUnlock() body

Code: Select all

void chMtxUnlock(mutex_t *mp) {
  thread_t *ctp = currp;
  mutex_t *lmp;

  chDbgCheck(mp != NULL);

  chSysLock();

  chDbgAssert((ch.rlist.r_queue.p_next == (thread_t *)&ch.rlist.r_queue) ||
              (ch.rlist.r_current->p_prio >= ch.rlist.r_queue.p_next->p_prio),
              "priority violation, missing reschedule");

  chDbgAssert(ctp->p_mtxlist != NULL, "owned mutexes list empty");

and it catches it here also. So for some reason my touchscreen thread is put in ready list but is not switched, or i dont know ;/.

[Giovanni]

The problem could be originated elsewhere. Do you have calls to I-class functions NOT in ISRs?

Just to make sure, there could be a small nasty bug in there.

Edit: found the problem, your fix is proper.

Giovanni

[Giovanni]

Hi,

Fixed as bug #632, thanks for finding.

2.6.9, 3.0.1 and trunk were affected, fixed on repository.

Giovanni

[likewise]

2.6.9, 3.0.1 and trunk were affected, fixed on repository.

Did the bug appear first in these revisions, or was it already there earlier (in 3.0.0 for example)?

[Giovanni]

Hi,

It is as old as the kernel, its harmless nature made it go unnoticed. The occurrence is very rare and the anomaly fixes itself on the next reschedule.

Giovanni