[Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils
Hi, Harish I built evolution 2.6 on my Solaris X86 the other day. The build process was successful, however, as soon as I started evolution-2.6, it crashed. We investigated this problem and arrived at the following conclusions: camel_vee_folder_hash_folder in evolution-data-server/camle/camel-vee-folder.c invokes functions including md5_init, md5_update and md5_final. The fact is, two copies of md5_utils.[c|h] with exactly same functions defined, exist in the evolution system, one in evolution-data-server/libedataser and the other in evolution/e-utils. Camel-vee-folder.c includes evolution-data-server/libedataserver/md5-utils.h, but when evolution runs, the md5_* functions in evolution/e-utils/md5-utils.c instead of those in evolution-data-server/libedataserver/md5-utils.c are invoked, which we think should not be the case. Currently, the MD5Context structures in evolution-data-server/libedataserver/md5-utils.h and evolution/e-utils/md5-utils.h are different with the first one not having a doByteReverse member. When evolution-2.6 is run, the ctx variable in camel_vee_folder_hash_folder does not have doByteReverse, but it is passed into the md5_* functions, a doByteReverse (which actually points to something else in the stack) is modified. This is the reason why evolution-2.6 crashes under Solaris. We are curious why it works well under linux with the stack illegally changed. When we went further into this issue, we saw that there's a huge lot of duplication in evolution-data-server/libedataser and evolution/e-utils. With such duplications, similar problems may surface in the future when one copy of the code is modified while the other remains unchanged. We think that something should be done to solve this problem. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils
On Thu, 2005-11-24 at 16:33 +0800, Irene wrote: Currently, the MD5Context structures in evolution-data-server/libedataserver/md5-utils.h and evolution/e-utils/md5-utils.h are different with the first one not having a doByteReverse member. Hm, that would be my fault: I've been working with e-d-s and cleaned up the libedataserver/md5-utils to remove the doByteReverse member. The obvious solution is to remove md5-utils from e-utils. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils
On Thu, 2005-11-24 at 09:19 +, Ross Burton wrote: On Thu, 2005-11-24 at 16:33 +0800, Irene wrote: Currently, the MD5Context structures in evolution-data-server/libedataserver/md5-utils.h and evolution/e-utils/md5-utils.h are different with the first one not having a doByteReverse member. Hm, that would be my fault: I've been working with e-d-s and cleaned up the libedataserver/md5-utils to remove the doByteReverse member. The obvious solution is to remove md5-utils from e-utils. It looks as if the md5-utils in e-util isn't used at all in Evolution, OK to remove it from evolution HEAD? Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: About evolution-data-server/libedataser and evolution/e-utils
On Thu, 2005-11-24 at 16:33 +0800, Irene wrote: Hi, Harish I built evolution 2.6 on my Solaris X86 the other day. The build process was successful, however, as soon as I started evolution-2.6, it crashed. We investigated this problem and arrived at the following conclusions: camel_vee_folder_hash_folder in evolution-data-server/camle/camel-vee-folder.c invokes functions including md5_init, md5_update and md5_final. The fact is, two copies of md5_utils.[c|h] with exactly same functions defined, exist in the evolution system, one in evolution-data-server/libedataser and the other in evolution/e-utils. Right. This is the result of an incomplete migration of the files and the existence of duplicates is a known structural issue - though we have not seen bugs/functional breakage yet. This just explains why the problem has existed w/o crying for attention for this long- we do need to fix it. Camel-vee-folder.c includes evolution-data-server/libedataserver/md5-utils.h, but when evolution runs, the md5_* functions in evolution/e-utils/md5-utils.c instead of those in evolution-data-server/libedataserver/md5-utils.c are invoked, which we think should not be the case. Building with an eye for this detail (building against the right function) solves this problem. This is why it works on Linux, i guess. I need to see how Solaris x86 handles this. When we went further into this issue, we saw that there's a huge lot of duplication in evolution-data-server/libedataser and evolution/e-utils. With such duplications, similar problems may surface in the future when one copy of the code is modified while the other remains unchanged. We think that something should be done to solve this problem. yes. let us get this discussed on the meeting next week. I would love if someone can volunteer to do a detailed audit on this duplication and chalk out how we can get rid of the cruft. (In some cases, I suspect they may not be exact duplicates and both may be required in that form by different pieces). Takers, you can count on me to chip in to lend a hand :-) Cheers, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils
On Thu, 2005-11-24 at 09:27 +, Ross Burton wrote: On Thu, 2005-11-24 at 09:19 +, Ross Burton wrote: On Thu, 2005-11-24 at 16:33 +0800, Irene wrote: Currently, the MD5Context structures in evolution-data-server/libedataserver/md5-utils.h and evolution/e-utils/md5-utils.h are different with the first one not having a doByteReverse member. Hm, that would be my fault: I've been working with e-d-s and cleaned up the libedataserver/md5-utils to remove the doByteReverse member. The obvious solution is to remove md5-utils from e-utils. It looks as if the md5-utils in e-util isn't used at all in Evolution, OK to remove it from evolution HEAD? I agree. Mailer guys, anyone think otherwise ? Ross ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils
Hi, Md5-utils.ch are not the only files that are duplicated. Most of the files in evolution/e-util have similar copies in evolution-data-server/libedataserver. We are worried that in the future, if files in libedataserver are modified with their counterparts in e-util unchanged, more annoying bugs will come into being. BTW, we've debugged with evolution-2.6 under Linux and found that functions e-util/md5-utils.c were wrongly used too. The reason why evolution survives under linux with this mistake is probably due to the differences between Linux and Solaris structures. You may have a try by setting a breakpoint at camel_vee_folder_has_folder, print ctx (you'll see no doByteReverse here), and step in to md5_init, also print *ctx, now, doByteReverse comes out somehow. Thanks --Irene On Thu, 2005-11-24 at 18:09, Harish Krishnaswamy wrote: On Thu, 2005-11-24 at 09:27 +, Ross Burton wrote: On Thu, 2005-11-24 at 09:19 +, Ross Burton wrote: On Thu, 2005-11-24 at 16:33 +0800, Irene wrote: Currently, the MD5Context structures in evolution-data-server/libedataserver/md5-utils.h and evolution/e-utils/md5-utils.h are different with the first one not having a doByteReverse member. Hm, that would be my fault: I've been working with e-d-s and cleaned up the libedataserver/md5-utils to remove the doByteReverse member. The obvious solution is to remove md5-utils from e-utils. It looks as if the md5-utils in e-util isn't used at all in Evolution, OK to remove it from evolution HEAD? I agree. Mailer guys, anyone think otherwise ? Ross ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils
Md5-utils.ch are not the only files that are duplicated. Most of the files in evolution/e-util have similar copies in evolution-data-server/libedataserver. Yes. To be more precise, evolution-exchange in addition to e-util and libedataserver :-). I've created a wiki page http://live.gnome.org/EvolutionEUtilDieDieDie listing the files which are identical, which are different, etc, to track this. Ross Thanks Ross :-). That really gets us moving to the next step. Shreyas had taken the cause up [http://go-evolution.org/Evo2.6#Misc] early during the cycle and IIRC, had started doing something on it too. Shreyas ? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils
On Fri, 2005-11-25 at 23:49 +0530, Shreyas Sriniavasan wrote: On Thu, 2005-11-24 at 16:48 +0530, Harish Krishnaswamy wrote: Md5-utils.ch are not the only files that are duplicated. Most of the files in evolution/e-util have similar copies in evolution-data-server/libedataserver. Thanks Ross :-). That really gets us moving to the next step. Shreyas had taken the cause up [http://go-evolution.org/Evo2.6#Misc] early during the cycle and IIRC, had started doing something on it too. Shreyas ? Oh well, i had started doing something about it but it would entail moving most of the duplicate code out of e-util. This ofcourse would mean that most of the current e-util dependencies would then also depend on libedataserver. We never reached a consensus on whether thats a valid thing to do. If we can have consensus on that then doing it is just massive sed-awk operation. Ofcourse, a lot of those code werent in sync either when i last checked. We need to figure out if we need to make a new gal out of libedataserver. It needs to have stuff which most of evolution and e-d-s can link to. As evolution obviously depends on libedataserver already, surely for the files which are identical there is no problem at all? That leaves the files which have the same name yet are different (e-account, e-util) to be merged somehow, and then e-util can become a place for purely Evolution utility functions. http://live.gnome.org/EvolutionEUtilDieDieDie summarises the status for each of the files in e-util/. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils
On Thu, 2005-11-24 at 18:57 +, Ross Burton wrote: As evolution obviously depends on libedataserver already, surely for the files which are identical there is no problem at all? My thoughts exactly. I couldn't control myself, sorry, and went ahead with one of the duplicates: I changed the inclusions of e-time-utils.h in evolution end evolution-exchange to include it from libedataserver instead, and committed. Now the evolution copy of e-time-utils.h can be dropped from being installed. Presumably we can drop e-time-utils.c also from the sources of libeutil, or does Evo need to maintain 100% ABI compatibility in its shared libraries between releases? Is there 3rd-party code (plugins) in the wild that would expect to find these entry points in the libeutil shared library? I think it would be fine to just go ahead with changes like this that are obviously right and don't affect code behaviour, instead of waiting for discussion and approval which might never appear. --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
