Gdb crashes when calling functions on windows - Доктор Windows

I’m trying to find a non-slow method to print QString values from within GDB. My approach is to define a function (to be used only from within GDB) that takes a non-const reference to a QString, converts it to non-Unicode string, and sends the result to standard output. But using it in the manner I desire to use it causes a crash as explained below.

Suppose I have the following functions defined:

void printQString(const QString & in)
{
  // The other option is to use GDB trickery as indicated by http://tinyurl.com/k6mfgxy but that is DOG SLOW:
  printf("%sn",in.toLocal8Bit().data()); fflush(stdout);
}

void crunchOnIt(const QString & in)
{
   // ... Do something useful with "in" here ...
}

void someFunc()
{
  QFileInfo fileInfo("/tmp/flubberBouncesBest");
  fileInfo.makeAbsolute();
  if (fileInfo.isSymLink()) {
    crunchOnIt(fileInfo.symLinkTarget()); // <-- You are right here in GDB.
    return true;
  }
  return false;
}

Suppose you run the above from within GDB and are on the line indicated by «You are right here in GDB».

Now from within GDB you want to inspect the return value of fileInfo.symLinkTarget() before calling the crunchOnIt function. When I try the obvious, I get what looks to be a crash:

(gdb) call printQString(fileInfo.symLinkTarget())

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff059ba4b in gconv () from /usr/lib64/gconv/UTF-16.so
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(printQString(QString const&)) will be abandoned.
When the function is done executing, GDB will silently stop.

If, however, if GDB steps into crunchOnIt, and I call printQstring with the «in» parameter, it works just fine.

Having to edit the program to add a temporary, e.g.,:

void someFunc()
{
  QFileInfo fileInfo("/tmp/flubberBouncesBest");
  fileInfo.makeAbsolute();
  if (fileInfo.isSymLink()) {
    QString tmp = fileInfo.symLinkTarget(); // <-- No I don't want to have to recompile the program to insert this temporary!
    crunchOnIt(tmp);
    return true;
  }
  return false;
}

and recompile defeats the purpose of the printQstring function, because recompiling a large C++ program just to add temporaries is a significant waste of development time.

Is this a GDB bug whereby it is not keeping track of the temporary created by the fileInfo.symLinkTarget() expression that needs to be fed to the printQString function?

What alternatives do I have other than inserting the tmp-orary above?

Источник

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

Comments

Debugger can’t pass certain point in my program, while debugging under visual-studio-code. If I run the session in terminal (outside of IDE) everything works normal. In simplified version debugger crashes only when entering the problem function. Here is output from VS code debug console:

GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Stopped due to shared library event (no libraries added or removed)
Breakpoint 1, main () at main.cpp:18
18      std::cout << "Test!" << std::endl;
Breakpoint 2, main () at main.cpp:26
26      read_record(dataset);
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)
Breakpoint 3, main () at main.cpp:27
27      return 0;
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
The program '/home/pa/work/vsc-test/a.out' has exited with code 0 (0x00000000).

Here is simplified self contained code (test.txt must contain at least 4 bytes):

#include <iostream>
#include <fstream>
#include <vector>

std::vector<uint8_t> read_record( std::istream & stream )
{
    if (!stream)
        return std::vector<uint8_t>();

    std::vector<uint8_t> result(4);
    stream.read(reinterpret_cast<char *>(result.data()), 4);

    return std::move(result);
}

int main()
{
    std::cout << "Test!" << std::endl;

    char const * file_name = "test.txt";

    std::ifstream dataset(file_name);
    if (!dataset)
        throw std::runtime_error(std::string(file_name) + ": error: can't open dataset!");

    read_record(dataset);
    return 0;
}

Problem function: read_record

System Arch Linux 4.6.3-1
Visual Studio Code 1.3.1
C/C++ extension 0.7.1
g++ (GCC) 6.1.1 20160602

@peterazmanov I tried your scenario on Ubuntu 14.04 /w GDB 7.7.1. I compiled the above code with «g++ -g main.cpp -std=c++11» and then setting the breakpoints you are showing above. I’m able to step in and debug through the read_record method.

I’ll attempt to setup an Arch Linux machine to see if I can repro on that.

After system update (4.6.4-1) and extension update (0.8.0), the sample crashes.
Output:

=thread-group-added,id="i1"
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Stopped due to shared library event (no libraries added or removed)
Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
Breakpoint 1, main () at main.cpp:18
18      std::cout << "Test!" << std::endl;
Breakpoint 2, main () at main.cpp:26
26      read_record(dataset);
Loaded '/usr/lib/libstdc++.so.6'. Symbols loaded.
Loaded '/usr/lib/libm.so.6'. Symbols loaded.
Loaded '/usr/lib/libgcc_s.so.1'. Symbols loaded.
Loaded '/usr/lib/libc.so.6'. Symbols loaded.
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)
value.c:824: internal-error: value_contents_bits_eq: Assertion `offset1 + length <= TYPE_LENGTH (val1->enclosing_type) * TARGET_CHAR_BIT' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
value.c:824: internal-error: value_contents_bits_eq: Assertion `offset1 + length <= TYPE_LENGTH (val1->enclosing_type) * TARGET_CHAR_BIT' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
ERROR: GDB exited unexpectedly. Debugging will now abort.
The program '/home/pa/work/vsc-test/a.out' has exited with code -1 (0xffffffff).

@peterazmanov I reproed your issue on Arch Linux and it seems to be a bug in GDB. We communicate with GDB using the MI interface and when we step into read_record, we call -stack-list-arguments to update the UI with the arguments list information for the stack. This seems to cause the error you see in your latest log:

value.c:824: internal-error: value_contents_bits_eq: Assertion `offset1 + length <= TYPE_LENGTH (val1->enclosing_type) * TARGET_CHAR_BIT’ failed.
A problem internal to GDB has been detected,

I don’t know if this has to do with a change within gdb between 7.7(version on Ubuntu) and 7.11 (version on Arch Linux) or if the Arch Linux version has a change that isn’t on the mainline.

@pieandcakes
Can you verify that the same thing happens inside GDB? That is, step into the method, and then call the same command -stack-list-arguments and see if the debuggee quits? If it does, then there is, unfortunately nothing we can do about this other than file a bug against GDB.

@delmyers Yes, the same thing happens in GDB when I call -stack-list-arguments in that block of code. unfortunately there isn’t a non-mi command that I can verify this in regular mode GDB.

I downgraded GDB to version 7.7.1 and the sample stopped crashing. I can now debug my program. Another problem which I encountered recently with the newest gdb has gone too (trying to stop on breakpoint GDB freezes, eats all memory and crashes). I didn’t test versions between 7.7.1 and 7.11.1, maybe there is a newer version not affected by this bug.

I had a similar issue. Debugging with gdb was fine. Using gdb within vscode would report an error like the OP’s. Attempting to downgrade gdb induced other problems with gdb (I was on 7.12.4 and tried going back to 7.7.1), so I gave up on that path. I realized that I had some old watches and breakpoints set in vscode. I cleared all those out and — ba-da-bing — it started working again. YMMV.

@mlimber Can you tell me which OS you are running on?

@pieandcakes, I’m also on Arch Linux, which is code for running the latest version of virtually every Linux package. Specifically:

Linux localhost 4.10.4-1-ARCH #1 SMP PREEMPT Sat Mar 18 19:39:18 CET 2017 x86_64 GNU/Linux

vscode version 1.10.2
g++ version 6.3.1
gdb version 7.12.1

ghost

mentioned this issue

Jul 18, 2017

Has there been any update on this issue? Was there an issue filed with GDB?
I just noticed the same thing running GDB 8.0.1 and a really simple «Hello World» example.

I also tried downgrading GDB to 7.7.1, which did not help.
Interestingly it works, when I use the second build system of the project I’m building (scons vs cmake). Perhaps there are different compiler settings set, which don’t cause the bug in GDB.

Any update on this issue? I’m using gdb version 8.1 on Arch Linux and are still encouturing this issue.

Same here. I don’t have any issue if I run gdb from shell. In VSCode it crashes, tho.

This seems like an older issue. If you are still seeing crashes, please provide the gdb version and a log or snippet of what the error that gdb returns in the log. If this is because of gdb, we will need to file a bug there to have someone fix it.

I’m using gdb version 8.1 on Windows7 64bit , when a function have a return value, i use step out ,it crashes.
vscode version 1.25.0
mingw-w64，x86_64-8.1.0-win32-seh-rt_v6-rev0
g++ version 8.1.0
gdb version 8.1.0

@Nicolaze That seems to be an issue with MinGW 64bit’s gdb on 8.1. Unfortunately this is an issue with the toolset and not our extension. Our suggestion would be either to downgrade the version of gdb or if you don’t need 64bit, the 32bit version seems to work fine.

Similar issue with gdb and Visual Code Studio here:

Stopped due to shared library event (no libraries added or removed)
Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdda8, env=0x7fffffffddc0) at /home/my_executable.cpp:75

Ubuntu 16.04
gdb 7.11.1
gcc 5.4.0
vscode 1.27.2

I can start gdb in terminal and run the program in the gdb terminal without issues.

@mlimber : You mentioned that you cleared out old breakpoints and watches. Since I am also seeing a breakpoint: How do you do it? In MY code, I don’t have any breakpoints enabled. However, gdb is noticing a breakpoint of a file that I don’t even have on my computer. It is from an executable that somebody else built.

// EDIT
I just realized now that I also get a popup stating «unable to open my_executable.cpp», file not found. Which is true, I do not have it, because its a source file from an executable that somebody else built. I am just creating some libraries, which are read by the executable. So the question is: How do I disable such breakpoints?

Potentially helpful information when I run the command via gdb from terminal (successfully):

info breakpoints > No breakpoints or watchpoints (even though the debug console says there is a breakpoint in my_executable::75 ?)
info checkpoints > No checkpoints
info watchpoints > No watchpoints
info sources > A long list of files. Most of the files are NOT existent on my computer. The first row points to my_executable.cpp, which is the file the debug console in visual studio code complains about.

Similar problem here. It appear only when declaring an object from share library in my main.cpp. without it, everything is fine.

Ubuntu 16.04
gdb 7.11.1
gcc 5.4.0 or 6.4.0
vscode 1.27.2

My launch.json file:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
«version»: «0.2.0»,
«configurations»: [
{
«name»: «(gdb) Launch»,
«type»: «cppdbg»,
«request»: «launch»,
«program»: «${workspaceFolder}/build/TestYolo4Video/TestYolo4Video»,
«additionalSOLibSearchPath»: «${workspaceFolder}/build/YoloDetector/»,
«stopAtEntry»: false,
«cwd»: «${workspaceFolder}»,
«environment»: [],
«externalConsole»: true,
«MIMode»: «gdb»,
«logging»: { «engineLogging»: true },
«setupCommands»: [
{
«description»: «Enable pretty-printing for gdb»,
«text»: «-enable-pretty-printing»,
«ignoreFailures»: true
}
]
}
]
}

@rytisss Do you have a repro project you can share for your scenario?

This is an older issue and hasn’t had any updates. Please comment/open a new issue if it is still happening.

asialasr

pushed a commit
to asialasr/vscode-cpptools
that referenced
this issue

Mar 12, 2021

Fix Windows VS Code debugging with new CoreCLR-based OpenDebugAD7

I was having the same issue whenever I try to add a legitimate watch expression or execute a command in debug console. Even the Variables Tab in Run and Debug, shows value of vector<int>::iterator during debugging instead of the C++ iterator objects.

gdb 8.1 (MinGW-64)
gcc 8.1.0 
VSCode Version: 1.55.1 (user setup)

Switching to mingw-32 gdb this works fine.

Same issue on WSL with gdb 10.2

Have the same issue with
ubuntu 22.04
vscode 1.67.1
gdb 12.0.90
gcc (c++) 11.2.0

Works excellent if I use gdb in a terminal window.

@richardh538 I just ran into this as well, with a similar set of tools versions. It seems that the issue has been fixed in GDB but the fix isn’t in Ubuntu repositories yet: #9135 (comment).

To temporarily solve this until its updated in ubuntu 22.04 repos you can:

compile gdb-12.1 from source
or
Install the ubuntu 22.10 kinetic build which does not seem to add additional dependencies from here: https://launchpad.net/ubuntu/+source/gdb/12.1-0ubuntu1/+build/23606376
wget https://launchpad.net/ubuntu/+source/gdb/12.1-0ubuntu1/+build/23606376/+files/gdb_12.1-0ubuntu1_amd64.deb
sudo apt install ./gdb_12.1-0ubuntu1_amd64.deb

If you use multiarch, also check @jimfred post below.

Edit: By now there is a proposed update to gdb12.1-0 for 22.04 jammy here: https://launchpad.net/ubuntu/+source/gdb/12.1-0ubuntu1~22.04
so you might want to try this instead (works fine for me):
wget https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa/+build/23606523/+files/gdb_12.1-0ubuntu1~22.04_amd64.deb
sudo apt install ./gdb_12.1-0ubuntu1~22.04_amd64.deb

or you can add the toolchain build to your software sources: https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa
but I would not recommend that.

jhs67, richardh538, Arthur-CWW, blakeNaccarato, HampusAdolfsson, timlg07, oniboni, dawidwojtas-mudita, keithrausch, ri-char, and 24 more reacted with thumbs up emoji
AJIOB reacted with hooray emoji
timlg07, keithrausch, atetevoortwis, AngheloAlf, eugeniomiro, Alice-space, AJIOB, and LiuYinCarl reacted with heart emoji
keithrausch, Otavio-Burato, AngheloAlf, Alice-space, and AJIOB reacted with rocket emoji

In addition to the sudo apt install ./gdb in @LeLuc4’s response, I also needed gdb-multiarch for use with a RP2040. So…

wget https://launchpad.net/ubuntu/+source/gdb/12.1-0ubuntu1/+build/23606376/+files/gdb-multiarch_12.1-0ubuntu1_amd64.deb
chmod a+rwx ./gdb-multiarch_12.1-0ubuntu1_amd64.deb
this was needed to address a permissions error related to _apt
sudo apt install ./gdb-multiarch_12.1-0ubuntu1_amd64.deb
verify using gdb-multiarch --version and expect 12.1

Источник

This is what I see in my debugger log. I am pasting the parts from a little before the shutdown…

>182^done
t07:52:27.352
tResponse time: python theDumper.fetchStack({"limit":20,"nativemixed":0,"token":182}): 0.606 s
t07:52:27.368
<183-stack-select-frame 0
t07:52:27.368
<184python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["inspect","return","watch","local"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":184,"typeformats":{},"watchers":[]})
t07:52:27.368
t07:52:27.399 [31ms]
>183^done
t07:52:27.399
tResponse time: -stack-select-frame 0: 0.031 s
t07:52:27.399
t07:52:27.399
>&"python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["inspect","return","watch","local"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":184,"typeformats":{},"watchers":[]})n"

>~"result={token="0",data=[{iname="local.this",name="this",origaddr="0xb5b0c0",address="0x1ed0aae0",address="0x1ed0aae0",numchild="1",type="AddressWidget",value="",},{iname="local.temp",name="temp",origaddr="0xb5b098",address="0x1ed9ddd0",address="0x1ed9ddd0",numchild="1",type="QTableView",value="",},{iname="local.proxy",name="proxy",origaddr="0xb5b090",address="0x1ed9b160",address="0x1ed9b160",numchild="1",type="QSortFilterProxyModel",value="",},{iname="local.selectionModel",name="selectionModel",origaddr="0xb5b088",address="0x1edacd50",address="0x1edacd50",numchild="1",type="QItemSelectionModel",value="",},{iname="local.indexes",name="indexes",numchild="0",type="QList<QModelIndex>",valueencoded="notaccessible",value="",},],typeinfo=[],partial="0",counts={},timings=[]}n"
t07:52:28.211 [812ms]
>184^done
t07:52:28.211
tResponse time: python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["inspect","return","watch","local"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":184,"typeformats":{},"watchers":[]}): 0.843 s
t07:52:28.211
 <Rebuild Watchmodel 4 @ 07:52:28.211 >
t07:52:28.211
 Finished retrieving data.
t07:52:28.211

t07:52:34.228
<185python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["inspect","return","watch","local.temp","local"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"local.temp","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":185,"typeformats":{},"watchers":[]})
t07:52:34.259 [31ms]
>&"python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["inspect","return","watch","local.temp","local"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"local.temp","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":185,"typeformats":{},"watchers":[]})n"
>~"result={token="0",data=[{iname="local.temp",name="temp",origaddr="0xb5b098",address="0x1ed9ddd0",address="0x1ed9ddd0",numchild="1",sortable="1",children=[{iname="local.temp.@1",name="[QAbstractItemView]",sortgroup="999",address="0x1ed9ddd0",address="0x1ed9ddd0",numchild="1",type="QAbstractItemView",value="",},{name="staticMetaObject",numchild="1",address="0x680e26c0",type="QMetaObject",value="",},{name="[parent]",sortgroup="9",address="0x1ed0cea0",numchild="1",type="QStackedWidget",valueencoded="utf16",value="710074005f007400610062007700690064006700650074005f0073007400610063006b0065006400770069006400670065007400",},{name="[children]",sortgroup="8",numchild="8",valueencoded="itemcount",value="8",},{name="[extra]",sortgroup="1",numchild="1",value="",},{name="[properties]",sortgroup="5",numchild="1",valueencoded="minimumitemcount",value="5",},{name="[methods]",sortgroup="3",numchild="24",valueencoded="itemcount",value="24",},{name="[d]",address="0x1ed9f590",numchild="1",sortgroup="15",type="QTableViewPrivate",value="",},],type="QTableView",value="",},],typeinfo=[],partial="1",counts={'metaObjectFromType': 1},timings=[]}n"
t07:52:34.321 [62ms]
>185^done
t07:52:34.321
tResponse time: python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["inspect","return","watch","local.temp","local"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"local.temp","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":185,"typeformats":{},"watchers":[]}): 0.093 s
t07:52:34.321
 <Rebuild Watchmodel 5 @ 07:52:34.321 >
t07:52:34.321
 Finished retrieving data.
t07:52:34.321
dADJUSTING CHILD EXPECTATION FOR local.temp
t07:52:34.321

t07:52:48.368
<186python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["inspect","return","watch","local.temp.[properties]","local.temp","local"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"local.temp.[properties]","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":186,"typeformats":{},"watchers":[]})
t07:52:48.400 [32ms]
>&"python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["inspect","return","watch","local.temp.[properties]","local.temp","local"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"local.temp.[properties]","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":186,"typeformats":{},"watchers":[]})n"

t07:52:49.915 [1515ms]
dHANDLE GDB ERROR: The process was ended forcefully.
dProcess crashed
t07:52:49.915
dGDB PROCESS FINISHED, status 1, exit code -1073741819
t07:52:49.915
dNOTE: INFERIOR ILL
t07:52:49.915
dState changed from InferiorStopOk(11) to InferiorShutdownRequested(13)
t07:52:49.915
dCALL: SHUTDOWN INFERIOR
t07:52:49.915
dNO GDB PROCESS RUNNING, CMD IGNORED: kill  13
t07:52:49.915
dINFERIOR FINISHED SHUT DOWN
t07:52:49.915
dState changed from InferiorShutdownRequested(13) to InferiorShutdownFinished(14)
t07:52:49.915
dState changed from InferiorShutdownFinished(14) to EngineShutdownRequested(15)
t07:52:49.915
dCALL: SHUTDOWN ENGINE
t07:52:49.915
dPLAIN ADAPTER SHUTDOWN 15
t07:52:49.915
dINITIATE GDBENGINE SHUTDOWN, PROC STATE: 0
t07:52:49.915
dNOTE: ENGINE SHUTDOWN FINISHED
t07:52:49.915
dState changed from EngineShutdownRequested(15) to EngineShutdownFinished(16)
t07:52:49.915

Источник

GDB crashing

raynebc

Member #11,908

May 2010

Posted on 05/03/2018 3:05 AM

The project I work on has recently caused GDB to start crashing if I invoke a function that pulls up a file browse dialog window. The program behaves as expected when run outside the debugger, but trace debugging shows the crash occurs when GetOpenFileName() (which is a macro for GetOpenFileNameA() ) is called. GDB has always tended to have unusually long delays when I bring up this file browser in debug mode, but I’m not sure why the crashes only begun happening now.

I’m not seeing that MinGW offers a GDB build newer than what I have had for some time (7.6.1). I can work around this by defining the file I want to load as a command line parameter for my program, as this avoids having to bring up the file browser, but it’s a bit annoying. Does anybody have any suggestions for simple workarounds to this kind of problem?

Edgar Reynaldo

Major Reynaldo

May 2007

avatar

Posted on 05/03/2018 5:47 AM

This isn’t super helpful unless you have a Linux box but gdb on Linux works 10 times better than on windows

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math.

raynebc

Member #11,908

May 2010

Posted on 05/03/2018 12:27 PM

It wouldn’t surprise me. I do have Ubuntu on one of my laptops, but I dislike how it intercepts the ALT key for its stupid menu system so I do my development and testing on Windows. Supposedly this can be remapped (https://askubuntu.com/questions/122209/how-do-i-modify-or-disable-the-huds-use-of-the-alt-key?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa) but I haven’t spent much time dealing with it.

Edgar Reynaldo

Major Reynaldo

May 2007

avatar

Posted on 05/03/2018 2:56 PM

MSYS2’s pacman might have a more recent version of gdb, perhaps you could try that

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math.

raynebc

Member #11,908

May 2010

Posted on 05/03/2018 8:10 PM

Wouldn’t that only be usable in the MSYS environment?

Edgar Reynaldo

Major Reynaldo

May 2007

avatar

Posted on 05/03/2018 8:34 PM

Sure, but small sacrifice to get gdb to work

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math.

bamccaig

Member #7,536

July 2006

avatar

Posted on 05/03/2018 10:06 PM

There are many desktop environments in Linux so you could always try installing another desktop environment and see if that suits your needs better. Personally, I prefer MATE which is a fork of GNOME 2. Goes back to basics with the kind of GUI you got 10 years ago in XP. I haven’t noticed any Alt eatery from it. Honestly, it’s a little comical to hear of a developer that uses both environments, but chooses Windows for development. Also Ubuntu is a convenient distro for installing non-free software for media consumption, but it’s not necessarily the ideal platform for development. You could always try another Linux distro. Some other popular environments are Debian, Fedora, and Arch. Linux (meaning GNU+Linux+many other free software packages) is supposed to be free. You can make it what you want or need it to be. It’s not a walled garden like Windows or OS X.

Back on topic, I wonder if a crashing GDB would be considered a bug by the GDB project. Don’t ask me how you’re supposed to debug GDB though.

—
I mean the best with what I say. It doesn’t always sound that way.

Chris Katko

Member #1,881

January 2002

avatar

Posted on 05/05/2018 11:41 AM

Definitely file a bug report. You know the exact function that causes it. That should make it easy to replicate and then fix.

——sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” — Structure and Interpretation of Computer Programs
«Political Correctness is fascism disguised as manners» —George Carlin

raynebc

Member #11,908

May 2010

Posted on 05/05/2018 2:01 PM

The strange thing is that I used this version of MinGW and GDB to develop this particular code base for years. It didn’t begin crashing until I added lots of unrelated changes. I also noticed it soon after an OS reboot, so I don’t know if Windows/antivirus updates or anything else environmental are involved. The crash still happens if I disable the AV.

I have no expectation that I am causing memory corruption or anything like that, it would likely have been noticed by Coverity, cppcheck or maybe even Memwatch (a set of hooks for memory allocation functions that test for overflows, wild/double memory frees, etc), and I can trigger it at the very beginning of the execution of the program (before nearly any of the program’s code is used).

Edgar Reynaldo

Major Reynaldo

May 2007

avatar

Posted on 05/05/2018 10:14 PM

valgrind on Linux can do wonders for your program’s stability and correctness.

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math.

raynebc

Member #11,908

May 2010

Posted on 05/06/2018 1:41 PM

It’s already generally stable and correct with regard to memory handling (no buffer overflows, no wild frees, no memory leaks), this is entirely a GDB issue it seems.

Edgar Reynaldo

Major Reynaldo

May 2007

avatar

Posted on 05/07/2018 4:07 AM

You also get better error messages from gcc. They have more warnings enabled by default, as well as getting cutting edge versions.

We’re lucky anyone has ported gdb to windows at all. I’m using gdb 7.11.1, I can’t remember where I got that from either.

That version just started (finally) to get pretty printing enabled and working for STL template classes.

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math.

raynebc

Member #11,908

May 2010

Posted on 05/09/2018 12:54 PM

Windows 10’s April Service Pack overwrote GRUB. Again. Get your shit together, Microsoft. I’ll get around to fixing GRUB again when I get around to it, so I can get back in Ubuntu eventually.

Chris Katko

Member #1,881

January 2002

avatar

Posted on 05/09/2018 5:00 PM

Mine just restarted my system while I was watching TV, uploading a 32 GB file (14+ hours), and running a second Windows 10 VM. Also terminated a multiple hour slow download.

It closed it all.

It also bricked my laptop, and broke RDP for many work computers.

$ssholes.

Never had ANYTHING like that happen on Linux. They wouldn’t DARE reboot without asking you first.

Peter Hull

Member #1,136

March 2001

Posted on 05/11/2018 5:59 AM

Just to be clear, are you saying GDB itself crashes or your program crashes when run inside GDB?

You might be able to get the crashing process to write out a minidump (equivalent of coredump on Unix) and use windbg to figure out where it was. (there used to be something called DrMingW which was sporadically useful but I haven’t used MingW in years)

raynebc

Member #11,908

May 2010

Posted on 05/11/2018 12:04 PM

Windows specifically cites gdb.exe as crashing. It offers to open it in a debugger, but I don’t have any other ones on this computer.

Edgar Reynaldo

Major Reynaldo

May 2007

avatar

Posted on 05/11/2018 8:30 PM

You can debug GDB with GDB. Just attach it to the running gdb process that crashed. ‘gdb attach PID’

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math.

raynebc

Member #11,908

May 2010

Posted on 05/11/2018 9:44 PM

Will that provide useful information to the GDB team if GDB doesn’t happen to be built with symbols or something like that?

Edgar Reynaldo

Major Reynaldo

May 2007

avatar

Posted on 05/11/2018 10:43 PM

What you can get out of it is kind of happy go lucky. I doubt gdb has debugging symbols, but maybe you can get something useful like segfault at 0xdeadbeef or something.

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math.

raynebc

Member #11,908

May 2010

Posted on 05/12/2018 12:37 AM

I’m not getting much out of it, maybe you could suggest other commands to gather useful information from the crashed GDB process?

Attaching to process 7148
[New Thread 7148.0x62c]
[New Thread 7148.0x203c]
[New Thread 7148.0x2128]
Reading symbols from C:MinGWbingdb.exe...done.
(gdb) bt
#0  0x77bd000d in ntdll!DbgBreakPoint () from C:WindowsSysWOW64ntdll.dll
#1  0x77c5f306 in ntdll!DbgUiRemoteBreakin ()
   from C:WindowsSysWOW64ntdll.dll
#2  0x4f7b0aa7 in ?? ()
#3  0x00000000 in ?? ()
(gdb)

bamccaig

Member #7,536

July 2006

avatar

Posted on 05/12/2018 1:00 AM

If you want to go full r***** you could try to compile GDB yourself with debug symbols. But on Windows I can’t imagine that’s an easy task. I’m not even sure if it would be trivial in Linux.

Without debug symbols I think at best you’ll get a bunch of function addresses which won’t do much good unless somebody has a mapping for those addresses to actual functions.

That said, the stack trace you did get doesn’t look entirely useless. It doesn’t mean anything to me, but perhaps it would mean something to the GDB devs (or community). Won’t hurt to ask.

—
I mean the best with what I say. It doesn’t always sound that way.

raynebc

Member #11,908

May 2010

Posted on 05/12/2018 3:33 AM

Given that the regular gdb is on version 8.1, do you suspect they would tell me not to bother them if I can’t reproduce on the current release? Should I check with MinGW first?

Edgar Reynaldo

Major Reynaldo

May 2007

avatar

Posted on 05/12/2018 7:44 AM

Other options you can try (that may or may not be helpful), are :

>bt full
>bt 1 full
>info thread
>thread apply all bt [N] [full]

Who knows how much you’ll get out of it.

I’m trying to update and upgrade to latest msys2 and gdb to see what version they’re on.

EDIT
gdb in MSYS2 is on version 8.0.1. I would definitely give it a try. Just because gdb was compiled with msys2 doesn’t mean it can’t debug regular windows programs. It just needs debugging symbols.

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math.

raynebc

Member #11,908

May 2010

Posted on 05/12/2018 2:53 PM

Can I get just the GDB.exe from MSYS2? I could only immediately find an installer for MSYS2 and bundled tools, and from a quick glance at MSYS2’s website it seems it’s MinGW-w64-centric. I’m not immediately sure it would get along with my MinGW installation. In the meantime I’ll join the relocated MinGW mailing list and see if they want to look into it. Maybe they could provide builds with debugging symbols.

Here are those GDB outputs from a crashed instance:

#SelectExpand

1(gdb) bt full
2#0 0x77bd000d in ntdll!DbgBreakPoint () from C:WindowsSysWOW64ntdll.dll
3No symbol table info available.
4#1 0x77c5f306 in ntdll!DbgUiRemoteBreakin ()
5 from C:WindowsSysWOW64ntdll.dll
6No symbol table info available.
7#2 0x4c6174e9 in ?? ()
8No symbol table info available.
9#3 0x00000000 in ?? ()
10No symbol table info available.
11(gdb) bt 1 full
12#0 0x77bd000d in ntdll!DbgBreakPoint () from C:WindowsSysWOW64ntdll.dll
13No symbol table info available.
14(More stack frames follow…)
15(gdb) info thread
16 Id Target Id Frame
17* 3 Thread 8484.0x2278 0x77bd000d in ntdll!DbgBreakPoint ()
18 from C:WindowsSysWOW64ntdll.dll
19 2 Thread 8484.0x19a4 0x77be018d in ntdll!ZwWaitForMultipleObjects ()
20 from C:WindowsSysWOW64ntdll.dll
21 1 Thread 8484.0x2310 0x77be018d in ntdll!ZwWaitForMultipleObjects ()
22 from C:WindowsSysWOW64ntdll.dll
23(gdb)

The «thread apply all bt full» command printed a lot of output:
https://pastebin.com/raw/NVCnBB8f

Edgar Reynaldo

Major Reynaldo

May 2007

avatar

Posted on 05/12/2018 6:53 PM

I assume they would be pretty interested in this bit :

Thread 1
...
No symbol table info available.
#13 0x75558f74 in msvcrt!abort () from C:Windowssyswow64msvcrt.dll
No symbol table info available.
#14 0x005a2fdc in internal_vproblem (
    problem=0x6c675c <internal_error_problem>,
    file=0x737f36 <__PRETTY_FUNCTION__.20807+1622> "../../gdb-7.6.1/gdb/minsyms.c", line=862,
    fmt=0x7380d0 <__PRETTY_FUNCTION__.20807+2032> "sect_index_data not initialized", ap=0x2c7ebbc "207ｬ\") at ../../gdb-7.6.1/gdb/utils.c:840
        msg = "Recursive internal problem.n"
        dejavu = 1
#15 0x005a31ff in internal_verror (
    file=file@entry=0x737f36 <__PRETTY_FUNCTION__.20807+1622> "../../gdb-7.6.1/gdb/minsyms.c", line=line@entry=862,
    fmt=fmt@entry=0x7380d0 <__PRETTY_FUNCTION__.20807+2032> "sect_index_data not initialized", ap=ap@entry=0x2c7ebbc "207ｬ\")
    at ../../gdb-7.6.1/gdb/utils.c:944
No locals.
#16 0x005a3237 in internal_error (
    file=file@entry=0x737f36 <__PRETTY_FUNCTION__.20807+1622> "../../gdb-7.6.1/gdb/minsyms.c", line=line@entry=862,
    string=0x7380d0 <__PRETTY_FUNCTION__.20807+2032> "sect_index_data not initialized") at ../../gdb-7.6.1/gdb/utils.c:954
        ap = 0x2c7ebbc "207ｬ\"
#17 0x0052063a in prim_record_minimal_symbol (
    name=name@entry=0x678ad28 "api-ms-win-crt-multibyte-l1-1-0!_mbcasemap",
    address=address@entry=1714189152, ms_type=ms_type@entry=mst_data,
    objfile=0x6a8e4c0) at ../../gdb-7.6.1/gdb/minsyms.c:862
        section = <optimized out>
#18 0x0052a587 in add_pe_forwarded_sym (

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math.

Источник

Я пытаюсь создать программу на С++ в Windows, используя MinGW.

Построенная программа работает нормально, тем не менее, проблема возникает при отладке.

При отладке, если я пытаюсь проверить результат выполнения функции или метода, как показано на скриншотах ниже, GDB принудительно завершается.

Я запускал GDB как командную строку, но результат был тот же.

Я также изменил MinGW на другую версию, но безрезультатно.

GDB на WSL работает без проблем на тех же конфигурациях.

Не работает только на родной винде.

Буду признателен, если вы дадите мне знать, почему.

Just before watching "add(2, 3)".

ERROR: GDB exited unexpectedly. Debugging will now abort.

The same result of GDB command line.
"p v[1]", "p v.at(1)", "p v.empty()", "p v.size()", ... were failed,
"p add(2, 3)", "p my_obj.func()", ... were crashed.

G++ version is 8.1.0
gdb version is 8.1

3 ответа

Похоже, что это ошибка с информацией об ошибке GDB, и, похоже, ее можно воспроизвести с помощью :

настроить 64-разрядную среду MinGW

скомпилируйте и свяжите простое консольное приложение hello world c++ с помощью gcc (также версии 8.1.0)

начать отладку EXE-файла с помощью gdb

установить точку останова, например, на основной функции (b main)

выполнить команду информационных регистров (i r)

Отладчик неожиданно завершает работу и возвращает вас в командную строку.

Если веб-сайт показывает правильную информацию, похоже, что в настоящее время над ним никто не работает, но изменение версии GDB с 32-bit на 64-bit может решить эту проблему.

darclander
5 Сен 2020 в 03:32

Скорее всего, это уже исправлена ошибка gdb https://sourceware.org/bugzilla/show_bug. cgi?id=22854. Сообщалось об этом для версии 8.1, см. Version: 8.1 в отчете об ошибке. И это было исправлено в версии 8.2, см. Target Milestone: 8.2 в отчёте об ошибке. Вы должны обновить gdb как минимум до версии 8.2.

ks1322
9 Сен 2020 в 13:03

Источник