|
Back
Midas
Rome
Roody
Rootana
|
Midas DAQ System |
Not logged in |
|
|
23 Dec 2010, Konstantin Olchanski, Bug Report, odb corruption, odb race condition?
|
24 Dec 2010, Konstantin Olchanski, Bug Report, odb corruption, odb race condition?
|
24 Dec 2010, Konstantin Olchanski, Bug Report, odb corruption, odb race condition?
|
26 Dec 2010, Konstantin Olchanski, Bug Report, race condition and deadlock between ODB lock and SYSMSG lock in cm_msg()
|
29 Dec 2010, Konstantin Olchanski, Bug Report, use of nested locks in MIDAS
|
29 Dec 2010, Konstantin Olchanski, Bug Report, fixed. odb corruption, odb race condition?
|
11 Feb 2011, Konstantin Olchanski, Bug Report, fixed. odb corruption, odb race condition?
|
15 Feb 2011, Konstantin Olchanski, Bug Report, fixed. odb corruption, odb race condition?
|
16 Feb 2011, Konstantin Olchanski, Bug Report, fixed. odb corruption, odb race condition?
|
|
Message ID: 741
Entry time: 11 Feb 2011
In reply to: 739
Reply to this: 743
|
Author: |
Konstantin Olchanski |
Topic: |
Bug Report |
Subject: |
fixed. odb corruption, odb race condition? |
|
|
> >
> > The only remaining problem when running my script is some kind of deadlock between the ODB and SYSMSG semaphores...
> >
>
> For now, I am happy that we no longer corrupt ODB (nor deadlock) ...
>
Found one more deadlock between ODB and SYSMSG semaphores, this time through cm_watchdog():
If cm_watchdog somehow runs while we are holding the ODB semaphore, it will eventually try to lock SYSMSG (through bm_cleanup & co) in
violation of our semaphore locking order. If at the same time another application tries to lock stuff using the correct order (SYSMSG first, ODB last),
the two programs will deadlock (wait for each other forever). I presently have two copies of gdb attached to two copies of odbedit
waiting for each other in a deadlock through this cm_watchdog scenario...
Solution shall follow quickly, I have been hunting this deadlock for the last couple of weeks...
K.O. |