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



On Tue, 2006-01-03 at 12:04 +0000, michael meeks wrote:
> 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 ?

I might have had some kind of brain breakdown but it should have been
doing what I intended it to do. Could you make a patch so that we are
sure that I am testing the right fix?

Please?

Thanks,
  jules




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]