bug#9720: gdb-mi hangs

bug#9720: gdb-mi hangs

[Michael Veksler]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

Hello,

The behavior I see seems to be related to bug 6962. I attach a backtrace 
of the emacs process.

While trying out the latest emacs from the git repository (similarly, 
gdb from git) I encountered an hang. This happens when I debug my C++ 
code under the new gdb-mi interface.


I am no git expert and can't tell you the exact version of emacs. The 
last commit on my sandbox repository is:

commit 520888a9da6c3c27122c2597f757e88c81b97989
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Fri Oct 7 00:23:44 2011 -0700

The hang happens when the inferior terminates.

Sometimes it helps to kill the GDB process and press ctrl-g. It did not 
help this time.

---

Thanks

Michael


[-- Attachment #2: trace --]
[-- Type: text/plain, Size: 3534 bytes --]

(gdb) bt
#0  0x00000035874d9073 in __select_nocancel ()
    at ../sysdeps/unix/syscall-template.S:82
#1  0x00000000004ec183 in xg_select (max_fds=9, rfds=0x7fff5de2b3f0, wfds=
    0x7fff5de2b370, efds=0x0, timeout=0x7fff5de2b550) at xgselect.c:100
#2  0x00000000005addb5 in wait_reading_process_output (time_limit=-1, 
    microsecs=0, read_kbd=0, do_display=0, wait_for_cell=11942274, wait_proc=
    0x3846cb0, just_wait_proc=0) at process.c:4599
#3  0x00000000005b09be in Faccept_process_output (process=59010229, 
    seconds=<value optimized out>, millisec=<value optimized out>, 
    just_this_one=<value optimized out>) at process.c:3985
#4  0x000000000056f2fb in Ffuncall (nargs=<value optimized out>, 
    args=<value optimized out>) at eval.c:2985
#5  0x00000000005a8376 in exec_byte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=<value optimized out>, 
    args_template=<value optimized out>, nargs=<value optimized out>, 
    args=<value optimized out>) at bytecode.c:785
#6  0x000000000056e764 in eval_sub (form=<value optimized out>) at eval.c:2328
#7  0x00000000005719fc in internal_lisp_condition_case (var=11942274, bodyform=
    58333670, handlers=58333798) at eval.c:1453
#8  0x00000000005a7a25 in exec_byte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=<value optimized out>, 
    args_template=<value optimized out>, nargs=<value optimized out>, 
    args=<value optimized out>) at bytecode.c:981
#9  0x000000000056ed4a in funcall_lambda (fun=58406821, nargs=0, arg_vector=
    0x7fff5de2bb88) at eval.c:3205
#10 0x000000000056f16b in Ffuncall (nargs=1, args=0x7fff5de2bb80)
    at eval.c:3035
---Type <return> to continue, or q <return> to quit---
#11 0x00000000005a8376 in exec_byte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=<value optimized out>, 
    args_template=<value optimized out>, nargs=<value optimized out>, 
    args=<value optimized out>) at bytecode.c:785
#12 0x000000000056ed4a in funcall_lambda (fun=58389461, nargs=0, arg_vector=
    0x7fff5de2bd50) at eval.c:3205
#13 0x000000000056f16b in Ffuncall (nargs=1, args=0x7fff5de2bd48)
    at eval.c:3035
#14 0x000000000056f5d8 in call0 (fn=58359826) at eval.c:2728
#15 0x000000000056d481 in internal_condition_case (bfun=
    0x4f97f0 <safe_run_hooks_1>, handlers=11942322, hfun=
    0x4faef0 <safe_run_hooks_error>) at eval.c:1499
#16 0x00000000004fae9a in safe_run_hook_funcall (nargs=<value optimized out>, 
    args=<value optimized out>) at keyboard.c:1921
#17 0x000000000056dafc in run_hook_with_args (nargs=1, args=0x7fff5de2bf38, 
    funcall=0x4fae60 <safe_run_hook_funcall>) at eval.c:2680
#18 0x00000000004fc66f in safe_run_hooks (hook=58359826) at keyboard.c:1938
#19 0x000000000050866e in command_loop_1 () at keyboard.c:1356
#20 0x000000000056d481 in internal_condition_case (bfun=
    0x507660 <command_loop_1>, handlers=11994418, hfun=0x4fc4b0 <cmd_error>)
    at eval.c:1499
#21 0x00000000004faede in command_loop_2 (ignore=<value optimized out>)
    at keyboard.c:1158
#22 0x000000000056d368 in internal_catch (tag=Cannot access memory at address 0xffffffffffffffea
) at eval.c:1256
#23 0x00000000004fbf6a in command_loop () at keyboard.c:1137
#24 recursive_edit_1 () at keyboard.c:757
#25 0x00000000004fc2ac in Frecursive_edit () at keyboard.c:821
---Type <return> to continue, or q <return> to quit---
#26 0x00000000004f6a40 in main (argc=<value optimized out>, 
    argv=<value optimized out>) at emacs.c:1706
(gdb) 

bug#9720: gdb-mi hangs

[Glenn Morris]

I think this might have been fixed by the fix for bug#9839.
Please try the Emacs trunk or the 24.0.91 pretest when it appears and
let us know if you still see this issue.

bug#9720: gdb-mi hangs

[Michael Veksler]

Hello,

On 10/29/2011 02:19 AM, Glenn Morris wrote:
> I think this might have been fixed by the fix for bug#9839.
> Please try the Emacs trunk or the 24.0.91 pretest when it appears and
> let us know if you still see this issue.
>
I am not 100% positive whether this fixed the issue or not. I am no 
longer able to
reproduce the exact scenario with the older emacs. When I try then emacs 
takes
100% CPU but no longer hang, which is similar but not identical to the 
reported
issue.

With the newest emacs from git, it no longer takes 100% CPU when the 
inferior
terminates. This is a substantial improvement but I am not sure that the 
update
fixes the same bug I previously saw. I suspect that there were two 
related bugs,
and the developers fixed the bug that used to trigger the second one. It 
is just
a hunch; I can't back it up.

I'll work with the newer emacs and report if the issue recurs.

--
Michael