Subject: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU

From: Dov Grobgeld <[email-masked]>
Date: Sun, 6 May 2012 10:06:13 +0300

The *input/output of a.out* is empty.

It seems that I was wrong about read_key_sequence(). It doesn't "return
early". Here is a stack trace during the timeout:

#0  0x00110424 in __kernel_vsyscall ()
#1  0x005f288d in ___newselect_nocancel () at
../sysdeps/unix/syscall-template.S:82
#2  0x08149691 in xg_select (max_fds=17, rfds=0xbfffe860, wfds=0xbfffe7e0,
efds=0x0, timeout=0xbfffe7d4) at xgselect.c:100
#3  0x0821ffb0 in wait_reading_process_output (time_limit=30, microsecs=0,
read_kbd=-1, do_display=1, wait_for_cell=138903722, wait_proc=0x0,
just_wait_proc=0) at process.c:4620
#4  0x080601c7 in sit_for (timeout=120, reading=1, do_display=1) at
dispnew.c:6068
#5  0x08159606 in read_char (commandflag=1, nmaps=3, maps=0xbfffec50,
prev_event=138903722, used_mouse_menu=0xbfffed18, end_time=0x0) at
keyboard.c:2698
#6  0x08163f12 in read_key_sequence (keybuf=0xbfffee94, bufsize=30,
prompt=138903722, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:9341
#7  0x08157472 in command_loop_1 () at keyboard.c:1455
#8  0x081d629d in internal_condition_case (bfun=0x815711b <command_loop_1>,
handlers=138934706, hfun=0x8156ad5 <cmd_error>) at eval.c:1448
#9  0x08156e49 in command_loop_2 (ignore=138903722) at keyboard.c:1160
#10 0x081d5d6f in internal_catch (tag=138932706, func=0x8156e25
<command_loop_2>, arg=138903722) at eval.c:1205
#11 0x08156e05 in command_loop () at keyboard.c:1139
#12 0x0815670e in recursive_edit_1 () at keyboard.c:759
#13 0x0815685f in Frecursive_edit () at keyboard.c:823
#14 0x08154d65 in main (argc=1, argv=0xbffff5e4) at emacs.c:1711

read_char() returns 158534621.

Sorry, I can't redistribute the executable. If the problem can't be solved
by otherwise, I'll try to generate another executable that has this
problem. In any case, here is the output when running gdb from the command
line on the executable.

> gdb -i=mi SolarJet
=thread-group-added,id="i1"
~"GNU gdb (GDB) Fedora (7.2-52.fc14)\n"
~"Copyright (C) 2010 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to
change and redistribute it.\nThere is NO WARRANTY, to the extent permitted
by law.  Type \"show copying\"\nand \"show warranty\" for details.\n"
~"This GDB was configured as \"i686-redhat-linux-gnu\".\nFor bug reporting
instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>...\n"
~"Reading symbols from
/mnt/fdrive/git/SolarJet/Apps/SolarJet/Project/qt/BinLinux32/SolarJet..."
~"done.\n"
(gdb)

Thanks,
Dov

On Sun, May 6, 2012 at 8:39 AM, Chong Yidong <[email-masked]> wrote:

> Dov Grobgeld <[email-masked]> writes:
>
> > Please let me know if there are any tests or debug info that I can
> > provide you with that can help in resolving this issue. I tried
> > debugging it myself, but I found it to complex since I lack the
> > knowledge of how sub-processes are handled in emacs.
>
> If you look at the *input/output of a.out* buffer, does it contain any
> text?
>
> Also, when you say that read_key_sequence keeps returning, what is its
> return value?  Also, when read_key_sequence returns early, what is the
> value returned by read_char at keyboard.c:9341?
>
> Also, is it possible for you to provide a copy of the problematic
> program, or is it not allowed?
>