[Bug threads/21324] New: gdb hangs when 'thread apply all bt full' is used

["brian at ubuntu dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21324

            Bug ID: 21324
           Summary: gdb hangs when 'thread apply all bt full' is used
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: critical
          Priority: P2
         Component: threads
          Assignee: unassigned at sourceware dot org
          Reporter: brian at ubuntu dot com
  Target Milestone: ---

I run a service which does automated retracing of crashes from Ubuntu systems
and discovered that gdb was hanging (using 100% CPU and not returning anything)
when retracing crashes from vim on Ubuntu 16.10.

I can recreate this by running 'thread apply all bt full' (or 'thread apply 3
bt full' in this case) which then prints only the following:

  Thread 3 (Thread 0x7ff4636a8700 (LWP 7203)):

I tried using strace on the gdb process but only received:

 $ sudo strace -p 16418                                                         
 strace: Process 16418 attached
 strace: [ Process PID=16418 runs in x32 mode. ]

I've seen this behavior with these versions of gdb:

GNU gdb (Ubuntu 7.12.50.20170314-0ubuntu1) 7.12.50.20170314-git
GNU gdb (Ubuntu 7.11.90.20161005-0ubuntu1) 7.11.90.20161005-git
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1

I also tried a 7.9 version of gdb and that produced a backtrace.

GNU gdb (Ubuntu 7.9-1ubuntu1) 7.9

The backtrace:

Thread 2 (LWP 3015):
#0  0x00007fe23ecc9ea3 in select () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1  0x00007fe23f27ae48 in time_sleep () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#2  0x00007fe23f353427 in PyEval_EvalFrameEx () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#3  0x00007fe23f413a74 in _PyEval_EvalCodeWithName.lto_priv.1712 () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#4  0x00007fe23f413b53 in PyEval_EvalCodeEx () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#5  0x00007fe23f295e25 in function_call.lto_priv () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#6  0x00007fe23f383457 in PyObject_Call () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#7  0x00007fe23f34c3c7 in PyEval_EvalFrameEx () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#8  0x00007fe23f35364b in PyEval_EvalFrameEx () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#9  0x00007fe23f35364b in PyEval_EvalFrameEx () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#10 0x00007fe23f413a74 in _PyEval_EvalCodeWithName.lto_priv.1712 () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#11 0x00007fe23f413b53 in PyEval_EvalCodeEx () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#12 0x00007fe23f295d28 in function_call.lto_priv () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#13 0x00007fe23f383457 in PyObject_Call () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#14 0x00007fe23f3cfb0c in method_call.lto_priv () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#15 0x00007fe23f383457 in PyObject_Call () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#16 0x00007fe23f412577 in PyEval_CallObjectWithKeywords () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#17 0x00007fe23f32c0e2 in t_bootstrap () from
/tmp/apport_sandbox_kH9R1m/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
No symbol table info available.
#18 0x00007fe23ef9a6ca in start_thread (arg=0x7fe23a74f700) at
pthread_create.c:333
        __res = <optimized out>
        pd = 0x7fe23a74f700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140609620080384,
-1451514129212077889, 0, 140725579832159, 140609620081088, 140609620080384,
1449978205402990783, 1449968195707373759}, mask_was_saved = 0}}, priv = {pad =
{0x0, 0x0,
              0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#19 0x00007fe23ecd40af in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:105
No locals.

While I have many different core files that produce this behavior, I don't want
to make them publicly available since it isn't my data. I am happy to any
required debugging.

For completeness here is the full gdb command:

/usr/bin/gdb --ex 'set debug-file-directory
/mnt/sec-machines/apport-sandbox-dir/Ubuntu
16.10/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute-prefix
/mnt/sec-machines/apport-sandbox-dir/Ubuntu 16.10/amd64/report-sandbox' --ex
'add-auto-load-safe-path /mnt/sec-machines/apport-sandbox-dir/Ubuntu
16.10/amd64/report-sandbox' --ex 'set solib-search-path
/mnt/sec-machines/apport-sandbox-dir/Ubuntu
16.10/amd64/report-sandbox/lib/x86_64-linux-gnu' --ex 'file
"/mnt/sec-machines/apport-sandbox-dir/Ubuntu
16.10/amd64/report-sandbox//usr/bin/vim.gtk"' --ex 'core-file
/tmp/apport_core_vx39d9bm'

I used "Critical" for the severity since "Serious" wasn't available.

-- 
You are receiving this mail because:
You are on the CC list for the bug.