Deadlock when a thread that owns the spinlock is terminated unexpectedly.

[Google Code Exporter]

What steps will reproduce the problem?
1. I saw this with a standard C++ application loading .NET dlls then 
terminating.  
2. During termination it looks like the main thread exited but there was 
a .NET thread still executing that was trying to acquire the spinlock that 
was owned by the now exited thread.

What is the expected output? What do you see instead?
Expected that the spinlock acquire the lock if the owning thread has been 
terminated unexpectedly.  Result was a deadlock during shutdown.

What version of the product are you using? On what operating system?
Perftools 1.3, Windows Server 2003 64 bit (32 bit application).

Please provide any additional information below.
I've made changes to SlowLock to acquire a handle to the thread currently 
owning the lock and to test to see if it has exited.  If it has exited 
then I take ownership of the lock.  Please see issue 161 for the 
corresponding code changes.

Original issue reported on code.google.com by [e-mail] on 21 Jul 2009 at 2:51

[Google Code Exporter]

As with issue 161, I'd rather solve the underlying problem than change the 
spinlock
code.  Where was the .NET thread trying to acquire the spinlock?  What does it 
mean
that a thread 'owned' the spinlock -- do you mean that at the time the main 
thread
exited, it had the spinlock acquired?  If so, I think the best solution is to 
make
sure threads release the lock when they exit.  Do you know why the main thread 
had
the lock on exit?

Original comment by [e-mail] on 22 Jul 2009 at 8:55

[Google Code Exporter]

Ping.  I'd like to understand this a bit more.  How did the thread exit in a 
way that
didn't crash the entire program?  Presumably if it exited while some tcmalloc 
lock
was held, it was inside a tcmalloc routine.  That should never cause a thread 
to exit
without terminating the program.  Do you have stacktrace information?

Original comment by [e-mail] on 14 Oct 2009 at 11:11

• Added labels: Priority-Medium, Type-Defect

[Google Code Exporter]

As with issue 161, closing due to lack of feedback.

Original comment by [e-mail] on 10 Mar 2010 at 6:16

• Changed state: CannotReproduce