Monitor destructor...

[Keith McGuigan]

Peter -

Just a guess here, but I see that there's two constructors for Mutex(), one 
which sets _name to what you want, but the other one (the no-arg one) doesn't 
appear to initialize _name at all.  If you have a Mutex that was created via 
that constructor, _name will be junk and your deallocation in the desstructor 
will fail.  (By the way, what you have works but it would probably be better to 
deallocate the memory with FREE_C_HEAP_ARRAY(char,_name), to keep the name pairing).

--
- Keith

Peter Helfer wrote:
> Hi all
> 
> I've got some funny error I'm running into: In order to see what 
> deadlocks I'm creating, I extended the Monitor (Mutex) constructor to 
> copy the "name" parameter, instead of keeping it at "UNKNOWN" (as of 
> ClearMonitor).
> 
> class Monitor{
> ...
> char * _name;                    // Name of mutex REMOVED const!
> ..
> };
> static const char* Monitor::_default = "UNKNOWN";
> 
> 
> void Monitor::ClearMonitor (Monitor * m) {
>   m->_owner             = NULL ;
>   m->_snuck             = false ;
>   m->_name              = (char*) Monitor::_default;
>   m->_LockWord.FullWord = 0 ;
>   m->_EntryList         = NULL ;
>   m->_OnDeck            = NULL ;
>   m->_WaitSet           = NULL ;
>   m->_WaitLock[0]       = 0 ;
> }
> 
> Monitor::Monitor() { ClearMonitor(this); }
> 
> Monitor::Monitor (int Rank, const char * name, bool allow_vm_block) {
>   ClearMonitor (this) ;
> #ifdef ASSERT
>   if(name){
>         int len            = strnlen(name,63);
>         _name              = NEW_C_HEAP_ARRAY(char,len+1);
>         assert(_name, "Not enough mem");
>         strncpy(_name, name, len+1);
>   }
>   _allow_vm_block  = allow_vm_block;
>   _rank            = Rank ;
> #endif
> }
> 
> Monitor::~Monitor() {
>   assert 
> ((UNS(_owner)|UNS(_LockWord.FullWord)|UNS(_EntryList)|UNS(_WaitSet)|UNS(_OnDeck)) 
> == 0, "") ;
>   #ifdef ASSERT
>   if(_name != _default){
>         FreeHeap(_name);
>   }
>   #endif
> }
> 
> This is what I am seeing: it only doesnt work in this situation.. The 
> easy work around is to remove the code again, but thats actually not the 
> idea.. :-)
> 
> /home/peterh/workspace/openjdk/control/build/linux-i586-debug/bin/java 
> -client -Xmx881m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m 
> -classpath 
> /home/peterh/workspace/openjdk/control/build/linux-i586-debug/tmp/meta-index 
> BuildMetaIndex -o meta-index *.jar
> VM option 'PermSize=32m'
> VM option 'MaxPermSize=160m'
> ## nof_mallocs = 19744, nof_frees = 12802
> ## memory stomp: byte at 0x8189648 in front of object 0x8189660
> ### previous object (not sure if correct): 0x8189648 (73 bytes)
> ### next object (not sure if correct): 0x8189694 (1700358998 bytes)
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/os.cpp:544
> #
> # An unexpected error has been detected by Java Runtime Environment:
> #
> #  Internal Error 
> (/home/peterh/workspace/openjdk/hotspot/src/share/vm/runtime/os.cpp:544), 
> pid=7146, tid=2209852304
> #  Error: memory stomping error
> #
>