Created attachment 170637 [details]
lots of pipes ...

Thanks for a bug report. Could you try to find out where are these pipes from? I mean after what operation this will increase opened pipes, but doesn't close them? as this is probably from a mailer, then I would guess on something while doing auto-refresh on the account, which might be something like junk test and/or report through spam assassin or bogofilter. Are you using any of these? Is enabling/disabling of these doing any difference in opened pipes when calling Send/Receive? (might depends whether you receive any new message too, and whether you are not using "do not check junk when sender in my address book" option)

Just got it again. Trace appended. I have no idea where the pipes are from.

I do not have "Check incoming messages for junk" enabled in 'Junk' settings. I only have "Check custom headers for junk" - and I do not have "Do not mark messages as junk if sender is in my addressbook" set.


(evolution:22900): evolution-composer-autosave-WARNING **: Error opening directory '/home/michael/.local/share/evolution': Too many open files
[New Thread 0x822fcb70 (LWP 21235)]

(evolution:22900): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
**
camel:ERROR:camel-mime-message.c:627:camel_mime_message_get_subject: assertion failed: (mime_message)

Program received signal SIGABRT, Aborted.
0xffffe430 in __kernel_vsyscall ()
(gdb) bt

+ Trace 224131

Thread 21357 is not a good sign ;-)

all other threads quiescent. I am using:

$ rpm -q evolution evolution-data-server
evolution-2.32.20100914-4.5.i586
evolution-data-server-2.32.20100914-8.16.i586

And it has been running for a few days - probably with a composer window open overnight (or somesuch).

Could you try to get list of newly opened file descriptors after some actions, please? I tried keep evolution just running, opening and closing composer, doing automatic Send/Receive and such, and even some actions are adding new file descriptors, then they either remove them again (on composer close), or do not open them again the next time I try the same thing.

Please get diff of opened file descriptors between the time before you let it running and when you return to it back (after night or what is your "reproducer"), so we will see what was added. Bonus points if you'll be able to find the exact action which is causing this, because "let it running over night" limits testing ability slightly. :)

template crash is fixed in bug 633854

bug 516351 and bug 478711 may be related

Created attachment 191807 [details]
gdb trace

Got hit today in master (3.1.4)

*** Bug 555561 has been marked as a duplicate of this bug. ***

I'm seeing this with evolution 3.1.4. Checking /proc/PID/fd/ I see a leak of two fds (two ends of a pipe) every time I move from one message to another within a folder (preview enabled). This results in hitting the fd limit quite quickly.

(In reply to comment #9)
> I'm seeing this with evolution 3.1.4. Checking /proc/PID/fd/ I see a leak of
> two fds (two ends of a pipe) every time I move from one message to another
> within a folder (preview enabled). This results in hitting the fd limit quite
> quickly.

What is the account type you see this on, please? By any chance, is it IMAPX?

(In reply to comment #10)
> (In reply to comment #9)
> > I'm seeing this with evolution 3.1.4. Checking /proc/PID/fd/ I see a leak of
> > two fds (two ends of a pipe) every time I move from one message to another
> > within a folder (preview enabled). This results in hitting the fd limit quite
> > quickly.
> 
> What is the account type you see this on, please? By any chance, is it IMAPX?

Yes, this is with IMAPX.

Thanks for the update. That might mean that your issue is related to bug #655272. (Or vice versa, it depends in what way you are looking at this.)

Seems this should be closed as a duplicate of 655272

*** This bug has been marked as a duplicate of bug 655272 ***