[omniORB] OmniORBPy Object References Problem

[Viktor Kerkez]

I have a CORBA server and a CORBA application which sets a callback
object on the server (server has a SetCallback function). Callback has
only one function - OnEvent. When something happens on the server it
will call the OnEvent function with appropriate message.

Problem begins when the application shuts down. If the server tries to
call OnEvent two things can happen:

1. If the servers calls OnEvent in the main thread it blocks forever. I
tried to set all the corba timeouts but non of them works.

2. If I start a new thread for calling OnEvent function the server
crashes without exception (segmentation).

Does anyone have any suggestion what should I try?

Thank You in advance,
Viktor Kerkez

[Viktor Kerkez]

I am sending two simple examples where my problem can be replicated:

1. In "test system 1" when I call a method on a object that doesn't
exist any more, instead of raising TransientException program dies with:

omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: pyCallDescriptor.cc
line: 104
info: !tstate_
omniORB: Unexpected C++ exception during Python invocation.

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.


2. I "test system 2" i try to check if the reference is valid with
obj._non_existent(). Everything works untill i put a time.sleep(1) in my
servers main loop. When I put a time.sleep(1) it works untill the
first TRANSIENT or COMM error is raised, after that the server continues
to work normally but I cannot access any of the servers methods using
CORBA. Call blocks forever.

Post by Viktor Kerkez
I have a CORBA server and a CORBA application which sets a callback
object on the server (server has a SetCallback function). Callback has
only one function - OnEvent. When something happens on the server it
will call the OnEvent function with appropriate message.
Problem begins when the application shuts down. If the server tries to
1. If the servers calls OnEvent in the main thread it blocks forever. I
tried to set all the corba timeouts but non of them works.
2. If I start a new thread for calling OnEvent function the server
crashes without exception (segmentation).
Does anyone have any suggestion what should I try?
Thank You in advance,
Viktor Kerkez
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

--
*****************************************************
Viktor Kerkez
DMS Group
Puskinova 9a
21000 Novi Sad
Serbia & Montenegro

Phone: [phone]
***@dmsgroup.co.yu
http://www.dmsgroup.co.yu/
*****************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error.zip
Type: application/x-zip-compressed
Size: 11846 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080227/61f7e7ce/error-0001.bin

[Duncan Grisby]

Post by Viktor Kerkez
1. In "test system 1" when I call a method on a object that doesn't
exist any more, instead of raising TransientException program dies
omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: pyCallDescriptor.cc
line: 104
info: !tstate_
omniORB: Unexpected C++ exception during Python invocation.

What version of omniORB / omniORBpy? That looks like something that was
fixed quite a while ago. Please try with omniORB 4.1.2 / omniORBpy 3.2.

Cheers,

Duncan.

[Viktor Kerkez]

I'm using omniORB 4.1.2 / omniORBpy 3.2.

We tested these samples on Linux and they work perfectly. It's seems
that this is only issue on windows.

Post by Duncan Grisby

Post by Viktor Kerkez
1. In "test system 1" when I call a method on a object that doesn't
exist any more, instead of raising TransientException program dies
omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: pyCallDescriptor.cc
line: 104
info: !tstate_
omniORB: Unexpected C++ exception during Python invocation.

What version of omniORB / omniORBpy? That looks like something that was
fixed quite a while ago. Please try with omniORB 4.1.2 / omniORBpy 3.2.
Cheers,
Duncan.

--
*****************************************************
Viktor Kerkez
DMS Group
Puskinova 9a
21000 Novi Sad
Serbia & Montenegro

Phone: [phone]
***@dmsgroup.co.yu
http://www.dmsgroup.co.yu/
*****************************************************

[Viktor Kerkez]

I tested older version of the omniORBpy, and it turned out that these
tests work with omniORBpy 3.0 (also they work with 2.7).

3.1 is the first version in which they fail.

Post by Viktor Kerkez
I'm using omniORB 4.1.2 / omniORBpy 3.2.
We tested these samples on Linux and they work perfectly. It's seems
that this is only issue on windows.

Post by Duncan Grisby

Post by Viktor Kerkez
1. In "test system 1" when I call a method on a object that doesn't
exist any more, instead of raising TransientException program dies
omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: pyCallDescriptor.cc
line: 104
info: !tstate_
omniORB: Unexpected C++ exception during Python invocation.

What version of omniORB / omniORBpy? That looks like something that was
fixed quite a while ago. Please try with omniORB 4.1.2 / omniORBpy 3.2.
Cheers,
Duncan.

--
*****************************************************
Viktor Kerkez
DMS Group
Puskinova 9a
21000 Novi Sad
Serbia & Montenegro

Phone: [phone]
***@dmsgroup.co.yu
http://www.dmsgroup.co.yu/
*****************************************************

[Duncan Grisby]

Post by Viktor Kerkez
I'm using omniORB 4.1.2 / omniORBpy 3.2.
We tested these samples on Linux and they work perfectly. It's seems
that this is only issue on windows.

It turns out that it is a bug in Visual C++ 7.1. It generates completely
incorrect code for the function that invokes calls on remote objects and
retries if necessary. Fortunately there's a simple work-around that I've
checked in to CVS.

The fix will be in omniORB 4.1.3, to be released in the near future.

Cheers,

Duncan.