SIGSEGV when connecting to a remote gdbserver running on Android

[tals]

Describe the bug
When connecting a remote gdbserver running on Android, gdbgui spams the console with SIGSEGV errors.
This works fine with the gdb terminal client, and disabling "Attempt to flush stdout after each command is run" works around the issue (similarly #195)

The workaround is a little unfortunate, since it makes it harder to deploy gdbgui to other users.

To Reproduce
Steps to reproduce the behavior:

1. invoke gdbserver (taken from the NDK) on Android
2. connect to from the NDK's gdb
3. As soon as you execute target remote :<PORT>, the bottom terminal is flooded with SIGSEGV errors

Disabling "Attempt to flush stdout after each command is run" fixes the problem.

Screenshots

Please complete the following information:

• OS: macOS High Sierra 10.13.6 (17G65)
• gdbgui version (gdbgui -v): 0.13.0.0
• gdb version (gdb -v): GNU gdb (GDB) 7.11
• browser [e.g. chrome, safari]: chrome
• python packages (pip freeze):
  click==6.7
  Flask==0.12.4
  Flask-Compress==1.4.0
  Flask-SocketIO==2.9.6
  gdbgui==0.13.0.0
  gevent==1.3.6
  greenlet==0.4.14
  itsdangerous==0.24
  Jinja2==2.10
  MarkupSafe==1.0
  pygdbmi==0.8.3.0
  Pygments==2.2.0
  python-engineio==2.2.0
  python-socketio==2.0.0
  six==1.11.0
  Werkzeug==0.14.1

Additional context
gdbgui spams the bottom console with

gdbgui noticed a signal was recieved (Segmentation fault, SIGSEGV).

If the program exited due to a fault, you can attempt to re-enter the state of the program when the fault 

occurred by clicking the below button.


Program

 received signal SIGSEGV, Segmentation fault.

0x00000000000051d0 in ?? ()

[cs01]

Seems like it might make sense to turn off the Attempt to flush stdout after each command is run option if running remotely. I'm hesitant to turn it off unconditionally because program output often does not show up until the program exits. Does that sounds like a good solution to you?

The root of the problem is that gdb is being run as a subprocess of python and not attached directly to a terminal, so the programs being debugged have their output buffered by the kernel. Using something like https://github.com/xtermjs/xterm.js would fix the root of the problem, though that is a significant change to the architecture of gdbgui.

[tals]

My understanding is that gdb mi resolves the remote fflush to the wrong address (strange, since I had pulled the relevant system solibs and pointed gdb to them), which is why invoking it causes a SIGSEGV.

with that context, yeah it makes sense to not repeatedly call fflush against remote targets, since that configuration is more fragile.

Another option is to expose this as a cmdline arg. In my use case, gdbgui gets invoked via a wrapper script that also handles all the gdbserver+adb machinery.

[cs01]

This should be fixed in gdbgui v0.14.