"Assertion Failed" on Communicator.Destroy

DeepDiver

hi,

i get an Assertion (screenshot attached).

this is my code snippet causing the assertion:

		public void Shutdown()
		{
			if( m_adapter != null )
			{
				m_adapter.deactivate();
			}
			if( m_communicator != null )
			{
				m_communicator.shutdown();
				m_communicator.destroy();
				m_communicator = null;

				m_comm_ref_count = 0;
			}
		}

i also have following printout in the log file:

[ice.error]: exception in `Ice.ThreadPool.Server' thread domain-Corsair.Test.dll-Ice.ThreadPool.Server-0:
Ice.SocketException: SocketException ---> System.Net.Sockets.SocketException: An operation was attempted on something that is not a socket
   at System.Net.Sockets.Socket.Select(IList checkRead, IList checkWrite, IList checkError, Int32 microSeconds)
   at IceInternal.Network.doSelect(IList checkRead, IList checkWrite, IList checkError, Int32 milliSeconds)
   --- End of inner exception stack trace ---
   at IceInternal.Network.doSelect(IList checkRead, IList checkWrite, IList checkError, Int32 milliSeconds)
   at IceInternal.ThreadPool.run(BasicStream stream)
   at IceInternal.EventHandlerThread.Run()

environment:
ICE 2.1.1, WinXP

thanks for your time

tom

michi

It is difficult to work out what's happening without knowing which of the three assertions in ThreadPool.destroy() is triggering. (I'm surprised at the lack of line numbers too.)

Do you have any way to reproduce this problem? A code example that we can test with would be very useful.

Thanks,

Michi.

DeepDiver

I reproduced it!

hi michi,

i was able to reproduce the assertion in a small and simple project.
the project was build with ICE 2.1.1

take care and thanks alot

cu tom

PS: line numbers are missing because icecs.pdb is not part of the installer in ICE 2.1.1

michi

Hmmm... We fixed a few things around finalizers in 2.1.2. Could you install 2.1.2 and try with that please? (I just tried and didn't get the assertion with 2.1.2 whereas, with 2.1.1, the code fails as you say.)

Cheers,

Michi.

DeepDiver

hi michi,

i switched to 2.1.2 and its working now!

thanks alot!

tom

PS: in the 2.1.2 installer the pdb files for all .net assemblies are missing.
intention or accident?

DeepDiver

hi michi,

im sorry to say the assertions didn't really go away in 2.1.2.
i did add the pdb file to the GAC in order to get a more detailed error desc.

it seems to be some timing issue, because once in 20 times it works WITHOUT
any assertion/exception ....

this comes from the VS debugger output window

---- DEBUG ASSERTION FAILED ----
---- Assert Short Message ----

---- Assert Long Message ----


at ThreadPool.destroy() C:\projects\ICE.SOURCES\IceCS-2.1.2\src\Ice\ThreadPool.cs(143)
at Instance.destroy() C:\projects\ICE.SOURCES\IceCS-2.1.2\src\Ice\Instance.cs(583)
at CommunicatorI.destroy() C:\projects\ICE.SOURCES\IceCS-2.1.2\src\Ice\CommunicatorI.cs(32)
at Class1.Main(String[] args) c:\projects\iceassertion\iceassertion\class1.cs(38)

---- DEBUG ASSERTION FAILED ----
---- Assert Short Message ----

---- Assert Long Message ----


at ThreadPool.destroy() C:\projects\ICE.SOURCES\IceCS-2.1.2\src\Ice\ThreadPool.cs(144)
at Instance.destroy() C:\projects\ICE.SOURCES\IceCS-2.1.2\src\Ice\Instance.cs(583)
at CommunicatorI.destroy() C:\projects\ICE.SOURCES\IceCS-2.1.2\src\Ice\CommunicatorI.cs(32)
at Class1.Main(String[] args) c:\projects\iceassertion\iceassertion\class1.cs(38)

Written to the console:

IceAssertion.exe: error: exception in `Ice.ThreadPool.Server' thread IceAssertion.exe-Ice.ThreadPool.Server-0:
Ice.SocketException: SocketException ---> System.Net.Sockets.SocketException: An operation was attempted on something that is not a socket
at System.Net.Sockets.Socket.Select(IList checkRead, IList checkWrite, IList checkError, Int32 microSeconds)
at IceInternal.Network.doSelect(IList checkRead, IList checkWrite, IList checkError, Int32 milliSeconds) in C:\projects\ICE.SOURCES\IceCS-2.1.2\src\Ice\Network.cs:line 541
--- End of inner exception stack trace ---
at IceInternal.Network.doSelect(IList checkRead, IList checkWrite, IList checkError, Int32 milliSeconds) in C:\projects\ICE.SOURCES\IceCS-2.1.2\src\Ice\Network.cs:line 549
at IceInternal.ThreadPool.run(BasicStream stream) in C:\projects\ICE.SOURCES\IceCS-2.1.2\src\Ice\ThreadPool.cs:line 364
at IceInternal.EventHandlerThread.Run() in C:\projects\ICE.SOURCES\IceCS-2.1.2\src\Ice\ThreadPool.cs:line 891

i also tried to add a waitforshutdown() statement before calling destroy, but
this didn't change anything.

let me know if you need more input on this topic

thx & have a nice weekend

cu tom

DeepDiver

hi michi,

i spend some more time with the problem:

removing the call to adapter.deactivate() removes the assertion.

so i was debugging into the code:
- ThreadPool.unregister() adds an element to _changes
- this entry is causing the assertion on destroy because the threadpool did
not process the change entry until this point.
- actually the threadpool did catch an exception and is trying to access
Instance.logger() to report the error.
location: IceInternal.ThreadPool.EventHandlerThread.Run() Zeile 896
Instance is locked by Instance.destroy()


take care

tom

michi

Thanks a lot for the bug report. I'll have a look at this this week.

Cheers,

Michi.

michi

Your problem happens because the adapter is in the holding state. If you take the adapter out of the holding state first, things shut down fine. I'm working on a fix--in the mean time, can you take the adapter out of the holding state before destroying the communicator?

Cheers,

Michi.

DeepDiver

hi michi,

i no longer move the adapter into the hold state.
this fixes the problem.

thanks alot

cu tom

michi

It turns out that the bug manifests itself if you transition quickly into the holding state and then destroy the communicator.

It's possible to fix this but, instead, we are considering removing the holding state altogether. Can I ask you why you had the adapter in the holding state in the first place?

Thanks,

Michi.

DeepDiver

hi michi,

i'm implementing a windows service and did use adapter.hold() within the
stop operation of the server.

because i initially wanted to share a communicator within one process hosting
multiple windows services the adapter of each service was set to hold.
deactivate() would cause an exception on activate() when starting again.

currently i'm back at the point where i use one process with one
communicator implementing one service.
in this case i don't need adapter.hold().

thx & cu tom