From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9466F3858412; Fri, 17 Dec 2021 13:07:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9466F3858412 From: "cristian.lupascu at nxp dot com" To: gdb-prs@sourceware.org Subject: [Bug mi/28711] New: gdb closes when displaying structs with long field names in eclipse Date: Fri, 17 Dec 2021 13:07:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: mi X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cristian.lupascu at nxp dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 13:07:56 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28711 Bug ID: 28711 Summary: gdb closes when displaying structs with long field names in eclipse Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: mi Assignee: unassigned at sourceware dot org Reporter: cristian.lupascu at nxp dot com Target Milestone: --- Created attachment 13862 --> https://sourceware.org/bugzilla/attachment.cgi?id=3D13862&action=3Ded= it testcase and traces Requirements for reproducing: 1) Eclipse (Version: 2021-12 (4.22.0)) with C/C++ plugin (C/C++ Development Tools 10.4.1.202109150103 org.eclipse.cdt.feature.group Eclipse CDT). I have setup eclipse to use the nightly GDB version (GNU gdb (GDB) 12.0.50.20211217-git), but the bug still occurs. 2) OS: Linux (Linux vm 5.11.0-43-generic #47~20.04.2-Ubuntu SMP Mon Dec 13 11:06:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux). If you use the provided = test case, the bug can be reproduced on both physical and virtual machines. Steps to reproduce: 1) Create a C project in eclipse and add test.c to it (from the attachment). The file contains a simple testcase that defines a struct with 2000 fields = with increasing name lengths up to 2000 characters. 2) Build and debug. After initiating the debug session the program should be stopped at main(). Mouse over the variable "var" to display it OR open the Variables view in eclipse and expand the struct. 3) The debug session unexpectedly ends. GDB has exited with code 0. Analysis: 1) Note that eclipse starts GDB with "/home/cristi/Downloads/gdb-12.0.50.20211217/gdb/gdb --interpreter mi2 --nx= -q --interpreter console -ex new-ui mi /dev/pts/0 -ex set pagination off -ex s= how version". Eclipse uses "new-ui mi /dev/pts/0" only on Linux. This is why th= is bug is not reproducible on Windows or Mac. 2) Using "sudo strace -s 5000 -p $(pidof gdb)" reveals the issue. I've incl= uded the full output in the attachment. The crucial part is the following lines: ``` read(9, "70-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 1024) =3D 64 read(9, "\n71-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n", 1024) =3D 67 lseek(9, -66, SEEK_CUR) =3D -1 ESPIPE (Illegal seek) lseek(9, -66, SEEK_CUR) =3D -1 ESPIPE (Illegal seek) lseek(9, -66, SEEK_CUR) =3D -1 ESPIPE (Illegal seek) ``` GDB doesn't receive the full command in the first read, then it attempts to lseek() back to the first "\n" from the second read(). The lseek() fails wi= th ESPIPE and soon after GDB exits. 3) File descriptor 9 is "/dev/pts/0", the communication terminal between IDE and GDB, so lseek() can't be used on it. lrwx------ 1 cristi cristi 64 dec 17 14:49 9 -> /dev/pts/0 Additional info: On a phyisical machine, this issue is not noticeable in a practical scenari= o. You would need a field name with a length of 1000 characters in order to reproduce it. However, this issue can easily happen on a VM in a realistic scenario. As y= ou can see above, a struct field with a name less that 64 characters could eas= ily reproduce the issue. --=20 You are receiving this mail because: You are on the CC list for the bug.=