[omniNotify] 64 bit notifd on Solaris 2.8 core dumps immediately

[Mark Zimmerman]

Greetings:

I think I have gotten this working now; here is a quick summary before
I set this aside until Monday:

Many changes like this:

-  _supl_admin(RDI_ULongHash, RDI_ULongRank),
-  _cons_admin(RDI_ULongHash, RDI_ULongRank),
+  _supl_admin(RDI_UIntHash, RDI_UIntRank),
+  _cons_admin(RDI_UIntHash, RDI_UIntRank),

In CosNotifyFilter_i, _fid was used inconsistently as a unsigned long
and a CosNF::FilterID. This caused problems. I redeclared it as
CosNF::FilterID.

Many changes like this to silence compiler warnings:

-       sprintf(buf, "proxy%ld", sc1.key());
+       sprintf(buf, "proxy%ld", (long)sc1.key());

At the moment, it is necessary to compile with -DNDEBUG since the
debug code is broken. It fails down inside of RDI_OPLOCK_SCOPE_LOCK.

-- Mark

On Thu, Jun 16, 2005 at 02:05:26PM +0200, Emmanuel Taurel wrote:
> Hello,
> 
> I have seen you e-mails regarding omniNotify on 64 bits. I had the same 
> kind of problems but using
> Linux (Suse 9.0). My understanding of the problem is nearly the same 
> than you.
> In the CORBA Notification service IDL files, there are some IDL long. 
> These IDL longs are
> in C++ CORBA::Long which is always 32 bits whatever the computer is (32 
> or 64 bits).
> But as you mention, in omniNotify, these CORBA::Long are used with 
> hashing functions
> based on C++ long which is 64 bits on 64 bits computer.
> 
> But, in omniNotify, you also have hashing functions based on "int".
> Therefore, I have replaced in several source files, the use of the 
> RDI_SLongHash and  RDI_SLongRank
> functions by the RDI_SIntHash and RDI_SIntRank when compiling on 64 bits 
> platform.
> 
> After these changes, I am able to use omniNotify on 64 bits computer.
> (at least the features I am interested in).
> 
> If you want, I can give you the list of source files I have modified and 
> line number.
> It is only a trick to make it running. A proper fix is to detect long 
> size at configuration time
> and to change hashing function accordingly  (or to change the 
> RDI_SLongHash and  RDI_SLongRank
> functions to take long size into account)
> 
> Hoping this help
> 
> Emmanuel Taurel (taurel at esrf.fr)
> 
> Mark Zimmerman wrote:
> 
> >I made a few attempts at such bludgeonlike solutions and just made a
> >big mess. However, I think I just realized where to start looking: The
> >problem is really not that the hash functions are broken but rather
> >that the the wrong ones are being used. Also, I see that the hash
> >functions are not chosen by magic but are specified to the
> >constructors. e.g.  EventChannel_i.cc lines 68-69 and elsewhere. The
> >simplest solution is probably found there. I will look more in the
> >morning.
> >
> >-- Mark
> >
> >
> >On Wed, Jun 15, 2005 at 04:37:07PM -0400, Bob Gruber wrote:
> > 
> >
> >>I'm not able to look at the code right now, but assuming that the
> >>omniNotify code is always referring to a CORBA::Long when it is
> >>manipulating longs, one could replace the use of 'long' with
> >>'CORBA::Long' in the entire code base.
> >>
> >>In particular, change
> >>
> >>(*(long*)foo)
> >>
> >>to 
> >>
> >>(*(CORBA::Long*)foo)
> >>
> >>Does that work?
> >>
> >>
> >>
> >>On 6/15/05, Mark Zimmerman <markzimm at frii.com> wrote:
> >>   
> >>
> >>>sizeof(void*) = sizeof(long) always. This code by itself is OK but the
> >>>problem is created higher up in the call tree. It is not the size of
> >>>the pointers that is the problem but rather the size and alignment of
> >>>the data element being pointed to. It starts out as a reference to a
> >>>32 bit value but is transmogrified through perverse magic into what it
> >>>thinks is a pointer to a 64 bit value.
> >>>
> >>>-- Mark
> >>>
> >>>On Wed, Jun 15, 2005 at 08:16:37PM +0100, Jon wrote:
> >>>     
> >>>
> >>>>Hi
> >>>>is that because they are casting void * to long *?
> >>>>eg
> >>>>inline int RDI_SLongRank(const void* L, const void* R)
> >>>>{ return *((long *) L) - *((long *) R); }
> >>>>
> >>>>are those types different sizes on 64 bit solaris 8?
> >>>>you could hack up a quick test program to take size of each type to 
> >>>>check?
> >>>>
> >>>>
> >>>>
> >>>>Jon
> >>>>
> >>>>On Wednesday 15 June 2005 18:28, Mark Zimmerman wrote:
> >>>>       
> >>>>
> >>>>>On Wed, Jun 15, 2005 at 10:46:10AM -0600, Mark Zimmerman wrote:
> >>>>>         
> >>>>>
> >>>>>>notifd seems to run fine with this change but I am concerned that this
> >>>>>>might break it in other ways I have not yet encountered.
> >>>>>>           
> >>>>>>
> >>>>>Well, "seems to run fine" was a major overstatement; It really just
> >>>>>starts up fine but continues to get bus errors as soon as something
> >>>>>tries to use it. All of the functions in RDIHashFuncs.h that contain
> >>>>>the string 'Long' in their names exhibit this problem.
> >>>>>
> >>>>>-- Mark
> >>>>>
> >>>>>_______________________________________________
> >>>>>omninotify-list mailing list
> >>>>>omninotify-list at omniorb-support.com
> >>>>>http://www.omniorb-support.com/mailman/listinfo/omninotify-list
> >>>>>         
> >>>>>
> >>>_______________________________________________
> >>>omninotify-list mailing list
> >>>omninotify-list at omniorb-support.com
> >>>http://www.omniorb-support.com/mailman/listinfo/omninotify-list
> >>>
> >>>     
> >>>
> >
> >_______________________________________________
> >omninotify-list mailing list
> >omninotify-list at omniorb-support.com
> >http://www.omniorb-support.com/mailman/listinfo/omninotify-list
> > 
> >