Today I continued working on the user interface support for ceofhack and created an interesting bug, which lead to other interesting "features":

The second time a user interface connected to ceofhack-0.5.4-2-ga1a4b17 it hung, and at the same time ceofhack got the input from cmd_ui on stdin:

Ignoring text (2100) (later versions send this to all peers in channel)

Digging a bit into the source, I found out that the accept() call in ui_read returns 0:

ui_handle.c:35:while((nsock = accept(fds[HP_READ], NULL, NULL)) != -1) {

I've never seen accept returning 0 before. As 0 is the value of STDIN_FILENO, this explained the strange behaviour, because helper_check_input() found the old stdin handler to be responsable for that socket (via helper_find_by_fd()).

After digging a bit deeper, I found the reason for all the confusion: helper_disable() closed all four helper file descriptors, of which only two (HP_READ and HP_WRITE) were initialised by helper_fdonly(). The other two contained the value 0, because the code is compiled and linked with the gcc debugging option -g.

As only those two are used in ceofhack, helper_disable() was fixed to close only those two.

Interesting, which ways debugging may take, isn't it?