On Thu, 2018-04-19 at 00:39 +0000, Wuweijia wrote:
> memcheck expensive sanity: distinguished_secondaries have changed
>
> valgrind: external/valgrind/coregrind/m_scheduler/scheduler.c:2240
> (vgPlain_sanity_check_general): Assertion
> 'VG_TDICT_CALL(tool_expensive_sanity_check)' failed.
>
> host stacktrace:
> ==4540== at 0x3803AA8C: show_sched_status_wrk (m_libcassert.c:343)
> ==4540== by 0x3803AD07: report_and_quit (m_libcassert.c:419)
> ==4540== by 0x3803AD07: vgPlain_assert_fail (m_libcassert.c:485)
> ==4540== by 0x3808119B: vgPlain_sanity_check_general (scheduler.c:2240)
> ==4540== by 0x3808142F: vgPlain_scheduler (scheduler.c:1308)
> ==4540== by 0x3808E307: thread_wrapper (syswrap-linux.c:103)
> ==4540== by 0x3808E307: run_a_thread_NORETURN (syswrap-linux.c:156)
> ==4540== by 0x3808E6CF: vgModuleLocal_start_thread_NORETURN
> (syswrap-linux.c:325)
> ==4540== by 0x380B4143: ??? (in
> /system/lib64/valgrind/memcheck-arm64-linux)
>
The above is a valgrind self-check/sanity check that detects an internal
corruption in its own internal memcheck data structure.
Never seen this assert failing up to now.
This might be
* a bug in valgrind itself
* (less likely) a nasty bug in your application that succeeded
to corrupt valgrind memcheck data structures
Was there any application error reported by Valgrind before this
failing self-check ?
* (less likely?) an hardware problem, such as failing memory ?
Philippe
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
