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.
