Re: (ITS#3709) slapd deadlock on DEL

[hyc@symas.com]

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.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support