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

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

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

--- Comment #4 from Andrew Burgess <aburgess at redhat dot com> ---
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.

lseek isn't supported on terminals, and so things start to go wrong.  I haven't
bothered to track down exactly what causes GDB to exit, because I'm not
convinced it's important.  What matters is that by sharing the file descriptor
for both reading and writing, we end up triggering these invalid lseeks from
within glibc.


It turns out that the code I changed in comment #3, once upon a time, did open
the terminal 3 times.  This was changed in this commit:

  commit afe09f0b6311a4dd1a7e2dc6491550bb228734f8
  Date:   Thu Jul 18 17:20:04 2019 +0100

    Fix for using named pipes on Windows

The idea seemed to be, to use a named pipe on windows instead of a terminal.

First, I don't know anything about named pipes on windows, but...

... if we consider named pipes on Linux, I'm not convinced that using named
pipes will work here.  My assumption is that the debugger frontend would create
a named pipe, and then try to attach the MI interface to that pipe.

GDB would then be writing MI output to the pipe, and also, reading incoming
commands from the pipe.

The problem is, that when GDB writes out MI output, it will also see that
output as incoming commands.

On the other end, we have the same problem.  The front end writes commands to
the pipe and then tries to read MI output from the pipe.  But the command that
was just written will be available for reading, and so will be consumed as MI
output.

In short, you end up in a mess with everyone pumping output into the pipe and
then competing to consume that same output.

What I wonder instead is, maybe we should change the `new-ui` command. 
Currently we allow `new-ui INTERPRETER PATH-TO-PTTY`.  Maybe we should allow
something like this too: `new-ui INTERPRETER PATH-TO-INPUT-PIPE
PATH-TO-OUTPUT-PIPE PATH-TO-ERROR-PIPE`

If only one path is provided, we open it 3 times for in/out/err.  If three
paths are provided then each is opened once.  This would require the front end
to then manage three named pipes though.

Maybe named pipes on windows behave differently though...

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