Re: ORBit bug?

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi,

> > > The demarshalling code does not allocate memory for the name. Instead it
> > > uses a pointer into the receive buffer:
> > >
> > >     set._buffer[_ORBIT_tmpvar_3].name = (void *) _ORBIT_curptr;
> > >
> > > and later the code calls:
> > >
> > >     Bonobo_PropertySet__free(&set, NULL, CORBA_TRUE);
> > >
> > > Notice that release_strings is TRUE. So the memory is freed twice?
> >
> > Ownership of individual elements in a sequence is controlled by a separate
> >
> > flag named _release. If that's false, the elements in _buffer are not
> > freed.
> > I'm guessing (without looking at the code) that it's false in this case.
> 
> Sure, but the code sets this flag to TRUE.

This indeed is an ORBit bug. And I see no easy way to solve that. Even calling 
Bonobo_PropertySet__free(&set, NULL, CORBA_FALSE); wouldn't help, as
ORBit_demarshal_any will be called with dup_strings=TRUE, so we would gain a
memory hole. (which of course is better than the current state of affairs,
which simply says, that calling SetValues will result in an dying server). I
do not know the idl-compiler enough to fix that.

We had a nice feature in the now dead-declared CVS HEAD, that would do without
free_strings by prefixing all nonfreeable strings by a magic constant (the
place is always free because it otherwise hosts the string size) Is there any
chance that we backport that, Elliot? Or are you going to fix that otherwise?

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi