36 lines
1.5 KiB
Markdown
36 lines
1.5 KiB
Markdown
[[!meta title="What went wrong, if accept(2) returns 0?"]]
|
|
|
|
Today I continued working on the
|
|
[[user interface support|ceofhack-ui-support-1]]
|
|
for [[ceofhack|software/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](http://git.schottelius.org/?p=EOF/ceofhack;a=commit;h=a1a4b17fae050faf3f049b15ee20985c1684f46d)
|
|
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?
|
|
|
|
[[!tag programming]]
|