Re: [Valgrind-developers] Hang in err_disable4

[Philippe W. <phi...@sk...>]

Are there some other threads still alive when the process hangs ?
What are these threads doing ?

Would be nice to re-run with more trace (-v -v -v -d -d -d --trace-sched=yes)
and see how has last acquired the lock without releasing it 

Philippe


On Sun, 2020-03-29 at 16:27 +0200, Paul FLOYD wrote:
> Hi
>  
> I'm trying to debug this regtest on FreeBSD. The test has functions main, fn1 anf fn2.
> main: creates a load of fn1 threads
> fn1: function disables error reporting then waits on a semaphore
> main: post semaphore
> fn1: drop off end and terminate
> main: join fn1 threads
> main: and created another load of threads, fn2 this time
> fn2: read from feed memory then waits on the semaphore
> main: semaphore post
> fn2: drop off end and terminate
> main: join threads
> main: status reporting
>  
> The callstack where memcheck is hanging is
>  
> * frame #0: 0x0000000038088b92 memcheck-amd64-freebsd`do_syscall_WRK at m_syscall.c:383:1 frame #1: 0x0000000038088c2e memcheck-amd64-freebsd`vgPlain_do_syscall(sysno=3, a1=469737, a2=17224604422, a3=1, a4=0, a5=0, a6=0, a7=0, a8=0) at m_syscall.c:1097:10 frame #2: 0x0000000038070776 memcheck-amd64-freebsd`vgPlain_read(fd=469737, buf=0x0000000402aa9b06, count=1) at m_libcfile.c:247:17 frame #3: 0x0000000038173292 memcheck-amd64-freebsd`vgModuleLocal_sema_down(sema=0x0000000402006640, as_LL='\0') at sema.c:107:10 frame #4: 0x0000000038172f2a memcheck-amd64-freebsd`acquire_sched_lock(p=0x0000000402006640) at sched-lock-generic.c:69:4 frame #5: 0x0000000038172e7b memcheck-amd64-freebsd`vgModuleLocal_acquire_sched_lock(p=0x0000000402006640) at sched-lock.c:88:26 frame #6: 0x00000000380e6a7c memcheck-amd64-freebsd`vgPlain_acquire_BigLock_LL(who=0x0000000000000000) at scheduler.c:425:4 frame #7: 0x00000000380e6659 memcheck-amd64-freebsd`vgPlain_acquire_BigLock(tid=1, who="VG_(vg_yield)") at scheduler.c:349:4 frame #8: 0x00000000380e6e4f memcheck-amd64-freebsd`vgPlain_vg_yield at scheduler.c:530:4 frame #9: 0x00000000380ee88c memcheck-amd64-freebsd`vgPlain_post_syscall(tid=1) at syswrap-main.c:2470:7 frame #10: 0x00000000380ee326 memcheck-amd64-freebsd`vgPlain_client_syscall(tid=1, trc=73) at syswrap-main.c:2351:4 frame #11: 0x00000000380e86e2 memcheck-amd64-freebsd`handle_syscall(tid=1, trc=73) at scheduler.c:1211:4 frame #12: 0x00000000380e90b3 memcheck-amd64-freebsd`vgPlain_scheduler(tid=1) at scheduler.c:1529:3 frame #13: 0x0000000038100540 memcheck-amd64-freebsd`thread_wrapper(tidW=1) at syswrap-freebsd.c:95:10 frame #14: 0x00000000381006bc memcheck-amd64-freebsd`run_a_thread_NORETURN(tidW=1) at syswrap-freebsd.c:133:10
>  
> I'm seeing the process waiting in the read syscall to the semaphore pipe. What I don't understand is how the main thread is supposed to execute at this point in order for the semaphore to signal. Does anyone have some light to shine on how this should work?
>  
> Possibly related, I'm also seeing sanity check errors with this case, after the mmap.
>  
> A+
> Paul
>  
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers