GNOME Bugzilla – Bug 346443
Preview page stops updating after displaying a specified mail
Last modified: 2013-09-13 00:48:37 UTC
Please describe the problem: The preview page can't be updated to reflect another message after displaying a specified mail. Steps to reproduce: 1.Lauch evolution 2.Make sure the preview window is enabled. 3.Click on the attached mail in the mail browser window, the preview window will display the content of the mail. 4.Click on aother mail, the preview page doesn't change. Actual results: The preview window can't display other mails. Expected results: When you click on another mail, the preview window should change to reflect the mail's content. Does this happen every time? Yes Other information:
Created attachment 68287 [details] The mail which causes the preview window stops updating
The bug doesn't happen on evolution-data-server 1.7.2, but can be reproduced on evolution-data-server 1.7.3. I found the changes to e-msgport.c caused the problem. The problem starts to happend on version 1.7 of e-msgport.c. The following changes cause the bug: 2006-05-31 Jeffrey Stedfast <fejj@novell.com> Hopeful fix for Novell bug #176277 * libedataserver/e-msgport.c: Changed the structure of EMsgPort slightly to make ::prpipe a union more like ::pipe. (e_pipe): For convenience, on error set the fds each to -1. (e_prpipe): New convenience function much like e_pipe but for PRFileDescs. (e_msgport_new): Always create the pipes here now instead of creating them on demand. (e_msgport_fd): Simply return the pipe fd (no longer creates the pipe on demand). (e_msgport_prfd): Same.
To reproduce this bug, you must use mozilla nss api. i.e, you have to define macro HAVE_NSS.
The bug happens in function e-msgport.c::e_msgport_new::PR_CreatePipe, it reports an error PR_UNKNOWN_ERROR. From the source code of PR_CreatePipe, we can know that system call "pipe" failed which sets errno to EMFILE: to many open files. We can get a conclusion that is a regression of fix for Novell bug #176277.
that means that there's too many file descriptors open, which means there's no way to fix this bug with any tom-foolery in the e-msgport code you can easily work around this by upping the number of allowed fd's of your system.
Jeffrey, you are right. In solaris, the default fd limit number is 256, however, on some linux platforms, the default number is 1024. Jeff Cai will provide a patch soon to do sth. as in mozilla and firefox: http://lxr.mozilla.org/mozilla/source/xpfe/bootstrap/nsSigHandlers.cpp#215
Created attachment 68449 [details] [review] Set number of file descriptors that a process may create to 512 for Solaris This section of code will only be used in Solaris, so I define a preprocessor macro SOLARIS.
Created attachment 68452 [details] [review] Set number of file descriptors that a process may create to 512 for Solaris
Varadhan : poke !
Looks like releated to Bug#350907. Also, raising fds from the application doesn't sound okay to me.
No, we don't use the pipe filter. As Jeff pointed in comment 2, it is related to fejj's patch. And from http://mail.gnome.org/archives/evolution-list/2006-August/msg00159.html It seems it happend on linux, too. This might be a stopper for Evolution 2.16. Could Novell QA do some test on this bug?
1024 fds on Linux. And I still get EMFILE errors trying to start evolution. Perhaps I could increase the number allowed (I have not really looked into it), but seriously, you need more than 1024 fds? I certainly don't understand why, but that just sounds ridiculous. Why so many pipes? Using strace I see evolution creating pipe after pipe until it tries to open too many and then crashes.
*** This bug has been marked as a duplicate of 348888 ***