[Bug gdb/31048] New: GDB commands very slow due to too many lseek calls

[Bug gdb/31048] New: GDB commands very slow due to too many lseek calls

[aditya24.garg at gmail dot com]

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

            Bug ID: 31048
           Summary: GDB commands very slow due to too many lseek calls
           Product: gdb
           Version: 9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: aditya24.garg at gmail dot com
                CC: aditya24.garg at gmail dot com
  Target Milestone: ---

OS: Linux (Ubuntu 20.04.5)

Overview: I have a project consisting of multiple .so files. I have refactored
one of the .so files to a templatized version, therefore now i have quite a few
template classes and functions. Now on using GDB for debugging, commands like
print/ptype are running extremely slow in certain frames. Its taking over a
minute to just execute ptype <namespace::variable-name>

Actual Results: For local args and variables, GDB print/ptype works pretty fast
but with one of the static singleton variables, GDB print/ptype is taking 1
minute to execute. I tried using strace on gdb PID and saw that over 5000 LSEEK
calls for the same offset were being made repeatedly.

From comment on another old ticket
(https://sourceware.org/bugzilla/show_bug.cgi?id=17764#c5), I tried setting
demangle-style to none after which this problem disappeared. Everything became
superfast.

But debugging with mangled names is very inconvenient so i am exploring
solutions to fix this slowness while still using demangler.

Expected Results: Expectation was that GDB will return response within a few
seconds, instead its taking around a minute.

GDB Version: GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2

Environment: 
OS: Linux 5.4.0-135-generic #152-Ubuntu SMP Wed Nov 23 20:19:22 UTC 2022 x86_64
x86_64 x86_64 GNU/Linux

GCC: Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)

GDB: This GDB was configured as "x86_64-linux-gnu"


Strace Logs:
lseek(158, 4980736, SEEK_SET)           = 4980736
lseek(158, 4980736, SEEK_SET)           = 4980736
lseek(158, 4980736, SEEK_SET)           = 4980736
lseek(158, 4980736, SEEK_SET)           = 4980736
lseek(158, 4980736, SEEK_SET)           = 4980736
lseek(158, 4980736, SEEK_SET)           = 4980736
lseek(158, 4980736, SEEK_SET)           = 4980736
lseek(158, 4980736, SEEK_SET)           = 4980736
ptrace(PTRACE_PEEKTEXT, 865894, 0x7fffe0ccb260, [0x7fffe3a0c920]) = 0
rt_sigaction(SIGINT, {sa_handler=0x556e929a32e0, sa_mask=[INT],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fb93304d090},
{sa_handler=0x556e929a32e0, sa_mask=[INT], sa_flags=SA_RESTORER|SA_RESTART, s>
brk(0x556ec2ea5000)                     = 0x556ec2ea5000
brk(0x556ec2ec6000)                     = 0x556ec2ec6000
brk(0x556ec2ee7000)                     = 0x556ec2ee7000
brk(0x556ec2f08000)                     = 0x556ec2f08000
brk(0x556ec2f29000)                     = 0x556ec2f29000
brk(0x556ec2f4a000)                     = 0x556ec2f4a000



Interesting fact: When i execute ptype <variable>. It takes 1 minute to run
when current frame selected (lets say frame 5) is from file1.so. And if i go to
frame 10 which belongs to file2.so, then same ptype command executes in 5
seconds. All the changes i have made are for file2.so and no change has been
made to file1.so implementation.

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

[Bug gdb/31048] GDB commands very slow due to too many lseek calls

[aditya24.garg at gmail dot com]

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

--- Comment #1 from Aditya Garg <aditya24.garg at gmail dot com> ---

Regarding this: 
```
Interesting fact: When i execute ptype <variable>. It takes 1 minute to run
when current frame selected (lets say frame 5) is from file1.so. And if i go to
frame 10 which belongs to file2.so, then same ptype command executes in 5
seconds. All the changes i have made are for file2.so and no change has been
made to file1.so implementation.
```

Did some more investigation and found out that frame 5 and 10 belong to the
same so file. My bad.

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

[Bug gdb/31048] GDB commands very slow due to too many lseek calls

[aditya24.garg at gmail dot com]

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

--- Comment #2 from Aditya Garg <aditya24.garg at gmail dot com> ---
I had BOOST_FORCEINLINE around 90% of the functions which were all member
functions to some template class. Once i removed BOOST_FORCEINLINE keyword, gdb
ptype/print issue got resolved. Size of the so files is still the same as
before. I can't understand why force inlining might cause gdb slowness. Any
thoughts?

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

[Bug gdb/31048] GDB commands very slow due to too many lseek calls

[simon.marchi at polymtl dot ca]

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

Simon Marchi <simon.marchi at polymtl dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.marchi at polymtl dot ca

--- Comment #3 from Simon Marchi <simon.marchi at polymtl dot ca> ---
Hi Aditya,

First of all, can you try with GDB from the git master branch?  It is not
really useful to develop on an old version like 9.2, since what you find might
not apply to the current code.

Then, do you think you would be able to make a reproducer?  Otherwise all we
can do is speculate, and that is not really useful.

Otherwise, I would suggest giving profiling a shot to see where time is spent. 
I personally use `perf` for that.

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

[Bug gdb/31048] GDB commands very slow due to too many lseek calls

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
I'm vaguely surprised to hear that lseek is a performance
issue, or maybe that it's even frequently called at all.
Are you using stabs by chance?

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

[Bug gdb/31048] GDB commands very slow due to too many lseek calls

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

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

[Bug gdb/31048] GDB commands very slow due to too many lseek calls

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

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

[Bug gdb/31048] GDB commands very slow due to too many lseek calls

[aditya24.garg at gmail dot com]

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

--- Comment #5 from Aditya Garg <aditya24.garg at gmail dot com> ---
Why i thought the issue was due to LSEEK is because while i was waiting for
ptype command to show result, all i could see in strace was LSEEK to the same
offset.

For now, i used a brute force approach to solving this. Commented out certain
parts of code to see if things are improving. Luckily, when i remove
BOOST_FORCEINLINE from class member functions, things got back to normal.

Does anyone has any idea why force inlining could slow down GDB?

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

[Bug gdb/31048] GDB commands very slow due to too many lseek calls

[tromey at sourceware dot org]

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

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Aditya Garg from comment #5)

> Does anyone has any idea why force inlining could slow down GDB?

I wouldn't expect this to really affect "print" or "ptype".
It can make "break" slow down though.

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