Bug#1055646: gdb: extremely slow response to basic commands
Hello Héctor, On Tue, 28 Nov 2023 13:37:40 +0100 =?UTF-8?B?SMOpY3RvciBPcsOzbiBNYXJ0w61uZXo=?= wrote: > I wanted to drop a link to addr2line bug[1], could that be related? > > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29785 Thanks for this link. It looks like it can be related, but I can't confirm this at the moment. > > I thought that this BUG should be easy to eliminate - but it turns out > > that there are several serious BUGs in the gdb, and the only way to > > eliminate them is to debug the gdb first ;) > > Which several serious bugs? I understand you mean in the upstream GNU > GDB, instead of the Debian GNU GDB package. Are those reported > upstream? Well, I think that at least 2 problems are obvious: - huge memory consumption (can be related to the upstream bug or just a memory leak) - creation of useless threads: I would expect that "enable-threading" really enables SMP for searching symbol tables, memory ranges, etc. I haven't reported this yet, because first I want to fully understand whats going on. And yes, I mean upstream GNU GDB bugs. Regards.
Bug#1055646: gdb: extremely slow response to basic commands
Hello, I have found the root cause of this problem: It doesn't matter if the gdb is compiled with sbuild, debuild or dpkg-buildpackage. It's slow, because it reads BFDs from a *hidden* directory "/usr/lib/debug/.build-id/" The gdb compiled using "configure" script had different prefix, so its "relocatable" paths were pointing to an empty "debug" directory - that's why it was "fast". But, this is not the end of problems: When the gdb is started, it reads symbols from target program and from libraries which are loaded by the target program. In my test case (2.5MiB executable with debug symbols included + wxWidgets library with dbgsym package installed) the symbol table size is ~8MiB, and the gdb process is using ~50MiB. This is sufficient to debug the program, but after issuing the "run" command, the BFDs from "/usr/lib/debug/.build-id/" are read - and gdb creates a Monster Symbol Table with size over 200MiB (~280Mib used in total). Then things are getting only worse - any gdb command for displaying type or value of target program' variables causes the the memory consumption to double, in my case from ~280MiB to ~570MiB and the response times become deadly slow. But, this is not the end of problems: (2) In all test cases the gdb was compiled with --enable-threading - and indeed, gdb creates (num_CPU +1) threads on startup (in my case it's 17 for 16-core CPU). But the threading support in gdb is an illusion - those additional threads are *never* used, with a single exception - they are used only after the "run" command is issued, probably to read the BFDs. For any other gdb command only the main thread is consuming CPU time. I thought that this BUG should be easy to eliminate - but it turns out that there are several serious BUGs in the gdb, and the only way to eliminate them is to debug the gdb first ;) Regards
Bug#1055646: gdb: extremely slow response to basic commands
Hello, On Tue, 21 Nov 2023 13:53:00 +0100 =?UTF-8?B?SMOpY3RvciBPcsOzbiBNYXJ0w61uZXo=?= wrote: > Hello, > > On Wed, 15 Nov 2023 at 23:09, tomazzi wrote: > > > To do this, I need to have a complete build log with all the > > compiler/linker flags, compiler warnings, etc. > > Find logs at https://buildd.debian.org/status/logs.php?pkg=gdb=amd64 Many thanks for the link - I have the log, but I need some time to analyze it. > > Unfortunately, the methods described on the official Debian Wiki page > > does not allow to build gdb from source package -> "debuild" fails to > > produce the binary shipped by Debian. (I would say that this deserves a > > separate BUG report). > > I am unsure about that, usually you can build using dpkg-buildpackage. The gdb compiled with: $> dpkg-buildpackage --build=binary --host-type=x86_64-linux-gnu -us -uc reports configuration identical with the installed gdb, but the files are of different size: installed 9.9MiB, compiled 9.3MiB. The newly build gdb is also very slow. I've also compiled the "hacked" gdb with Debian patches applied, and it's fast - so no regression here. Didn't tried sbuild yet. Regards
Bug#1055646: gdb: extremely slow response to basic commands
Hello Héctor, Well, I want to fix this bug, because gdb is a very important tool for me, and compiling gdb from ./configure script is just a hack - not a real solution (which would eliminate the problem for good). To do this, I need to have a complete build log with all the compiler/linker flags, compiler warnings, etc. Unfortunately, the methods described on the official Debian Wiki page does not allow to build gdb from source package -> "debuild" fails to produce the binary shipped by Debian. (I would say that this deserves a separate BUG report). Now, the "hacked" gdb is also different - so the first step is to find differences in the build process, like the exact list of features enabled/disabled. So, can You please explain how did You build the gdb? Regards. On Mon, 13 Nov 2023 22:20:28 +0100 =?UTF-8?B?SMOpY3RvciBPcsOzbiBNYXJ0w61uZXo=?= wrote: > Hello Tomazzi, > > On Mon, 13 Nov 2023 at 21:51, tomazzi wrote: > > > > Hello, > > > > I've just built gdb "the Debian way", to check what are the differences > > in the build process: > > $> apt source gdb > > $> apt build-dep gdb > > $> debuild -b -uc -us > > > > From debuild output: > > > > gdb-default: configured with: > > ... > > --without-babeltrace > > --with-babeltrace > > ... > > gdb-minimal: configured with: > > ... > > --without-babeltrace > > --with-babeltrace > > --without-babeltrace > > ... > > > > This looks bad, but the results are even more "interresting": > > Latest switch is the one that should be in-use > > > The gdb binary installed in the system (**debsums OK**) reports the > > following configuration (the "show configuration" command, differences > > only): > > > > ... > > --with-babeltrace > > --with-mpfr > > --with-xxhash > > --with-python=/usr (relocatable) > > --with-python-libdir=/usr/lib (relocatable) > > --enable-source-highlight > > ... > > > > The newly "debuild" gdb reports something *different*: > > ... > > --without-babeltrace << this: conflicting build flags > > --without-mpfr > > --with-xxhash > > --without-python > > --without-python-libdir > > --disable-source-highlight > > ... > > > > > > The gdb which I've compiled using ./configure script (so *without* > > Debian patches) reports: > > ... > > --with-babeltrace > > --with-mpfr > > --without-xxhash << this: libxxhash-dev is installed, but
Bug#1055646: gdb: extremely slow response to basic commands
Hello, I've just built gdb "the Debian way", to check what are the differences in the build process: $> apt source gdb $> apt build-dep gdb $> debuild -b -uc -us From debuild output: gdb-default: configured with: ... --without-babeltrace --with-babeltrace ... gdb-minimal: configured with: ... --without-babeltrace --with-babeltrace --without-babeltrace ... This looks bad, but the results are even more "interresting": The gdb binary installed in the system (**debsums OK**) reports the following configuration (the "show configuration" command, differences only): ... --with-babeltrace --with-mpfr --with-xxhash --with-python=/usr (relocatable) --with-python-libdir=/usr/lib (relocatable) --enable-source-highlight ... The newly "debuild" gdb reports something *different*: ... --without-babeltrace << this: conflicting build flags --without-mpfr --with-xxhash --without-python --without-python-libdir --disable-source-highlight ... The gdb which I've compiled using ./configure script (so *without* Debian patches) reports: ... --with-babeltrace --with-mpfr --without-xxhash << this: libxxhash-dev is installed, but flag is disabled ? --with-python=/usr --with-python-libdir=/usr/lib --disable-source-highlight << this ... Regards
Bug#1055646: gdb: extremely slow response to basic commands
Today I've tried to do the same trick on some other machine (using build flags from previous mail), but the build failed with error message: "ar: `u' modifier ignored since `D' is the default (see `U')" while compiling "libgdbsupport.a" So I've just spent few hours trying to figure out why it worked on the other PC ... Long story short: During testing, I've first run ./configure from the gdb/gdb directory with the following flags: ./configure --enable-threading --with-gnu-ld --enable-libbacktrace --with-xxhash=yes --with-debuginfod=yes Then I've run ./configure from top /gdb dir (with the aforementioned flags) and the compilation went fine. So now the process is reproducible. Regards
Bug#972343: ITP: wxedid -- Graphical editor for monitor resolution and timing data (EDID)
Hi Felix, I've just noticed that there's a bug in the wxedid.1 manpage - the program allows to pass the file path to be opened as an cmd line argument, and there's an -t|--text option which tells that the file is in text format. Without this option, wxedid assumes that the file contains binary EDID data. See wxEDID_App.cpp -> wxEDID_App::CmdLineArgs(). Best Regards. On 16/10/2020 15:57, Felix Lechner wrote: Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: Tomasz Pawlak * Package name: wxedid Version : 0.0.21 Upstream Author : Tomasz Pawlak * URL : https://sourceforge.net/projects/wxedid/ * License : GPL-3+ Programming Lang: C++ Description : Graphical editor for monitor resolution and timing data (EDID) wxEDID is a wxWidgets based editor for Extended Display Identification Data (EDID). It operates on offline files that can be flashed to a monitor using the technique described here: https://wiki.debian.org/RepairEDID. This tool can modify the base EDID v1.3+ structure and the CEA/CTA-861-G, as the first extension block. The program also provides a DTD constructor to aid with the selection of suitable timings. The tool can import and export EDID data in binary blob and in hexadecimal formats. As a small package with few prerequisites and two releases per year, maintenance should be moderate. There was discussion if the software should be packaged at all. It is available in Suse and Archlinux, presumably because it is helpful when fixing your monitor's EDID. Kind regards Felix Lechner
