GNOME Bugzilla – Bug 239886
Can't connect to IMAP server with the build of evolution Solaris+Forte
Last modified: 2013-09-10 14:03:10 UTC
When evolution runs on Solaris9, complied using Forte 6 update 2. We met this critical bug. Steps to reproduce the problem: 1. Build evolution trunk using Forte on Solaris 9 2. Create an IMAP account 3. Connect to the IMAP server Actual Results: Error message: "Error while "Reconnecting to IMAP server server_name: Could not connect to server_name:143:Error 0" Expected Results: Connect success and password dialog comes out. How often does this happen? Always. <Critical>
After a research, we want to clear several points: 1. Evolution will run different code on Solaris build using Forte compared to Linux build using gcc on some place. For example, evolution use gethostbyname(char*) to get the host infomation on Solaris while gethostbyname_r(...) to do some same thing on Linux. 2. When connect to IMAP server, "connect" method which works connecting to the server will have different errno on Solaris and on Linux. On Linux , some times errno = EINTR(is 4), while on Solaris , it is 0 always. 3. So there may be some architecural differrence when we see the comparations need attention. We will add a patch soon.
Created attachment 42139 [details] [review] patch for test
The patch can run well on Solaris and Linux both on my test. Connect to IMAP server success and evolution works well then. This patch has: 1. Memset sockaddr_in sin to 0 first. Or some of its content may be undecideble. 2. Add treatment to the condition when connect result errno is 0 or EINTR(which is the errno returned on Solaris and Linux commonly).
After careful review, we found the direct cause of this bug is the use of unthread-safe errno. This could cause many errno checks invalid. Please add a global compile switch like -D_REENTRANT and -mt in Solaris, compiled by Forteu.
just so I'm clear, the patch is no good - the real fix is to ad -D_REENTRANT and -mt to the build line. correct?
i've added gthread-2.0 to the camel cflags/libs defintion. should fix it. mail already implicitly gets -d_reentrant, but i'll add it explicitly to that and eutil just to make sure, i wonder if this will fix those smp probs? i dont know why its not using gethostbyname_r, unless solaris 9 has made gethostbyname interface mt safe, since i thought it was part of solaris. also note evo must use posix threads. solaris threads are not supported in evo.
Thanks!Alex,Jeff,Notze.I'm trying to rebuild evolution with -D_REENTRANT and -mt. But next time I make a evolution build, need I also build gal and gtkhtml and libgnomeprint and libgnomepirntui with these 2 swith? I saw some tips which says that some condition don't welcome these 2 switch. Please make a clean to their use to the evolution dependence pkgs. Thanks.
I have seen -D_reentrant when I was building gal, I think we don't need to add -D_reentrant for another lib except for evolution.
-D_REENTRANT should be added globally. Or, errno (and other global static variables) could be mismatched. Yesterday, I added a set of #ifndef _REENTRANT #define _REENTRANT 1 #endif at the very beginning of the file camel-tcp-stream-raw.c and it turns out network is ok. Today I have rebuilt evolution with -D_REENTRANT and -mt globally on. Such bugs never reappear. As to the gethostbyname_r, there should be something wrong with the configure file. When checking gethostbyname_r, -lnsl should be added while config.log shows not.