Community
Participate
Working Groups
I ran a project named gdbtest to configure eclipse and pretty print. I unexpectedly ran into some very awkward bug.(I just don't know what to say. This is undescribable. How can this happen?) first, below is my test source code --- /* note that this is a modified version of a test source from stackexchange, but I do not remember where. sorry. */ #include <map> #include <utility> #include <vector> #include <cstdio> int main() { std::vector<int> v; v.push_back(0); v.push_back(1); v.push_back(2); std::map<int,int> m; m[0]=0; m[1]=-1; m[2]=-2; printf("exit normally\n"); printf("exit normally\n"); } --- It is very strange. If I break right after the declaration of map which is std::map<int,int> m; and then execute further, there is nothing strange. However, if I break past the declaration and some assignment such as at m[1]=-1; It exits with an abnormal exit value of something like 34304. It doesn't seem to be a bug of gdb since it works fine on the cmd. -- Configuration Details -- Product: Eclipse IDE 4.10.0.20181214-0600 (org.eclipse.epp.package.cpp.product)Installed Features: org.eclipse.platform 4.10.0.v20181206-0815 --stack trace dumped by gdb in case of usefulness-- Stack trace: Frame Function Args 000FFFFBC70 00180060BE9 (00000000000, 000000102F0, 001801983F0, 000FFFFDE50) 00000000002 00180062ABA (006009C4610, 00000000000, 00000000288, 00000000000) 000FFFFBF50 00180130B1B (00600280DB0, 006007F1C28, 0000000002F, 00000000000) 006009C4480 00180156BC4 (001800C82DE, 0010084956C, 0010084956A, 0018030ABD0) 006009C4480 0018012D1BB (00000000000, 0018010C815, 000FFFFC1C0, 006009C4480) 006009C4480 0018012D4EF (0010066A496, FFFFFFFFFFFFFFFF, 00100849820, FFFFFFFFFFFFFFFF) 006009C4480 001006686EA (006009C4480, 00000000017, 00000000002, 0060097FE80) 006009C4480 0010066ABEC (000FFFFC550, 000FFFFC6A0, 00000000000, 000FFFFC3A8) 00000000000 0010066ACAE (001007D9D60, 00000000000, 00000000000, 000FFFFC3A8) 00000000000 001005770AA (001006692C7, 0018030ABD0, 001007D9FE0, 001007D9E4B) 00000000000 00100521905 (00100799CA9, 006007C5F38, 000FFFFC6A0, 00000000000) 00000000001 0010052196E (858E0E78077D2D7B, 0060024D6F0, 00100667317, 00100666A00) 00000000001 00100685C4A (001005248B6, 00200000000, 858E0E78077D2D7B, 00000000001) 00000000001 00100685CF3 (0060024D6F0, 0018030ABD0, 0010066779B, 00600996770) 00000000001 0010046FE4C (0060067F3D0, 00000000000, 001006623A1, 0060067F3D0) 00000000001 00100470F72 (00000000000, 006007C5EF0, 0018021A8B8, 000FFFFD680) End of stack trace (more stack frames may be present)
Hi! Here are a couple of bugzilla that report similar issues. If it's the same problem, it might in fact be a GDB issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=436745 https://bugs.eclipse.org/bugs/show_bug.cgi?id=362151 TL;DR: you might avoid the issue if you close the variables view before hitting the breakpoint, preventing CDT from asking the value of some un-initialized std:: variable(s). Good luck, Marc