Bug 578351 - GDB hangs with lseek syscall and 100% cpu usage
Summary: GDB hangs with lseek syscall and 100% cpu usage
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb
Version: 12
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Jan Kratochvil
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-31 00:36 UTC by Kevin Bowling
Modified: 2010-07-20 18:07 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-04-05 20:35:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
GDB backtrace (7.31 KB, text/plain)
2010-03-31 00:36 UTC, Kevin Bowling
no flags Details

Description Kevin Bowling 2010-03-31 00:36:55 UTC
Created attachment 403623 [details]
GDB backtrace

Description:
When trying to print certain pointers in a Qt/C++ application, gdb hangs indefinitely with 100% CPU usage.  strace shows an infinite loop of the same lseek call.  A backtrace of gdb attached to the stuck gdb is attached.

Version:
GNU gdb (GDB) Fedora (7.0.1-36.fc12) x86_64


How reproducible:
Every time.

Steps to Reproduce:
1. Run gdb on our large Qt/C++ application
2. Try and print a QString
  
Actual results:
Infinite loop of "lseek(11, 20354560, SEEK_SET) = 20354560" in strace, 100% cpu usage.

Expected results:
Printing of QString variable.

Additional info:
Arails bug #3485

Also saw this while attaching gdb to the stuck gdb process.  Relevant?  Is there a way to disable "itertoolsmodule"?

Reading symbols from /usr/lib64/python2.6/lib-dynload/itertoolsmodule.so...Reading symbols from /usr/lib/debug/usr/lib64/python2.6/lib-dynload/itertoolsmodule.so.debug...done.
done.
Loaded symbols for /usr/lib64/python2.6/lib-dynload/itertoolsmodule.so
lookup_partial_symbol (pst=0x222b2d0, name=0x7fffe4533ef0 "oaCommon::srcName", 
    global=1, domain=VAR_DOMAIN) at ../../gdb/symtab.c:1735
1735      if (length == 0)

Comment 1 Kevin Bowling 2010-03-31 01:31:59 UTC
I just found that with LD_BIND_NOW=1 set, gdb works as expected.

Comment 2 Jan Kratochvil 2010-04-02 22:05:42 UTC
Tried to attach to twinkle and printed various QString's but I do not see a problem.

(gdb) frame
#1  0x0000003d3033c931 in QKeySequence::decodeString (str=...) at kernel/qkeysequence.cpp:441
441	    } else if ( accel[0] == 'F' && (fnum = accel.mid(1).toInt()) && (fnum >= 1) && (fnum <= 35) ) {
(gdb) p accel
$12 = {static null = {static null = <same as static member of an already seen type>, d = 0x0, 
    static shared_null = 0x0}, d = 0xd5fe10, static shared_null = 0x0}
(gdb) p &accel
$13 = (QString *) 0x7fffffffa1d0

But found one C++ namespaces performance backport has been forgotten so hopefully it gets fixed by it.

Comment 3 Fedora Update System 2010-04-02 22:30:30 UTC
gdb-7.0.1-38.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gdb-7.0.1-38.fc12

Comment 4 Kevin Bowling 2010-04-05 23:37:48 UTC
patch 38 and above seem to be working.  Thanks!

Comment 5 Fedora Update System 2010-07-20 18:07:48 UTC
gdb-7.0.1-49.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gdb-7.0.1-49.fc12


Note You need to log in before you can comment on or make changes to this bug.