[omniORB] The cause of the exception in echo/eg1 example for omniORB3 on NT

[Chung, David]

	I ran eg1, and I also received the exception.  The exception is
actually thrown after it EXITS out of the main() (after all the screen
outputs for eg1.exe have been displayed).  The exception thrown is NT native
exception, caused by memory access error.  

-------------------------------

	What seems to be happening is this: there are two static variables
of interest in your library:

	(1) the_nil_poa
	(2) omni::internal_lock

	These static variables are cleaned up automatically after the exit
of main() in echo.cc.  
	
	When the_nil_poa gets destroyed, the following code gets executed 

	// in POA.CC
	// stuff
	...
	omniORBPOA::~omniORBPOA()
	{
  		ASSERT_OMNI_TRACEDMUTEX_HELD(omni::internalLock, 0); 

  		if ( pd_policy.single_threaded )  delete pd_call_lock;	
	}


	When the ASSERT tries to access the argument, omni::internalLock
(the static variable), it already has been deleted by the implicit clean up
code after main().  I know this, because I single-stepped through the code
to see omni::internalLock being deleted prior to the deletion of
the_nil_poa.  

	Since one tries to access what has been deleted, you get memory
access error.  

------------------------------------------

P.S:  Brief background on the setup.  (NT4.0 SP3, MSVC++)

	I rebuilt all the libraries in the debug mode; I did not try to link
with any dlls.  Finally, I did not link it with the omniDynamic3.  This is
not because I disagree with what you said below, but simply because, for
temporary debugging of eg1, I think, leaving out omniDynamic3 is probably
better, because the omniDynamic can introduce additional bugs.

	I do not think, though, the bug is caused by the linker.

---------------------------------------------

	

> -----Original Message-----
> From:	djr@uk.research.att.com [SMTP:djr@uk.research.att.com]
> Sent:	Wednesday, October 20, 1999 1:12 PM
> To:	David.Chung@uspto.gov
> Subject:	RE: [omniORB] omniORB3 on NT update
> 
> On Wed, 20 Oct 1999, Chung, David wrote:
> 
> > 	Dave, 
> > 	
> > 	I just checked your latest builds -- it certainly is behaving
> > better!
> > 
> > 	Few things:
> > 
> > 	(1) As I indicated in my earlier email, you may want to include
> > 
> > 		msvcdllstub.cc
> > 
> > 	in your make file for building static omniORB3.lib, so that CORBA
> > apps does not need to link with  omniDynamic3.lib in order to resolve
> > symbols.  (Unless you plan to resolve the symbols other ways).  You can
> > certainly resolve the symbols using omniDynamic3, but according to you,
> > omniORB3 is supposed to be independent from omniDynamic, right?
> 
> 
> For the moment I don't want to do this, because I want to try and find out
> why the dependancy is arising.  Long term if we can't find a proper fix I
> may put this workaround in.
> 
> 
> Cheers,
> David
>