Re: Another Segfault In GIOP Code

[Chris McGee <sirnewton_01 yahoo ca>]

Hi Michael,

Thanks for the different debugging techniques. I
didn't realize that some of these tools existed and
they definitely save alot of time.

Anyways, here's the results that I got:

EF_PROTECT_BELOW(electric-fence):

167             how = *(((ORBitMemHow *) mem) - 1);
(gdb) bt
#0  ORBit_free_T (mem=0x41527000) at allocators.c:167
#1  0x40035781 in ORBit_free (mem=0x41527000) at
allocators.c:213
#2  0x40031882 in ORBit_small_invoke_adaptor
(adaptor_obj=0x41401000,
    recv_buffer=0x4151b000, m_data=0x80c6f60,
data=0xbffff5e0, ev=0xbffff6a0)
    at orbit-small.c:951
#3  0x4003ee9e in ORBit_POAObject_handle_request
(pobj=0x41401000,
    opname=0x4152103c "_get_application_title",
ret=0x0, args=0x0, ctx=0x0,
    recv_buffer=0x4151b000, ev=0xbffff6a0) at
poa.c:1139
#4  0x4003f178 in
ORBit_POAObject_invoke_incoming_request
(pobj=0x41401000,
    recv_buffer=0x4151b000, opt_ev=0xbffff6a0) at
poa.c:1210
#5  0x4003f419 in ORBit_POA_handle_request
(poa=0x40501000,
    recv_buffer=0x4151b000, objkey=0x4151b018) at
poa.c:1376
#6  0x40042437 in ORBit_handle_request
(orb=0x404f7000, recv_buffer=0x4151b000)
    at orbit-adaptor.c:164
#7  0x4002de77 in giop_connection_handle_input
(lcnx=0x414ff000)
    at giop-recv-buffer.c:1259
#8  0x4005d61d in linc_connection_io_handler
(gioc=0x0, condition=G_IO_IN,
    data=0x414ff000) at linc-connection.c:996
#9  0x4005efc0 in linc_source_dispatch
(source=0x41513000,
    callback=0x4005d4b8 <linc_connection_io_handler>,
user_data=0x414ff000)
    at linc-source.c:54
#10 0x4010b44f in g_get_current_time () from
/usr/lib/libglib-2.0.so.0
#11 0x4010c369 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#12 0x4010c66f in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#13 0x4010ccbe in g_main_loop_run () from
/usr/lib/libglib-2.0.so.0
#14 0x4005c014 in linc_main_loop_run () at linc.c:303
#15 0x4002b6ad in giop_main_run () at giop.c:397
#16 0x4002f866 in CORBA_ORB_run (orb=0x404f7000,
ev=0xbffff910)
    at corba-orb.c:966
#17 0x0805f6c5 in fresco_server_run ()
#18 0x0805f8cf in main ()
#19 0x40184a51 in __libc_start_main () from
/lib/libc.so.6

EF_PROTECT_FREE (electric-fence):
--Works Fine--

MALLOC_CHECK_=2:
#0  0x40191a41 in kill () from /lib/libc.so.6
#1  0x400a024b in pthread_kill () from
/lib/libpthread.so.0
#2  0x400a0521 in raise () from /lib/libpthread.so.0
#3  0x40192976 in abort () from /lib/libc.so.6
#4  0x401d318a in _IO_file_xsputn () from
/lib/libc.so.6
#5  0x401d422f in free () from /lib/libc.so.6
#6  0x4010c356 in g_free () from
/usr/lib/libglib-2.0.so.0
#7  0x40030738 in ORBit_free_T (mem=0x80f9b28) at
allocators.c:187
#8  0x40030781 in ORBit_free (mem=0x80f9b28) at
allocators.c:213
#9  0x4002c882 in ORBit_small_invoke_adaptor
(adaptor_obj=0x80f67b0,
    recv_buffer=0x80f99c8, m_data=0x80c6f60,
data=0xbffff5e0, ev=0xbffff6a0)
    at orbit-small.c:951
#10 0x40039e9e in ORBit_POAObject_handle_request
(pobj=0x80f67b0,
    opname=0x80f9ac4 "_get_application_title",
ret=0x0, args=0x0, ctx=0x0,
    recv_buffer=0x80f99c8, ev=0xbffff6a0) at
poa.c:1139
#11 0x4003a178 in
ORBit_POAObject_invoke_incoming_request
(pobj=0x80f67b0,
    recv_buffer=0x80f99c8, opt_ev=0xbffff6a0) at
poa.c:1210
#12 0x4003a419 in ORBit_POA_handle_request
(poa=0x80d9538,
    recv_buffer=0x80f99c8, objkey=0x80f99e0) at
poa.c:1376
#13 0x4003d437 in ORBit_handle_request (orb=0x80d9480,
recv_buffer=0x80f99c8)
    at orbit-adaptor.c:164
#14 0x40028e77 in giop_connection_handle_input
(lcnx=0x80f9418)
    at giop-recv-buffer.c:1259
#15 0x4005961d in linc_connection_io_handler
(gioc=0x0, condition=G_IO_IN,
    data=0x80f9418) at linc-connection.c:996
#16 0x4005afc0 in linc_source_dispatch
(source=0x80f98d8,
    callback=0x400594b8 <linc_connection_io_handler>,
user_data=0x80f9418)
    at linc-source.c:54
#17 0x4010744f in g_get_current_time () from
/usr/lib/libglib-2.0.so.0
#18 0x40108369 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#19 0x4010866f in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#20 0x40108cbe in g_main_loop_run () from
/usr/lib/libglib-2.0.so.0
#21 0x40058014 in linc_main_loop_run () at linc.c:303
#22 0x400266ad in giop_main_run () at giop.c:397
#23 0x4002a866 in CORBA_ORB_run (orb=0x80d9480,
ev=0xbffff910)
    at corba-orb.c:966
#24 0x0805f6c5 in fresco_server_run ()
#25 0x0805f8cf in main ()
#26 0x40180a51 in __libc_start_main () from
/lib/libc.so.6

valgrind:
==1559== Memcheck, a.k.a. Valgrind, a memory error
detector for x86-linux.
==1559== Copyright (C) 2002, and GNU GPL'd, by Julian
Seward.
==1559== Using valgrind-1.9.5, a program
instrumentation system for x86-linux.
==1559== Copyright (C) 2000-2002, and GNU GPL'd, by
Julian Seward.
==1559== Estimated CPU clock rate is 1012 MHz
==1559== For more details, rerun with: -v
==1559==
==1559== pthread_mutex_destroy: mutex is still in use
==1559==    at 0x40285E41: pthread_error
(vg_libpthread.c:292)
==1559==    by 0x40286CED: __pthread_mutex_destroy
(vg_libpthread.c:1002)
==1559==    by 0x403B6258: closedir (in
/lib/libc-2.3.1.so)
==1559==    by 0x4020EC76: scan_socket_dir (giop.c:93)
.
.
.
==1559==
==1559== Invalid read of size 4
==1559==    at 0x40219693: ORBit_free_T
(allocators.c:167)
==1559==    by 0x40219780: ORBit_free
(allocators.c:213)
==1559==    by 0x40215881: ORBit_small_invoke_adaptor
(orbit-small.c:951)
==1559==    by 0x40222E9D:
ORBit_POAObject_handle_request (poa.c:1139)
==1559==    Address 0x41285724 is 4 bytes before a
block of size 16 alloc'd
==1559==    at 0x4015D28E: calloc
(vg_clientfuncs.c:245)
==1559==    by 0x402C128F: g_malloc0 (in
/usr/lib/libglib-2.0.so.0.200.1)
==1559==    by 0x805F41C:
impl_Fresco_ClientContext__get_application_title (in
/export/home/cmcgee/FRESCO/Fresco-030501/Fresco-Orbit/ccontext)
==1559==    by 0x8060377:
_ORBIT_skel_small_Fresco_ClientContext__get_application_title
(in
/export/home/cmcgee/FRESCO/Fresco-030501/Fresco-Orbit/ccontext)

The above errors seem to crop up on the first request
sent from my omniorb process that requests the
application_title data member from my orbit client.
When I don't instrument my executable with any of
these profilers then the error crops up in later
messages sent from omniorb to orbit.

Thanks for you help, I hope this information is
helpful.

Chris


--- Michael Meeks <michael@ximian.com> wrote:
> Hi Chris,
> 
> On Sat, 2003-05-10 at 05:21, Chris McGee wrote:
> > I found another segmentation fault in the GIOP
> code.
> 
> 	Ok - this looks like plain and simple memory
> corruption / a double free
> somewhere. I'm hoping this is in your code ;-)
> 
> 	Here is how to set about finding it:
> 
> 	a) export MALLOC_CHECK_=2
> 	re-run your app to see if the stack-trace is more
> informative
> 
> 	b) link to electric fence; ensure you add a 'free
> (malloc(8))'
> 	to your main function; re-run in gdb likewise.
> 
> 	c) Download / build 'valgrind' (google for it), and
> that 
> 	should nail the problem ( you need to use
> --alignment=8 ).
> 
> 	Thanks for chasing this one,
> 
> 	Regards,
> 
> 		Michael.
> 
> -- 
>  mmeeks@gnu.org  <><, Pseudo Engineer, itinerant
> idiot
> 

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com