I have a problem when i'm in remote debugging. I use QtCreator 4.15.0, and qt version 5.15.2. Linux = Debian GNU/Linux 10 (buster). When i'm debugging stopped on a breakpoint (only in this case) and i'm debugging step by step after a while the application dies, this seems to be caused by using QProcess in threads parallel to the thread where i'm debugging. I think it is a problem with the gdbserver that in the debug window it shows the following message: "Can't detemine the currente address space of thread Thread xxxxx A problem internal to GDB has been detected, further debugging may prove unreliable." and after close the connection. But I have no idea how to fix it. Gdb Server version 8.2.1 and it was configured for "x86_64-linux-gnu".
Hi, GDB(server) 8.2 is quite old. Could you please try with the latest snapshot of GDB 11 (which is soon to be released)? https://sourceware.org/pub/gdb/snapshots/branch/?C=M;O=D
I think the latest version of gdb does not compile on debian10, the debian 10 distribution only makes it available up to gdb 8.2.1, now I do a test
I have the follow error in debian10: /mnt/hgfs/ScambioLinux/gdbserver/gdb-11.0.90.20210830/missing makeinfo --split-size=5000000 --split-size=5000000 -I ./../../readline/readline/doc -I ./../mi -I . \ -o gdb.info ./gdb.texinfo /mnt/hgfs/ScambioLinux/gdbserver/gdb-11.0.90.20210830/missing: 81: /mnt/hgfs/ScambioLinux/gdbserver/gdb-11.0.90.20210830/missing: makeinfo: not found WARNING: 'makeinfo' is missing on your system. You should only need it if you modified a '.texi' file, or any other file indirectly affecting the aspect of the manual. You might want to install the Texinfo package: <http://www.gnu.org/software/texinfo/> The spurious makeinfo call might also be the consequence of using a buggy 'make' (AIX, DU, IRIX), in which case you might want to install GNU make: <http://www.gnu.org/software/make/> make[4]: *** [Makefile:491: gdb.info] Error 127 make[4]: Leaving directory '/mnt/hgfs/ScambioLinux/gdbserver/gdb-11.0.90.20210830/gdb/doc' make[3]: *** [Makefile:1974: subdir_do] Error 1 make[3]: Leaving directory '/mnt/hgfs/ScambioLinux/gdbserver/gdb-11.0.90.20210830/gdb' make[2]: *** [Makefile:1640: all] Error 2 make[2]: Leaving directory '/mnt/hgfs/ScambioLinux/gdbserver/gdb-11.0.90.20210830/gdb' make[1]: *** [Makefile:10450: all-gdb] Error 2 make[1]: Leaving directory '/mnt/hgfs/ScambioLinux/gdbserver/gdb-11.0.90.20210830' make: *** [Makefile:903: all] Error 2
I did the same test with gdb 10 and DEbian unstable it gives me a different error, but the result is the same. with gdb 11 on debian10 it doesn't get to the end of make but it generates the executables, by replacing the executables of gdb and gdbserver gives me the same error of gdb 10
THe error with gdb10 and 11 is >&"Remote 'g' packet reply is too long (expected 560 bytes, got 2416 bytes): 00000000000000000000000000000000b9b95ff7ff7f0000b0cb1af5ff7f000000000000000000001110000000000000004a00f0ff7f0000a8cb1af5ff7f0000000000000000000040cc1af5ff7f00000000000000000000460200000000000001000000000000003ccc1af5ff7f0000000000000000000018cd1af5ff7f0000b9b95ff7ff7f000046020000330000002b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff000000000000000000000000000000000000000000002f7573722f62696e2f77686f616d69002f7573722f62696e2f77686f616d69002f002f002f002f002f002f002f002f002f002f0000000000000000000000000029292929292929292929292929292929b0e3d3f7ff7f0000a0e3d3f7ff7f000004000000140100000000000000000000000000000000000000000000000000005f715f737461727475704e6f7469666900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000380000000000000000d71af5ff7f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\n" >&"p
Created attachment 13638 [details] testcase
Created attachment 13639 [details] log
Created attachment 13640 [details] log 8.2.1
(In reply to Massimiliano from comment #3) > I have the follow error in debian10: > > /mnt/hgfs/ScambioLinux/gdbserver/gdb-11.0.90.20210830/missing makeinfo > --split-size=5000000 --split-size=5000000 -I ./../../readline/readline/doc > -I ./../mi -I . \ > -o gdb.info ./gdb.texinfo > /mnt/hgfs/ScambioLinux/gdbserver/gdb-11.0.90.20210830/missing: 81: > /mnt/hgfs/ScambioLinux/gdbserver/gdb-11.0.90.20210830/missing: makeinfo: not > found > WARNING: 'makeinfo' is missing on your system. You are missing the "makeinfo" tool. Using Debian's package tracker, you can find that this is provided by the "texinfo" package: https://packages.debian.org/search?suite=buster&arch=any&mode=path&searchon=contents&keywords=makeinfo
(In reply to Massimiliano from comment #6) > Created attachment 13638 [details] > testcase Thanks, can you please provide the commands required to compile the test case, and then the GDB commands required to reach the bug? If you can, start your GDB with the "-nx" switch to avoid loading any gdbinit file. That makes it easier to reproduce on our side, as sometimes people have some setting in their gdbinit that isn't mentioned but is important for the reproduction of the bug.
I am not very practical to use the gdb or to compile on the command line because I usually use the qtcreator that gives it all. However I add a new testcase "testcasenew" made by me. with the instructions of how I did to generate the problem: 1) to compile go to the testcasenew directory and give the following commands: - qmake untitled.pro - qmake - make 2) Copy the executable to the target and after I have given: - gdbserver localhost: 2000 testcase 3) On the host machine - gdb -nx testcase - remote target 192.168.127.172:2000 - b main - break main.cpp: 33 4) then give the following command until it goes into error - continue
Created attachment 13643 [details] New test case
Created attachment 13644 [details] New test case
Created attachment 13645 [details] Screenshot
Created attachment 13646 [details] test new case
Ok, I reproduced: (gdb) Continuing. [Detaching after fork from child process 2096323] [New inferior 2] Reading /home/simark/Downloads/testcasenew/testcase from remote target... Reading /home/simark/Downloads/testcasenew/testcase from remote target... Reading symbols from target:/home/simark/Downloads/testcasenew/testcase... [New Thread 2096324.2096324] [Switching to Thread 2096324.2096324] Remote 'g' packet reply is too long (expected 560 bytes, got 816 bytes): 000000000000000000000000000000008d315df7ff7f00004075e7f3ff7f000000000000000000001110000000000000004a00e4ff7f00003875e7f3ff7f00000000000000000000d075e7f3ff7f0000000000000000000046020000000000000100000000000000cc75e7f3ff7f00000000000000000000104e00e4ff7f00008d315df7ff7f000046020000330000002b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff000000000000000000000000000000000000000000002f7573722f62696e2f77686f616d69002f7573722f62696e2f77686f616d69002f002f002f002f002f002f002f002f002f002f00000000000000000000000000292929292929292929292929292929291026d3f7ff7f00000026d3f7ff7f00000400000014010000000000000000000000000000000000000000000000000000697465282900315f715f73746172747500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f000038000000000000004086e7f3ff7f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 I have seen this issue, I have a patch that fixes at least part of that, but I did not have time to test it properly and submit it. It is here for now: https://review.lttng.org/c/binutils-gdb/+/6187
This was discussed a while ago: https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html
(In reply to Simon Marchi from comment #16) > Ok, I reproduced: > > (gdb) > Continuing. > [Detaching after fork from child process 2096323] > [New inferior 2] > Reading /home/simark/Downloads/testcasenew/testcase from remote target... > Reading /home/simark/Downloads/testcasenew/testcase from remote target... > Reading symbols from target:/home/simark/Downloads/testcasenew/testcase... > [New Thread 2096324.2096324] > [Switching to Thread 2096324.2096324] > Remote 'g' packet reply is too long (expected 560 bytes, got 816 bytes): > 000000000000000000000000000000008d315df7ff7f00004075e7f3ff7f00000000000000000 > 0001110000000000000004a00e4ff7f00003875e7f3ff7f00000000000000000000d075e7f3ff > 7f0000000000000000000046020000000000000100000000000000cc75e7f3ff7f00000000000 > 000000000104e00e4ff7f00008d315df7ff7f000046020000330000002b000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000000000000000 > 000000000000000000000000007f03000000000000ffff0000000000000000000000000000000 > 00000000000002f7573722f62696e2f77686f616d69002f7573722f62696e2f77686f616d6900 > 2f002f002f002f002f002f002f002f002f002f000000000000000000000000002929292929292 > 92929292929292929291026d3f7ff7f00000026d3f7ff7f000004000000140100000000000000 > 00000000000000000000000000000000000000697465282900315f715f7374617274750000000 > 00000000000000000000000000000000000000000000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000000000000000 > 000000000000000000000000000000000000000000000000000000000000000801f0000380000 > 00000000004086e7f3ff7f0000000000000000000000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000000000000000 > 000000000000000 > > I have seen this issue, I have a patch that fixes at least part of that, but > I did not have time to test it properly and submit it. It is here for now: > > https://review.lttng.org/c/binutils-gdb/+/6187 I'm testing the change at the moment it seems to work much better
> I'm testing the change at the moment it seems to work much better Thanks for testing, that's good to know. I will eventually get to re-checking the patch and submitting it upstream.
(In reply to Simon Marchi from comment #19) > > I'm testing the change at the moment it seems to work much better > > Thanks for testing, that's good to know. I will eventually get to > re-checking the patch and submitting it upstream. I did some tests, I saw that it is much more stable but I also saw that it is slower, did you have time to do some tests? I wanted to know if the change is confirmed for the new gdb. thanks
Is it the patch I gave you that makes things slower, or a newer GDB versus an older GDB? Do you have a specific scenario I could test to see the performance difference?
(In reply to Simon Marchi from comment #21) > Is it the patch I gave you that makes things slower, or a newer GDB versus > an older GDB? Do you have a specific scenario I could test to see the > performance difference? i did the test using qtcreator. gdbserver 8.2.1 is very fast to do "Step Over" while from gdb11 for the same operation it takes 5 seconds, so I can say that it is not a problem of the patch, because I tried the patch with version 12.
If feasible, could you try to share a reproducer and the commands that give you that "slow step"? I'd be interested in digging a little bit. In the mean time, I have posted the patches related to this bug a few days ago: https://sourceware.org/pipermail/gdb-patches/2021-October/182922.html
(In reply to Simon Marchi from comment #23) > If feasible, could you try to share a reproducer and the commands that give > you that "slow step"? I'd be interested in digging a little bit. > > In the mean time, I have posted the patches related to this bug a few days > ago: > > https://sourceware.org/pipermail/gdb-patches/2021-October/182922.html unfortunately i can't reproduce the problem using the command line with a small example, i see it with my program which is very big using qtcreator, i wouldn't want it to be qtcreator's fault. it can also be seen using a small program, but the effect is much less, but on the command line I don't know how to show it. practically in the debug window with local variables this always takes a while to update the value of the variables when you are stopped on a break.
If you can give some steps to reproduce using qtcreator, I could give it a try.
Created attachment 13773 [details] debug gdb 8.2
Created attachment 13774 [details] debug gdb 12
(In reply to Massimiliano from comment #27) > Created attachment 13774 [details] > debug gdb 12 I have attached two videos of what I mean, where you can see how the variables update more slowly in the debug window. there are the two versions compared, I go to the debug menu and press step over.
I see. It could be the process of updating all the varobjs that takes time. If possible, could you attach the MI logs of both sessions? It's supposed to be possible to get them in QtCreator: https://myprogrammingnotes.com/qt-creator-interact-debugger-gdb.html If that log did show timestamps, it would be helpful, as we could get an idea of what takes time. But just seeing which commands QtCreator uses here would be helpful.
Just asking to verify, so we can rule this out: are your 2 GDBs built the same way? By default the build system doesn't enable optimizations (AFAIK), so if your GDB 8.2 comes from some distribution, it might be optimized, and if you built your own GDB 11 / 12, it might not.
Created attachment 13779 [details] congif log gdb 8.2
Created attachment 13780 [details] config log gdb 11
Created attachment 13781 [details] log qtcreator gdb 8.2 1/2
Created attachment 13782 [details] log qtcreator gdb 8.2 2/2
Created attachment 13783 [details] log qtcreator gdb 11 1/2
Created attachment 13784 [details] log qtcreator gdb 11 2/2
(In reply to Massimiliano from comment #36) > Created attachment 13784 [details] > log qtcreator gdb 11 2/2 I had already tried looking at the qtcreator logs (which I have attached) with no particular success. I have also attached the logs of the two compilations of gdb 8.2 and 11
For whether your GDB 11 build is optimized... I see some -O2 in the config.log. But to be sure, go in the gdb/ directory and do "make clean && make V=1". If you see -O2 on the command line, that's good. The steps that seems to take time is this one. With GDB 8 (1-2 seconds): 10:19:12.918 6362python theDumper.fetchVariables({"autoderef":0,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["watch","local","inspect","return"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","timestamps":1,"token":6362,"typeformats":{},"watchers":[{"exp":"6472697665724964","iname":"watch.0"},{"exp":"64737044726976657248617368","iname":"watch.1"},{"exp":"657468496e666f726d6174696f6e48617368","iname":"watch.2"},{"exp":"68526573756c74","iname":"watch.3"},{"exp":"697041647272657373416e644e65746d61736b","iname":"watch.4"},{"exp":"6c69737442617254797065","iname":"watch.5"},{"exp":"6d61704d6f64756c61724d616368696e65496e666f","iname":"watch.6"},{"exp":"6d6f64656c496e666f","iname":"watch.7"},{"exp":"6d6f64656c6c6f5374616d70616e7465","iname":"watch.8"},{"exp":"706172616d65746572546f436f6e76657274","iname":"watch.9"},{"exp":"706172616d6574657273546f4265436f6e766572746564","iname":"watch.10"},{"exp":"76616c7565","iname":"watch.11"},{"exp":"76617248617368","iname":"watch.12"}]}) 10:19:14.229 With GDB 11 (~12 seconds): 11:22:22.323 [1ms] 6462python theDumper.fetchVariables({"autoderef":0,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["watch","local","inspect","return"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","timestamps":1,"token":6462,"typeformats":{},"watchers":[{"exp":"6472697665724964","iname":"watch.0"},{"exp":"64737044726976657248617368","iname":"watch.1"},{"exp":"657468496e666f726d6174696f6e48617368","iname":"watch.2"},{"exp":"68526573756c74","iname":"watch.3"},{"exp":"697041647272657373416e644e65746d61736b","iname":"watch.4"},{"exp":"6c69737442617254797065","iname":"watch.5"},{"exp":"6d61704d6f64756c61724d616368696e65496e666f","iname":"watch.6"},{"exp":"6d6f64656c496e666f","iname":"watch.7"},{"exp":"6d6f64656c6c6f5374616d70616e7465","iname":"watch.8"},{"exp":"706172616d65746572546f436f6e76657274","iname":"watch.9"},{"exp":"706172616d6574657273546f4265436f6e766572746564","iname":"watch.10"},{"exp":"76616c7565","iname":"watch.11"},{"exp":"76617248617368","iname":"watch.12"}]}) 11:22:34.311 That seems to be a Python helper used by QtCreator to dump variables. It might be possible to reproduce the slowness out of QtCreator by running to the same point, and doing a similar call to theDumper.fetchVariables. Do you see the same slowness if you debug locally instead of remotely?
(In reply to Simon Marchi from comment #38) > For whether your GDB 11 build is optimized... I see some -O2 in the > config.log. But to be sure, go in the gdb/ directory and do "make clean && > make V=1". If you see -O2 on the command line, that's good. > > The steps that seems to take time is this one. With GDB 8 (1-2 seconds): > > 10:19:12.918 > 6362python > theDumper.fetchVariables({"autoderef":0,"context":"","displaystringlimit": > "100","dyntype":1,"expanded":["watch","local","inspect","return"],"fancy":1, > "formats":{},"nativemixed":0,"partialvar":"","passexceptions":0, > "qobjectnames":1,"resultvarname":"","stringcutoff":"10000","timestamps":1, > "token":6362,"typeformats":{},"watchers":[{"exp":"6472697665724964","iname": > "watch.0"},{"exp":"64737044726976657248617368","iname":"watch.1"},{"exp": > "657468496e666f726d6174696f6e48617368","iname":"watch.2"},{"exp": > "68526573756c74","iname":"watch.3"},{"exp": > "697041647272657373416e644e65746d61736b","iname":"watch.4"},{"exp": > "6c69737442617254797065","iname":"watch.5"},{"exp": > "6d61704d6f64756c61724d616368696e65496e666f","iname":"watch.6"},{"exp": > "6d6f64656c496e666f","iname":"watch.7"},{"exp": > "6d6f64656c6c6f5374616d70616e7465","iname":"watch.8"},{"exp": > "706172616d65746572546f436f6e76657274","iname":"watch.9"},{"exp": > "706172616d6574657273546f4265436f6e766572746564","iname":"watch.10"},{"exp": > "76616c7565","iname":"watch.11"},{"exp":"76617248617368","iname":"watch. > 12"}]}) > 10:19:14.229 > > With GDB 11 (~12 seconds): > > 11:22:22.323 [1ms] > 6462python > theDumper.fetchVariables({"autoderef":0,"context":"","displaystringlimit": > "100","dyntype":1,"expanded":["watch","local","inspect","return"],"fancy":1, > "formats":{},"nativemixed":0,"partialvar":"","passexceptions":0, > "qobjectnames":1,"resultvarname":"","stringcutoff":"10000","timestamps":1, > "token":6462,"typeformats":{},"watchers":[{"exp":"6472697665724964","iname": > "watch.0"},{"exp":"64737044726976657248617368","iname":"watch.1"},{"exp": > "657468496e666f726d6174696f6e48617368","iname":"watch.2"},{"exp": > "68526573756c74","iname":"watch.3"},{"exp": > "697041647272657373416e644e65746d61736b","iname":"watch.4"},{"exp": > "6c69737442617254797065","iname":"watch.5"},{"exp": > "6d61704d6f64756c61724d616368696e65496e666f","iname":"watch.6"},{"exp": > "6d6f64656c496e666f","iname":"watch.7"},{"exp": > "6d6f64656c6c6f5374616d70616e7465","iname":"watch.8"},{"exp": > "706172616d65746572546f436f6e76657274","iname":"watch.9"},{"exp": > "706172616d6574657273546f4265436f6e766572746564","iname":"watch.10"},{"exp": > "76616c7565","iname":"watch.11"},{"exp":"76617248617368","iname":"watch. > 12"}]}) > 11:22:34.311 > > That seems to be a Python helper used by QtCreator to dump variables. It > might be possible to reproduce the slowness out of QtCreator by running to > the same point, and doing a similar call to theDumper.fetchVariables. > > Do you see the same slowness if you debug locally instead of remotely? I had already checked the -o2 option and also in my opinion it is already optimized, even doing "make clean && make V = 1" does not change anything. i have the same problem using the gdb11 locally
(In reply to Massimiliano from comment #39) > (In reply to Simon Marchi from comment #38) > > For whether your GDB 11 build is optimized... I see some -O2 in the > > config.log. But to be sure, go in the gdb/ directory and do "make clean && > > make V=1". If you see -O2 on the command line, that's good. > > > > The steps that seems to take time is this one. With GDB 8 (1-2 seconds): > > > > 10:19:12.918 > > 6362python > > theDumper.fetchVariables({"autoderef":0,"context":"","displaystringlimit": > > "100","dyntype":1,"expanded":["watch","local","inspect","return"],"fancy":1, > > "formats":{},"nativemixed":0,"partialvar":"","passexceptions":0, > > "qobjectnames":1,"resultvarname":"","stringcutoff":"10000","timestamps":1, > > "token":6362,"typeformats":{},"watchers":[{"exp":"6472697665724964","iname": > > "watch.0"},{"exp":"64737044726976657248617368","iname":"watch.1"},{"exp": > > "657468496e666f726d6174696f6e48617368","iname":"watch.2"},{"exp": > > "68526573756c74","iname":"watch.3"},{"exp": > > "697041647272657373416e644e65746d61736b","iname":"watch.4"},{"exp": > > "6c69737442617254797065","iname":"watch.5"},{"exp": > > "6d61704d6f64756c61724d616368696e65496e666f","iname":"watch.6"},{"exp": > > "6d6f64656c496e666f","iname":"watch.7"},{"exp": > > "6d6f64656c6c6f5374616d70616e7465","iname":"watch.8"},{"exp": > > "706172616d65746572546f436f6e76657274","iname":"watch.9"},{"exp": > > "706172616d6574657273546f4265436f6e766572746564","iname":"watch.10"},{"exp": > > "76616c7565","iname":"watch.11"},{"exp":"76617248617368","iname":"watch. > > 12"}]}) > > 10:19:14.229 > > > > With GDB 11 (~12 seconds): > > > > 11:22:22.323 [1ms] > > 6462python > > theDumper.fetchVariables({"autoderef":0,"context":"","displaystringlimit": > > "100","dyntype":1,"expanded":["watch","local","inspect","return"],"fancy":1, > > "formats":{},"nativemixed":0,"partialvar":"","passexceptions":0, > > "qobjectnames":1,"resultvarname":"","stringcutoff":"10000","timestamps":1, > > "token":6462,"typeformats":{},"watchers":[{"exp":"6472697665724964","iname": > > "watch.0"},{"exp":"64737044726976657248617368","iname":"watch.1"},{"exp": > > "657468496e666f726d6174696f6e48617368","iname":"watch.2"},{"exp": > > "68526573756c74","iname":"watch.3"},{"exp": > > "697041647272657373416e644e65746d61736b","iname":"watch.4"},{"exp": > > "6c69737442617254797065","iname":"watch.5"},{"exp": > > "6d61704d6f64756c61724d616368696e65496e666f","iname":"watch.6"},{"exp": > > "6d6f64656c496e666f","iname":"watch.7"},{"exp": > > "6d6f64656c6c6f5374616d70616e7465","iname":"watch.8"},{"exp": > > "706172616d65746572546f436f6e76657274","iname":"watch.9"},{"exp": > > "706172616d6574657273546f4265436f6e766572746564","iname":"watch.10"},{"exp": > > "76616c7565","iname":"watch.11"},{"exp":"76617248617368","iname":"watch. > > 12"}]}) > > 11:22:34.311 > > > > That seems to be a Python helper used by QtCreator to dump variables. It > > might be possible to reproduce the slowness out of QtCreator by running to > > the same point, and doing a similar call to theDumper.fetchVariables. > > > > Do you see the same slowness if you debug locally instead of remotely? > > I had already checked the -o2 option and also in my opinion it is already > optimized, even doing "make clean && make V = 1" does not change anything. i > have the same problem using the gdb11 locally I also tried a different linux distribution, the distribution included the gdb10, I didn't have to recompile it, it has the same slowness defect