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
