microsoft
Debugger: corrupted double-linked list
Environment
- OS and version: archlinux
- VS Code: 1.96.0 - insider
- C/C++ extension: 1.23.1
- GDB / LLDB version: GNU gdb (GDB) 15.2
Bug Summary and Steps to Reproduce
Bug Summary: Sometimes when I start to debug a cpp file, gdb crashes with "corrupted double-linked list". That seems to happen randomly, and usually disappear after a restart or rebuild.
Steps to reproduce:
- In the latest archlinux, install vscode-insider from aur.
- install the C/C++ extension.
- Write a cpp file.
- build
- launch.
- There's "corrupted double-linked list" in the shell.
Debugger Configurations
{
"tasks": [
{
"type": "cppbuild",
"label": "C/C++: g++ Build",
"command": "/usr/bin/g++",
"args": [
"-fdiagnostics-color=always",
"-g",
"${file}",
"-o",
"${workspaceFolder}/Problems/bin/${fileBasenameNoExtension}",
"-Wall",
"-mcmodel=large",
"-fsanitize=undefined,address"
],
"options": {
"cwd": "${fileDirname}"
},
"problemMatcher": [
"$gcc"
],
"group": {
"kind": "build",
"isDefault": true
}
}
],
"version": "2.0.0"
}
launch.json:
{
"name": "(gdb) launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/Problems/bin/${fileBasenameNoExtension}",
"args": [
"2>",
"${workspaceFolder}/Problems/logs/${fileBasenameNoExtension}.log",
"<",
"${workspaceFolder}/Problems/input/${fileBasenameNoExtension}.in",
">",
"${workspaceFolder}/Problems/output/${fileBasenameNoExtension}.out"
],
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "enable-pretty-printing",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "gdb-set disassembly-flavor intel",
"text": "-gdb-set disassembly-flavor intel",
"ignoreFailures": true
}
],
"logging": {
"trace": false,
"traceResponse": false,
"engineLogging": false
}
}
Debugger Logs
Shell:
/tmp/Microsoft-MIEngine-Cmd-o4wyfsi1.uvj: 第 2 行：44048 已中止 （核心已转储）"/usr/bin/gdb" --interpreter=mi --tty=$DbgTerm < "/tmp/Microsoft-MIEngine-In-bm43zbsy.hm0" > "/tmp/Microsoft-MIEngine-Out-bjnwcvx0.uct"
Output:
Activating task providers cppbuild
Debug Console:
Nothing after gdb's copyright information.
Core dump:
PID: 44048 (gdb)
UID: 1000 (Sving1024)
GID: 1000 (Sving1024)
Signal: 6 (ABRT)
Timestamp: Sat 2024-11-09 21:50:47 CST (7min ago)
Command Line: /usr/bin/gdb --interpreter=mi --tty=/dev/pts/2
Executable: /usr/bin/gdb
Control Group: /user.slice/user-1000.slice/[email protected]/session.slice/[email protected]
Unit: [email protected]
User Unit: [email protected]
Slice: user-1000.slice
Owner UID: 1000 (Sving1024)
Boot ID: 0decefcddda24410bcd734a899f90617
Machine ID: f708d61fa25b4732ad2631e253cfbfa6
Hostname: archlinux-asm236x
Storage: /var/lib/systemd/coredump/core.gdb.1000.0decefcddda24410bcd734a899f90617.44048.1731160247000000.zst (present)
Size on Disk: 3.9M
Message: Process 44048 (gdb) of user 1000 dumped core.
Module /usr/lib/guile/3.0/ccache/ice-9/format.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/vlist.go without build-id.
Module /usr/lib/guile/3.0/ccache/srfi/srfi-26.go without build-id.
Module /usr/lib/guile/3.0/ccache/language/scheme/decompile-tree-il.go without build-id.
Module /usr/lib/guile/3.0/ccache/language/scheme/compile-tree-il.go without build-id.
Module /usr/lib/guile/3.0/ccache/language/scheme/spec.go without build-id.
Module /usr/lib/guile/3.0/ccache/system/vm/loader.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/receive.go without build-id.
Module /usr/lib/guile/3.0/ccache/system/base/message.go without build-id.
Module /usr/lib/guile/3.0/ccache/system/base/language.go without build-id.
Module /usr/lib/guile/3.0/ccache/system/base/compile.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/eval-string.go without build-id.
Module /usr/share/gdb/guile/gdb.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/regex.go without build-id.
Module /usr/lib/guile/3.0/ccache/system/base/target.go without build-id.
Module /usr/lib/guile/3.0/ccache/system/foreign.go without build-id.
Module /usr/lib/guile/3.0/ccache/system/foreign-library.go without build-id.
Module /usr/lib/guile/3.0/ccache/srfi/srfi-16.go without build-id.
Module /usr/lib/guile/3.0/ccache/language/tree-il.go without build-id.
Module /usr/lib/guile/3.0/ccache/oop/goops.go without build-id.
Module /usr/lib/guile/3.0/ccache/system/base/syntax.go without build-id.
Module /usr/lib/guile/3.0/ccache/system/base/pmatch.go without build-id.
Module /usr/lib/guile/3.0/ccache/language/tree-il/primitives.go without build-id.
Module /usr/lib/guile/3.0/ccache/rnrs/bytevectors.go without build-id.
Module /usr/lib/guile/3.0/ccache/srfi/srfi-4.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/exceptions.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/control.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/q.go without build-id.
Module /usr/lib/guile/3.0/ccache/srfi/srfi-9/gnu.go without build-id.
Module /usr/lib/guile/3.0/ccache/system/base/ck.go without build-id.
Module /usr/lib/guile/3.0/ccache/srfi/srfi-9.go without build-id.
Module /usr/lib/guile/3.0/ccache/srfi/srfi-1.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/futures.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/match.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/threads.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/ports.go without build-id.
Module /usr/lib/guile/3.0/ccache/srfi/srfi-11.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/copy-tree.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/deprecated.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/networking.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/psyntax-pp.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/boot-9.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/posix.go without build-id.
Module /usr/lib/guile/3.0/ccache/ice-9/eval.go without build-id.
Stack trace of thread 44048:
#0 0x000071f420bb63f4 n/a (libc.so.6 + 0x963f4)
#1 0x000071f420b5d120 raise (libc.so.6 + 0x3d120)
#2 0x00006234c1650772 n/a (gdb + 0x2bf772)
#3 0x000071f420b5d1d0 n/a (libc.so.6 + 0x3d1d0)
#4 0x000071f420bb63f4 n/a (libc.so.6 + 0x963f4)
#5 0x000071f420b5d120 raise (libc.so.6 + 0x3d120)
#6 0x000071f420b444c3 abort (libc.so.6 + 0x244c3)
#7 0x000071f420b45354 n/a (libc.so.6 + 0x25354)
#8 0x000071f420bc0765 n/a (libc.so.6 + 0xa0765)
#9 0x000071f420bc138c n/a (libc.so.6 + 0xa138c)
#10 0x000071f420bc425a n/a (libc.so.6 + 0xa425a)
#11 0x000071f420bc5fae __libc_calloc (libc.so.6 + 0xa5fae)
#12 0x00006234c1ea79fc n/a (gdb + 0xb169fc)
#13 0x00006234c17368b1 n/a (gdb + 0x3a58b1)
#14 0x00006234c17369f7 n/a (gdb + 0x3a59f7)
#15 0x00006234c174652d n/a (gdb + 0x3b552d)
#16 0x00006234c1747aeb n/a (gdb + 0x3b6aeb)
#17 0x00006234c1ef9524 n/a (gdb + 0xb68524)
#18 0x00006234c1517d82 n/a (gdb + 0x186d82)
#19 0x00006234c1520395 n/a (gdb + 0x18f395)
#20 0x00006234c1f5677f n/a (gdb + 0xbc577f)
#21 0x00006234c17c1773 n/a (gdb + 0x430773)
#22 0x00006234c17c2cad n/a (gdb + 0x431cad)
#23 0x00006234c17c3194 n/a (gdb + 0x432194)
#24 0x00006234c16505f7 n/a (gdb + 0x2bf5f7)
#25 0x00006234c1a26740 n/a (gdb + 0x695740)
#26 0x00006234c1ebc3e1 n/a (gdb + 0xb2b3e1)
#27 0x00006234c1f0b703 n/a (gdb + 0xb7a703)
#28 0x00006234c178f765 n/a (gdb + 0x3fe765)
#29 0x00006234c1428c15 n/a (gdb + 0x97c15)
#30 0x000071f420b45e08 n/a (libc.so.6 + 0x25e08)
#31 0x000071f420b45ecc __libc_start_main (libc.so.6 + 0x25ecc)
#32 0x00006234c143fc25 n/a (gdb + 0xaec25)
Stack trace of thread 44053:
#0 0x000071f420bb0a19 n/a (libc.so.6 + 0x90a19)
#1 0x000071f420bb3479 pthread_cond_wait (libc.so.6 + 0x93479)
#2 0x000071f420ed6c31 __gthread_cond_wait (libstdc++.so.6 + 0xd6c31)
#3 0x00006234c1ebf8ec n/a (gdb + 0xb2e8ec)
#4 0x000071f420ee1c34 execute_native_thread_routine (libstdc++.so.6 + 0xe1c34)
#5 0x000071f420bb439d n/a (libc.so.6 + 0x9439d)
#6 0x000071f420c3949c n/a (libc.so.6 + 0x11949c)
Stack trace of thread 44054:
#0 0x000071f420bb0a19 n/a (libc.so.6 + 0x90a19)
#1 0x000071f420bb3479 pthread_cond_wait (libc.so.6 + 0x93479)
#2 0x000071f420ed6c31 __gthread_cond_wait (libstdc++.so.6 + 0xd6c31)
#3 0x00006234c1ebf8ec n/a (gdb + 0xb2e8ec)
#4 0x000071f420ee1c34 execute_native_thread_routine (libstdc++.so.6 + 0xe1c34)
#5 0x000071f420bb439d n/a (libc.so.6 + 0x9439d)
#6 0x000071f420c3949c n/a (libc.so.6 + 0x11949c)
Stack trace of thread 44055:
#0 0x000071f420bb0a19 n/a (libc.so.6 + 0x90a19)
#1 0x000071f420bb3479 pthread_cond_wait (libc.so.6 + 0x93479)
#2 0x000071f420ed6c31 __gthread_cond_wait (libstdc++.so.6 + 0xd6c31)
#3 0x00006234c1ebf8ec n/a (gdb + 0xb2e8ec)
#4 0x000071f420ee1c34 execute_native_thread_routine (libstdc++.so.6 + 0xe1c34)
#5 0x000071f420bb439d n/a (libc.so.6 + 0x9439d)
#6 0x000071f420c3949c n/a (libc.so.6 + 0x11949c)
Stack trace of thread 44056:
#0 0x000071f420bb0a19 n/a (libc.so.6 + 0x90a19)
#1 0x000071f420bb3479 pthread_cond_wait (libc.so.6 + 0x93479)
#2 0x000071f420ed6c31 __gthread_cond_wait (libstdc++.so.6 + 0xd6c31)
#3 0x00006234c1ebf8ec n/a (gdb + 0xb2e8ec)
#4 0x000071f420ee1c34 execute_native_thread_routine (libstdc++.so.6 + 0xe1c34)
#5 0x000071f420bb439d n/a (libc.so.6 + 0x9439d)
#6 0x000071f420c3949c n/a (libc.so.6 + 0x11949c)
Stack trace of thread 44060:
#0 0x000071f420bb0a19 n/a (libc.so.6 + 0x90a19)
#1 0x000071f420bb3479 pthread_cond_wait (libc.so.6 + 0x93479)
#2 0x000071f4210f36a1 n/a (libgc.so.1 + 0x1f6a1)
#3 0x000071f4210f382f n/a (libgc.so.1 + 0x1f82f)
#4 0x000071f420bb439d n/a (libc.so.6 + 0x9439d)
#5 0x000071f420c3949c n/a (libc.so.6 + 0x11949c)
Stack trace of thread 44061:
#0 0x000071f420bb0a19 n/a (libc.so.6 + 0x90a19)
#1 0x000071f420bb3479 pthread_cond_wait (libc.so.6 + 0x93479)
#2 0x000071f4210f36a1 n/a (libgc.so.1 + 0x1f6a1)
#3 0x000071f4210f382f n/a (libgc.so.1 + 0x1f82f)
#4 0x000071f420bb439d n/a (libc.so.6 + 0x9439d)
#5 0x000071f420c3949c n/a (libc.so.6 + 0x11949c)
Stack trace of thread 44062:
#0 0x000071f420bb0a19 n/a (libc.so.6 + 0x90a19)
#1 0x000071f420bb3479 pthread_cond_wait (libc.so.6 + 0x93479)
#2 0x000071f4210f36a1 n/a (libgc.so.1 + 0x1f6a1)
#3 0x000071f4210f382f n/a (libgc.so.1 + 0x1f82f)
#4 0x000071f420bb439d n/a (libc.so.6 + 0x9439d)
#5 0x000071f420c3949c n/a (libc.so.6 + 0x11949c)
ELF object binary architecture: AMD x86-64
Other Extensions
core.gdb.1000.0decefcddda24410bcd734a899f90617.44048.1731160247000000.zip
Additional Information
No response
@Sving1024 This sounds like a gdb bug. I think you would need to file a bug on gdb.
@Sving1024 Or do you believe it's a bug in MIEngine? I'm not sure if MIEngine could cause such a gdb crash.
@Sving1024 There's a similar issue at https://github.com/microsoft/MIEngine/issues/968 you may want to refer to.
@Sving1024 This sounds like a gdb bug. I think you would need to file a bug on gdb.
I met the same problem with vsc-cpp. But when I use gdb manually there is no such problem.
@Eletary Sure, if that's the case, then it sounds like a bug from our extension/MIEngine.
It seems the issue is related to std::priority_queue.
The two codes trigger the bug nearly every time on my machine, neither rebooting nor restarting vscode doesn't help.
#include <iostream>
#include <queue>
using namespace std;
using ll = long long;
using ull = unsigned long long;
struct location {
ll x, y;
location() { x = y = 0; }
location(ll _x, ll _y) : x(_x), y(_y) {}
location operator+(const location &b) const {
return location(x + b.x, y + b.y);
}
location operator*(const ll &k) const { return location(x * k, y * k); }
location operator/(const ll &k) const { return location(x / k, y / k); }
};
struct node {
location l;
ll val;
bool operator<(const node &b) const { return val > b.val; }
};
int main(){
priority_queue<node> q;
for (ll i=0;i<5;i++) {
ll x,y,z;
cin>>x>>y>>z;
q.push({{x,y},z});
}
cout<<(q.top().l.x);
}
use input(from keyboard):
1 2 3 ^Z
[1] + 9393 suspended /usr/bin/env /bin/sh /tmp/Microsoft-MIEngine-Cmd-ugnqs3fb.t0r
If you redirect from a file, gdb crashes with a corrupted double-linked list initially, not even hitting the breakpoint at line 26.
With proper inputs (at least 5 integers in the input), the program works well.
However, in a more complex program(you can find that in the attachment), gdb will crash as soon as it starts whether the input is from the keyboard or redirected from a file.
#include <iostream>
#include <queue>
using namespace std;
using ll = long long;
using ull = unsigned long long;
struct test2{
ll x,y;
};
struct test{
ll x;
test2 t;
test(ll _x){
x=_x;
}
~test(){
cout<<"rm obj\n";
return;
}
bool operator<(const test& b)const{return x<b.x;}
};
int main(){
priority_queue<test> q;
for (ll i=0;i<5;i++) {
ll x;
cin>>x;
q.push({x});
}
cout<<(q.top().x);
}
using std::vector or other stl containers will not trigger the bug. The bug only appears with gdb 15.
attachment:
cpp.zip
GDB version: 15.2 OS: Arch linux 6.11.9 Code - OSS 1.95.1 C/C++ (ms-vscode) extension v1.6.0
I encountered very similar bug in C and it only occurs in very specific circumstances.
corrupted double-linked list
/tmp/Microsoft-MIEngine-Cmd-bpwk4k4a.saw: line 2: 62372 Aborted (core dumped) "/usr/bin/gdb" --interpreter=mi --tty=$DbgTerm < "/tmp/Microsoft-MIEngine-In-nizbfky0.rvb" > "/tmp/Microsoft-MIEngine-Out-w5aaqrco.ddb"
Generated cmake flags
Building program sanityCheck_DEBUG
Building: gcc C23 ./tools/sanityCheck -g;-Wall;-Wextra;-pedantic;-D_GLIBCXX_DEBUG;-fstack-usage;-fno-omit-frame-pointer;-O0
Compiler Flags: -fopenmp
Linker Libraries: /usr/lib/libasound.so;;PkgConfig::PKG_PipeWire;m;/usr/lib/libcurses.so;/usr/lib/libform.so
The program runs and compiles on its own perfectly fine
#include <stdio.h>
#include <stdint.h>
#include <string.h>
void unusedFile(FILE *fptr){
return;
}
void dummyFunc(){
uint8_t seed[4];
memset( seed, (uint8_t)32, 4 );
return;
}
int main(){
unusedFile(NULL);
dummyFunc();
return 0;
}
The debugger starts working again if:
- Remove either of the functions
- unusedFile() returns anything
- uint8_t is changed to char
- Removing build flags "-fstack-usage" "-fno-omit-frame-pointer"
- Changing unusedFile() argument to int
So it might be some specifically compiled assembly instruction that crashes the debugger, but this is getting beyond what I know about programming. I'm just a hobbyist.
Edit: Disabling or enabling OMP has no effect, so I removed a note about that.
Well, it seems that I have a lot of breakpoints in different files. After removing the other breakpoints, It works well.
Well, it seems that I have a lot of breakpoints in different files. After removing the other breakpoints, It works well.
I noticed that this bug is very inconsistent. Just changing GCC flags like OMP seemed to fix it at first, but then it'd fail with other source file differently. It sounds like some compiled assembly is being misinterpreted either by the plugin, or MIEngine like issue that sean mentioned. Though there's no mention about "corrupted double-linked list", which I get even when debugging C
Removing breakpoints from other files helped me too. Any update on the bug? Is it been looked at?
Recently, I am also unable to debug programs cause of this bug. I don't know what exactly is causing it. Renaming the file to something else, clearing the cache, removing breakpoints and restarting my system have helped sometimes, though now nothing is really working and this is a bit inconvenient to me. I'm listing my environment below.
Environment
- OS: Arch Linux 6.15.9-arch1-1
- VS Code: 1.103.0
- C/C++ Extension: 1.26.3
- Debugger: GNU GDB 16.3
I have tried debugging with GDB on the terminal and it works flawlessly there. This seems to be an active issue for quite a while, please look into it. I'm attaching the error output below.
Error
corrupted double-linked list
/tmp/Microsoft-MIEngine-Cmd-p2njajie.o5t: line 2: 91579 Aborted (core dumped) "/usr/bin/gdb" --interpreter=mi --tty=$DbgTerm < "/tmp/Microsoft-MIEngine-In-z4aoepen.jqg" > "/tmp/Microsoft-MIEngine-Out-4akjj255.azp"
Hello, I facing this issue quite regularly (and [https://github.com/microsoft/MIEngine/issues/968](this one) which looks related). It would really be great to get a fix on it. For me sometimes removing breakpoints helps or setting a breakpoint soon after program entry point.
