[Bug gdb/9988] New: case of endless looping in buildsym.c

[Bug gdb/9988] New: case of endless looping in buildsym.c

[a-gdb at nphiuu dot mine dot nu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7214 bytes --]

Processing of a datastructure in buildsym.c can be endless.

Environment: GNU/Linux SUSE on Intel and Z/Linux.
glibc-2.4-31.30
Custom compiled GDB 6.8.

A case was encountered in which an endless loop occurs in buildsym.c.  The loop
handles a datastructure. Breaking upon certain values occuring in the
datastructure showed the same value(s) recurring as the current. Left to run
over a weekend, the loop continued. The effect in use was that single stepping
at a certain location through the C code of the subject program, GDB would enter
the loop and not return.  The problem loop in GDB was found by running GDB in GDB.

The terminal code being debugged was a 60 to 90 MB C library with a loop of
linked functions. An attempt produce a simple test case failed.  Below is
information from GDB about GDB at the place of the loop:  the code and stack trace.

   ¦955               while (pbnext)                                           
                                       ¦
   ¦956                 {                                                      
                                       ¦
   ¦957                   /* swap blocks if unordered! */                      
                                       ¦
   ¦958                                                                        
                                       ¦
B+>¦959                   if (BLOCK_START (pb->block) < BLOCK_START
(pbnext->block))                                   ¦
   ¦960                     {                                                  
                                       ¦
   ¦961                       struct block *tmp = pb->block;                   
                                       ¦
   ¦962                       pb->block = pbnext->block;                       
                                       ¦
   ¦963                       pbnext->block = tmp;                             
                                       ¦
   ¦964                       swapped = 1;                                     
                                       ¦
   ¦965                     }                                                  
                                       ¦
   ¦966                   pb = pbnext;                                         
                                       ¦
   ¦967                   pbnext = pbnext->next;                               
                                       ¦
   ¦968                 }

#0  end_symtab (end_addr=3056981531, objfile=0x8832308, section=9) at buildsym.c:959
#1  0x08166419 in psymtab_to_symtab_1 (pst=0xaf8ef48) at dwarf2read.c:2644
#2  0x081665f1 in dwarf2_psymtab_to_symtab (pst=0x8838620) at dwarf2read.c:2373
#3  0x08110376 in psymtab_to_symtab (pst=0x8838620) at symfile.c:286
#4  0x0810c2db in lookup_symbol_aux_psymtabs (block_index=0, name=0xbffccd80
"if_FO_10001_82344", linkage_name=0x0,
    domain=VAR_DOMAIN, symtab=0x0) at symtab.c:1451
#5  0x081b172d in lookup_symbol_file (name=0xbffccd80 "if_FO_10001_82344",
linkage_name=0x0, block=0xad35b8c,
    domain=VAR_DOMAIN, symtab=0x0, anonymous_namespace=0) at cp-namespace.c:492
#6  0x081b17c3 in cp_lookup_symbol_namespace (namespace=0xbffcccd0 "",
name=0xbffccd80 "if_FO_10001_82344",
    linkage_name=0x0, block=0xad35b8c, domain=VAR_DOMAIN, symtab=0x0) at
cp-namespace.c:452
#7  0x081b19ee in lookup_namespace_scope (name=0xbffccd80 "if_FO_10001_82344",
linkage_name=0x0, block=0xad35b8c,
    domain=VAR_DOMAIN, symtab=0x0, scope=0x827a7c0 "", scope_len=0) at
cp-namespace.c:396
#8  0x0810c82f in lookup_symbol_in_language (name=0xbffccd80
"if_FO_10001_82344", block=0xad35b8c, domain=VAR_DOMAIN,
    lang=language_cplus, is_a_field_of_this=0x0, symtab=0x0) at symtab.c:1218
#9  0x0810c929 in lookup_symbol (name=0xb5cf4963 "?\006", block=0xb5cf4963,
domain=3050260835,
    is_a_field_of_this=0xb5cf4963, symtab=0xb5cf4963) at symtab.c:1161
#10 0x08185d4b in find_imps (symtab=0x0, block=0xb5cf4963, method=0x834612b
"if_FO_10001_82344", syms=0x0,
    nsym=0xbffcce20, ndebug=0xbffcce24) at objc-lang.c:1275
#11 0x08118848 in decode_objc (argptr=0xbffcd064, funfirstline=1,
file_symtab=0x0, canonical=0xbffcd060,
    saved_arg=0x834612b "if_FO_10001_82344") at linespec.c:1102
#12 0x08119708 in decode_line_1 (argptr=0xbffcd064, funfirstline=1,
default_symtab=0xafd9c64, default_line=861430,
    canonical=0xbffcd060, not_found_ptr=0xbffcd05c) at linespec.c:726
#13 0x080e6274 in do_captured_parse_breakpoint (ui=0x837abc0, data=0xb5cf4963)
at breakpoint.c:5174
#14 0x0812c412 in catch_exception (uiout=0x837abc0, func=0x80e60a0
<do_captured_parse_breakpoint>,
    func_args=0xbffcd0a0, mask=-1244706461) at exceptions.c:467
#15 0x080e6670 in break_command_really (arg=0x834612b "if_FO_10001_82344",
cond_string=0x0, thread=0,
    parse_condition_and_thread=1, tempflag=0, hardwareflag=0, ignore_count=0,
pending_break_support=AUTO_BOOLEAN_AUTO,
    from_tty=1) at breakpoint.c:5308
#16 0x080e6d55 in break_command_1 (arg=0xb5cf4963 "?\006", flag=243403148,
from_tty=243403052) at breakpoint.c:5462
#17 0x08085c16 in execute_command (p=0x834613b "4", from_tty=1) at top.c:449
#18 0x08130327 in command_handler (command=0x8346128 "b  if_FO_10001_82344") at
event-top.c:518
#19 0x08130837 in command_line_handler (rl=0xa3dc098 "b  if_FO_10001_82344") at
event-top.c:810
#20 0x081dfaf8 in rl_callback_read_char () at callback.c:205
#21 0x0812fc8b in rl_callback_read_char_wrapper (client_data=0x0) at event-top.c:177
#22 0x0812f4ea in handle_file_event (event_file_desc=-1244706461) at
event-loop.c:728
#23 0x0812efa2 in process_event () at event-loop.c:341
#24 0x0812f805 in gdb_do_one_event (data=0x0) at event-loop.c:378
#25 0x0812c62b in catch_errors (func=0x812f6d0 <gdb_do_one_event>,
func_args=0x0, errstring=0x827a7c0 "",
    mask=-1244706461) at exceptions.c:513
#26 0x080d1884 in tui_command_loop (data=0x0) at .././gdb/tui/tui-interp.c:153
#27 0x0812c92c in current_interp_command_loop () at interps.c:276
#28 0x0807f15b in captured_command_loop (data=0x0) at .././gdb/main.c:99
#29 0x0812c62b in catch_errors (func=0x807f150 <captured_command_loop>,
func_args=0x0, errstring=0x827a7c0 "",
    mask=-1244706461) at exceptions.c:513
#30 0x0807fa04 in captured_main (data=0xbffcd548) at .././gdb/main.c:882
#31 0x0812c62b in catch_errors (func=0x807f190 <captured_main>,
func_args=0xbffcd600, errstring=0x827a7c0 "",
    mask=-1244706461) at exceptions.c:513
#32 0x08080363 in gdb_main (args=0xe82098c) at .././gdb/main.c:891
#33 0x0807f13f in main (argc=-1244706461, argv=0xb5cf4963) at gdb.c:33

-- 
           Summary: case of endless looping in buildsym.c
           Product: gdb
           Version: 6.8
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: a-gdb at nphiuu dot mine dot nu
                CC: gdb-prs at sourceware dot org
  GCC host triplet: GNU/Linux


http://sourceware.org/bugzilla/show_bug.cgi?id=9988

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/9988] case of endless looping in buildsym.c

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2009-06-22 19:50 -------
Subject: Bug 9988

CVSROOT:	/cvs/src
Module name:	src
Changes by:	jkratoch@sourceware.org	2009-06-22 19:50:10

Modified files:
	gdb            : ChangeLog buildsym.c 

Log message:
	gdb/
	PR gdb/9988:
	* buildsym.c (block_compar): New function.
	(end_symtab): Replace the bubble sort by a qsort based code.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.10619&r2=1.10620
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/buildsym.c.diff?cvsroot=src&r1=1.71&r2=1.72



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9988

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/9988] case of endless looping in buildsym.c

[jan dot kratochvil at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at sourceware dot|jan dot kratochvil at redhat
                   |org                         |dot com
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|                            |1


http://sourceware.org/bugzilla/show_bug.cgi?id=9988

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/9988] case of endless looping in buildsym.c

[jan dot kratochvil at redhat dot com]

------- Additional Comments From jan dot kratochvil at redhat dot com  2009-06-22 19:56 -------
This specific debug info reading performance hit should be fixed now.
Load time decreased 40s->4.6s during my measurement.
http://sourceware.org/ml/gdb-patches/2009-06/threads.html#00568


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=9988

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.