https://bugs.kde.org/show_bug.cgi?id=372504

            Bug ID: 372504
           Summary: Hanging on exit_group
           Product: valgrind
           Version: 3.12 SVN
          Platform: Compiled Sources
                OS: Linux
            Status: UNCONFIRMED
          Severity: grave
          Priority: NOR
         Component: general
          Assignee: jsew...@acm.org
          Reporter: david.hag...@cobham.com
  Target Milestone: ---

I have a set of programs I am trying to debug an issue with, that I think may
be a memory bounds error. I am trying to use Valgrind to debug this, but it
introduces its own error - it won't terminate when the program does. The
program calls exit_group, and then valgrind just goes into a 100% CPU loop.

I'm a bit limited in what I can share about the programs, but:
1) Valgrind works fine for trivial programs such as /bin/true
2) It doesn't seem to matter what tool I pick: DRD, none, memcheck.
3) It is 100% repeatable on the programs I need to debug.
4) I've pulled down the latest released Valgrind sources (3.12.0) and built
them - no change.
5) It always ends the same way:

 --22893--   SCHED[1]: TRC: CHAIN_ME_FAST
--22893--   SCHED[1]: TRC: CHAIN_ME_FAST
--22893--   SCHED[1]: TRC: CHAIN_ME_FAST
--22893--   SCHED[1]: TRC: CHAIN_ME_FAST
--22893--   SCHED[1]: TRC: CHAIN_ME_SLOW
--22893--   SCHED[1]: TRC: CHAIN_ME_FAST
--22893--   SCHED[1]: TRC: CHAIN_ME_FAST
--22893--   SCHED[1]: TRC: FASTMISS
--22893--   SCHED[1]: TRC: CHAIN_ME_FAST
--22893--   SCHED[1]: TRC: SYSCALL
SYSCALL[22893,1](231) exit_group( 0 )--22893-- get_thread_out_of_syscall zaps
tid 2 lwp 22894
--22893-- get_thread_out_of_syscall zaps tid 3 lwp 22895
--22893--   SCHED[1]: releasing lock (VG_(vg_yield)) -> VgTs_Yielding
--22893--   SCHED[1]:  acquired lock (VG_(vg_yield))
--22893--   SCHED[1]: releasing lock (VG_(vg_yield)) -> VgTs_Yielding
--22893--   SCHED[1]:  acquired lock (VG_(vg_yield))
--22893--   SCHED[1]: releasing lock (VG_(vg_yield)) -> VgTs_Yielding
--22893--   SCHED[1]:  acquired lock (VG_(vg_yield))
--22893--   SCHED[1]: releasing lock (VG_(vg_yield)) -> VgTs_Yielding
--22893--   SCHED[1]:  acquired lock (VG_(vg_yield))
--22893--   SCHED[1]: releasing lock (VG_(vg_yield)) -> VgTs_Yielding
--22893--   SCHED[1]:  acquired lock (VG_(vg_yield))
--22893--   SCHED[1]: releasing lock (VG_(vg_yield)) -> VgTs_Yielding
--22893--   SCHED[1]:  acquired lock (VG_(vg_yield))
--22893--   SCHED[1]: releasing lock (VG_(vg_yield)) -> VgTs_Yielding
--22893--   SCHED[1]:  acquired lock (VG_(vg_yield))
--22893--   SCHED[1]: releasing lock (VG_(vg_yield)) -> VgTs_Yielding
--22893--   SCHED[1]:  acquired lock (VG_(vg_yield))
--22893--   SCHED[1]: releasing lock (VG_(vg_yield)) -> VgTs_Yielding
--22893--   SCHED[1]:  acquired lock (VG_(vg_yield))
--22893--   SCHED[1]: releasing lock (VG_(vg_yield)) -> VgTs_Yielding
--22893--   SCHED[1]:  acquired lock (VG_(vg_yield))
<repeat until kill -9>

6) It always is spinning in the same area:
#0  0x0000000038056bf9 in do_syscall_WRK ()
#1  0x0000000038056d52 in vgPlain_do_syscall (sysno=sysno@entry=128,
a1=a1@entry=34520677520, a2=a2@entry=34520677552, a3=a3@entry=941228976,
a4=a4@entry=8, a5=a5@entry=0, a6=a6@entry=0, a7=a7@entry=0,
    a8=a8@entry=0) at m_syscall.c:956
#2  0x000000003804321c in vgPlain_sigtimedwait_zero (set=set@entry=0x80997bc90,
info=info@entry=0x80997bcb0) at m_libcsignal.c:420
#3  0x0000000038055be3 in vgPlain_poll_signals (tid=tid@entry=1) at
m_signals.c:2962
#4  0x0000000038099714 in vgPlain_reap_threads (self=self@entry=1) at
m_syswrap/syswrap-generic.c:2828
#5  0x00000000380a282b in vgSysWrap_linux_sys_exit_group_before (tid=1,
layout=0x80997bdd0, arrghs=0x80237aff8, status=0x80237b040, flags=<optimized
out>) at m_syswrap/syswrap-linux.c:777
#6  0x00000000380935c0 in vgPlain_client_syscall (tid=tid@entry=1,
trc=trc@entry=73) at m_syswrap/syswrap-main.c:1906
#7  0x0000000038090193 in handle_syscall (tid=tid@entry=1, trc=73) at
m_scheduler/scheduler.c:1118
#8  0x0000000038091757 in vgPlain_scheduler (tid=tid@entry=1) at
m_scheduler/scheduler.c:1435
#9  0x00000000380a0beb in thread_wrapper (tidW=1) at
m_syswrap/syswrap-linux.c:103
#10 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:156

It always thinks there are threads running. However, it never allows anything
to run so the thread can never terminate.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to