3.16.1 is fairly old, can you try something more recent?

Docker doesn't seem to be a good environment for running Valgrind. I've never used it but I keep hearing of problems. I don't think that Docker does a good enough job of virtualizaton. Valgrind works better either on a real OS or on full virtualization systems like VirtualBox and VMware.

Of course, I have just repeated the same steps with ver 3.22.0, but unfortunately the outcome remains the same, albeit a bit more detailed.


==10121== Command: ./test
==10121==

valgrind: m_scheduler/scheduler.c:1730 (vgPlain_scheduler): the 'impossible' happened.
valgrind: VG_(scheduler), phase 3: run_innerloop detected host state invariant failure

host stacktrace:
==10121==    at 0x5803B997: show_sched_status_wrk (m_libcassert.c:407)
==10121==    by 0x5803BAD0: report_and_quit (m_libcassert.c:478)
==10121==    by 0x5803BBC4: vgPlain_assert_fail (m_libcassert.c:544)
==10121==    by 0x580951C8: vgPlain_scheduler (scheduler.c:1757)
==10121==    by 0x580E615E: thread_wrapper (syswrap-linux.c:102)
==10121==    by 0x580E615E: run_a_thread_NORETURN (syswrap-linux.c:155)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 10121)
==10121==    at 0x40023FD: handle_preload_list (rtld.c:902)
==10121==    by 0x4005541: dl_main (rtld.c:1735)
==10121==    by 0x401A055: _dl_sysdep_start (dl-sysdep.c:252)
==10121==    by 0x4001FEC: _dl_start_final (rtld.c:485)
==10121==    by 0x4001FEC: _dl_start (rtld.c:575)
==10121==    by 0x40010BA: ??? (in /lib/i386-linux-gnu/ld-2.31.so)
client stack range: [0x3F7FF000 0x3F800FFF] client SP: 0x3F7FFA60
valgrind stack range: [0x2326F000 0x2336EFFF] top usage: 6792 of 1048576


I know containerization poses some challenges, but I am trying to work with as little disk space as possible.

(In reply to railway_bylaws.0b from comment #2)
> Of course, I have just repeated the same steps with ver 3.22.0, but
> unfortunately the outcome remains the same, albeit a bit more detailed.
> 
> 
> ==10121== Command: ./test
> ==10121==
> 
> valgrind: m_scheduler/scheduler.c:1730 (vgPlain_scheduler): the 'impossible'
> happened.
> valgrind: VG_(scheduler), phase 3: run_innerloop detected host state
> invariant failure
> 
> host stacktrace:
> ==10121==    at 0x5803B997: show_sched_status_wrk (m_libcassert.c:407)
> ==10121==    by 0x5803BAD0: report_and_quit (m_libcassert.c:478)
> ==10121==    by 0x5803BBC4: vgPlain_assert_fail (m_libcassert.c:544)
> ==10121==    by 0x580951C8: vgPlain_scheduler (scheduler.c:1757)
> ==10121==    by 0x580E615E: thread_wrapper (syswrap-linux.c:102)
> ==10121==    by 0x580E615E: run_a_thread_NORETURN (syswrap-linux.c:155)
> 
> sched status:
>   running_tid=1
> 
> Thread 1: status = VgTs_Runnable (lwpid 10121)
> ==10121==    at 0x40023FD: handle_preload_list (rtld.c:902)
> ==10121==    by 0x4005541: dl_main (rtld.c:1735)
> ==10121==    by 0x401A055: _dl_sysdep_start (dl-sysdep.c:252)
> ==10121==    by 0x4001FEC: _dl_start_final (rtld.c:485)
> ==10121==    by 0x4001FEC: _dl_start (rtld.c:575)
> ==10121==    by 0x40010BA: ??? (in /lib/i386-linux-gnu/ld-2.31.so)
> client stack range: [0x3F7FF000 0x3F800FFF] client SP: 0x3F7FFA60
> valgrind stack range: [0x2326F000 0x2336EFFF] top usage: 6792 of 1048576
> 
> 
> I know containerization poses some challenges, but I am trying to work with
> as little disk space as possible.

I forgot to stress that the issue only presents itself when compiling with the -m32 flag, valgrind behaves as expected otherwise, even in a containerized environment.

Can you provide an exe that reproduces the problem?

As far as I know none of the Valgrind developers use Docker, and x86 isn't actively supported, so there's not much chance of this being fixed.

It might help if you could build Valgrind from source and get a proper stacktrace from Valgrind. Many Linux packagers have decided that they know better than the Valgrind developers and they strip the Valgrind bninaries.

Various x86_64 (amd64) builders on builder.sourceware.org are docker based. I think valgrind works fine under a linux container/docker setup. But none of them run x86 (32bit).

The comments around the assert read:

      case VG_TRC_INVARIANT_FAILED:
         /* This typically happens if, after running generated code,
            it is detected that host CPU settings (eg, FPU/Vector
            control words) are not as they should be.  Vex's code
            generation specifies the state such control words should
            be in on entry to Vex-generated code, and they should be
            unchanged on exit from it.  Failure of this assertion
            usually means a bug in Vex's code generation. */
         //{ UInt xx;
         //  __asm__ __volatile__ (
         //     "\t.word 0xEEF12A10\n"  // fmrx r2,fpscr
         //     "\tmov %0, r2" : "=r"(xx) : : "r2" );
         //  VG_(printf)("QQQQ new fpscr = %08x\n", xx);
         //}
         vg_assert2(0, "VG_(scheduler), phase 3: "
                       "run_innerloop detected host "
                       "state invariant failure", trc);