| Summary: | The 'impossible' happened | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | M Welinder <mwelinder> |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | ||
| Priority: | NOR | ||
| Version: | 3.2.3 | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | Full valgrind log | ||
This is a duplicate of another bug that we've closed, but unfortunately I can't find the original now. It turns out to be a bug in certain Linux kernel versions on x86_64, which did not completely accurately preserve process' floating point state across context switches. Valgrind periodically checks that the FPU state (precision?) is what it set it to, and asserts when it sees an "unexpected" change (on the basis that it is buggy code generation on Valgrind's part, whereas in reality the kernel messed up). Probably bug 143888. *** This bug has been marked as a duplicate of bug 143888 *** |
Created attachment 28986 [details] Full valgrind log 1. In Emacs, please 10000 copies of "xxxxxxxxxx " on one long line. 2. valgrind bash 3. Paste the line from Emacs into bash ==> valgrind: m_scheduler/scheduler.c:996 (vgPlain_scheduler): the 'impossible' happened. valgrind: VG_(scheduler), phase 3: run_innerloop detected host state invariant failure ==20519== at 0x380193CA: report_and_quit (m_libcassert.c:136) ==20519== by 0x3801963D: vgPlain_assert_fail (m_libcassert.c:200) ==20519== by 0x3803A262: vgPlain_scheduler (scheduler.c:994) ==20519== by 0x3804D17F: thread_wrapper (syswrap-linux.c:87) ==20519== by 0x3804D276: run_a_thread_NORETURN (syswrap-linux.c:120) This has been observed with valgrind 3.2.3 and 3.3.0 The machine is x86_64. Bash is 3.1.16(1)-release. Distribution is SuSE 10.1. Valgrind is self-compiled; configure line had only a --prefix option.