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

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
(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 important.
> 
> 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.
> 
> 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.
> 
> But, moving on, GDB processes the first command, which results in some
> output.  GDB wants to print this output, and eventually, this output is sent
> to the output file descriptor via glibc.
> 
> glibc notices that the file position is 1023 bytes ahead of where it should
> 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 how
stdin, stdout, stderr can coexist on one terminal.

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