Archived
This forum has been archived. Please start a new discussion on GitHub.
IceGrid assertion failure
Hi,
I've come across the following assertion a few times:
icegridregistry: LocatorI.cpp:36: virtual void IceGrid::AMI_Adapter_getDirectProxyI::ice_response(const Ice::ObjectPrx&): Assertion `obj' failed.
I'm using Ice3.0.1 on Debian Linux, compiled with gcc4.0.
The problem has cropped up a few times now so it's re-producible, but I haven't yet managed to narrow down the particular circumstances which cause it. I'll keep you posted if I get any more info.
The gdb stack trace is as follows:
icegridregistry: LocatorI.cpp:36: virtual void IceGrid::AMI_Adapter_getDirectProxyI::ice_response(const Ice::ObjectPrx&): Assertion `obj' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 196621 (LWP 29047)]
0xb73c16f1 in kill () from /lib/libc.so.6
(gdb) bt
#0 0xb73c16f1 in kill () from /lib/libc.so.6
#1 0xb75d5030 in pthread_kill () from /lib/libpthread.so.0
#2 0xb75d53fb in raise () from /lib/libpthread.so.0
#3 0xb73c1464 in raise () from /lib/libc.so.6
#4 0xb73c29d8 in abort () from /lib/libc.so.6
#5 0xb73ba485 in __assert_fail () from /lib/libc.so.6
#6 0x0817d866 in IceGrid::AMI_Adapter_getDirectProxyI::ice_response (this=0x82c2d68,
obj=@0xb1a4f878) at LocatorI.cpp:36
#7 0x080aba04 in IceGrid::AMI_Adapter_getDirectProxy::__response (this=0x82c2d68, __ok=true)
at Internal.cpp:856
#8 0xb782e4a4 in IceInternal::OutgoingAsync::__finished (this=0x82c2d68, is=@0xb1a4fa7c)
at OutgoingAsync.cpp:187
#9 0xb77b1def in Ice::ConnectionI::message (this=0x82d5e18, stream=@0xb1a4fa7c,
threadPool=@0xb1a4fcd0) at ConnectionI.cpp:1310
#10 0xb78852ae in IceInternal::ThreadPool::run (this=0x82d60c8) at ThreadPool.cpp:652
#11 0xb7885a76 in IceInternal::ThreadPool::EventHandlerThread::run (this=0x82c6698)
at ThreadPool.cpp:875
#12 0xb7656145 in startHook (arg=0x82c6698) at Thread.cpp:357
#13 0xb75d1c37 in pthread_start_thread () from /lib/libpthread.so.0
#14 0xb75d1d80 in pthread_start_thread_event () from /lib/libpthread.so.0
#15 0xb74582ba in clone () from /lib/libc.so.6
I've come across the following assertion a few times:
icegridregistry: LocatorI.cpp:36: virtual void IceGrid::AMI_Adapter_getDirectProxyI::ice_response(const Ice::ObjectPrx&): Assertion `obj' failed.
I'm using Ice3.0.1 on Debian Linux, compiled with gcc4.0.
The problem has cropped up a few times now so it's re-producible, but I haven't yet managed to narrow down the particular circumstances which cause it. I'll keep you posted if I get any more info.
The gdb stack trace is as follows:
icegridregistry: LocatorI.cpp:36: virtual void IceGrid::AMI_Adapter_getDirectProxyI::ice_response(const Ice::ObjectPrx&): Assertion `obj' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 196621 (LWP 29047)]
0xb73c16f1 in kill () from /lib/libc.so.6
(gdb) bt
#0 0xb73c16f1 in kill () from /lib/libc.so.6
#1 0xb75d5030 in pthread_kill () from /lib/libpthread.so.0
#2 0xb75d53fb in raise () from /lib/libpthread.so.0
#3 0xb73c1464 in raise () from /lib/libc.so.6
#4 0xb73c29d8 in abort () from /lib/libc.so.6
#5 0xb73ba485 in __assert_fail () from /lib/libc.so.6
#6 0x0817d866 in IceGrid::AMI_Adapter_getDirectProxyI::ice_response (this=0x82c2d68,
obj=@0xb1a4f878) at LocatorI.cpp:36
#7 0x080aba04 in IceGrid::AMI_Adapter_getDirectProxy::__response (this=0x82c2d68, __ok=true)
at Internal.cpp:856
#8 0xb782e4a4 in IceInternal::OutgoingAsync::__finished (this=0x82c2d68, is=@0xb1a4fa7c)
at OutgoingAsync.cpp:187
#9 0xb77b1def in Ice::ConnectionI::message (this=0x82d5e18, stream=@0xb1a4fa7c,
threadPool=@0xb1a4fcd0) at ConnectionI.cpp:1310
#10 0xb78852ae in IceInternal::ThreadPool::run (this=0x82d60c8) at ThreadPool.cpp:652
#11 0xb7885a76 in IceInternal::ThreadPool::EventHandlerThread::run (this=0x82c6698)
at ThreadPool.cpp:875
#12 0xb7656145 in startHook (arg=0x82c6698) at Thread.cpp:357
#13 0xb75d1c37 in pthread_start_thread () from /lib/libpthread.so.0
#14 0xb75d1d80 in pthread_start_thread_event () from /lib/libpthread.so.0
#15 0xb74582ba in clone () from /lib/libc.so.6
0
Comments
-
Thanks for the report. We will look into it. However, if you can determine how to reproduce the issue it would be easier for us to fix this problem.0
-
Hi,
I found a race condition which could trigger this assert if a dynamically added adapter (i.e.: not added through the deployment mechanism) is removed while a client is doing a locate request to obtain the endpoints of the adapter. Could this be what is happening with your application?
I've attached a source patch, could you give it a try and let us know if this fixes the problem?
To apply the patch
$ cd Ice-3.0.1
$ patch -p0 < patch.dynadapters.txt
Thanks!
Cheers,
Benoit.0 -
benoit wrote:Hi,
$ cd Ice-3.0.1
$ patch -p0 < patch.dynadapters.txt
Bugger -- I'm really sorry, I meant to say that I'm using Ice 3.1.0, not Ice 3.0.1.
I have managed to track this down a little further though. My scenario is as described in this thread: http://www.zeroc.com/vbulletin/showthread.php?t=2495
I think the part that breaks things is when my separate GUI application queries the admin interface of the registry for a list of AdapterIDs.
I've tried under two conditions: (1) the registry running on the same host as the GUI, and (2) the registry running on a remote host. Scenario (1) always fails, while scenario (2) always succeeds.
It doesn't seem to be something special about my computer, since my friend saw the same issue when running a local registry.
Alex0 -
One other thing I should mention: we did not see this issue when doing the same thing using Ice3.0.1.
Alex0 -
Hi,
I still suspect this is the same issue. I'm attaching a patch for Ice 3.1.0 to this post. I think it's much more likely to happen with 3.1.0 because dynamically added adapters are now removed when the server deactivates the object adapter.
Let me know whether or not you can still reproduce the assert after applying the patch!
Cheers,
Benoit.0 -
Benoit,
This patch seems to have done the trick, I can't seem to reproduce the problem after applying it. Thanks very much!
Alex0 -
Thanks a lot for reporting this issue! I've posted the patch (the same as the one from this thread) on the Patch forums [thread=2499]here[/thread]. The fix will be included in the next Ice release!
Cheers,
Benoit.0
