Developer friendly debugging in gdb

Limits of the basic GDB interface

The main user's complain about gdb is the lack of a friendly interface. The basic interface is command line based, alternating just one line of information with the command entering prompt.
While debugging complex source code, it is quite annoying to be able to see only one line of source, without any context. The list command allows to print few lines of source code around the currently executing line, but alternating the next command with the list one is, again, not very productive. Graphical debuggers, like ddd, offer a more rich interface to gdb, but I'm used to debug over a terminal connection and ddd requires an X server.
The solution is an additional gdb built-in interface that offers a better debugging experience: TUI (text user interface).

Select on Linux is really dangerous

Why is it dangerous?

The select system call can be used to check if a file descriptor (usually a socket) is ready for reading or writing. The function accepts as an input three sets, each one containing the file descriptors of the entities (pipes, sockets, ...) to test for readability, writability or an error state.
The largest file descriptor that can be stored in these sets is limited by the FD_SETSIZE constant, that is usually equal to 1024. If a file descriptor having a value larger than FD_SETSIZE is "stored" in one of such arrays, the effects is undetermined: but generally that operation results in an invalid memory access.

So if your program can potentially use many file descriptors, it is possible that select and its sets will make it fail. The remainder of this blog shows how to replace select with poll, that is not limited by the value of the file descriptors it can handle.