Re: (ITS#3709) slapd deadlock on DEL

Aaron Richton wrote:
>I exercised the database in question quite a bit this morning, making
>thousands of ADD/DEL operations. Unfortunately, none of these exhibited
>the deadlock that I got in the batch prompting this ITS. So my hopes for
>reproduction seem slim. Oh well...
>
>I've had a few ITS's based off smells-like-deadlock conditions. They're
>generally in production environments, so I don't want to leave them
>hanging forever, but I can take a few minutes to use gcore, db_stat, and
>anything else that might be interesting. If there was a list of these
>interesting commands somewhere, I'd be glad to include them in the future.
>
>
Understood. gcore is good, but we'll also need a copy of your slapd
binary to make use of the core file. And if you use dynamically loaded
modules, and those modules are involved in the stack trace, we'll need
those too.
First I would use gdb to attach to the hung process.
gdb /path/to/slapd <pid>
thr apply all bt full
Sometimes the backtrace will abort because of an invalid stack
somewhere, or it will run too long because gdb doesn't recognize the end
of the stack. In these cases, you can limit the trace e.g.
thr apply all bt 20
to get only the most recent 20 frames.
The db_stat -CA output is important of course. The back trace you
provided shows two locker IDs in use, the db_stat output would show
which locker IDs are conflicting and that would help us pinpoint what
the offending lock is.
>On Sat, 7 May 2005, Howard Chu wrote:
>
>
>
>>If you can reproduce this situation, it would help to see the output of
>>db_stat -CA on the database environment at this point.
>>
>>
>
>.
>
>
>
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.comhttp://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support