What this looks like to me is that there was a nested pend without the same number of releases. Maybe some path out of some code that is rarely hit where a mutex is granted but not released?
Just a guess... > On Nov 5, 2017, at 8:26 PM, Jitesh Shah <[email protected]> wrote: > > Hey Guys, > I am running v1.0.0 branch (0db6321a75deda126943aa187842da6b977cd1c1). > Seeing some strange mutex behaviour. > > So once in a bazillion times, a mutex fails to release. Here is how the > structure looks like when it fails: > >> (gdb) p/x send_mutex >> $1 = {mu_head = {slh_first = 0x0}, _pad = 0x0, mu_prio = 0x1, mu_level = >> 0x1, mu_owner = 0x0} > > > Why is mu_owner set to 0? That causes the os_mutex_release call to fail > since the current task doesn't match the owner task anymore. > > The task which holds the mutex looks like this: > >> (gdb) p/x cent_task >> $3 = {t_stackptr = 0x20008a28, t_stacktop = 0x20008ac8, t_stacksize = >> 0x80, t_taskid = 0x6, t_prio = 0x1, t_state = 0x1, t_flags = 0x10, >> t_lockcnt = 0x1, t_pad = 0x0, >> t_name = 0x22378, t_func = 0x90ad, t_arg = 0x0, t_obj = 0x0, >> t_sanity_check = {sc_checkin_last = 0x0, sc_checkin_itvl = 0x0, sc_func = >> 0x0, sc_arg = 0x0, sc_next = { >> sle_next = 0x0}}, t_next_wakeup = 0x0, t_run_time = 0x0, >> t_ctx_sw_cnt = 0x213d, t_os_task_list = {stqe_next = 0x0}, t_os_list = >> {tqe_next = 0x20001338, >> tqe_prev = 0x200001a8}, t_obj_list = {sle_next = 0x0}} > > > Comparing t_prio and mu_prio, this confirms that this task is indeed > holding the mutex (no other task is waiting on the mutex). > > What can happen that set mu_owner to 0? My original theory was that if a > mutex_pend was called from an interrupt context, mu_owner would be 0. But > in this case, the only task that is calling mutex is running an eventq, so > that is unlikely. > > Any ideas? > > Jitesh > > -- > This email including attachments contains Mad Apparel, Inc. DBA Athos > privileged, confidential, and proprietary information solely for the use > for the addressed recipients. If you are not the intended recipient, please > be aware that any review, disclosure, copying, distribution, or use of the > contents of this message is strictly prohibited. If you have received this > in error, please delete it immediately and notify the sender. All rights > reserved by Mad Apparel, Inc. 2012. The information contained herein is the > exclusive property of Mad Apparel, Inc. and should not be used, > distributed, reproduced, or disclosed in whole or in part without prior > written permission of Mad Apparel, Inc.
