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: SourceForge.net <no...@so...> - 2009-12-21 10:00:23
|
Bugs item #2918559, was opened at 2009-12-21 10:00 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=2918559&group_id=44742 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: not portable to python2.6 Initial Comment: "import regex" is not any more supported in yapps2.py I suggest to remove "regex" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=2918559&group_id=44742 |
From: SourceForge.net <no...@so...> - 2009-12-17 15:28:02
|
Bugs item #2916306, was opened at 2009-12-17 15:28 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=2916306&group_id=44742 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDL Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: definition of empty module Initial Comment: the grammar defined in idl.g does not allow to have something like module test { } I suggest to modify the following lines: rule module: MODULE IDENTIFIER {{ self.p.module_header(IDENTIFIER) }} '{' definition+ '}' {{ self.p.module_body() }} in rule module: MODULE IDENTIFIER {{ self.p.module_header(IDENTIFIER) }} '{' definition* '}' {{ self.p.module_body() }} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=2916306&group_id=44742 |
From: SourceForge.net <no...@so...> - 2007-05-17 18:10:54
|
Patches item #1720894, was opened at 2007-05-17 11:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440742&aid=1720894&group_id=44742 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: patch for IDL compiler Initial Comment: This patch fixes two issues with the IDL compiler. - Forward declarations of struct and enum - Wstring literals ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440742&aid=1720894&group_id=44742 |
From: SourceForge.net <no...@so...> - 2007-01-11 17:08:59
|
Bugs item #1633392, was opened at 2007-01-11 17:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1633392&group_id=44742 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IIOP Engine Group: v1.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lieven Matthys (lievenmatthys) Assigned to: Nobody/Anonymous (nobody) Summary: Request/Response body alignment incorrectly added to GIOP 1. Initial Comment: Hi, I ran into an interoperability problem between Fnorb and Sun Java 1.5 and upwards. Some debugging showed that as of Java 1.5, the following bug is fixed: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4775833 >From this bug report: << When a GIOP 1.2 Request header is built it adds padding bytes to the output stream to align the Request Body on an 8 byte boundary as per "CORBA formal 00-11-07 15.4.2.2" which states in the first paragraph that: "GIOP 1.2 body must be aligned on an 8 octet boundary." This is incorrect when there is no Request Body (ie: for methods with no parameters). "CORBA formal 00-11-07 section 15.4.2.1", last paragraph, states: "There is no padding after the request header when an unfragmented request message body is empty." This also applies to Response headers/bodies. >> Fnorb happens to contain this same bug, and throws an exception when a correct message is offered. Workaround to make it work for me are: in GIOPClient.py, extra tests for the padding: def __process_reply(self, request, (reply_header, cursor)): """ Process a GIOP reply. """ # Align on the next 8-byte boundary for GIOP 1.2 if self.__giop_version.minor == 2 : if len(request.outputs()) > 0 or reply_header.reply_status == GIOP.SYSTEM_EXCEPTION or reply_header.reply_status == GIOP.USER_EXCEPTION: .... in GIOPServer.py, also see if more is coming: def process_giop_message(self, message): """ Process a GIOP message. ..... # Align on the next 8-byte boundary for GIOP 1.2 if giop_header.GIOP_version.minor == 2 and giop_header.message_size + 12> cursor.offset() + 1 : ..... regards, Lieven ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1633392&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-12-21 14:10:06
|
Bugs item #1387125, was opened at 2005-12-21 06:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1387125&group_id=44742 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDL Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: const unsigned long long parsed incorrectly Initial Comment: parser/idl.py line 769 returns p.unsigned_long_int() instead of "long_long" calculated on the previous line. This causes "CONST UNSIGNED LONG LONG" to be reported as unsigned long type, not unsigned long long. This can then fail range checks. Fix is to return long_long. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1387125&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-11-14 13:30:33
|
Bugs item #1356550, was opened at 2005-11-14 05:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1356550&group_id=44742 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: v1.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: empty list_initial_services() on HPUX Initial Comment: When connecting from speedy python client to lazy remote BEA server I got empty list after list_initial_services(). I noticed, that when python interpret works quickly, it attemps to send() before asynchronous connect() finishes?! This leads on HPUX to error 232 Connection reset by peer after recv(). Client application sees CORBA.COMM_FAILURE(0, CORBA.COMPLETED_MAYBE) I see it's necessary wait for "write enabled" before send. I tried succesfully the following patch to fix the problem: *** orb/IIOPConnection.py.orig Mon Oct 28 08:30:47 2002 --- orb/IIOPConnection.py Mon Nov 14 11:26:58 2005 *************** *** 131,136 **** --- 131,137 ---- """ Send as much of the data as we can. """ try: + (iwtd, owtd, ewtd) = select.select([], [self.__socket], []) #wait for connect! n = self.__socket.send(data) except socket.error: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1356550&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-05-09 07:07:34
|
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: 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-05-09 09:07 Message: Logged In: YES user_id=232289 Hello Derek, no way for me to have that minimal example on time (end of last week). Instead, unfortunately, I've been charged with other work I cannot postpone at the moment. I don't know when I'll be able to provide such an example. Feel free to close the bug report: when I'll have time and I'll be re-assigned to the problem, I'll reopen another bug report (or this one, I don't know if it's possible). Thank you for your help. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-03 13:55 Message: Logged In: YES user_id=435731 > Thank you very much Derek for your time. No problem. I've been struggling to get time to research this for a while now, sorry about the delay. > I can ensure that the IDL is the same for the client and the > server. Okay, good! At least we can eliminate that. > Anyway, if your test succeeded, now is up to me to produce > the smallest example that exhibit the problem. That would be useful! > Honestly, I haven't replied to you until now because I'm a > bit overloaded at work I know the feeling :) > For this reason I hope I'm able to produce such an example > for the end of the week. Okay, great. I'll leave the bug open then. I have noticed since my last comment that when I put some trace statements into Fnorb the typecode contained in the "any" sent by TAO doesn't contain an indirection! I'm using the most recent version of TAO (it's the only one that will build for me on Fedora Core 3) so maybe I'm just not provoking the problem at all! I will look at the options on TAO and see if I can force it to behave the same way with regards to indirections in the typecode of an "any". Then we have a closer match between your example and mine. Since you've probably used TAO more than me, do you happen to know if there is some flexibility here and how I might adjust it? I might also ask around (comp.object.corba etc) about this issue ... ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-05-03 00:30 Message: Logged In: YES user_id=232289 Thank you very much Derek for your time. I can ensure that the IDL is the same for the client and the server. Anyway, if your test succeeded, now is up to me to produce the smallest example that exhibit the problem. Honestly, I haven't replied to you until now because I'm a bit overloaded at work (and also because, for now, we have a little abandoned Fnorb-based simulators). For this reason I hope I'm able to produce such an example for the end of the week. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 07:26 Message: Logged In: YES user_id=435731 Danilo, I've got good news and bad news (I guess). The good news is that I was able to write a little C++ TAO client and Python Fnorb server to try your example (despite leaving Henning+Vinoski at work!). The bad news is that it worked fine. I packed the struct into an any on the C++ side, sent it to the Fnorb server, extracted the struct from the any and the values of the struct are exactly as expected. Just to make sure, here's the IDL I'm using to do this: typedef long long Ident; struct ArgsIn { Ident id; boolean flag; Ident childId; }; interface TestAny { void do_something(in any anAny); }; Now, my C++ client only calls this operation. It is perfectly possible that some operation call before that is messing up the byte alignment (GIOP is annoying that way), so the next question is: in your code, do you call some other operation before "do_something"? (This is why having a small example the reproduces the problem is so useful, I don't have to ask all these questions but I can just look at the example instead!) Anyway, please at least respond if you're still interested in this problem, even if you aren't able to think about this, just so I know if you're still alive :) If I don't hear anything I'll close it as "not a bug" in a couple of days. I think I've done all I can from this end. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 05:18 Message: Logged In: YES user_id=435731 Just looking back through this problem's history, I can see that I asked you to make 100% certain you had regenerated the stubs and skeletons from the *same* IDL for both Fnorb and TAO. This simple oversight (that I make every now and again, to be honest) can often be the source of such problems. Since I've not heard anything since, can I dare hope that you did this and the problem just went away? I also asked for a small example that demonstrated the problem, and I've heard nothing back ... as I said before I'm not really keen on writing reams of C++/CORBA code due to 1) the painful nature of the C++ mapping 2) I don't support a *Python* ORB because I want to write lots of C++ on the weekend ;) I'll have a crack at it today but if I add the struct you described to the TAO test code that I have right now in the Fnorb repository, and it works, I'll probably just log that fact here and close this as "not a bug". ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 05:10 Message: Logged In: YES user_id=435731 I had to give up building TAO on my older machine, it was painful doing *anything* TAO related on it ... but my dev box is all patched up and I'm building TAO on it now. I'm going to look at this problem this afternoon. My first step will be to try to reproduce it. Sorry about the delay. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-19 04:20 Message: Logged In: YES user_id=435731 Danilo, The good news is I've managed to get the "beta" release of TAO building here on FC 3. What I'll try to do is muck about with adding your struct to the TAO interoperability tests I've already written in C++, and see if I can't reproduce the problem. I'll do that this afternoon (19/3), so stay tuned ... dt. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 07:26 Message: Logged In: YES user_id=435731 Hi Danilo, I can't compile either TAO 1.3 or 1.4 on Red Hat Fedora Core 3. It gives an obscure compiler error then dies during the build. A quick search doesn't reveal any quick fix for this, apart from it being related somehow to the version of the C++ compiler shipped with Core 3 - and I'm not really keen to muck around with building different versions of the C++ compiler just to suit TAO. Especially considering that it will probably mean also building special versions of any tools and libraries that the compiler uses. Sigh. I'll keep searching for an quick answer that doesn't involve patching compilers :) In the meantime, tell us how recompiling the IDL on both sides goes ... I'd honestly forgotten how painful it is to make C++ code work on a given platform. What a nuisance. I can't really blame the TAO people - I know it's damned hard to write non-trivial C++ code that works across all the popular compilers (at least, last time I used C++ circa 2001). I'll just hold out the vague hope that it's simply mismatched IDL for now, before I start spending *lots* of time getting TAO working. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 05:39 Message: Logged In: YES user_id=435731 Hi Danilo, I just quickly tried passing this struct as an any from Fnorb client to Fnorb server, and that worked fine. Before we go any further, I notice there was some confusion early on about exactly what form this struct took, which indicates it *might* just be an IDL mismatch due to a change. Please, just to be sure, go and recompile your IDL for *both* TAO and Fnorb, recompile all your C++, and see if that fixes things. Do this even if you're certain you did it already - it's *so* easy to forget to recompile the IDL on one side, and you start getting all kinds of inexplicable hassle. I make this mistake often, if I have to do it manually - so before we spend more time on this please just try that first. The next step would be to try this with a TAO client ... and that's getting painful. Basically, I don't use C++ at all any more and I despise the C++/CORBA mapping. It fills me with dread just to think about it. In short, it will be time consuming and frustrating to have to write a TAO/C++ client from scratch just to reproduce this myself. Would it be possible for you to come up with a short C++ client (and a corresponding Fnorb Python server) that I can build here against TAO to reproduce the problem? It still won't be easy for me even *with* that code, as I'm still not using my "real" machine (let's just say "warranties == hassle"), and building/using TAO on this older machine is not the most pleasurable experience imaginable as I recall. But I will build TAO here (it *will* take hours) so that I'll be ready to go when you lay your example code on me :) Regards, Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-12 08:22 Message: Logged In: YES user_id=435731 Okay, at least the new version of Fnorb works :) As an aside, I think we will try to support the "magic" object-as-object-reference behaviour for people still using the BOA. Too many people would have assumed that this will just work. I'll have to think about this - shouldn't be too hard. Anyway, your problem: so we've established that it doesn't work even with the most recent fixes. In that case, I'll have to try your example code and try to reproduce it here! Probably tomorrow - I'll get back to you when done. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-04 13:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-26 08: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 02: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-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-05-03 11:55:18
|
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-05-03 21:55 Message: Logged In: YES user_id=435731 > Thank you very much Derek for your time. No problem. I've been struggling to get time to research this for a while now, sorry about the delay. > I can ensure that the IDL is the same for the client and the > server. Okay, good! At least we can eliminate that. > Anyway, if your test succeeded, now is up to me to produce > the smallest example that exhibit the problem. That would be useful! > Honestly, I haven't replied to you until now because I'm a > bit overloaded at work I know the feeling :) > For this reason I hope I'm able to produce such an example > for the end of the week. Okay, great. I'll leave the bug open then. I have noticed since my last comment that when I put some trace statements into Fnorb the typecode contained in the "any" sent by TAO doesn't contain an indirection! I'm using the most recent version of TAO (it's the only one that will build for me on Fedora Core 3) so maybe I'm just not provoking the problem at all! I will look at the options on TAO and see if I can force it to behave the same way with regards to indirections in the typecode of an "any". Then we have a closer match between your example and mine. Since you've probably used TAO more than me, do you happen to know if there is some flexibility here and how I might adjust it? I might also ask around (comp.object.corba etc) about this issue ... ---------------------------------------------------------------------- Comment By: Danilo Turina (daniloturina) Date: 2005-05-03 08:30 Message: Logged In: YES user_id=232289 Thank you very much Derek for your time. I can ensure that the IDL is the same for the client and the server. Anyway, if your test succeeded, now is up to me to produce the smallest example that exhibit the problem. Honestly, I haven't replied to you until now because I'm a bit overloaded at work (and also because, for now, we have a little abandoned Fnorb-based simulators). For this reason I hope I'm able to produce such an example for the end of the week. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 15:26 Message: Logged In: YES user_id=435731 Danilo, I've got good news and bad news (I guess). The good news is that I was able to write a little C++ TAO client and Python Fnorb server to try your example (despite leaving Henning+Vinoski at work!). The bad news is that it worked fine. I packed the struct into an any on the C++ side, sent it to the Fnorb server, extracted the struct from the any and the values of the struct are exactly as expected. Just to make sure, here's the IDL I'm using to do this: typedef long long Ident; struct ArgsIn { Ident id; boolean flag; Ident childId; }; interface TestAny { void do_something(in any anAny); }; Now, my C++ client only calls this operation. It is perfectly possible that some operation call before that is messing up the byte alignment (GIOP is annoying that way), so the next question is: in your code, do you call some other operation before "do_something"? (This is why having a small example the reproduces the problem is so useful, I don't have to ask all these questions but I can just look at the example instead!) Anyway, please at least respond if you're still interested in this problem, even if you aren't able to think about this, just so I know if you're still alive :) If I don't hear anything I'll close it as "not a bug" in a couple of days. I think I've done all I can from this end. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 13:18 Message: Logged In: YES user_id=435731 Just looking back through this problem's history, I can see that I asked you to make 100% certain you had regenerated the stubs and skeletons from the *same* IDL for both Fnorb and TAO. This simple oversight (that I make every now and again, to be honest) can often be the source of such problems. Since I've not heard anything since, can I dare hope that you did this and the problem just went away? I also asked for a small example that demonstrated the problem, and I've heard nothing back ... as I said before I'm not really keen on writing reams of C++/CORBA code due to 1) the painful nature of the C++ mapping 2) I don't support a *Python* ORB because I want to write lots of C++ on the weekend ;) I'll have a crack at it today but if I add the struct you described to the TAO test code that I have right now in the Fnorb repository, and it works, I'll probably just log that fact here and close this as "not a bug". ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 13:10 Message: Logged In: YES user_id=435731 I had to give up building TAO on my older machine, it was painful doing *anything* TAO related on it ... but my dev box is all patched up and I'm building TAO on it now. I'm going to look at this problem this afternoon. My first step will be to try to reproduce it. Sorry about the delay. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-19 13:20 Message: Logged In: YES user_id=435731 Danilo, The good news is I've managed to get the "beta" release of TAO building here on FC 3. What I'll try to do is muck about with adding your struct to the TAO interoperability tests I've already written in C++, and see if I can't reproduce the problem. I'll do that this afternoon (19/3), so stay tuned ... dt. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 16:26 Message: Logged In: YES user_id=435731 Hi Danilo, I can't compile either TAO 1.3 or 1.4 on Red Hat Fedora Core 3. It gives an obscure compiler error then dies during the build. A quick search doesn't reveal any quick fix for this, apart from it being related somehow to the version of the C++ compiler shipped with Core 3 - and I'm not really keen to muck around with building different versions of the C++ compiler just to suit TAO. Especially considering that it will probably mean also building special versions of any tools and libraries that the compiler uses. Sigh. I'll keep searching for an quick answer that doesn't involve patching compilers :) In the meantime, tell us how recompiling the IDL on both sides goes ... I'd honestly forgotten how painful it is to make C++ code work on a given platform. What a nuisance. I can't really blame the TAO people - I know it's damned hard to write non-trivial C++ code that works across all the popular compilers (at least, last time I used C++ circa 2001). I'll just hold out the vague hope that it's simply mismatched IDL for now, before I start spending *lots* of time getting TAO working. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 14:39 Message: Logged In: YES user_id=435731 Hi Danilo, I just quickly tried passing this struct as an any from Fnorb client to Fnorb server, and that worked fine. Before we go any further, I notice there was some confusion early on about exactly what form this struct took, which indicates it *might* just be an IDL mismatch due to a change. Please, just to be sure, go and recompile your IDL for *both* TAO and Fnorb, recompile all your C++, and see if that fixes things. Do this even if you're certain you did it already - it's *so* easy to forget to recompile the IDL on one side, and you start getting all kinds of inexplicable hassle. I make this mistake often, if I have to do it manually - so before we spend more time on this please just try that first. The next step would be to try this with a TAO client ... and that's getting painful. Basically, I don't use C++ at all any more and I despise the C++/CORBA mapping. It fills me with dread just to think about it. In short, it will be time consuming and frustrating to have to write a TAO/C++ client from scratch just to reproduce this myself. Would it be possible for you to come up with a short C++ client (and a corresponding Fnorb Python server) that I can build here against TAO to reproduce the problem? It still won't be easy for me even *with* that code, as I'm still not using my "real" machine (let's just say "warranties == hassle"), and building/using TAO on this older machine is not the most pleasurable experience imaginable as I recall. But I will build TAO here (it *will* take hours) so that I'll be ready to go when you lay your example code on me :) Regards, Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-12 17:22 Message: Logged In: YES user_id=435731 Okay, at least the new version of Fnorb works :) As an aside, I think we will try to support the "magic" object-as-object-reference behaviour for people still using the BOA. Too many people would have assumed that this will just work. I'll have to think about this - shouldn't be too hard. Anyway, your problem: so we've established that it doesn't work even with the most recent fixes. In that case, I'll have to try your example code and try to reproduce it here! Probably tomorrow - I'll get back to you when done. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-04 22:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- 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: SourceForge.net <no...@so...> - 2005-05-02 22:30:55
|
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: 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-05-03 00:30 Message: Logged In: YES user_id=232289 Thank you very much Derek for your time. I can ensure that the IDL is the same for the client and the server. Anyway, if your test succeeded, now is up to me to produce the smallest example that exhibit the problem. Honestly, I haven't replied to you until now because I'm a bit overloaded at work (and also because, for now, we have a little abandoned Fnorb-based simulators). For this reason I hope I'm able to produce such an example for the end of the week. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 07:26 Message: Logged In: YES user_id=435731 Danilo, I've got good news and bad news (I guess). The good news is that I was able to write a little C++ TAO client and Python Fnorb server to try your example (despite leaving Henning+Vinoski at work!). The bad news is that it worked fine. I packed the struct into an any on the C++ side, sent it to the Fnorb server, extracted the struct from the any and the values of the struct are exactly as expected. Just to make sure, here's the IDL I'm using to do this: typedef long long Ident; struct ArgsIn { Ident id; boolean flag; Ident childId; }; interface TestAny { void do_something(in any anAny); }; Now, my C++ client only calls this operation. It is perfectly possible that some operation call before that is messing up the byte alignment (GIOP is annoying that way), so the next question is: in your code, do you call some other operation before "do_something"? (This is why having a small example the reproduces the problem is so useful, I don't have to ask all these questions but I can just look at the example instead!) Anyway, please at least respond if you're still interested in this problem, even if you aren't able to think about this, just so I know if you're still alive :) If I don't hear anything I'll close it as "not a bug" in a couple of days. I think I've done all I can from this end. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 05:18 Message: Logged In: YES user_id=435731 Just looking back through this problem's history, I can see that I asked you to make 100% certain you had regenerated the stubs and skeletons from the *same* IDL for both Fnorb and TAO. This simple oversight (that I make every now and again, to be honest) can often be the source of such problems. Since I've not heard anything since, can I dare hope that you did this and the problem just went away? I also asked for a small example that demonstrated the problem, and I've heard nothing back ... as I said before I'm not really keen on writing reams of C++/CORBA code due to 1) the painful nature of the C++ mapping 2) I don't support a *Python* ORB because I want to write lots of C++ on the weekend ;) I'll have a crack at it today but if I add the struct you described to the TAO test code that I have right now in the Fnorb repository, and it works, I'll probably just log that fact here and close this as "not a bug". ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 05:10 Message: Logged In: YES user_id=435731 I had to give up building TAO on my older machine, it was painful doing *anything* TAO related on it ... but my dev box is all patched up and I'm building TAO on it now. I'm going to look at this problem this afternoon. My first step will be to try to reproduce it. Sorry about the delay. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-19 04:20 Message: Logged In: YES user_id=435731 Danilo, The good news is I've managed to get the "beta" release of TAO building here on FC 3. What I'll try to do is muck about with adding your struct to the TAO interoperability tests I've already written in C++, and see if I can't reproduce the problem. I'll do that this afternoon (19/3), so stay tuned ... dt. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 07:26 Message: Logged In: YES user_id=435731 Hi Danilo, I can't compile either TAO 1.3 or 1.4 on Red Hat Fedora Core 3. It gives an obscure compiler error then dies during the build. A quick search doesn't reveal any quick fix for this, apart from it being related somehow to the version of the C++ compiler shipped with Core 3 - and I'm not really keen to muck around with building different versions of the C++ compiler just to suit TAO. Especially considering that it will probably mean also building special versions of any tools and libraries that the compiler uses. Sigh. I'll keep searching for an quick answer that doesn't involve patching compilers :) In the meantime, tell us how recompiling the IDL on both sides goes ... I'd honestly forgotten how painful it is to make C++ code work on a given platform. What a nuisance. I can't really blame the TAO people - I know it's damned hard to write non-trivial C++ code that works across all the popular compilers (at least, last time I used C++ circa 2001). I'll just hold out the vague hope that it's simply mismatched IDL for now, before I start spending *lots* of time getting TAO working. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 05:39 Message: Logged In: YES user_id=435731 Hi Danilo, I just quickly tried passing this struct as an any from Fnorb client to Fnorb server, and that worked fine. Before we go any further, I notice there was some confusion early on about exactly what form this struct took, which indicates it *might* just be an IDL mismatch due to a change. Please, just to be sure, go and recompile your IDL for *both* TAO and Fnorb, recompile all your C++, and see if that fixes things. Do this even if you're certain you did it already - it's *so* easy to forget to recompile the IDL on one side, and you start getting all kinds of inexplicable hassle. I make this mistake often, if I have to do it manually - so before we spend more time on this please just try that first. The next step would be to try this with a TAO client ... and that's getting painful. Basically, I don't use C++ at all any more and I despise the C++/CORBA mapping. It fills me with dread just to think about it. In short, it will be time consuming and frustrating to have to write a TAO/C++ client from scratch just to reproduce this myself. Would it be possible for you to come up with a short C++ client (and a corresponding Fnorb Python server) that I can build here against TAO to reproduce the problem? It still won't be easy for me even *with* that code, as I'm still not using my "real" machine (let's just say "warranties == hassle"), and building/using TAO on this older machine is not the most pleasurable experience imaginable as I recall. But I will build TAO here (it *will* take hours) so that I'll be ready to go when you lay your example code on me :) Regards, Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-12 08:22 Message: Logged In: YES user_id=435731 Okay, at least the new version of Fnorb works :) As an aside, I think we will try to support the "magic" object-as-object-reference behaviour for people still using the BOA. Too many people would have assumed that this will just work. I'll have to think about this - shouldn't be too hard. Anyway, your problem: so we've established that it doesn't work even with the most recent fixes. In that case, I'll have to try your example code and try to reproduce it here! Probably tomorrow - I'll get back to you when done. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-04 13:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-26 08: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 02: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-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-05-02 05:26:10
|
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-05-02 15:26 Message: Logged In: YES user_id=435731 Danilo, I've got good news and bad news (I guess). The good news is that I was able to write a little C++ TAO client and Python Fnorb server to try your example (despite leaving Henning+Vinoski at work!). The bad news is that it worked fine. I packed the struct into an any on the C++ side, sent it to the Fnorb server, extracted the struct from the any and the values of the struct are exactly as expected. Just to make sure, here's the IDL I'm using to do this: typedef long long Ident; struct ArgsIn { Ident id; boolean flag; Ident childId; }; interface TestAny { void do_something(in any anAny); }; Now, my C++ client only calls this operation. It is perfectly possible that some operation call before that is messing up the byte alignment (GIOP is annoying that way), so the next question is: in your code, do you call some other operation before "do_something"? (This is why having a small example the reproduces the problem is so useful, I don't have to ask all these questions but I can just look at the example instead!) Anyway, please at least respond if you're still interested in this problem, even if you aren't able to think about this, just so I know if you're still alive :) If I don't hear anything I'll close it as "not a bug" in a couple of days. I think I've done all I can from this end. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 13:18 Message: Logged In: YES user_id=435731 Just looking back through this problem's history, I can see that I asked you to make 100% certain you had regenerated the stubs and skeletons from the *same* IDL for both Fnorb and TAO. This simple oversight (that I make every now and again, to be honest) can often be the source of such problems. Since I've not heard anything since, can I dare hope that you did this and the problem just went away? I also asked for a small example that demonstrated the problem, and I've heard nothing back ... as I said before I'm not really keen on writing reams of C++/CORBA code due to 1) the painful nature of the C++ mapping 2) I don't support a *Python* ORB because I want to write lots of C++ on the weekend ;) I'll have a crack at it today but if I add the struct you described to the TAO test code that I have right now in the Fnorb repository, and it works, I'll probably just log that fact here and close this as "not a bug". ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 13:10 Message: Logged In: YES user_id=435731 I had to give up building TAO on my older machine, it was painful doing *anything* TAO related on it ... but my dev box is all patched up and I'm building TAO on it now. I'm going to look at this problem this afternoon. My first step will be to try to reproduce it. Sorry about the delay. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-19 13:20 Message: Logged In: YES user_id=435731 Danilo, The good news is I've managed to get the "beta" release of TAO building here on FC 3. What I'll try to do is muck about with adding your struct to the TAO interoperability tests I've already written in C++, and see if I can't reproduce the problem. I'll do that this afternoon (19/3), so stay tuned ... dt. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 16:26 Message: Logged In: YES user_id=435731 Hi Danilo, I can't compile either TAO 1.3 or 1.4 on Red Hat Fedora Core 3. It gives an obscure compiler error then dies during the build. A quick search doesn't reveal any quick fix for this, apart from it being related somehow to the version of the C++ compiler shipped with Core 3 - and I'm not really keen to muck around with building different versions of the C++ compiler just to suit TAO. Especially considering that it will probably mean also building special versions of any tools and libraries that the compiler uses. Sigh. I'll keep searching for an quick answer that doesn't involve patching compilers :) In the meantime, tell us how recompiling the IDL on both sides goes ... I'd honestly forgotten how painful it is to make C++ code work on a given platform. What a nuisance. I can't really blame the TAO people - I know it's damned hard to write non-trivial C++ code that works across all the popular compilers (at least, last time I used C++ circa 2001). I'll just hold out the vague hope that it's simply mismatched IDL for now, before I start spending *lots* of time getting TAO working. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 14:39 Message: Logged In: YES user_id=435731 Hi Danilo, I just quickly tried passing this struct as an any from Fnorb client to Fnorb server, and that worked fine. Before we go any further, I notice there was some confusion early on about exactly what form this struct took, which indicates it *might* just be an IDL mismatch due to a change. Please, just to be sure, go and recompile your IDL for *both* TAO and Fnorb, recompile all your C++, and see if that fixes things. Do this even if you're certain you did it already - it's *so* easy to forget to recompile the IDL on one side, and you start getting all kinds of inexplicable hassle. I make this mistake often, if I have to do it manually - so before we spend more time on this please just try that first. The next step would be to try this with a TAO client ... and that's getting painful. Basically, I don't use C++ at all any more and I despise the C++/CORBA mapping. It fills me with dread just to think about it. In short, it will be time consuming and frustrating to have to write a TAO/C++ client from scratch just to reproduce this myself. Would it be possible for you to come up with a short C++ client (and a corresponding Fnorb Python server) that I can build here against TAO to reproduce the problem? It still won't be easy for me even *with* that code, as I'm still not using my "real" machine (let's just say "warranties == hassle"), and building/using TAO on this older machine is not the most pleasurable experience imaginable as I recall. But I will build TAO here (it *will* take hours) so that I'll be ready to go when you lay your example code on me :) Regards, Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-12 17:22 Message: Logged In: YES user_id=435731 Okay, at least the new version of Fnorb works :) As an aside, I think we will try to support the "magic" object-as-object-reference behaviour for people still using the BOA. Too many people would have assumed that this will just work. I'll have to think about this - shouldn't be too hard. Anyway, your problem: so we've established that it doesn't work even with the most recent fixes. In that case, I'll have to try your example code and try to reproduce it here! Probably tomorrow - I'll get back to you when done. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-04 22:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- 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: SourceForge.net <no...@so...> - 2005-05-02 03:18:44
|
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-05-02 13:18 Message: Logged In: YES user_id=435731 Just looking back through this problem's history, I can see that I asked you to make 100% certain you had regenerated the stubs and skeletons from the *same* IDL for both Fnorb and TAO. This simple oversight (that I make every now and again, to be honest) can often be the source of such problems. Since I've not heard anything since, can I dare hope that you did this and the problem just went away? I also asked for a small example that demonstrated the problem, and I've heard nothing back ... as I said before I'm not really keen on writing reams of C++/CORBA code due to 1) the painful nature of the C++ mapping 2) I don't support a *Python* ORB because I want to write lots of C++ on the weekend ;) I'll have a crack at it today but if I add the struct you described to the TAO test code that I have right now in the Fnorb repository, and it works, I'll probably just log that fact here and close this as "not a bug". ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-05-02 13:10 Message: Logged In: YES user_id=435731 I had to give up building TAO on my older machine, it was painful doing *anything* TAO related on it ... but my dev box is all patched up and I'm building TAO on it now. I'm going to look at this problem this afternoon. My first step will be to try to reproduce it. Sorry about the delay. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-19 13:20 Message: Logged In: YES user_id=435731 Danilo, The good news is I've managed to get the "beta" release of TAO building here on FC 3. What I'll try to do is muck about with adding your struct to the TAO interoperability tests I've already written in C++, and see if I can't reproduce the problem. I'll do that this afternoon (19/3), so stay tuned ... dt. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 16:26 Message: Logged In: YES user_id=435731 Hi Danilo, I can't compile either TAO 1.3 or 1.4 on Red Hat Fedora Core 3. It gives an obscure compiler error then dies during the build. A quick search doesn't reveal any quick fix for this, apart from it being related somehow to the version of the C++ compiler shipped with Core 3 - and I'm not really keen to muck around with building different versions of the C++ compiler just to suit TAO. Especially considering that it will probably mean also building special versions of any tools and libraries that the compiler uses. Sigh. I'll keep searching for an quick answer that doesn't involve patching compilers :) In the meantime, tell us how recompiling the IDL on both sides goes ... I'd honestly forgotten how painful it is to make C++ code work on a given platform. What a nuisance. I can't really blame the TAO people - I know it's damned hard to write non-trivial C++ code that works across all the popular compilers (at least, last time I used C++ circa 2001). I'll just hold out the vague hope that it's simply mismatched IDL for now, before I start spending *lots* of time getting TAO working. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 14:39 Message: Logged In: YES user_id=435731 Hi Danilo, I just quickly tried passing this struct as an any from Fnorb client to Fnorb server, and that worked fine. Before we go any further, I notice there was some confusion early on about exactly what form this struct took, which indicates it *might* just be an IDL mismatch due to a change. Please, just to be sure, go and recompile your IDL for *both* TAO and Fnorb, recompile all your C++, and see if that fixes things. Do this even if you're certain you did it already - it's *so* easy to forget to recompile the IDL on one side, and you start getting all kinds of inexplicable hassle. I make this mistake often, if I have to do it manually - so before we spend more time on this please just try that first. The next step would be to try this with a TAO client ... and that's getting painful. Basically, I don't use C++ at all any more and I despise the C++/CORBA mapping. It fills me with dread just to think about it. In short, it will be time consuming and frustrating to have to write a TAO/C++ client from scratch just to reproduce this myself. Would it be possible for you to come up with a short C++ client (and a corresponding Fnorb Python server) that I can build here against TAO to reproduce the problem? It still won't be easy for me even *with* that code, as I'm still not using my "real" machine (let's just say "warranties == hassle"), and building/using TAO on this older machine is not the most pleasurable experience imaginable as I recall. But I will build TAO here (it *will* take hours) so that I'll be ready to go when you lay your example code on me :) Regards, Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-12 17:22 Message: Logged In: YES user_id=435731 Okay, at least the new version of Fnorb works :) As an aside, I think we will try to support the "magic" object-as-object-reference behaviour for people still using the BOA. Too many people would have assumed that this will just work. I'll have to think about this - shouldn't be too hard. Anyway, your problem: so we've established that it doesn't work even with the most recent fixes. In that case, I'll have to try your example code and try to reproduce it here! Probably tomorrow - I'll get back to you when done. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-04 22:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- 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: SourceForge.net <no...@so...> - 2005-05-02 03:10:35
|
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-05-02 13:10 Message: Logged In: YES user_id=435731 I had to give up building TAO on my older machine, it was painful doing *anything* TAO related on it ... but my dev box is all patched up and I'm building TAO on it now. I'm going to look at this problem this afternoon. My first step will be to try to reproduce it. Sorry about the delay. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-19 13:20 Message: Logged In: YES user_id=435731 Danilo, The good news is I've managed to get the "beta" release of TAO building here on FC 3. What I'll try to do is muck about with adding your struct to the TAO interoperability tests I've already written in C++, and see if I can't reproduce the problem. I'll do that this afternoon (19/3), so stay tuned ... dt. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 16:26 Message: Logged In: YES user_id=435731 Hi Danilo, I can't compile either TAO 1.3 or 1.4 on Red Hat Fedora Core 3. It gives an obscure compiler error then dies during the build. A quick search doesn't reveal any quick fix for this, apart from it being related somehow to the version of the C++ compiler shipped with Core 3 - and I'm not really keen to muck around with building different versions of the C++ compiler just to suit TAO. Especially considering that it will probably mean also building special versions of any tools and libraries that the compiler uses. Sigh. I'll keep searching for an quick answer that doesn't involve patching compilers :) In the meantime, tell us how recompiling the IDL on both sides goes ... I'd honestly forgotten how painful it is to make C++ code work on a given platform. What a nuisance. I can't really blame the TAO people - I know it's damned hard to write non-trivial C++ code that works across all the popular compilers (at least, last time I used C++ circa 2001). I'll just hold out the vague hope that it's simply mismatched IDL for now, before I start spending *lots* of time getting TAO working. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 14:39 Message: Logged In: YES user_id=435731 Hi Danilo, I just quickly tried passing this struct as an any from Fnorb client to Fnorb server, and that worked fine. Before we go any further, I notice there was some confusion early on about exactly what form this struct took, which indicates it *might* just be an IDL mismatch due to a change. Please, just to be sure, go and recompile your IDL for *both* TAO and Fnorb, recompile all your C++, and see if that fixes things. Do this even if you're certain you did it already - it's *so* easy to forget to recompile the IDL on one side, and you start getting all kinds of inexplicable hassle. I make this mistake often, if I have to do it manually - so before we spend more time on this please just try that first. The next step would be to try this with a TAO client ... and that's getting painful. Basically, I don't use C++ at all any more and I despise the C++/CORBA mapping. It fills me with dread just to think about it. In short, it will be time consuming and frustrating to have to write a TAO/C++ client from scratch just to reproduce this myself. Would it be possible for you to come up with a short C++ client (and a corresponding Fnorb Python server) that I can build here against TAO to reproduce the problem? It still won't be easy for me even *with* that code, as I'm still not using my "real" machine (let's just say "warranties == hassle"), and building/using TAO on this older machine is not the most pleasurable experience imaginable as I recall. But I will build TAO here (it *will* take hours) so that I'll be ready to go when you lay your example code on me :) Regards, Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-12 17:22 Message: Logged In: YES user_id=435731 Okay, at least the new version of Fnorb works :) As an aside, I think we will try to support the "magic" object-as-object-reference behaviour for people still using the BOA. Too many people would have assumed that this will just work. I'll have to think about this - shouldn't be too hard. Anyway, your problem: so we've established that it doesn't work even with the most recent fixes. In that case, I'll have to try your example code and try to reproduce it here! Probably tomorrow - I'll get back to you when done. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-04 22:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- 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: SourceForge.net <no...@so...> - 2005-05-01 13:20:01
|
Bugs item #1177026, was opened at 2005-04-05 14:51 Message generated for change (Comment added) made by genuts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1177026&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: application error Initial Comment: Error: instruction at 0x77f51baa referenced memory at 0x0000010 could not be writen. Both packages Fnorb-1.3.win32 and Fnorb-1.3RC1.win32 give similar error. What should I do? ---------------------------------------------------------------------- Comment By: GeNuts (genuts) Date: 2005-05-01 15:20 Message: Logged In: YES user_id=1270196 Sorry for the inconvenience. Hopefully my login works fine now. As previously state I did use the windows installer for Fnorb unable to finish installation of Fnorb. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2005-04-05 20:49 Message: Logged In: YES user_id=21627 As a starting point, please identify yourself. I don't think you will get an email notification for this comment, so it is uncertain whether you will even see it. As a next step, please specify precisely what you did. Is it the installation of Fnorb-1.3.win32 that gives the error, or running a Fnorb application that does so? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1177026&group_id=44742 |
From: <dth...@us...> - 2005-04-16 01:28:00
|
Update of /cvsroot/fnorb/fnorb/orb In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14425 Modified Files: GIOPClient.py Log Message: Fixed YET ANOTHER pseudo_del related bug (in __get_worker) that's been there since day one. This pseudo_del stuff has got to be rethought ... Index: GIOPClient.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/orb/GIOPClient.py,v retrieving revision 1.15 retrieving revision 1.16 diff -C2 -d -r1.15 -r1.16 *** GIOPClient.py 7 Nov 2004 12:50:42 -0000 1.15 --- GIOPClient.py 16 Apr 2005 01:27:47 -0000 1.16 *************** *** 34,37 **** --- 34,38 ---- """ GIOPClient class. """ + import traceback # Debugging # Standard/built-in modules. *************** *** 39,43 **** # Fnorb modules. ! import fnorb_thread, CORBA, GIOP, GIOPClientWorker, IOP, OctetStream, Util import cdrpy --- 40,46 ---- # Fnorb modules. ! # import fnorb_thread, CORBA, GIOP, GIOPClientWorker, IOP, OctetStream, Util ! import CORBA, GIOP, GIOPClientWorker, IOP, OctetStream, Util ! import thread import cdrpy *************** *** 66,70 **** # don't create more than one worker for the same client in # multi-threaded environments! ! self.__lk = fnorb_thread.allocate_lock() return --- 69,73 ---- # don't create more than one worker for the same client in # multi-threaded environments! ! self.__lk = thread.allocate_lock() return *************** *** 505,535 **** self.__lk.acquire() try: ! # If this is the first operation request then get a worker. ! if self.__worker is None: ! # Get a reference to the factory for GIOP client workers. cwf = GIOPClientWorker.GIOPClientWorkerFactory() ! # Create a new GIOP client worker (the concrete type of which ! # will be determined by the threading model). ! self.__worker = cwf.create_worker(self.__protocol, ! self.__address, self.__giop_version) ! # If the worker has received a 'CloseConnection' message, then ! # we need a new one! ! elif self.__worker.is_closed(): ! # Clean up the old worker. ! self.__worker.pseudo__del__() ! # Get a reference to the factory for GIOP client workers. ! cwf = GIOPClientWorker.GIOPClientWorkerFactory_init() ! # Create a new GIOP client worker (the concrete type of which ! # will be determined by the threading model). ! self.__worker = cwf.create_worker(self.__protocol, ! self.__address) ! # Return value. ! worker = self.__worker finally: --- 508,548 ---- self.__lk.acquire() try: ! # If this is the first operation request then get a worker. ! if self.__worker is None: ! # Get a reference to the factory for GIOP client workers. cwf = GIOPClientWorker.GIOPClientWorkerFactory() ! # Create a new GIOP client worker (the concrete type of which ! # will be determined by the threading model). ! self.__worker = cwf.create_worker(self.__protocol, ! self.__address, self.__giop_version) ! # If the worker has received a 'CloseConnection' message, then ! # we need a new one! ! elif self.__worker.is_closed(): ! # Clean up the old worker. ! # Set old worker to None first in case the closed ! # connection causes an exception to be thrown ! old_worker = self.__worker ! self.__worker = None ! old_worker.pseudo__del__() ! ! # Get a reference to the factory for GIOP client workers. ! cwf = GIOPClientWorker.GIOPClientWorkerFactory_init() ! ! # Create a new GIOP client worker (the concrete type of which ! # will be determined by the threading model). ! # This may throw an exception if the server does not ! # accept connections ! self.__worker = cwf.create_worker(self.__protocol, ! self.__address, ! self.__giop_version) ! ! # Return value. ! worker = self.__worker finally: |
From: SourceForge.net <no...@so...> - 2005-04-05 18:49:50
|
Bugs item #1177026, was opened at 2005-04-05 14:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1177026&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: application error Initial Comment: Error: instruction at 0x77f51baa referenced memory at 0x0000010 could not be writen. Both packages Fnorb-1.3.win32 and Fnorb-1.3RC1.win32 give similar error. What should I do? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2005-04-05 20:49 Message: Logged In: YES user_id=21627 As a starting point, please identify yourself. I don't think you will get an email notification for this comment, so it is uncertain whether you will even see it. As a next step, please specify precisely what you did. Is it the installation of Fnorb-1.3.win32 that gives the error, or running a Fnorb application that does so? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1177026&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-04-05 12:51:29
|
Bugs item #1177026, was opened at 2005-04-05 05:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1177026&group_id=44742 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: application error Initial Comment: Error: instruction at 0x77f51baa referenced memory at 0x0000010 could not be writen. Both packages Fnorb-1.3.win32 and Fnorb-1.3RC1.win32 give similar error. What should I do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=440740&aid=1177026&group_id=44742 |
From: SourceForge.net <no...@so...> - 2005-03-19 03:31:09
|
Bugs item #1068018, was opened at 2004-11-17 23:49 Message generated for change (Settings changed) 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: Closed >Resolution: Works For Me 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-03-19 13:30 Message: Logged In: YES user_id=435731 Since this bug cannot be reproduced, and we haven't received any more info, I'm closing this as "works for me". The most likely culprit in my opinion is somehow accidentally using Fnorb 1.2 with Python 1.x since this *exact* API changed with Python 2.0, and would cause this precise problem. It certainly seems fine when I use Fnorb 1.2 with Python 2.2. We should definitely look at adding some logging down at this level so that we can easily tell what the problem is in future - converting it to a CORBA exception isn't exactly helpful. There's just so many things that can go wrong - Python API version mismatch, network problems, network misconfiguration and so on - and it would take no time to diagnose if we had that. We'll re-open this should more details be provided. ---------------------------------------------------------------------- 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-03-19 03:30:38
|
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-03-19 13:30 Message: Logged In: YES user_id=435731 Since this bug cannot be reproduced, and we haven't received any more info, I'm closing this as "works for me". The most likely culprit in my opinion is somehow accidentally using Fnorb 1.2 with Python 1.x since this *exact* API changed with Python 2.0, and would cause this precise problem. It certainly seems fine when I use Fnorb 1.2 with Python 2.2. We should definitely look at adding some logging down at this level so that we can easily tell what the problem is in future - converting it to a CORBA exception isn't exactly helpful. There's just so many things that can go wrong - Python API version mismatch, network problems, network misconfiguration and so on - and it would take no time to diagnose if we had that. We'll re-open this should more details be provided. ---------------------------------------------------------------------- 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-03-19 03:20:04
|
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-03-19 13:20 Message: Logged In: YES user_id=435731 Danilo, The good news is I've managed to get the "beta" release of TAO building here on FC 3. What I'll try to do is muck about with adding your struct to the TAO interoperability tests I've already written in C++, and see if I can't reproduce the problem. I'll do that this afternoon (19/3), so stay tuned ... dt. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 16:26 Message: Logged In: YES user_id=435731 Hi Danilo, I can't compile either TAO 1.3 or 1.4 on Red Hat Fedora Core 3. It gives an obscure compiler error then dies during the build. A quick search doesn't reveal any quick fix for this, apart from it being related somehow to the version of the C++ compiler shipped with Core 3 - and I'm not really keen to muck around with building different versions of the C++ compiler just to suit TAO. Especially considering that it will probably mean also building special versions of any tools and libraries that the compiler uses. Sigh. I'll keep searching for an quick answer that doesn't involve patching compilers :) In the meantime, tell us how recompiling the IDL on both sides goes ... I'd honestly forgotten how painful it is to make C++ code work on a given platform. What a nuisance. I can't really blame the TAO people - I know it's damned hard to write non-trivial C++ code that works across all the popular compilers (at least, last time I used C++ circa 2001). I'll just hold out the vague hope that it's simply mismatched IDL for now, before I start spending *lots* of time getting TAO working. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 14:39 Message: Logged In: YES user_id=435731 Hi Danilo, I just quickly tried passing this struct as an any from Fnorb client to Fnorb server, and that worked fine. Before we go any further, I notice there was some confusion early on about exactly what form this struct took, which indicates it *might* just be an IDL mismatch due to a change. Please, just to be sure, go and recompile your IDL for *both* TAO and Fnorb, recompile all your C++, and see if that fixes things. Do this even if you're certain you did it already - it's *so* easy to forget to recompile the IDL on one side, and you start getting all kinds of inexplicable hassle. I make this mistake often, if I have to do it manually - so before we spend more time on this please just try that first. The next step would be to try this with a TAO client ... and that's getting painful. Basically, I don't use C++ at all any more and I despise the C++/CORBA mapping. It fills me with dread just to think about it. In short, it will be time consuming and frustrating to have to write a TAO/C++ client from scratch just to reproduce this myself. Would it be possible for you to come up with a short C++ client (and a corresponding Fnorb Python server) that I can build here against TAO to reproduce the problem? It still won't be easy for me even *with* that code, as I'm still not using my "real" machine (let's just say "warranties == hassle"), and building/using TAO on this older machine is not the most pleasurable experience imaginable as I recall. But I will build TAO here (it *will* take hours) so that I'll be ready to go when you lay your example code on me :) Regards, Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-12 17:22 Message: Logged In: YES user_id=435731 Okay, at least the new version of Fnorb works :) As an aside, I think we will try to support the "magic" object-as-object-reference behaviour for people still using the BOA. Too many people would have assumed that this will just work. I'll have to think about this - shouldn't be too hard. Anyway, your problem: so we've established that it doesn't work even with the most recent fixes. In that case, I'll have to try your example code and try to reproduce it here! Probably tomorrow - I'll get back to you when done. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-04 22:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- 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: SourceForge.net <no...@so...> - 2005-03-13 06:26:59
|
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-03-13 16:26 Message: Logged In: YES user_id=435731 Hi Danilo, I can't compile either TAO 1.3 or 1.4 on Red Hat Fedora Core 3. It gives an obscure compiler error then dies during the build. A quick search doesn't reveal any quick fix for this, apart from it being related somehow to the version of the C++ compiler shipped with Core 3 - and I'm not really keen to muck around with building different versions of the C++ compiler just to suit TAO. Especially considering that it will probably mean also building special versions of any tools and libraries that the compiler uses. Sigh. I'll keep searching for an quick answer that doesn't involve patching compilers :) In the meantime, tell us how recompiling the IDL on both sides goes ... I'd honestly forgotten how painful it is to make C++ code work on a given platform. What a nuisance. I can't really blame the TAO people - I know it's damned hard to write non-trivial C++ code that works across all the popular compilers (at least, last time I used C++ circa 2001). I'll just hold out the vague hope that it's simply mismatched IDL for now, before I start spending *lots* of time getting TAO working. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-13 14:39 Message: Logged In: YES user_id=435731 Hi Danilo, I just quickly tried passing this struct as an any from Fnorb client to Fnorb server, and that worked fine. Before we go any further, I notice there was some confusion early on about exactly what form this struct took, which indicates it *might* just be an IDL mismatch due to a change. Please, just to be sure, go and recompile your IDL for *both* TAO and Fnorb, recompile all your C++, and see if that fixes things. Do this even if you're certain you did it already - it's *so* easy to forget to recompile the IDL on one side, and you start getting all kinds of inexplicable hassle. I make this mistake often, if I have to do it manually - so before we spend more time on this please just try that first. The next step would be to try this with a TAO client ... and that's getting painful. Basically, I don't use C++ at all any more and I despise the C++/CORBA mapping. It fills me with dread just to think about it. In short, it will be time consuming and frustrating to have to write a TAO/C++ client from scratch just to reproduce this myself. Would it be possible for you to come up with a short C++ client (and a corresponding Fnorb Python server) that I can build here against TAO to reproduce the problem? It still won't be easy for me even *with* that code, as I'm still not using my "real" machine (let's just say "warranties == hassle"), and building/using TAO on this older machine is not the most pleasurable experience imaginable as I recall. But I will build TAO here (it *will* take hours) so that I'll be ready to go when you lay your example code on me :) Regards, Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-12 17:22 Message: Logged In: YES user_id=435731 Okay, at least the new version of Fnorb works :) As an aside, I think we will try to support the "magic" object-as-object-reference behaviour for people still using the BOA. Too many people would have assumed that this will just work. I'll have to think about this - shouldn't be too hard. Anyway, your problem: so we've established that it doesn't work even with the most recent fixes. In that case, I'll have to try your example code and try to reproduce it here! Probably tomorrow - I'll get back to you when done. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-04 22:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- 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: SourceForge.net <no...@so...> - 2005-03-13 04:39:07
|
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-03-13 14:39 Message: Logged In: YES user_id=435731 Hi Danilo, I just quickly tried passing this struct as an any from Fnorb client to Fnorb server, and that worked fine. Before we go any further, I notice there was some confusion early on about exactly what form this struct took, which indicates it *might* just be an IDL mismatch due to a change. Please, just to be sure, go and recompile your IDL for *both* TAO and Fnorb, recompile all your C++, and see if that fixes things. Do this even if you're certain you did it already - it's *so* easy to forget to recompile the IDL on one side, and you start getting all kinds of inexplicable hassle. I make this mistake often, if I have to do it manually - so before we spend more time on this please just try that first. The next step would be to try this with a TAO client ... and that's getting painful. Basically, I don't use C++ at all any more and I despise the C++/CORBA mapping. It fills me with dread just to think about it. In short, it will be time consuming and frustrating to have to write a TAO/C++ client from scratch just to reproduce this myself. Would it be possible for you to come up with a short C++ client (and a corresponding Fnorb Python server) that I can build here against TAO to reproduce the problem? It still won't be easy for me even *with* that code, as I'm still not using my "real" machine (let's just say "warranties == hassle"), and building/using TAO on this older machine is not the most pleasurable experience imaginable as I recall. But I will build TAO here (it *will* take hours) so that I'll be ready to go when you lay your example code on me :) Regards, Derek. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-03-12 17:22 Message: Logged In: YES user_id=435731 Okay, at least the new version of Fnorb works :) As an aside, I think we will try to support the "magic" object-as-object-reference behaviour for people still using the BOA. Too many people would have assumed that this will just work. I'll have to think about this - shouldn't be too hard. Anyway, your problem: so we've established that it doesn't work even with the most recent fixes. In that case, I'll have to try your example code and try to reproduce it here! Probably tomorrow - I'll get back to you when done. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-04 22:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- 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: SourceForge.net <no...@so...> - 2005-03-12 07:22:41
|
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-03-12 17:22 Message: Logged In: YES user_id=435731 Okay, at least the new version of Fnorb works :) As an aside, I think we will try to support the "magic" object-as-object-reference behaviour for people still using the BOA. Too many people would have assumed that this will just work. I'll have to think about this - shouldn't be too hard. Anyway, your problem: so we've established that it doesn't work even with the most recent fixes. In that case, I'll have to try your example code and try to reproduce it here! Probably tomorrow - I'll get back to you when done. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-04 22:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- 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: SourceForge.net <no...@so...> - 2005-03-04 12:02:12
|
Bugs item #1118723, was opened at 2005-02-08 08:13 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2005-03-04 04:02 Message: Logged In: NO No success!!!! With the modifications you suggested the servers starts, but, anyway, I always have the "indirection" problem: Traceback (most recent call last): File "xxxxx.py", line xx, in ? boa._fnorb_mainloop() File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 278, in _fnorb_mainloop protocol.start(timeout) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/IIOPProtocol.py", line 83, 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 166, 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 365, in _fnorb_request self.__process_request(request) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/BOA.py", line 489, 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 964, 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 3931, in unmarshal typecode._fnorb_unmarshal(cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 1766, in _fnorb_unmarshal member_type = tcf.unmarshal(encapsulation_cursor) File "/usr/local/lib/python2.2/site-packages/Fnorb/orb/TypeCode.py", line 3910, in unmarshal raise 'Invalid indirection for recursive typecode.' Invalid indirection for recursive typecode. ---------------------------------------------------------------------- Comment By: Derek Thomson (dthomson) Date: 2005-02-25 23: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-25 17: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-21 07: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-16 15: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 02: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 14: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 06: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 05: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 03: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 03: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 03: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 06: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 08: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 04: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-27 07:12:29
|
Update of /cvsroot/fnorb/fnorb/script In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26253 Modified Files: fnifr.py Log Message: Updated to use the POA Index: fnifr.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/script/fnifr.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** fnifr.py 30 Nov 2003 15:50:15 -0000 1.2 --- fnifr.py 27 Feb 2005 07:12:20 -0000 1.3 *************** *** 39,43 **** # Fnorb modules. ! from Fnorb.orb import BOA, CORBA # Interface Repository modules. --- 39,43 ---- # Fnorb modules. ! from Fnorb.orb import PortableServer, CORBA # Interface Repository modules. *************** *** 59,67 **** orb._fnorb_override_options({'Threading Model': 'Reactive'}) ! # Get the root POA. poa = orb.resolve_initial_references('RootPOA') # Create the interface repository. ! ifr = IFR.IFR(argv, poa) # Start the event loop. --- 59,71 ---- orb._fnorb_override_options({'Threading Model': 'Reactive'}) ! # Initialise the POA. poa = orb.resolve_initial_references('RootPOA') + user_id_policy = poa.create_id_assignment_policy( + PortableServer.POA.USER_ID) + child_poa = poa.create_POA('child', None, [ user_id_policy ]) + # Create the interface repository. ! ifr = IFR.IFR(argv, child_poa) # Start the event loop. |
From: <dth...@us...> - 2005-02-27 07:11:33
|
Update of /cvsroot/fnorb/fnorb/tests/POA In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25957/POA Modified Files: ChatClient.py test_poa_functions.py tkchat.py Log Message: Updated to reflect fact that OAs are no longer passed to servants. Index: ChatClient.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/tests/POA/ChatClient.py,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** ChatClient.py 9 Jan 2005 13:01:39 -0000 1.1 --- ChatClient.py 27 Feb 2005 07:11:22 -0000 1.2 *************** *** 10,15 **** class ChatListenerImpl (chat__POA.Listener): ! def __init__(self, poa): ! chat__POA.Listener.__init__(self, poa) def send(self, sender, channel, message): --- 10,15 ---- class ChatListenerImpl (chat__POA.Listener): ! def __init__(self): ! chat__POA.Listener.__init__(self) def send(self, sender, channel, message): *************** *** 34,42 **** # ! impl = ChatListenerImpl(child_poa) oid = 'chat_listener' child_poa.activate_object_with_id(oid, impl) ! chat_server.register_listener(impl, [ 'noise', 'chat' ]) for i in range(0, 10): --- 34,43 ---- # ! impl = ChatListenerImpl() oid = 'chat_listener' child_poa.activate_object_with_id(oid, impl) ! impl_ref = child_poa.servant_to_reference(impl) ! chat_server.register_listener(impl_ref, [ 'noise', 'chat' ]) for i in range(0, 10): Index: test_poa_functions.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/tests/POA/test_poa_functions.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -d -r1.4 -r1.5 *** test_poa_functions.py 23 Jan 2005 08:58:51 -0000 1.4 --- test_poa_functions.py 27 Feb 2005 07:11:22 -0000 1.5 *************** *** 29,33 **** class PoaRunner: ! "Run a POA in a separate thread of control." def __init__(self, poa): --- 29,33 ---- class PoaRunner: ! "Run a POA in a separate thread of control, so we can stop it at will." def __init__(self, poa): *************** *** 47,54 **** "Listen for messages from the server." ! def __init__(self, poa, received): ! chat__POA.Listener.__init__(self, poa) self.received = received - self.poa = poa def send(self, sender, channel, message): --- 47,53 ---- "Listen for messages from the server." ! def __init__(self, received): ! chat__POA.Listener.__init__(self) self.received = received def send(self, sender, channel, message): *************** *** 89,93 **** received = Received() ! impl = ChatListenerImpl(user_id_poa, received) oid = 'chat_listener' user_id_poa.activate_object_with_id(oid, impl) --- 88,92 ---- received = Received() ! impl = ChatListenerImpl(received) oid = 'chat_listener' user_id_poa.activate_object_with_id(oid, impl) *************** *** 101,110 **** # - # Register the listener object with the server. - # - - self.chat_server.register_listener(impl, [ 'chat' ]) - - # # Start the event loop. # --- 100,103 ---- *************** *** 113,117 **** poa_runner.start() ! sent_message = "some text" # --- 106,115 ---- poa_runner.start() ! # ! # Register the listener object with the server. ! # ! ! impl_ref = user_id_poa.servant_to_reference(impl) ! self.chat_server.register_listener(impl_ref, [ 'chat' ]) # *************** *** 119,122 **** --- 117,122 ---- # + sent_message = "some text" + self.chat_server.send('tester', 'chat', sent_message) *************** *** 124,128 **** time.sleep(0.01) ! poa_runner.stop() # --- 124,128 ---- time.sleep(0.01) ! # poa_runner.stop() # *************** *** 150,154 **** received = Received() ! impl = ChatListenerImpl(system_id_poa, received) system_id_poa.activate_object(impl) --- 150,154 ---- received = Received() ! impl = ChatListenerImpl(received) system_id_poa.activate_object(impl) *************** *** 165,169 **** # ! impl2 = ChatListenerImpl(system_id_poa, received) system_id_poa.activate_object(impl2) --- 165,169 ---- # ! impl2 = ChatListenerImpl(received) system_id_poa.activate_object(impl2) *************** *** 172,179 **** # # Register the listener object with the server. # ! self.chat_server.register_listener(impl, [ 'chat' ]) # --- 172,294 ---- # + # Start the event loop. + # + + poa_runner = PoaRunner(system_id_poa) + poa_runner.start() + + time.sleep(1) + + # # Register the listener object with the server. # ! impl_ref = system_id_poa.servant_to_reference(impl) ! self.chat_server.register_listener(impl_ref, [ 'chat' ]) ! ! # ! # Send the message and wait for reply. ! # ! ! sent_message = "some text for the system identified object" ! ! self.chat_server.send('tester', 'chat', sent_message) ! ! while not received.has_received(): ! time.sleep(0.01) ! ! # poa_runner.stop() ! ! # ! # Check that the reply is as expected. ! # ! ! self.assertEqual(received.get_message(), sent_message) ! ! def test_create_reference_with_id(self): ! # ! # Create a child POA with "USER_ID" policy. ! # ! ! user_id_policy = self.poa.create_id_assignment_policy( ! PortableServer.POA.USER_ID) ! ! child_poa = self.poa.create_POA('child_poa', ! None, ! [ user_id_policy ]) ! ! # ! # Now create a listener object with a specific id using ! # create_reference_with_id. ! # ! ! received = Received() ! impl = ChatListenerImpl(received) ! oid = 'chat_listener' ! impl_ref = child_poa.create_reference_with_id( ! oid, ! 'IDL:chat/Listener:1.0') ! child_poa.activate_object_with_id(oid, impl) ! ! # ! # Register the listener object with the server. ! # ! ! self.chat_server.register_listener(impl_ref, [ 'chat' ]) ! ! # ! # Start the event loop. ! # ! ! poa_runner = PoaRunner(child_poa) ! poa_runner.start() ! ! sent_message = "some text for the object" ! ! # ! # Send the message and wait for reply. ! # ! ! self.chat_server.send('tester', 'chat', sent_message) ! ! while not received.has_received(): ! time.sleep(0.01) ! ! # poa_runner.stop() ! ! # ! # Check that the reply is as expected. ! # ! ! self.assertEqual(received.get_message(), sent_message) ! ! def test_deactivate_object(self): ! # ! # Create a child POA with "SYSTEM_ID" policy. ! # ! ! system_id_policy = self.poa.create_id_assignment_policy( ! PortableServer.POA.SYSTEM_ID) ! ! system_id_poa = self.poa.create_POA('system2_id_poa', ! None, ! [ system_id_policy ]) ! ! # ! # Now create a listener object with a specific id using ! # activate_object_with_id. ! # ! ! received = Received() ! impl = ChatListenerImpl(received) ! system_id_poa.activate_object(impl) ! ! # ! # Check that the object was constructed with the correct object ! # key. ! # ! ! expected_key = 0 ! self.assertEqual(system_id_poa.servant_to_id(impl), str(expected_key)) # *************** *** 184,188 **** poa_runner.start() ! sent_message = "some text for the system identified object" # --- 299,312 ---- poa_runner.start() ! print >>sys.stderr, "Started event loop" ! ! # ! # Register the listener object with the server. ! # ! ! impl_ref = system_id_poa.servant_to_reference(impl) ! self.chat_server.register_listener(impl_ref, [ 'chat' ]) ! ! print >>sys.stderr, "Registered listener" # *************** *** 190,199 **** # self.chat_server.send('tester', 'chat', sent_message) while not received.has_received(): time.sleep(0.01) ! poa_runner.stop() # --- 314,327 ---- # + sent_message = "some text for the system identified object" + self.chat_server.send('tester', 'chat', sent_message) + + print >>sys.stderr, "Sent message" while not received.has_received(): time.sleep(0.01) ! # poa_runner.stop() # Index: tkchat.py =================================================================== RCS file: /cvsroot/fnorb/fnorb/tests/POA/tkchat.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -d -r1.4 -r1.5 *** tkchat.py 23 Jan 2005 04:17:41 -0000 1.4 --- tkchat.py 27 Feb 2005 07:11:23 -0000 1.5 *************** *** 32,40 **** return groups ! class ChatListenerImpl (chat__POA.Listener): "Listen for messages from the server." ! def __init__(self, poa, text): ! chat__POA.Listener.__init__(self, poa) self.text = text --- 32,40 ---- return groups ! class ChatListenerImpl(chat__POA.Listener): "Listen for messages from the server." ! def __init__(self, text): ! chat__POA.Listener.__init__(self) self.text = text *************** *** 55,78 **** entry = event.widget text = entry.get() ! self.server.send(name, "chat", text) self.message.set('') ! def run_client(name, config_file_name): """Construct a GUI for sending and receiving messages to and from the chat server.""" # ! # Parse the configuration file. # ! config_file = file(config_file_name) ! groups = parse_config(config_file) # ! # Create the ORB and a POA. # ! TkReactor.TkReactor_init() ! orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID) stringified_ior = open('chat_server.ref', 'r').read() --- 55,84 ---- entry = event.widget text = entry.get() ! self.server.send(self.name, "chat", text) self.message.set('') ! def run_client(args): """Construct a GUI for sending and receiving messages to and from the chat server.""" # ! # Create the ORB and a POA. # ! TkReactor.TkReactor_init() ! orb = CORBA.ORB_init(args, CORBA.ORB_ID) # ! # Get the chat client command line configuration. # ! (exec_name, name, config_file_name) = args[0:3] ! ! # ! # Parse the configuration file. ! # ! ! config_file = file(config_file_name) ! groups = parse_config(config_file) stringified_ior = open('chat_server.ref', 'r').read() *************** *** 122,130 **** # ! impl = ChatListenerImpl(child_poa, text) oid = 'chat_listener' child_poa.activate_object_with_id(oid, impl) ! chat_server.register_listener(impl, groups) # Start the event loop. --- 128,137 ---- # ! impl = ChatListenerImpl(text) oid = 'chat_listener' child_poa.activate_object_with_id(oid, impl) ! impl_ref = child_poa.servant_to_reference(impl) ! chat_server.register_listener(impl_ref, groups) # Start the event loop. *************** *** 132,135 **** if __name__ == "__main__": ! (exec_name, name, config_file_name) = sys.argv[0:3] ! run_client(name, config_file_name) --- 139,141 ---- if __name__ == "__main__": ! run_client(sys.argv) |