Re: Bug in giop_recv_buffer_unuse()? BiDir GIOP related?

[michael meeks <michael meeks novell com>]

On Wed, 2005-12-28 at 09:41 +0100, Jules Colding wrote:
> > > ==4558==  Address 0x1B9C292C is 100 bytes inside a block of size 104 free'd
> > > ==4558==    at 0x1B909743: free (vg_replace_malloc.c:152)
> > > ==4558==    by 0x40CC23: g_free (in /usr/lib/libglib-2.0.so.0.600.6)
> > > ==4558==    by 0x1B928E8A: giop_recv_buffer_unuse (giop-recv-buffer.c:511)
> > > ==4558==    by 0x1B92EE21: ORBit_handle_location_forward (corba-object.c:420)
> > > ==4558==    by 0x1B92C2F1: orbit_small_demarshal (orbit-small.c:532)
> > > ==4558==    by 0x1B92C8C0: ORBit_small_invoke_stub (orbit-small.c:660)
> > > ==4558==    by 0x1B92CA43: ORBit_small_invoke_stub_n (orbit-small.c:575)
> > > ==4558==    by 0x1B93D0F0: ORBit_c_stub_invoke (poa.c:2644)
> > > ==4558==    by 0x80675EE: BRUTUS_BrutusLogOn_Logon (BrutusLogOn-stubs.c:29)
> > > ==4558==    by 0x805BC2E: main (main.c:782)
> > 
> > 	So - clearly the forwarding code is broken :-)
..
> Sounds reasonable but I tried it and the problem persevered. 

	Most odd - clearly it's an FMR caused by the under-tested forwarding
code, and clearly just reading the code there is a bug as I described -
with that fix, that would give the above trace. You sure your fix
works ?

	HTH,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot