From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 88FD4385841D; Fri, 24 Dec 2021 17:03:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 88FD4385841D From: "fweimer at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug mi/28711] gdb closes when displaying structs with long field names in eclipse Date: Fri, 24 Dec 2021 17:03:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed 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: fweimer at redhat dot com X-Bugzilla-Status: NEW 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: cc Message-ID: In-Reply-To: References: 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, 24 Dec 2021 17:03:14 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28711 Florian Weimer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fweimer at redhat dot com --- Comment #5 from Florian Weimer --- (In reply to Andrew Burgess from comment #4) > So what happens is that a lot of input arrives on the read file descriptor > in one go. GDB does a fgetc, and glibc then does a read on the file > descriptor. I see glibc read up to 1024 bytes. Clearly, the original bug > reporter saw much smaller reads from glibs, but that's not really importa= nt. >=20 > If the first command that arrives (including the commands final \n > character) is larger than one read buffer (so for me, larger than 1024 > bytes), then glibc will perform a second read, also of up to 1024 bytes to > find the rest of the command. >=20 > If we imagine that the final \n character is the first character in the > second read buffer, and that we get a full 1024 bytes in the second read > buffer, then GDB has read 1023 bytes more than it actually needed. As a > result, the file position of the file descriptor is 1023 bytes ahead of > where glibc actually thinks it should be in the file. >=20 > But, moving on, GDB processes the first command, which results in some > output. GDB wants to print this output, and eventually, this output is s= ent > to the output file descriptor via glibc. >=20 > glibc notices that the file position is 1023 bytes ahead of where it shou= ld > be, and so tries to lseek the file position back to the expected location. This description suggests to me that GDB does not use two different stdio streams for reading and writing. With one stream, POSIX requires fseek calls when switching from reading to writing and vice versa. This is obviously a non-starter for terminal devices because they do not support seeking. So opening the same terminal device multiple times is the way to go, it's h= ow stdin, stdout, stderr can coexist on one terminal. --=20 You are receiving this mail because: You are on the CC list for the bug.=