search

buffer8848 / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

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

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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 escri...@hotmail.com on 21 Jul 2009 at 2:51

GoogleCodeExporter commented 9 years ago 
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 csilv...@gmail.com on 22 Jul 2009 at 8:55

GoogleCodeExporter commented 9 years ago 
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 csilv...@gmail.com on 14 Oct 2009 at 11:11

GoogleCodeExporter commented 9 years ago 
As with issue 161, closing due to lack of feedback.

Original comment by csilv...@gmail.com on 10 Mar 2010 at 6:16