Aaron Stone wrote:
Paul J Stevens <[EMAIL PROTECTED]> said:
In the wiki you (I assume) are suggesting that the data corruption
in lists may be caused by sharing of data between a list.c list and
a GList. If that's coming from you, what makes you say that?
That's my understanding of what you've been complaining about with respect
to list.c / GList and differently allocated memory sources. No?
Ok, well not so then.
The infinite loops we've been seeing in pop3d and imap4d occur in 2.0.0 vanilla.
No glists or any glib code for that matter occur anywhere in that code. But it's
stack corruption alright: I've concluded that in pop3.c the call to
db_update_pop is resulting in a runaway loop.
The code:
int db_update_pop(PopSession_t * session_ptr)
{
struct element *tmpelement;
u64_t user_idnr = 0;
/* get first element in list */
tmpelement = list_getstart(&session_ptr->messagelst);
while (tmpelement != NULL) {
/* check if they need an update in the database */
if (((struct message *) tmpelement->data)->
virtual_messagestatus !=
((struct message *) tmpelement->data)->messagestatus) {
Somehow this loop extends beyond the end of messagelst. This seems to me to be
indicative of stack corruption, but of course more experienced c programmers may
well conclude otherwise. The construction of the list involved looks clean to
me, but I maybe wrong.
Moving the 2.0 codebase to glist seems to me out of the question, i.e. I'm not
doing it. I'm testing the new list code for inclusion in cvs-head, but it's a
massive patch which introduces all sorts of possible memory leaks that have to
be resolved.
But all hope is not lost if we introduce some sanity checks in the top of the
loop: esp those messagestatus fields should be tested to fit the required
profile for such fields, else break the while loop. Correct?
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
