Dear Maintainer,

After opening pdf attachments from my mail client (icedove), each evince process keeps an open network connection to the mail server (long after the document has completed loading).

(I'm assuming that evince is retrieving the document, otherwise I am unsure why it needs a network connection in the first place).

The problem is that after I have 10 documents open my mail client is unable to contact (or authenticate to) the mail server as it limits the number of active connections to 10 per IP.


Evince should close the connection once the document is loaded, or better yet, load the document from /tmp and not make/keep any network connections.

The immediate workaround is to save all attachments and then open them (which is somewhat inconvenient).

Regards,
Andrew

Control: reassign 795934 icedove
Control: retitle 795934 leaks file descriptors to attachment handlers
Control: found 795934 38.1.0-1

evince does not retrieve the document itself; icedove does give it a
filename in /tmp for the attachment.

The problem is that evince is executed as a subprocess of icedove, and
icedove does not either mark its open file descriptors as close-on-exec,
or close all file descriptors (except for stdin, stdout, stderr and any
other deliberately-inherited fds) in the child process after fork() but
before exec(). Any process that executes subprocesses should do at least
one of those two things, preferably both.

As a result, file descriptors that were open in icedove (including
sockets, pipes, the cache, and mailbox files) remain open in the child
process.

I can reproduce this with a different attachment handler, which
demonstrates that this is not unique to evince: if I open an attachment
with gvim, then "ls -l /proc/$(pgrep gvim)/fd", I can see that gvim has
incorrectly inherited various open file descriptors pointing to sockets,
pipes, ~/.icedove/*/Cache/*, and ~/.icedove/*/ImapMail/*/*.msf.

Quoting the rest of Andrew's report for the icedove maintainer.

Regards,
    S