|
From: Jeroen N. W. <jn...@xs...> - 2005-12-08 20:45:54
|
Greetings, Recently I started getting a regression test error in memcheck/tests/mempool, the bottom line being "INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting". However, memchecking mempool outside of the regression test did *not* reproduce the problem. Using selfhosting, running memcheck on memcheck running mempool resulted in this error report: 4: ==7238== Invalid read of size 4 4: ==7238== at 0xA00117FE: vgPlain_HT_destruct (m_hashtable.c:241) 4: ==7238== by 0xA000219A: vgMAC_destroy_mempool (mac_malloc_wrappers.c:458) 4: ==7238== by 0xA000814A: vgMAC_handle_common_client_requests (mac_shared.c:1018) 4: ==7238== by 0xA0006078: mc_handle_client_request (mc_main.c:2501) 4: ==7238== by 0xA00364AC: do_client_request (scheduler.c:1106) 4: ==7238== by 0xA0035B18: vgPlain_scheduler (scheduler.c:721) 4: ==7238== by 0xA004A0CE: thread_wrapper (syswrap-linux.c:86) 4: ==7238== by 0xA004A1E5: run_a_thread_NORETURN (syswrap-linux.c:119) 4: ==7238== Address 0x518565F0 is not stack'd, malloc'd or (recently) free'd [The prefix '4: ' indicates that this report originated in the outer valgrind/memcheck.] Any thoughts? Jeroen. |
|
From: Robert W. <rj...@du...> - 2005-12-08 20:53:59
|
> Recently I started getting a regression test error in > memcheck/tests/mempool, the bottom line being "INTERNAL ERROR: Valgrind > received a signal 11 (SIGSEGV) - exiting". Yup - I just noticed this yesterday. Hopefully I'll have some time tomorrow or over the weekend to fix this up. Regards, Robert. |
|
From: Julian S. <js...@ac...> - 2005-12-09 02:00:52
|
I looked briefly at this but got lost in the hash table stuff. I believe it may be some problem with freeing hash table components or some such in the wrong order, or at the wrong time. The bug has been there for a while, but only recently started producing segfaults, following a change in VG_(arena_free) to fill up freed memory with junk. J On Thursday 08 December 2005 20:53, Robert Walsh wrote: > > Recently I started getting a regression test error in > > memcheck/tests/mempool, the bottom line being "INTERNAL ERROR: Valgrind > > received a signal 11 (SIGSEGV) - exiting". > > Yup - I just noticed this yesterday. Hopefully I'll have some time > tomorrow or over the weekend to fix this up. > > Regards, > Robert. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <nj...@cs...> - 2005-12-08 21:03:35
|
On Thu, 8 Dec 2005, Jeroen N. Witmond wrote: > Recently I started getting a regression test error in > memcheck/tests/mempool, the bottom line being "INTERNAL ERROR: Valgrind > received a signal 11 (SIGSEGV) - exiting". However, memchecking mempool > outside of the regression test did *not* reproduce the problem. > > Using selfhosting, running memcheck on memcheck running mempool resulted > in this error report: > 4: ==7238== Invalid read of size 4 > 4: ==7238== at 0xA00117FE: vgPlain_HT_destruct (m_hashtable.c:241) > 4: ==7238== by 0xA000219A: vgMAC_destroy_mempool > (mac_malloc_wrappers.c:458) > 4: ==7238== by 0xA000814A: vgMAC_handle_common_client_requests > (mac_shared.c:1018) > 4: ==7238== by 0xA0006078: mc_handle_client_request (mc_main.c:2501) > 4: ==7238== by 0xA00364AC: do_client_request (scheduler.c:1106) > 4: ==7238== by 0xA0035B18: vgPlain_scheduler (scheduler.c:721) > 4: ==7238== by 0xA004A0CE: thread_wrapper (syswrap-linux.c:86) > 4: ==7238== by 0xA004A1E5: run_a_thread_NORETURN (syswrap-linux.c:119) > 4: ==7238== Address 0x518565F0 is not stack'd, malloc'd or (recently) free'd > > [The prefix '4: ' indicates that this report originated in the outer > valgrind/memcheck.] > > Any thoughts? Keep going! It looks like you're really close to isolating the bug :) Nick |