|
From: Michael R.
|
I'm seeing the following... ==16015== Memcheck, a memory error detector. ==16015== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==16015== Using LibVEX rev 1854, a library for dynamic binary translation. ==16015== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==16015== Using valgrind-3.3.1, a dynamic binary instrumentation framework. ==16015== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==16015== --16015-- Command line --16015-- ./obj/t --16015-- --logorrhea --16015-- Startup, with flags: --16015-- -v --16015-- -v --16015-- -v --16015-- --db-attach=yes --16015-- Contents of /proc/version: --16015-- Linux version 2.6.18-92.1.6.el5 (moc...@bu...) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Wed Jun 25 13:45:47 EDT 2008 --16015-- Arch and hwcaps: X86, x86-sse1-sse2 --16015-- Page sizes: currently 4096, max supported 4096 --16015-- Valgrind library directory: /usr/lib/valgrind --16015-- TT/TC: VG_(init_tt_tc) (startup of code management) --16015-- TT/TC: cache: 8 sectors of 29772288 bytes each = 238178304 total --16015-- TT/TC: table: 524168 total entries, max occupancy 419328 (80%) --16015-- Reading syms from /lib/ld-2.3.2.so (0x4400000) --16015-- svma 0x0000000000, avma 0x0004400000 --16015-- Reading syms from /home/m/112129/parkcity/tmm/test/unittest/obj/t (0x8048000) --16015-- svma 0x0008048000, avma 0x0008048000 --16015-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck (0x38000000) --16015-- svma 0x0038000000, avma 0x0038000000 --16015-- object doesn't have a dynamic symbol table --16015-- Reading suppressions file: /usr/lib/valgrind/default.supp --16015-- TT/TC: initialise sector 0 --16015-- REDIR: 0x4411d20 (index) redirected to 0x38022d4f (vgPlain_x86_linux_REDIR_FOR_index) --16015-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so (0x7A5D000) --16015-- svma 0x0000000000, avma 0x0007A5D000 --16015-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x7A5F000) --16015-- svma 0x0000000000, avma 0x0007A5F000 ==16015== WARNING: new redirection conflicts with existing -- ignoring it --16015-- new: 0x04411d20 (index ) R-> 0x07a6262c index --16015-- REDIR: 0x4411ec0 (strlen) redirected to 0x7a62850 (strlen) --16015-- Reading syms from /usr/lib/libf5uname.so (0x7A6A000) --16015-- svma 0x0000000000, avma 0x0007A6A000 --16015-- Reading syms from /lib/tls/libc-2.3.2.so (0x7A76000) --16015-- svma 0x0000000000, avma 0x0007A76000 --16015-- Reading syms from /lib/libdl-2.3.2.so (0x7BAF000) --16015-- svma 0x0000000000, avma 0x0007BAF000 --16015-- REDIR: 0x7aed290 (rindex) redirected to 0x7a62554 (rindex) --16015-- REDIR: 0x7aee750 (memset) redirected to 0x7a63334 (memset) client request: code 4d430000, addr 0x8EE7AA0, len 262144 client request: code 4d430002, addr 0x8EE7AC0, len 4 client request: code 4d430000, addr 0x8EE7AC0, len 4 client request: code 1301, addr 0x8EE7AC4, len 8 --16015-- REDIR: 0x7aecf90 (strlen) redirected to 0x7a62834 (strlen) --16015-- REDIR: 0x7aed150 (strncmp) redirected to 0x7a62a64 (strncmp) client request: code 4d430002, addr 0x8EE7B00, len 4 client request: code 4d430000, addr 0x8EE7B00, len 4 client request: code 1301, addr 0x8EE7B04, len 33 --16015-- REDIR: 0x7aec930 (strcpy) redirected to 0x7a62888 (strcpy) --16015-- REDIR: 0x7aeecf0 (memcpy) redirected to 0x7a62b9c (memcpy) --16015-- REDIR: 0x7aed210 (strncpy) redirected to 0x7a62940 (strncpy) ==16015== Warning: set address range perms: large range 121634816 (defined) client request: code 4d430002, addr 0x8EE7B40, len 4 client request: code 4d430000, addr 0x8EE7B40, len 4 client request: code 1301, addr 0x8EE7B44, len 864 --16015-- REDIR: 0x7aebe30 (strcmp) redirected to 0x7a62ad0 (strcmp) client request: code 4d430000, addr 0x10B40000, len 114032640 ==16015== Warning: set address range perms: large range 114032640 (noaccess) client request: code 4d430002, addr 0x8EE7EC0, len 4 client request: code 4d430000, addr 0x8EE7EC0, len 4 client request: code 1301, addr 0x8EE7EC4, len 120 client request: code 4d430002, addr 0x8EE7F40, len 4 client request: code 4d430000, addr 0x8EE7F40, len 4 client request: code 1301, addr 0x8EE7F44, len 56 client request: code 4d430002, addr 0x8EE7F80, len 4 client request: code 4d430000, addr 0x8EE7F80, len 4 client request: code 1301, addr 0x8EE7F84, len 64 client request: code 4d430002, addr 0x8EE8000, len 4 client request: code 4d430000, addr 0x8EE8000, len 4 client request: code 1301, addr 0x8EE8004, len 5 client request: code 4d430002, addr 0x8EE8040, len 4 client request: code 4d430000, addr 0x8EE8040, len 4 client request: code 1301, addr 0x8EE8044, len 5 client request: code 4d430002, addr 0x8EE8080, len 4 client request: code 4d430000, addr 0x8EE8080, len 4 client request: code 1301, addr 0x8EE8084, len 6 client request: code 4d430002, addr 0x8EE80C0, len 4 client request: code 4d430000, addr 0x8EE80C0, len 4 client request: code 1301, addr 0x8EE80C4, len 5 client request: code 4d430002, addr 0x8EE8100, len 4 client request: code 4d430000, addr 0x8EE8100, len 4 client request: code 1301, addr 0x8EE8104, len 4 client request: code 4d430002, addr 0x8EE8140, len 4 client request: code 4d430000, addr 0x8EE8140, len 4 client request: code 1301, addr 0x8EE8144, len 16 client request: code 4d430002, addr 0x8EE8180, len 4 client request: code 4d430000, addr 0x8EE8180, len 4 client request: code 1301, addr 0x8EE8184, len 12 client request: code 4d430002, addr 0x8EE81C0, len 4 client request: code 4d430000, addr 0x8EE81C0, len 4 client request: code 1301, addr 0x8EE81C4, len 4 valgrind: m_mallocfree.c:210 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. valgrind: Heap block lo/hi size mismatch: lo = 1044569, hi = 0. Probably caused by overrunning/underrunning a heap block's bounds. ==16015== at 0x3801499A: report_and_quit (m_libcassert.c:140) ==16015== by 0x38014AF7: vgPlain_assert_fail (m_libcassert.c:200) ==16015== by 0x3801BD5F: vgPlain_arena_malloc (m_mallocfree.c:1144) ==16015== by 0x380133F0: vgPlain_record_ExeContext (m_execontext.c:360) ==16015== by 0x38001382: create_MC_Chunk (mc_malloc_wrappers.c:141) ==16015== by 0x3800145D: vgMemCheck_new_block (mc_malloc_wrappers.c:211) ==16015== by 0x3800A7FF: mc_handle_client_request (mc_main.c:4721) ==16015== by 0x3802C312: do_client_request (scheduler.c:1380) ==16015== by 0x3802BE1C: vgPlain_scheduler (scheduler.c:979) ==16015== by 0x3802E46C: thread_wrapper (syswrap-linux.c:89) ==16015== by 0x3802E549: run_a_thread_NORETURN (syswrap-linux.c:122) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==16015== at 0x8064912: malloc (sys.c:1191) ==16015== by 0x8064A66: realloc (sys.c:1215) ==16015== by 0x88BAA9A: tmidx_resize (libtmstat.c:340) ==16015== by 0x88BAB5F: tmidx_add (libtmstat.c:388) ==16015== by 0x88BB313: tmstat_slab_alloc (libtmstat.c:836) ==16015== by 0x88BB6B1: tmstat_row_alloc (libtmstat.c:909) ==16015== by 0x88BD4DE: tmstat_table_register (libtmstat.c:2139) ==16015== by 0x88BBD4C: tmstat_create (libtmstat.c:1261) ==16015== by 0x81395EC: init_tmstat (tmstat.c:35) ==16015== by 0x8065094: init_tmm (t.c:64) ==16015== by 0x80651EF: main (t.c:105) This is Valgrind 3.3.1. As you can see, the program has its own allocator, instrumented for Valgrind. With very slightly different command-line options (to my program), there are no problems and I can't identify any of these client requests as being nonsensical. Any clues to offer? Thank you in advance for any help. |