[Bug mi/28711] New: gdb closes when displaying structs with long field names in eclipse

["cristian.lupascu at nxp dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28711

            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=13862&action=edit
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 show
version". Eclipse uses "new-ui mi /dev/pts/0" only on Linux. This is why this
bug is not reproducible on Windows or Mac.

2) Using "sudo strace -s 5000 -p $(pidof gdb)" reveals the issue. I've included
the full output in the attachment. The crucial part is the following lines:

```
read(9, "70-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
1024) = 64
read(9, "\n71-var-info-path-expression
var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n", 1024) = 67
lseek(9, -66, SEEK_CUR)                 = -1 ESPIPE (Illegal seek)
lseek(9, -66, SEEK_CUR)                 = -1 ESPIPE (Illegal seek)
lseek(9, -66, SEEK_CUR)                 = -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 with
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 scenario.
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 you
can see above, a struct field with a name less that 64 characters could easily
reproduce the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.