Archived
This forum has been archived. Please start a new discussion on GitHub.
current.con.getInfo(): segmentation fault (core dumped) python ./server.py
Hi ZeroC users and developers!
Here is the problematic code:
Is the server and client code fine?
Starting the server works:
The client connects to the server and fails:
The server has crashed with a segmentation fault:
Here comes my system configuration:
What am I doing wrong?
Thank you in advance!
Here is the problematic code:
$ cat tux.ice module chaos { interface Tux { void fly(); }; }; $ cat client.py import Ice import sys import chaos ic= Ice.initialize(sys.argv) base= ic.stringToProxy("theTux:default -p 12345") tux= chaos.TuxPrx.checkedCast(base) assert tux is not None tux.fly() print "OK" $ cat server.py import sys import Ice import chaos class TuxI(chaos.Tux): def fly(self, current): print "Flying ..." print "dir current.con:", dir(current.con) clientInfo= current.con.getInfo() print "Done: Flying" ic= Ice.initialize(sys.argv) adapter= ic.createObjectAdapterWithEndpoints("theAdapter", "default -p 12345") obj= TuxI() adapter.add(obj, ic.stringToIdentity("theTux")) adapter.activate() print "Waiting for shutdown" ic.waitForShutdown()
Is the server and client code fine?
Starting the server works:
$ python ./server.py Waiting for shutdown
The client connects to the server and fails:
$ python ./client.py Traceback (most recent call last): File "./client.py", line 12, in <module> tux.fly() File "/home/mkulas/tmp/ice_remote_addr/tux_ice.py", line 56, in fly return _M_chaos.Tux._op_fly.invoke(self, ((), _ctx)) Ice.ConnectionLostException: Ice.ConnectionLostException: recv() returned zero
The server has crashed with a segmentation fault:
$ python ./server.py Waiting for shutdown Flying ... dir current.con: ['__class__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'begin_flushBatchRequests', 'close', 'createProxy', 'end_flushBatchRequests', 'flushBatchRequests', 'getAdapter', 'getEndpoint', 'getInfo', 'setAdapter', 'timeout', 'toString', 'type'] zsh: segmentation fault (core dumped) python ./server.py $ gdb `which python` core GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs Copyright (C) 2014 Free Software Foundation, Inc. [... SNIPPED ...] warning: core file may not match specified executable file. [New LWP 22932] [New LWP 22928] [New LWP 22929] [New LWP 22931] [New LWP 22933] [New LWP 22930] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `python ./server.py'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fccaed94838 in __dynamic_cast () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (gdb) bt #0 0x00007fccaed94838 in __dynamic_cast () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x00007fccafbb64fb in dynamicCast<Ice::ConnectionInfo> (r=...) at ../../../cpp/include/Ice/Handle.h:175 #2 IcePy::createConnectionInfo (connectionInfo=...) at ConnectionInfo.cpp:423 #3 0x00007fccafbb47e6 in connectionGetInfo (self=<optimized out>) at Connection.cpp:436 #4 0x00000000004cb00d in PyEval_EvalFrameEx () #5 0x00000000004e6970 in ?? () #6 0x0000000000505128 in ?? () #7 0x00000000004b3ffe in PyObject_Call () #8 0x00007fccafbd5b41 in IcePy::TypedUpcall::dispatch (this=0x7fcca4001790, servant=0x7fccae438b50, inBytes=..., current=...) at Operation.cpp:3337 #9 0x00007fccafbd0fb2 in IcePy::TypedServantWrapper::ice_invoke_async ( this=0x2acfec0, cb=..., inParams=..., current=...) at Operation.cpp:4106 #10 0x00007fccaf7b9e17 in Ice::BlobjectArrayAsync::__dispatch (this=0x2acfec0, in=..., current=...) at Object.cpp:436 #11 0x00007fccaf759cf4 in IceInternal::Incoming::invoke ( this=this@entry=0x7fccacbba490, servantManager=..., stream=stream@entry=0x7fccacbbaaa8) at Incoming.cpp:677 #12 0x00007fccaf732803 in Ice::ConnectionI::invokeAll ( this=this@entry=0x7fcca4000ca0, stream=..., invokeNum=invokeNum@entry=1, requestId=requestId@entry=2, compress=compress@entry=0 '\000', servantManager=..., adapter=...) at ConnectionI.cpp:3124 #13 0x00007fccaf732b98 in Ice::ConnectionI::dispatch ( this=this@entry=0x7fcca4000ca0, startCB=..., sentCBs=std::vector of length 0, capacity 0, compress=<optimized out>, requestId=2, invokeNum=1, servantManager=..., adapter=..., outAsync=..., stream=...) at ConnectionI.cpp:1629 #14 0x00007fccaf7346e9 in Ice::ConnectionI::message (this=0x7fcca4000ca0, current=...) at ConnectionI.cpp:1576 #15 0x00007fccaf86eabc in IceInternal::ThreadPool::run (this=0x2ad0140, thread=...) at ThreadPool.cpp:643 [... SNIPPED ...]
Here comes my system configuration:
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.10 Release: 14.10 Codename: utopic $ slice2py --version 3.5.1 $ python --version Python 2.7.8
What am I doing wrong?
Thank you in advance!
0
Comments
-
Hi,
I cannot reproduce the crash with the provided test case.jose@sirius:~/Work/zeroc/Ice-3.5.1/py/demo/Ice/flux$ LD_LIBRARY_PATH=../../../../cpp/lib PYTHONPATH=../../../python python Server.py Waiting for shutdown Flying ... dir current.con: ['__class__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'begin_flushBatchRequests', 'close', 'createProxy', 'end_flushBatchRequests', 'flushBatchRequests', 'getAdapter', 'getEndpoint', 'getInfo', 'setAdapter', 'timeout', 'toString', 'type'] Done: Flying
Using same OS, Ice and python versions$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.10 Release: 14.10 Codename: utopic $ slice2py --version 3.5.1 $ python --version Python 2.7.8
How did you build and install Ice-3.5.1? seems to me like for some reason the type info for TCPConnectionInfo ins't available to the IcePy python extension and this result in the dynamic_cast crash0 -
I cannot reproduce the crash with the provided test case.jose@sirius:~/Work/zeroc/Ice-3.5.1/py/demo/Ice/flux$ LD_LIBRARY_PATH=../../../../cpp/lib PYTHONPATH=../../../python python Server.py Waiting for shutdown Flying ... dir current.con: ['__class__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'begin_flushBatchRequests', 'close', 'createProxy', 'end_flushBatchRequests', 'flushBatchRequests', 'getAdapter', 'getEndpoint', 'getInfo', 'setAdapter', 'timeout', 'toString', 'type'] Done: Flying
Using same OS, Ice and python versions$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.10 Release: 14.10 Codename: utopic $ slice2py --version 3.5.1 $ python --version Python 2.7.8
How did you build and install Ice-3.5.1? seems to me like for some reason the type info for TCPConnectionInfo ins't available to the IcePy python extension and this result in the dynamic_cast crash
My programs were working fine with Ice 3.4.x on Ubuntu 13.10. Then, I have
updated to Ubuntu 14.10 which caused to update the Ice libraries.
Thus, I am using the Ice binaries coming from Ubuntu.
Which libraries do you recommend for Ubuntu 14.10? Do you compile
Ice yourself?0 -
I have build 3.5.1 from sources for the testing, maybe a problem with the upgrade, you can try to remove all Ice packages, and re-install them, ensure you don't have any Ice 13.10 packages left behind.0
-
Hi xdm!I have build 3.5.1 from sources for the testing, maybe a problem with the upgrade, you can try to remove all Ice packages, and re-install them, ensure you don't have any Ice 13.10 packages left behind.
After reinstalling the Ice packages from Ubuntu, the failure was
still there. Then I have built Ice from scratch and then the failure
is gone. Thank you!0 -
Seems a problem with the packages provided by Ubuntu, ZeroC does not build these packages. I have test with Ubuntu packages and get the same crash.
Looking at their source builds I see that their C++ Ice packages are build with -std=c++0x but the IcePy extension is not I wonder if this is causing the rtti crash.
If you want the Ubuntu packages to be fixed you will need to report the bug to Ubuntu package maintainers.0 -
If you want the Ubuntu packages to be fixed you will need to report the bug to Ubuntu package maintainers.
[X] Done [0]
Thank you again for your effort, xdm!
[0] https://bugs.launchpad.net/ubuntu/+source/zeroc-ice/+bug/14102650 -
Thanks Jose for mentioning how the "-std=c++0x" compiler flag is used in the Ubuntu build. This pointed me in the right direction.
I had similar errors on Debian Jessie with python 3.4.2 and zeroc-ice 3.5.1.
I also tried Debian testing and Ubuntu testing with the same result. Both those systems ran python 3.5.1 and and zeroc-ice 3.5.1.
The bug is indeed caused by different use of the "-std=c++0x" compiler flag during the build of the C++ Ice packages and the IcePy extension. But this is not a bug in the Debian/Ubuntu
build script. The bug is just triggered by the use of the build flag "CPP11=yes" in the Debian/Ubuntu build script.
The "CPP11=yes" build flag causes the compiler flag "-std=c++0x" to be included like it should be. But this compiler flag is reset during the build of the IcePy extension by the line
"CPPFLAGS =" in the second half of zeroc-ice-3.5.1/py/config/Make.rules.
The following patch solved the bug as far as the python extension is concerned:
--- zeroc-ice-3.5.1/py/config/Make.rules.original 2013-10-04 17:48:15.000000000 +0200
+++ zeroc-ice-3.5.1/py/config/Make.rules 2016-02-24 16:08:58.531547408 +0100
endif
CPPFLAGS =
+ifeq ($(CXX),g++)
+ ifeq ($(CPP11), yes)
+ CPPFLAGS = -std=c++0x
+ endif
+endif
+
ICECPPFLAGS = -I$(slicedir)
SLICE2PYFLAGS = $(ICECPPFLAGS)
LDFLAGS = $(LDPLATFORMFLAGS) $(CXXFLAGS) -L$(libdir)
We don't use zeroc-ice with ruby or PHP so we didn't test the ruby and PHP extentions. But looking at the other Make.rules* files I expect similar errors with ruby and PHP.
Best regards,
Kees Theunissen0