[omniORB] 4.0.7: reference to servant becomming nil after some time

[Igor Lautar]

Hi,

Is it possible that an existing reference (_narrowed to valid ITF)
becomes nil?

Either by changing network configuration (IPs etc.) or something else.
Is it at all possible that this occurs, excluding omniORB bugs (is such
a bug in 4.0.7?)?

Our code is roughly the following (pseudo):
1) string_to_object
2) _narrow to itf
3) check nil
4) use

It once (only once) happened that after some time (observed after 2
weeks of client uptime) of running, reference became nil. It couldn't be
nil at the start as there is a check for it.

It could also be some memory corruption (writing where we shouldn't).

Ideas/comments?

Regards,
Igor

[Igor Lautar]

Hi,

This happened on Windows 2003 Server x64 with omniORB compiled with MS
CL 14.00.50727.42.

thx,
Igor

Post by Igor Lautar
Hi,
Is it possible that an existing reference (_narrowed to valid ITF)
becomes nil?
Either by changing network configuration (IPs etc.) or something
else. Is it at all possible that this occurs, excluding omniORB bugs
(is such a bug in 4.0.7?)?
1) string_to_object
2) _narrow to itf
3) check nil
4) use
It once (only once) happened that after some time (observed after 2
weeks of client uptime) of running, reference became nil. It couldn't
be nil at the start as there is a check for it.
It could also be some memory corruption (writing where we shouldn't).
Ideas/comments?
Regards,
Igor

[Duncan Grisby]

Post by Igor Lautar
Is it possible that an existing reference (_narrowed to valid ITF)
becomes nil?

No. omniORB will definitely never change an object reference to be nil.

Post by Igor Lautar
Either by changing network configuration (IPs etc.) or something else.
Is it at all possible that this occurs, excluding omniORB bugs (is such
a bug in 4.0.7?)?
1) string_to_object
2) _narrow to itf
3) check nil
4) use
It once (only once) happened that after some time (observed after 2
weeks of client uptime) of running, reference became nil. It couldn't be
nil at the start as there is a check for it.
It could also be some memory corruption (writing where we shouldn't).

It is almost certainly either memory corruption, or that you have
released the object reference too many times so it is no longer valid.

Cheers,

Duncan.