You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(46) |
Aug
(13) |
Sep
(7) |
Oct
(37) |
Nov
(2) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(21) |
Feb
(104) |
Mar
(39) |
Apr
(7) |
May
(6) |
Jun
(5) |
Jul
(16) |
Aug
(38) |
Sep
(1) |
Oct
|
Nov
(18) |
Dec
(1) |
2004 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
(4) |
May
(5) |
Jun
(1) |
Jul
(7) |
Aug
(1) |
Sep
|
Oct
|
Nov
(10) |
Dec
|
2005 |
Jan
(19) |
Feb
(30) |
Mar
(7) |
Apr
(3) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
From: <dth...@us...> - 2005-02-27 07:10:18
|
Update of /cvsroot/fnorb/fnorb/examples/misc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25519/misc Modified Files: poa_server.py Log Message: Updated to reflect the new policy that OAs aren't passed to servants. Index: poa_server.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/examples/misc/poa_server.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** poa_server.py 26 Jan 2004 11:20:50 -0000 1.2 --- poa_server.py 27 Feb 2005 07:10:07 -0000 1.3 *************** *** 48,52 **** def __init__(self, poa, name): ! CORBA.Object_skel.__init__(self, poa) self._name = name --- 48,52 ---- def __init__(self, poa, name): ! CORBA.Object_skel.__init__(self) self._name = name *************** *** 60,64 **** # Base class constructor. ! CORBA.Object_skel.__init__(self, poa) self.poa = poa --- 60,64 ---- # Base class constructor. ! CORBA.Object_skel.__init__(self) self.poa = poa |
From: <dth...@us...> - 2005-02-27 07:10:16
|
Update of /cvsroot/fnorb/fnorb/examples/tkinter In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25519/tkinter Modified Files: server.py Log Message: Updated to reflect the new policy that OAs aren't passed to servants. Index: server.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/examples/tkinter/server.py,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -d -r1.11 -r1.12 *** server.py 30 Nov 2003 15:29:13 -0000 1.11 --- server.py 27 Feb 2005 07:10:07 -0000 1.12 *************** *** 153,157 **** # Initialise the BOA. ! boa = BOA.BOA_init(orb, sys.argv, BOA.BOA_ID) print 'Creating object reference...' --- 153,157 ---- # Initialise the BOA. ! boa = BOA.BOA_init(sys.argv, BOA.BOA_ID) print 'Creating object reference...' |
From: <dth...@us...> - 2005-02-27 07:10:16
|
Update of /cvsroot/fnorb/fnorb/examples/hello-world In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25519/hello-world Modified Files: server.py Log Message: Updated to reflect the new policy that OAs aren't passed to servants. Index: server.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/examples/hello-world/server.py,v retrieving revision 1.10 retrieving revision 1.11 diff -C2 -d -r1.10 -r1.11 *** server.py 6 Apr 2004 09:32:51 -0000 1.10 --- server.py 27 Feb 2005 07:10:07 -0000 1.11 *************** *** 75,79 **** # Create an instance of the implementation class. ! impl = HelloWorldServer(boa) print 'Activating the implementation...' --- 75,79 ---- # Create an instance of the implementation class. ! impl = HelloWorldServer() print 'Activating the implementation...' |
From: <dth...@us...> - 2005-02-27 07:08:36
|
Update of /cvsroot/fnorb/fnorb/orb In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25033 Modified Files: CORBA.py BOA.py Log Message: The OA is no longer passed to servants, this change implements that policy. Index: CORBA.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/orb/CORBA.py,v retrieving revision 1.62 retrieving revision 1.63 diff -C2 -d -r1.62 -r1.63 *** CORBA.py 6 Apr 2004 09:46:12 -0000 1.62 --- CORBA.py 27 Feb 2005 07:08:26 -0000 1.63 *************** *** 644,647 **** --- 644,662 ---- return options + def _fnorb_get_option(self, option): + """ Get the value of one option, or None if not present. """ + + self.__lk.acquire() + + try: + + try: + return self.__options[option] + except KeyError, ex: + return None + + finally: + self.__lk.release() + def _fnorb_get_process_codeset(self): "Return the codeset used in narrow (byte) strings." *************** *** 1590,1594 **** _FNORB_ID = 'IDL:omg.org/CORBA/Object:1.0' ! def __init__(self, boa=None): """ Constructor. --- 1605,1609 ---- _FNORB_ID = 'IDL:omg.org/CORBA/Object:1.0' ! def __init__(self): """ Constructor. *************** *** 1600,1604 **** """ ! self.__boa = boa self.__initialise() return --- 1615,1633 ---- """ ! # ! # If we're not using the POA, we can use the singleton BOA ! # to implement certain operations (like marshal_value) that would ! # not otherwise be possible, so we grab a reference to the BOA. ! # ! # If we are using the POA, we don't set the self.__boa attribute ! # so that attempted usage will cause an exception to be thrown. ! # ! ! orb = CORBA.ORB_init() ! poa_option = orb._fnorb_get_option('POA') ! ! if not poa_option: ! self.__boa = BOA.BOA_init() ! self.__initialise() return *************** *** 1647,1655 **** """ - # Get a reference to the ORB that we are living in. - orb = self.__boa._fnorb_get_boa() # Get a reference to the Interface Repository. ! ir = orb.resolve_initial_references('InterfaceRepository') # Lookup our interface id to get the interface definition object. --- 1676,1682 ---- """ # Get a reference to the Interface Repository. ! ir = CORBA.ORB_init().resolve_initial_references('InterfaceRepository') # Lookup our interface id to get the interface definition object. Index: BOA.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/orb/BOA.py,v retrieving revision 1.39 retrieving revision 1.40 diff -C2 -d -r1.39 -r1.40 *** BOA.py 6 Apr 2004 09:39:57 -0000 1.39 --- BOA.py 27 Feb 2005 07:08:26 -0000 1.40 *************** *** 51,61 **** ############################################################################# def BOA_init(argv=[], boa_id=BOA_ID): """ Initialise the BOA. """ ! boa = BOA(argv, boa_id) ! return boa class BOA: --- 51,65 ---- ############################################################################# + _the_boa = None + def BOA_init(argv=[], boa_id=BOA_ID): """ Initialise the BOA. """ ! global _the_boa ! if _the_boa == None: ! _the_boa = BOA(argv, boa_id) + return _the_boa class BOA: |
From: <dth...@us...> - 2005-02-27 07:06:12
|
Update of /cvsroot/fnorb/fnorb/orb In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24567 Modified Files: PortableServer.py Log Message: Fixed policy naming errors. Index: PortableServer.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/orb/PortableServer.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -d -r1.4 -r1.5 *** PortableServer.py 18 Jul 2004 11:14:19 -0000 1.4 --- PortableServer.py 27 Feb 2005 07:06:03 -0000 1.5 *************** *** 319,322 **** --- 319,336 ---- encaps.data()) + + # If the ORB is running in multi-threaded mode then start a thread-pool + # to handle incoming requests. + orb = CORBA.ORB_init() + if orb._fnorb_threading_model() == Util.THREADED: + # Get the size of the thread pool from the ORB. + size = orb._fnorb_thread_pool_size() + if size > 0: + from ThreadPoolQueue import ThreadPoolQueue + + # Create and start the queue. + self.__queue = ThreadPoolQueue(size, self.__process_request) + self.__queue.start() + return *************** *** 530,537 **** if self.id_assignment_policy._get_value() != POA.SYSTEM_ID: ! raise PortableServer.POA.WrongPolicyException() if self.servant_retention_policy._get_value() != POA.RETAIN: ! raise PortableServer.POA.WrongPolicyException() # Check that the servant is not already registered in the --- 544,551 ---- if self.id_assignment_policy._get_value() != POA.SYSTEM_ID: ! raise POA.WrongPolicyException() if self.servant_retention_policy._get_value() != POA.RETAIN: ! raise POA.WrongPolicyException() # Check that the servant is not already registered in the *************** *** 540,544 **** if self.id_uniqueness_policy._get_value() == POA.UNIQUE_ID: if p_servant in self.aom.values(): ! raise PortableServer.POA.ServantAlreadyActive() # Create the object's Id. --- 554,558 ---- if self.id_uniqueness_policy._get_value() == POA.UNIQUE_ID: if p_servant in self.aom.values(): ! raise POA.ServantAlreadyActive() # Create the object's Id. *************** *** 572,576 **** # ServantRetentionPolicy must be RETAIN. if self.servant_retention_policy._get_value() != POA.RETAIN: ! raise PortableServer.POA.WrongPolicyException() # TODO We must "detect" if this is not an id generated by this POA, --- 586,590 ---- # ServantRetentionPolicy must be RETAIN. if self.servant_retention_policy._get_value() != POA.RETAIN: ! raise POA.WrongPolicyException() # TODO We must "detect" if this is not an id generated by this POA, *************** *** 578,582 **** # IdAssignmentPolicy is SYSTEM_ID. if self.id_assignment_policy._get_value() == POA.SYSTEM_ID: ! raise PortableServer.POA.WrongPolicyException() # Check that the servant is not already registered in the --- 592,596 ---- # IdAssignmentPolicy is SYSTEM_ID. if self.id_assignment_policy._get_value() == POA.SYSTEM_ID: ! raise POA.WrongPolicyException() # Check that the servant is not already registered in the *************** *** 585,592 **** if self.id_uniqueness_policy._get_value() == POA.UNIQUE_ID: if p_servant in self.aom.values(): ! raise PortableServer.POA.ServantAlreadyActive() if self.aom.has_key(oid): ! raise PortableServer.POA.ObjectAlreadyActive() # Register the servant with the new id in the active object map. --- 599,606 ---- if self.id_uniqueness_policy._get_value() == POA.UNIQUE_ID: if p_servant in self.aom.values(): ! raise POA.ServantAlreadyActive() if self.aom.has_key(oid): ! raise POA.ObjectAlreadyActive() # Register the servant with the new id in the active object map. *************** *** 607,611 **** if self.servant_retention_policy._get_value() != POA.RETAIN: ! raise PortableServer.POA.WrongPolicyException() # Remove the object key from the implementation's key table. --- 621,625 ---- if self.servant_retention_policy._get_value() != POA.RETAIN: ! raise POA.WrongPolicyException() # Remove the object key from the implementation's key table. *************** *** 631,635 **** if self.id_assignment_policy._get_value() != POA.SYSTEM_ID: ! raise PortableServer.POA.WrongPolicyException() assert 0, "Not yet supported" --- 645,649 ---- if self.id_assignment_policy._get_value() != POA.SYSTEM_ID: ! raise POA.WrongPolicyException() assert 0, "Not yet supported" *************** *** 650,654 **** # IdAssignmentPolicy is SYSTEM_ID. if self.id_assignment_policy._get_value() == POA.SYSTEM_ID: ! raise PortableServer.POA.WrongPolicyException() # Create an IOR. --- 664,668 ---- # IdAssignmentPolicy is SYSTEM_ID. if self.id_assignment_policy._get_value() == POA.SYSTEM_ID: ! raise POA.WrongPolicyException() # Create an IOR. *************** *** 674,678 **** if self.servant_retention_policy._get_value() != POA.RETAIN: ! raise PortableServer.POA.WrongPolicyException() id_uniqueness_policy = \ --- 688,692 ---- if self.servant_retention_policy._get_value() != POA.RETAIN: ! raise POA.WrongPolicyException() id_uniqueness_policy = \ *************** *** 684,688 **** and implicit_activation_policy != POA.IMPLICIT_ACTIVATION ): ! raise PortableServer.POA.WrongPolicyException() if p_servant in self.aom.values() and \ --- 698,702 ---- and implicit_activation_policy != POA.IMPLICIT_ACTIVATION ): ! raise POA.WrongPolicyException() if p_servant in self.aom.values() and \ *************** *** 710,714 **** # TODO Throw ServantNotActive. ! raise PortableServer.POA.ServantNotActive() # Servant reference_to_servant( --- 724,728 ---- # TODO Throw ServantNotActive. ! raise POA.ServantNotActive() # Servant reference_to_servant( *************** *** 764,768 **** if servant_retention_policy != POA.RETAIN and \ request_processing_policy == POA.USE_DEFAULT_SERVANT: ! raise PortableServer.POA.WrongPolicyException() # Default servants aren't supported yet. --- 778,782 ---- if servant_retention_policy != POA.RETAIN and \ request_processing_policy == POA.USE_DEFAULT_SERVANT: ! raise POA.WrongPolicyException() # Default servants aren't supported yet. *************** *** 772,776 **** # TODO Throw WrongPolicy exception. if not self.aom.has_key(oid): ! raise PortableServer.POA.WrongPolicyException() return self.aom[oid] --- 786,790 ---- # TODO Throw WrongPolicy exception. if not self.aom.has_key(oid): ! raise POA.WrongPolicyException() return self.aom[oid] *************** *** 786,793 **** if self.servant_retention_policy._get_value() != POA.RETAIN: ! raise PortableServer.POA.WrongPolicyException() if not self.aom.has_key(oid): ! raise PortableServer.POA.ObjectNotActive() servant = self.aom[oid] --- 800,807 ---- if self.servant_retention_policy._get_value() != POA.RETAIN: ! raise POA.WrongPolicyException() if not self.aom.has_key(oid): ! raise POA.ObjectNotActive() servant = self.aom[oid] *************** *** 822,837 **** """ Start the event loop. """ - # If the ORB is running in multi-threaded mode then start a thread-pool - # to handle incoming requests. orb = CORBA.ORB_init() - if orb._fnorb_threading_model() == Util.THREADED: - # Get the size of the thread pool from the ORB. - size = orb._fnorb_thread_pool_size() - if size > 0: - from ThreadPoolQueue import ThreadPoolQueue - - # Create and start the queue. - self.__queue = ThreadPoolQueue(size, self.__process_request) - self.__queue.start() # Ladies and Gentlemen, start your engines... --- 836,840 ---- |
From: <dth...@us...> - 2005-02-27 07:01:58
|
Update of /cvsroot/fnorb/fnorb/orb In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23713 Modified Files: GIOPServerWorkerReactive.py Log Message: Handle connection closure gracefully. Index: GIOPServerWorkerReactive.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/orb/GIOPServerWorkerReactive.py,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -d -r1.6 -r1.7 *** GIOPServerWorkerReactive.py 28 Oct 2002 07:30:47 -0000 1.6 --- GIOPServerWorkerReactive.py 27 Feb 2005 07:01:48 -0000 1.7 *************** *** 38,41 **** --- 38,43 ---- import CORBA, EventHandler, GIOPServerWorker, GIOPConnectionHandler, Reactor + import sys + class GIOPServerWorkerReactive(GIOPServerWorker.GIOPServerWorker, *************** *** 160,164 **** --- 162,177 ---- # Write event. elif mask & Reactor.WRITE: + try: + # If there aren't any messages to send, then this + # is the shutdown phase, so we close the connection + # and return. + + if len(self.__outgoing) == 0: + self.handle_close() + return + + # Send the message + self.__handler.send(self.__outgoing[0]) |
From: <dth...@us...> - 2005-02-27 06:58:48
|
Update of /cvsroot/fnorb/fnorb/cos/naming In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22472/naming Modified Files: NamingContext.py Log Message: Updated COS services to line up with new policy of NOT passing an OA to servant skeletons. Index: NamingContext.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/cos/naming/NamingContext.py,v retrieving revision 1.12 retrieving revision 1.13 diff -C2 -d -r1.12 -r1.13 *** NamingContext.py 30 Nov 2003 15:13:00 -0000 1.12 --- NamingContext.py 27 Feb 2005 06:58:38 -0000 1.13 *************** *** 124,128 **** assert isinstance(boa, BOA.BOA) ! CosNaming_skel.NamingContext_skel.__init__(self, boa) # A factory responsible for creating new naming contexts. --- 124,128 ---- assert isinstance(boa, BOA.BOA) ! CosNaming_skel.NamingContext_skel.__init__(self) # A factory responsible for creating new naming contexts. |
From: <dth...@us...> - 2005-02-27 06:58:48
|
Update of /cvsroot/fnorb/fnorb/cos/interface_repository In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22472/interface_repository Modified Files: IFR.py IntRepImpl.py Log Message: Updated COS services to line up with new policy of NOT passing an OA to servant skeletons. Index: IFR.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/cos/interface_repository/IFR.py,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -d -r1.6 -r1.7 *** IFR.py 30 Nov 2003 15:11:21 -0000 1.6 --- IFR.py 27 Feb 2005 06:58:38 -0000 1.7 *************** *** 39,43 **** # Fnorb modules. ! from Fnorb.orb import POA, CORBA # Interface Repository modules. --- 39,43 ---- # Fnorb modules. ! from Fnorb.orb import PortableServer, CORBA # Interface Repository modules. *************** *** 63,67 **** # Activate the implementation. ! oid = poa.activate_object(impl) obj = poa.id_to_reference(oid) --- 63,68 ---- # Activate the implementation. ! oid = 'IFR' ! poa.activate_object_with_id(oid, impl) obj = poa.id_to_reference(oid) Index: IntRepImpl.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/cos/interface_repository/IntRepImpl.py,v retrieving revision 1.28 retrieving revision 1.29 diff -C2 -d -r1.28 -r1.29 *** IntRepImpl.py 6 Apr 2004 09:27:21 -0000 1.28 --- IntRepImpl.py 27 Feb 2005 06:58:38 -0000 1.29 *************** *** 51,55 **** """ Constructor. """ ! IntRep_skel.IRObject_skel.__init__(self, boa) self.__boa = boa --- 51,55 ---- """ Constructor. """ ! IntRep_skel.IRObject_skel.__init__(self) self.__boa = boa |
From: SourceForge.net <no...@so...> - 2005-02-26 07:10:32
|
Bugs item #1118723, was opened at 2005-02-09 02:13 Message generated for change (Comment added) made by dthomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Derek Thomson (dthomson) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Derek Thomson (dthomson) Date: 2005-02-26 17:10 Message: Logged In: YES user_id=435731 Ah, here's your problem: > stringified_ior_neMgr = orb.object_to_string(simpleMgr) The issue is this - when there's only one object adapter, you can use the servant in place of a real CORBA object reference like this - because it's easy to get the right object adapter. This doesn't work when there's more than one object adapter, so you're now effectively passing in an object of the wrong "type". If you do this instead: > stringified_ior_neMgr = orb.object_to_string(obj1) It works fine. I just tried it. So if you change your code to only use real CORBA object references to operations like object_to_string, it'll be fine. On the other hand, I wonder how hard it would be to have the ORB support the old "magic" behaviour if you're not using the POA. I'll have to think about it, as this will break anyone who relies on the old behavior and I'd rather not hurt anyone who is still using the BOA if I can. I'll muck around with it. In the meantime, you should *finally* be able see if your typecode woes are addressed! ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-26 11:04 Message: Logged In: YES user_id=435731 Thanks, I'll try this out as soon as I can (this weekend, once I get my dev. PC working again). My goal is to allow the BOA to still work in the new POA release ... and the old BOA tests and examples still in fact work, so I *thought* I'd gotten it working alright. So I'm not sure what the problem is here. I've done something wrong no doubt. Let me get back to you. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-22 01:52 Message: Logged In: YES user_id=232289 I produced a simplified example that exhibits the latest problem I encountered. --- simple.idl BEGIN --- module MyModule { typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; interface Simple { void doSomething(in any arg); }; }; --- simple.idl END --- --- tryout.py BEGIN --- #!/usr/bin/env python import sys, os, re, string # fnorb modules from Fnorb.orb import BOA, CORBA import MyModule import MyModule_skel class SimpleMgr(MyModule_skel.Simple_skel): def __init__(self): print "SimpleMgr initialization" print '' orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID) boa = BOA.BOA_init(sys.argv, BOA.BOA_ID) obj1 = boa.create('SimpleMgr', SimpleMgr._FNORB_ID) simpleMgr = SimpleMgr() boa.obj_is_ready(obj1, simpleMgr) stringified_ior_neMgr = orb.object_to_string(simpleMgr) --- tryout.py END --- Am I doing something wrong? ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-17 09:25 Message: Logged In: YES user_id=435731 Urk. How annoying. I've not seen this one before. Welcome to Fnorb 1.4 beta testing, I guess :) I've gone to some trouble to allow the BOA to *still* work in this new POA supporting version of Fnorb, and it seems to be fine in the Fnorb tests and examples ... So, either the package I put together is flakey (I just built it with "python setup.py sdist") or you've managed to find a problem. Can me the code that makes it do this - that is, enough of an example so I can run it and see what's going on? That'll be the fastest way to find the problem. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 20:53 Message: Logged In: YES user_id=232289 Thank you for the package. Unfortunately, now the process fails to start: Traceback (most recent call last): File "mysimu.py", line 1061, in ? stringified_ior_myMgr = orb.object_to_string(myMgr) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 305, in object_to_string ior = object._fnorb_ior() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1714, in _fnorb_ior boa = self.__boa File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1617, in __getattr__ raise AttributeError, name AttributeError: _Object_skel__boa ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-16 08:12 Message: Logged In: YES user_id=435731 Sorry, I've been busy. I just sent it. Tell us how it goes. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 00:21 Message: Logged In: YES user_id=232289 Derek, did you send me anything? Because I received nothing. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-13 23:21 Message: Logged In: YES user_id=232289 Of course Derek, I don't know if there's a way to use SourceForge to send that package to my mailbox, so use this address: user: turina domain: libero.it (just to avoid email harvesters of spammers) Thank you. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:24 Message: Logged In: YES user_id=435731 Danilo, I have a source distribution packed up for you, but SourceForge won't allow an attachment greater than 256K. The package is about 326K. Can I simply email it to you, as it is not really very large? Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 21:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-11 00:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-10 02:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 22:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: <dth...@us...> - 2005-02-26 06:59:14
|
Update of /cvsroot/fnorb/fnorb/examples/misc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12245 Modified Files: server.py Log Message: BOA no longer needed by skeleton. Index: server.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/examples/misc/server.py,v retrieving revision 1.26 retrieving revision 1.27 diff -C2 -d -r1.26 -r1.27 *** server.py 6 Apr 2004 09:34:49 -0000 1.26 --- server.py 26 Feb 2005 06:59:04 -0000 1.27 *************** *** 48,52 **** def __init__(self, boa, name): ! CORBA.Object_skel.__init__(self, boa) self._name = name --- 48,52 ---- def __init__(self, boa, name): ! CORBA.Object_skel.__init__(self) self._name = name *************** *** 60,64 **** # Base class constructor. ! CORBA.Object_skel.__init__(self, boa) self.boa = boa --- 60,64 ---- # Base class constructor. ! CORBA.Object_skel.__init__(self) self.boa = boa *************** *** 160,164 **** obj = self.boa.create(name, SpriteServer._FNORB_ID) self.boa.obj_is_ready(obj, sprite) ! return sprite def take_nested_struct(self, outer_struct): --- 160,164 ---- obj = self.boa.create(name, SpriteServer._FNORB_ID) self.boa.obj_is_ready(obj, sprite) ! return obj def take_nested_struct(self, outer_struct): |
From: SourceForge.net <no...@so...> - 2005-02-26 01:04:11
|
Bugs item #1118723, was opened at 2005-02-09 02:13 Message generated for change (Comment added) made by dthomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Derek Thomson (dthomson) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Derek Thomson (dthomson) Date: 2005-02-26 11:04 Message: Logged In: YES user_id=435731 Thanks, I'll try this out as soon as I can (this weekend, once I get my dev. PC working again). My goal is to allow the BOA to still work in the new POA release ... and the old BOA tests and examples still in fact work, so I *thought* I'd gotten it working alright. So I'm not sure what the problem is here. I've done something wrong no doubt. Let me get back to you. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-22 01:52 Message: Logged In: YES user_id=232289 I produced a simplified example that exhibits the latest problem I encountered. --- simple.idl BEGIN --- module MyModule { typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; interface Simple { void doSomething(in any arg); }; }; --- simple.idl END --- --- tryout.py BEGIN --- #!/usr/bin/env python import sys, os, re, string # fnorb modules from Fnorb.orb import BOA, CORBA import MyModule import MyModule_skel class SimpleMgr(MyModule_skel.Simple_skel): def __init__(self): print "SimpleMgr initialization" print '' orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID) boa = BOA.BOA_init(sys.argv, BOA.BOA_ID) obj1 = boa.create('SimpleMgr', SimpleMgr._FNORB_ID) simpleMgr = SimpleMgr() boa.obj_is_ready(obj1, simpleMgr) stringified_ior_neMgr = orb.object_to_string(simpleMgr) --- tryout.py END --- Am I doing something wrong? ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-17 09:25 Message: Logged In: YES user_id=435731 Urk. How annoying. I've not seen this one before. Welcome to Fnorb 1.4 beta testing, I guess :) I've gone to some trouble to allow the BOA to *still* work in this new POA supporting version of Fnorb, and it seems to be fine in the Fnorb tests and examples ... So, either the package I put together is flakey (I just built it with "python setup.py sdist") or you've managed to find a problem. Can me the code that makes it do this - that is, enough of an example so I can run it and see what's going on? That'll be the fastest way to find the problem. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 20:53 Message: Logged In: YES user_id=232289 Thank you for the package. Unfortunately, now the process fails to start: Traceback (most recent call last): File "mysimu.py", line 1061, in ? stringified_ior_myMgr = orb.object_to_string(myMgr) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 305, in object_to_string ior = object._fnorb_ior() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1714, in _fnorb_ior boa = self.__boa File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1617, in __getattr__ raise AttributeError, name AttributeError: _Object_skel__boa ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-16 08:12 Message: Logged In: YES user_id=435731 Sorry, I've been busy. I just sent it. Tell us how it goes. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 00:21 Message: Logged In: YES user_id=232289 Derek, did you send me anything? Because I received nothing. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-13 23:21 Message: Logged In: YES user_id=232289 Of course Derek, I don't know if there's a way to use SourceForge to send that package to my mailbox, so use this address: user: turina domain: libero.it (just to avoid email harvesters of spammers) Thank you. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:24 Message: Logged In: YES user_id=435731 Danilo, I have a source distribution packed up for you, but SourceForge won't allow an attachment greater than 256K. The package is about 326K. Can I simply email it to you, as it is not really very large? Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 21:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-11 00:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-10 02:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 22:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-26 00:56:52
|
Bugs item #1118723, was opened at 2005-02-09 02:13 Message generated for change (Settings changed) made by dthomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) >Assigned to: Derek Thomson (dthomson) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-22 01:52 Message: Logged In: YES user_id=232289 I produced a simplified example that exhibits the latest problem I encountered. --- simple.idl BEGIN --- module MyModule { typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; interface Simple { void doSomething(in any arg); }; }; --- simple.idl END --- --- tryout.py BEGIN --- #!/usr/bin/env python import sys, os, re, string # fnorb modules from Fnorb.orb import BOA, CORBA import MyModule import MyModule_skel class SimpleMgr(MyModule_skel.Simple_skel): def __init__(self): print "SimpleMgr initialization" print '' orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID) boa = BOA.BOA_init(sys.argv, BOA.BOA_ID) obj1 = boa.create('SimpleMgr', SimpleMgr._FNORB_ID) simpleMgr = SimpleMgr() boa.obj_is_ready(obj1, simpleMgr) stringified_ior_neMgr = orb.object_to_string(simpleMgr) --- tryout.py END --- Am I doing something wrong? ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-17 09:25 Message: Logged In: YES user_id=435731 Urk. How annoying. I've not seen this one before. Welcome to Fnorb 1.4 beta testing, I guess :) I've gone to some trouble to allow the BOA to *still* work in this new POA supporting version of Fnorb, and it seems to be fine in the Fnorb tests and examples ... So, either the package I put together is flakey (I just built it with "python setup.py sdist") or you've managed to find a problem. Can me the code that makes it do this - that is, enough of an example so I can run it and see what's going on? That'll be the fastest way to find the problem. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 20:53 Message: Logged In: YES user_id=232289 Thank you for the package. Unfortunately, now the process fails to start: Traceback (most recent call last): File "mysimu.py", line 1061, in ? stringified_ior_myMgr = orb.object_to_string(myMgr) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 305, in object_to_string ior = object._fnorb_ior() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1714, in _fnorb_ior boa = self.__boa File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1617, in __getattr__ raise AttributeError, name AttributeError: _Object_skel__boa ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-16 08:12 Message: Logged In: YES user_id=435731 Sorry, I've been busy. I just sent it. Tell us how it goes. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 00:21 Message: Logged In: YES user_id=232289 Derek, did you send me anything? Because I received nothing. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-13 23:21 Message: Logged In: YES user_id=232289 Of course Derek, I don't know if there's a way to use SourceForge to send that package to my mailbox, so use this address: user: turina domain: libero.it (just to avoid email harvesters of spammers) Thank you. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:24 Message: Logged In: YES user_id=435731 Danilo, I have a source distribution packed up for you, but SourceForge won't allow an attachment greater than 256K. The package is about 326K. Can I simply email it to you, as it is not really very large? Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 21:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-11 00:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-10 02:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 22:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-21 15:52:36
|
Bugs item #1118723, was opened at 2005-02-08 17:13 Message generated for change (Comment added) made by daniloturina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Danilo Turina (daniloturina) Date: 2005-02-21 16:52 Message: Logged In: YES user_id=232289 I produced a simplified example that exhibits the latest problem I encountered. --- simple.idl BEGIN --- module MyModule { typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; interface Simple { void doSomething(in any arg); }; }; --- simple.idl END --- --- tryout.py BEGIN --- #!/usr/bin/env python import sys, os, re, string # fnorb modules from Fnorb.orb import BOA, CORBA import MyModule import MyModule_skel class SimpleMgr(MyModule_skel.Simple_skel): def __init__(self): print "SimpleMgr initialization" print '' orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID) boa = BOA.BOA_init(sys.argv, BOA.BOA_ID) obj1 = boa.create('SimpleMgr', SimpleMgr._FNORB_ID) simpleMgr = SimpleMgr() boa.obj_is_ready(obj1, simpleMgr) stringified_ior_neMgr = orb.object_to_string(simpleMgr) --- tryout.py END --- Am I doing something wrong? ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-17 00:25 Message: Logged In: YES user_id=435731 Urk. How annoying. I've not seen this one before. Welcome to Fnorb 1.4 beta testing, I guess :) I've gone to some trouble to allow the BOA to *still* work in this new POA supporting version of Fnorb, and it seems to be fine in the Fnorb tests and examples ... So, either the package I put together is flakey (I just built it with "python setup.py sdist") or you've managed to find a problem. Can me the code that makes it do this - that is, enough of an example so I can run it and see what's going on? That'll be the fastest way to find the problem. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 11:53 Message: Logged In: YES user_id=232289 Thank you for the package. Unfortunately, now the process fails to start: Traceback (most recent call last): File "mysimu.py", line 1061, in ? stringified_ior_myMgr = orb.object_to_string(myMgr) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 305, in object_to_string ior = object._fnorb_ior() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1714, in _fnorb_ior boa = self.__boa File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1617, in __getattr__ raise AttributeError, name AttributeError: _Object_skel__boa ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-15 23:12 Message: Logged In: YES user_id=435731 Sorry, I've been busy. I just sent it. Tell us how it goes. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-15 15:21 Message: Logged In: YES user_id=232289 Derek, did you send me anything? Because I received nothing. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-13 14:21 Message: Logged In: YES user_id=232289 Of course Derek, I don't know if there's a way to use SourceForge to send that package to my mailbox, so use this address: user: turina domain: libero.it (just to avoid email harvesters of spammers) Thank you. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 12:24 Message: Logged In: YES user_id=435731 Danilo, I have a source distribution packed up for you, but SourceForge won't allow an attachment greater than 256K. The package is about 326K. Can I simply email it to you, as it is not really very large? Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 12:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 12:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-10 15:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-09 17:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 13:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-16 23:25:50
|
Bugs item #1118723, was opened at 2005-02-09 02:13 Message generated for change (Comment added) made by dthomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Derek Thomson (dthomson) Date: 2005-02-17 09:25 Message: Logged In: YES user_id=435731 Urk. How annoying. I've not seen this one before. Welcome to Fnorb 1.4 beta testing, I guess :) I've gone to some trouble to allow the BOA to *still* work in this new POA supporting version of Fnorb, and it seems to be fine in the Fnorb tests and examples ... So, either the package I put together is flakey (I just built it with "python setup.py sdist") or you've managed to find a problem. Can me the code that makes it do this - that is, enough of an example so I can run it and see what's going on? That'll be the fastest way to find the problem. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 20:53 Message: Logged In: YES user_id=232289 Thank you for the package. Unfortunately, now the process fails to start: Traceback (most recent call last): File "mysimu.py", line 1061, in ? stringified_ior_myMgr = orb.object_to_string(myMgr) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 305, in object_to_string ior = object._fnorb_ior() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1714, in _fnorb_ior boa = self.__boa File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1617, in __getattr__ raise AttributeError, name AttributeError: _Object_skel__boa ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-16 08:12 Message: Logged In: YES user_id=435731 Sorry, I've been busy. I just sent it. Tell us how it goes. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 00:21 Message: Logged In: YES user_id=232289 Derek, did you send me anything? Because I received nothing. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-13 23:21 Message: Logged In: YES user_id=232289 Of course Derek, I don't know if there's a way to use SourceForge to send that package to my mailbox, so use this address: user: turina domain: libero.it (just to avoid email harvesters of spammers) Thank you. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:24 Message: Logged In: YES user_id=435731 Danilo, I have a source distribution packed up for you, but SourceForge won't allow an attachment greater than 256K. The package is about 326K. Can I simply email it to you, as it is not really very large? Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 21:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-11 00:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-10 02:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 22:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-16 10:53:18
|
Bugs item #1118723, was opened at 2005-02-08 17:13 Message generated for change (Comment added) made by daniloturina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 11:53 Message: Logged In: YES user_id=232289 Thank you for the package. Unfortunately, now the process fails to start: Traceback (most recent call last): File "mysimu.py", line 1061, in ? stringified_ior_myMgr = orb.object_to_string(myMgr) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 305, in object_to_string ior = object._fnorb_ior() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1714, in _fnorb_ior boa = self.__boa File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/CORBA.py", line 1617, in __getattr__ raise AttributeError, name AttributeError: _Object_skel__boa ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-15 23:12 Message: Logged In: YES user_id=435731 Sorry, I've been busy. I just sent it. Tell us how it goes. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-15 15:21 Message: Logged In: YES user_id=232289 Derek, did you send me anything? Because I received nothing. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-13 14:21 Message: Logged In: YES user_id=232289 Of course Derek, I don't know if there's a way to use SourceForge to send that package to my mailbox, so use this address: user: turina domain: libero.it (just to avoid email harvesters of spammers) Thank you. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 12:24 Message: Logged In: YES user_id=435731 Danilo, I have a source distribution packed up for you, but SourceForge won't allow an attachment greater than 256K. The package is about 326K. Can I simply email it to you, as it is not really very large? Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 12:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 12:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-10 15:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-09 17:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 13:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-15 22:12:11
|
Bugs item #1118723, was opened at 2005-02-09 02:13 Message generated for change (Comment added) made by dthomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Derek Thomson (dthomson) Date: 2005-02-16 08:12 Message: Logged In: YES user_id=435731 Sorry, I've been busy. I just sent it. Tell us how it goes. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-16 00:21 Message: Logged In: YES user_id=232289 Derek, did you send me anything? Because I received nothing. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-13 23:21 Message: Logged In: YES user_id=232289 Of course Derek, I don't know if there's a way to use SourceForge to send that package to my mailbox, so use this address: user: turina domain: libero.it (just to avoid email harvesters of spammers) Thank you. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:24 Message: Logged In: YES user_id=435731 Danilo, I have a source distribution packed up for you, but SourceForge won't allow an attachment greater than 256K. The package is about 326K. Can I simply email it to you, as it is not really very large? Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 21:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-11 00:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-10 02:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 22:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-15 14:21:27
|
Bugs item #1118723, was opened at 2005-02-08 17:13 Message generated for change (Comment added) made by daniloturina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Danilo Turina (daniloturina) Date: 2005-02-15 15:21 Message: Logged In: YES user_id=232289 Derek, did you send me anything? Because I received nothing. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-13 14:21 Message: Logged In: YES user_id=232289 Of course Derek, I don't know if there's a way to use SourceForge to send that package to my mailbox, so use this address: user: turina domain: libero.it (just to avoid email harvesters of spammers) Thank you. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 12:24 Message: Logged In: YES user_id=435731 Danilo, I have a source distribution packed up for you, but SourceForge won't allow an attachment greater than 256K. The package is about 326K. Can I simply email it to you, as it is not really very large? Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 12:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 12:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-10 15:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-09 17:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 13:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-13 13:21:09
|
Bugs item #1118723, was opened at 2005-02-08 17:13 Message generated for change (Comment added) made by daniloturina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Danilo Turina (daniloturina) Date: 2005-02-13 14:21 Message: Logged In: YES user_id=232289 Of course Derek, I don't know if there's a way to use SourceForge to send that package to my mailbox, so use this address: user: turina domain: libero.it (just to avoid email harvesters of spammers) Thank you. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 12:24 Message: Logged In: YES user_id=435731 Danilo, I have a source distribution packed up for you, but SourceForge won't allow an attachment greater than 256K. The package is about 326K. Can I simply email it to you, as it is not really very large? Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 12:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 12:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-10 15:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-09 17:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 13:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-13 11:37:53
|
Bugs item #1068018, was opened at 2004-11-17 23:49 Message generated for change (Comment added) made by dthomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1068018&group_id=44742 Category: IIOP Engine Group: v1.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Derek Thomson (dthomson) Summary: raise CORBA.COMM_FAILURE() # System exception Initial Comment: We have some Python code which is fully functional with Python 1.5 and Fnorb 1.1.... And with Fnorb 1.2 and Python 2.2, we have this error : EmlViewImpl::ObjectImpl::GetMultiColumn: ...........done Unhandled exception in thread: Traceback (most recent call last): File "/vobs/ETH.vob0/src/adaptation/emlim_snmp_proxy/simu_server/core_impl/GetAsynchReplyThread.py", line 60, in _worker apply(func,args) File "/vobs/ETH.vob0/src/adaptation/emlim_snmp_proxy/simu_server/core_impl/GetAsynchReplyThread.py", line 105, in doAction reply.GetMultiResp_completed(neName,RetrievedList,status,CORBA.TRUE) File "/vobs/ETH.vob0/src/common/emlview_adaptation/genstubskel/idl2python/OpticsIMCsgReply/__init__.py", line 72, in GetMultiResp_completed apply(request.invoke, args, kw) File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/DII.py", line 160, in invoke (forwarded, self.__results) = client.synchronous(self, args) File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/GIOPClient.py", line 92, in synchronous worker = self.__get_worker() File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/GIOPClient.py", line 401, in __get_worker self.__address) File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/GIOPClientWorker.py", line 101, in create_worker worker = GIOPClientWorkerThreaded(protocol, address) File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/GIOPClientWorkerThreaded.py", line 89, in __init__ self.__connection.connect(self.__address) File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/IIOPConnection.py", line 107, in connect raise CORBA.COMM_FAILURE() # System exception. Fnorb.orb.CORBA.COMM_FAILURE: Minor: 0 Completed: COMPLETED_NO ---------------------------------------------------------------------- >Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:37 Message: Logged In: YES user_id=435731 Okay, I've tried the "hello world" and "misc" examples with Fnorb 1.2 and Python 2.2.1, and they seems to work fine. So I don't think it's intrinsically a Fnorb problem at the moment. For the time being, I'll wait for either the details of the socket error (as we discussed) or a small self-contained example that I can use to reproduce the problem. Regards, Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-11 00:52 Message: Logged In: YES user_id=435731 Do you have any updates on this? There's not much that can be done without knowing what the error is. The other thing to realize is that the Python socket interface (specifically the "connect" method!) changed at version 2.0, which would cause this problem. However, since we fixed the code with Fnorb 1.2 to use the new connect arguments, that means that the combination of Python 2.2 with Fnorb 1.2 should be okay. Something like Python 2.2 and Fnorb 1.1 wouldn't be. Neither would Python 1.x or Fnorb 1.2. So I guess one thing to look at would be whether you're running the version of Python and/or Fnorb that you think you are (it's easy to end up with the wrong Python executable, expecially on systems that come with Python 1.x installed, so check your environment settings and so on). Another thing to try, like I said already, would be a more recent version of Python - maybe the doco is wrong and the change-over in the socket interface happened later than 2.0. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-01-04 20:39 Message: Logged In: YES user_id=435731 Okay, that's great. Getting the actual error thrown by the method invocations on the socket would be a big help. I had another thought - did you try it with any version greater than Python 2.2? Can you try and see what happens? ---------------------------------------------------------------------- Comment By: Ch. Lafaille (clafaille) Date: 2005-01-04 17:03 Message: Logged In: YES user_id=1160917 When using Python 1.5.2 + Fnorb 1.1, all is OK without any change on the server side and no change on client side code (only modification on usage of cdrpy/cdr module). The problem occurs only with Python 2.2 + Fnorb 1.2. I'll modify the code to see the socket exception and I'll discuss with the dev team to see if it's possible to extract a part of our code and to have a maximum of informations for the resolution of this problem. We're using TAO (C++ ORB) on the server side. JacORB (Java ORB) is also used but it's not involved in our case. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-01-04 01:26 Message: Logged In: YES user_id=435731 It seems I misread that trace - it's actually long stack trace with an extra blank line in there. Anyway, the code in IIOPConnection that throws the exception is the code that tries to make the first connection to the server - and it's just not able to connect at all, using the standard Python sockets library. So what's your server doing while this is happening? As for why it might work in older Pythons, I've no idea. Is the server the same? Is it Python/Fnorb, or something else? There really isn't enough information in this bug report to draw any conclusions, it's just a client side exception which could be due to anything ... I think you need to describe what you are trying to do exactly and what form both the client and the server take. Is there any error or any useful information about the server? How do you know it's running and accepting connections, for example? If it's dying before that point, that would be an obvious cause of the error you provided for the client! The first thing is to find out what the actually socket error is. Try writing out the socket exception that is actually caught in IIOPConnection.connect below, by adding some debug code in the "except" block that catches it (reproduced below) and tell us what you see. # Create a socket and connect to the remote object. try: self.__socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.__socket.connect(address) # Set the socket by default to NON-blocking mode. # Jython sockets have no 'setblocking' method. if hasattr(self.__socket, 'setblocking'): self.__socket.setblocking(0) # Connected! self.__connected = 1 except socket.error, ex: --> Write out exception details here raise CORBA.COMM_FAILURE() # System exception. Also, try telnet-ing to the server's port to see if you can connect to it at all. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-01-03 21:37 Message: Logged In: YES user_id=435731 Honestly, I haven't had time to even think about this yet. I should have pinged you earlier, but that's life at this time of the year. I will try to at least keep people up to date in future, even if I can't work on the problem itself. Fundamentally, the issue is this - I just can't provide free support - especially this time of year and given my current ... harsh ... set of deadlines at my real (paying!) job. This has been going on for longer than I thought it would so I never got back to you. Anyway, I'll get to your problem when I can get to it, and that's all I can promise. If other people working on some other project are in a situation where they can provide responsive support for free then by all means switch to it - I'm simply not in that situation so I wouldn't be offended in the slightest. My time is utterly taken up right now - I'm trying to clear some time in January for Fnorb (I really want to get that new release out!) but even that's not going to be easy. So just quickly: the first exception trace is the server, right? Well, it looks to me at first glance like your server fell over, and of course this causes the client to throw an exception when it tries to talk to the server. Since it seems to me like the server fell over in your code from the stack trace given, I'm not sure it's a Fnorb problem. Can you provide more details? The best situation would be for you to provide some code fragments which I could run to reproduce the problem - I realize this is work but the more you do the less I have to, and that's good since I'm the bottleneck! ---------------------------------------------------------------------- Comment By: Ch. Lafaille (clafaille) Date: 2005-01-03 19:30 Message: Logged In: YES user_id=1160917 It seems that FNORB is a dead project, I've suggested to our dev team to move to OmniOrbPy which seems a more active project. I've submitted this bug more than 1 month ago and I've no news. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-11-18 00:11 Message: Logged In: NO I've created this bug as clafaille ident but it seems that the registration procedure hasn't yet finished... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1068018&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-13 11:24:22
|
Bugs item #1118723, was opened at 2005-02-09 02:13 Message generated for change (Comment added) made by dthomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:24 Message: Logged In: YES user_id=435731 Danilo, I have a source distribution packed up for you, but SourceForge won't allow an attachment greater than 256K. The package is about 326K. Can I simply email it to you, as it is not really very large? Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 21:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-11 00:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-10 02:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 22:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-13 11:09:03
|
Bugs item #1118723, was opened at 2005-02-09 02:13 Message generated for change (Comment added) made by dthomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Derek Thomson (dthomson) Date: 2005-02-13 21:09 Message: Logged In: YES user_id=435731 Hi Danilo, Unfortunately, I've had to spend this weekend at work, so I couldn't try your example against TAO. What I will do instead is package up a CVS checkout of Fnorb from the head of the repository and attach it to this bug report, as you suggest. Can you try that and see if it fixes your problem? Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 21:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-11 00:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-10 02:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 22:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-11 11:32:21
|
Bugs item #1118723, was opened at 2005-02-08 17:13 Message generated for change (Comment added) made by daniloturina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Danilo Turina (daniloturina) Date: 2005-02-11 12:32 Message: Logged In: YES user_id=232289 I've never used CVS and, in addition, my PC is behind a very restrictive firewall. If there's a way to get the lastest non-released version of Fnorb through the web access of CVS (without downloading file per file), let me know. Otherwise you could send a tar.gz with that very latest version (for example using the attachment function of this page). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-10 15:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-09 17:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 13:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-10 14:52:37
|
Bugs item #1068018, was opened at 2004-11-17 23:49 Message generated for change (Comment added) made by dthomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1068018&group_id=44742 Category: IIOP Engine Group: v1.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Derek Thomson (dthomson) Summary: raise CORBA.COMM_FAILURE() # System exception Initial Comment: We have some Python code which is fully functional with Python 1.5 and Fnorb 1.1.... And with Fnorb 1.2 and Python 2.2, we have this error : EmlViewImpl::ObjectImpl::GetMultiColumn: ...........done Unhandled exception in thread: Traceback (most recent call last): File "/vobs/ETH.vob0/src/adaptation/emlim_snmp_proxy/simu_server/core_impl/GetAsynchReplyThread.py", line 60, in _worker apply(func,args) File "/vobs/ETH.vob0/src/adaptation/emlim_snmp_proxy/simu_server/core_impl/GetAsynchReplyThread.py", line 105, in doAction reply.GetMultiResp_completed(neName,RetrievedList,status,CORBA.TRUE) File "/vobs/ETH.vob0/src/common/emlview_adaptation/genstubskel/idl2python/OpticsIMCsgReply/__init__.py", line 72, in GetMultiResp_completed apply(request.invoke, args, kw) File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/DII.py", line 160, in invoke (forwarded, self.__results) = client.synchronous(self, args) File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/GIOPClient.py", line 92, in synchronous worker = self.__get_worker() File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/GIOPClient.py", line 401, in __get_worker self.__address) File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/GIOPClientWorker.py", line 101, in create_worker worker = GIOPClientWorkerThreaded(protocol, address) File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/GIOPClientWorkerThreaded.py", line 89, in __init__ self.__connection.connect(self.__address) File "/toolbox/public/apps/Languages/python-2.2/lib/python2.2/site-packages/Fnorb/orb/IIOPConnection.py", line 107, in connect raise CORBA.COMM_FAILURE() # System exception. Fnorb.orb.CORBA.COMM_FAILURE: Minor: 0 Completed: COMPLETED_NO ---------------------------------------------------------------------- >Comment By: Derek Thomson (dthomson) Date: 2005-02-11 00:52 Message: Logged In: YES user_id=435731 Do you have any updates on this? There's not much that can be done without knowing what the error is. The other thing to realize is that the Python socket interface (specifically the "connect" method!) changed at version 2.0, which would cause this problem. However, since we fixed the code with Fnorb 1.2 to use the new connect arguments, that means that the combination of Python 2.2 with Fnorb 1.2 should be okay. Something like Python 2.2 and Fnorb 1.1 wouldn't be. Neither would Python 1.x or Fnorb 1.2. So I guess one thing to look at would be whether you're running the version of Python and/or Fnorb that you think you are (it's easy to end up with the wrong Python executable, expecially on systems that come with Python 1.x installed, so check your environment settings and so on). Another thing to try, like I said already, would be a more recent version of Python - maybe the doco is wrong and the change-over in the socket interface happened later than 2.0. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-01-04 20:39 Message: Logged In: YES user_id=435731 Okay, that's great. Getting the actual error thrown by the method invocations on the socket would be a big help. I had another thought - did you try it with any version greater than Python 2.2? Can you try and see what happens? ---------------------------------------------------------------------- Comment By: Ch. Lafaille (clafaille) Date: 2005-01-04 17:03 Message: Logged In: YES user_id=1160917 When using Python 1.5.2 + Fnorb 1.1, all is OK without any change on the server side and no change on client side code (only modification on usage of cdrpy/cdr module). The problem occurs only with Python 2.2 + Fnorb 1.2. I'll modify the code to see the socket exception and I'll discuss with the dev team to see if it's possible to extract a part of our code and to have a maximum of informations for the resolution of this problem. We're using TAO (C++ ORB) on the server side. JacORB (Java ORB) is also used but it's not involved in our case. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-01-04 01:26 Message: Logged In: YES user_id=435731 It seems I misread that trace - it's actually long stack trace with an extra blank line in there. Anyway, the code in IIOPConnection that throws the exception is the code that tries to make the first connection to the server - and it's just not able to connect at all, using the standard Python sockets library. So what's your server doing while this is happening? As for why it might work in older Pythons, I've no idea. Is the server the same? Is it Python/Fnorb, or something else? There really isn't enough information in this bug report to draw any conclusions, it's just a client side exception which could be due to anything ... I think you need to describe what you are trying to do exactly and what form both the client and the server take. Is there any error or any useful information about the server? How do you know it's running and accepting connections, for example? If it's dying before that point, that would be an obvious cause of the error you provided for the client! The first thing is to find out what the actually socket error is. Try writing out the socket exception that is actually caught in IIOPConnection.connect below, by adding some debug code in the "except" block that catches it (reproduced below) and tell us what you see. # Create a socket and connect to the remote object. try: self.__socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.__socket.connect(address) # Set the socket by default to NON-blocking mode. # Jython sockets have no 'setblocking' method. if hasattr(self.__socket, 'setblocking'): self.__socket.setblocking(0) # Connected! self.__connected = 1 except socket.error, ex: --> Write out exception details here raise CORBA.COMM_FAILURE() # System exception. Also, try telnet-ing to the server's port to see if you can connect to it at all. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-01-03 21:37 Message: Logged In: YES user_id=435731 Honestly, I haven't had time to even think about this yet. I should have pinged you earlier, but that's life at this time of the year. I will try to at least keep people up to date in future, even if I can't work on the problem itself. Fundamentally, the issue is this - I just can't provide free support - especially this time of year and given my current ... harsh ... set of deadlines at my real (paying!) job. This has been going on for longer than I thought it would so I never got back to you. Anyway, I'll get to your problem when I can get to it, and that's all I can promise. If other people working on some other project are in a situation where they can provide responsive support for free then by all means switch to it - I'm simply not in that situation so I wouldn't be offended in the slightest. My time is utterly taken up right now - I'm trying to clear some time in January for Fnorb (I really want to get that new release out!) but even that's not going to be easy. So just quickly: the first exception trace is the server, right? Well, it looks to me at first glance like your server fell over, and of course this causes the client to throw an exception when it tries to talk to the server. Since it seems to me like the server fell over in your code from the stack trace given, I'm not sure it's a Fnorb problem. Can you provide more details? The best situation would be for you to provide some code fragments which I could run to reproduce the problem - I realize this is work but the more you do the less I have to, and that's good since I'm the bottleneck! ---------------------------------------------------------------------- Comment By: Ch. Lafaille (clafaille) Date: 2005-01-03 19:30 Message: Logged In: YES user_id=1160917 It seems that FNORB is a dead project, I've suggested to our dev team to move to OmniOrbPy which seems a more active project. I've submitted this bug more than 1 month ago and I've no news. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-11-18 00:11 Message: Logged In: NO I've created this bug as clafaille ident but it seems that the registration procedure hasn't yet finished... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1068018&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-10 14:36:19
|
Bugs item #1118723, was opened at 2005-02-09 02:13 Message generated for change (Comment added) made by dthomson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Derek Thomson (dthomson) Date: 2005-02-11 00:36 Message: Logged In: YES user_id=435731 Hi Danilo, One more thing to try - could you check out the latest version of Fnorb from CVS and see if it still fails? IIRC we had some problems directly related to "long long" (or more specifically, to do with 4/8 byte padding boundary issues that using "long long" tends to provoke) a couple of months ago that have since been fixed, so with any luck that's causing your problem as well. Anyway, give it a go and see what happens. Regards, Derek. ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-02-10 02:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 22:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-02-09 16:40:35
|
Bugs item #1118723, was opened at 2005-02-08 17:13 Message generated for change (Comment added) made by daniloturina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danilo Turina (daniloturina) Assigned to: Nobody/Anonymous (nobody) Summary: TAO-Fnorb interoperability on indirection within typecode Initial Comment: We have a CORBA client written in C++ (with TAO 1.3 as an orb) and a CORBA server written in Python 2.2 (with Fnorb 1.2). With an IDL like this: typedef long long Ident; struct ArgsIn { Ident id; Ident childId; }; void doSomething(in Any); When we pass an argument of type ArgIn to doSomething our Python Corba server exits with this error: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. Notice that: 1) a Corba server written in C++ with the same IDL, does not have any problem; 2) if we change ArgsIn in this way: struct ArgsIn { Ident id; long long childId; }; we don't have any problem (however changing the IDL is not an option for us). ---------------------------------------------------------------------- >Comment By: Danilo Turina (daniloturina) Date: 2005-02-09 17:40 Message: Logged In: YES user_id=232289 I also tried with 1.3, but I have the same problem: File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 281, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 74, in start self.__reactor.start_event_loop(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 143, in start_event_loop self.do_one_event(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/SelectReactor.py", line 184, in do_one_event handler.handle_event(Reactor.READ) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 155, in handle_event self.__handler.recv() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPConnectionHandler.py", line 191, in recv self.__listener.message_received( File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServerWorkerReactive.py", line 198, in message_received self.__giop_server.process_giop_message(message) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/GIOPServer.py", line 167, in process_giop_message self.__oa._fnorb_request((self, request_header, cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 355, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 479, in __process_request apply(method, (server_request,)) File "/opt/testenvironment/VLAN711/simu/adapt_simul/lib/AdaptationEmlNeMgr_skel/__init__.py", line 383, in _skel_uploadTerminations arguments = server_request.arguments() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/DSI.py", line 92, in arguments arguments.append(tc._fnorb_unmarshal_value(self.__cursor)) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 921, in _fnorb_unmarshal_value result._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/Any.py", line 85, in _fnorb_unmarshal self.__typecode = CORBA.TypeCodeFactory_init().unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3264, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1676, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3243, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. N.B. I told you the wrong structure, in my first description of the bug, the correct one is: struct ArgsIn { Ident id; boolean flag; Ident childId; }; I tried to debug a bit the TypeCode.py portion of the code where the problem seems to happen: 3240 # Find the repeated/recursive typecode in the stack. 3241 for (typecode, offset) in cursor.stack().items(): 3242 if offset == mark + indirection: 3243 break 3244 else: 3245 raise 'Invalid indirection for recursive typecode.' and I found that, when the "childId" portion of the typecode it's unmarshaled, in cursor.stack().items() there's one item whose offset is 64L, while it should be equal to mark + indirection = 412L + (-168) = 244L (I checked the typecode with the debugger, and the replicated type is exactly at 244L). ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-09 13:44 Message: Logged In: YES user_id=435731 Hi Danilo, We've received your problem report, but I personally won't have a chance to look at this until the weekend. In the meantime, could you try this against Fnorb 1.3? Regards, Derek. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1118723&group_id=44742 |