Ok, I've had a quick look at that code, and I see one problem right off:
I cannot find any guarantee anywhere that the last nextnode pointer is
NULL. This will cause an infinite loop like nothing else. It may even
be intermittent to boot!
This is an easy fix: make sure that list_nodeadd() sets the nextnode
pointer of the element that it just added to NULL.
> 2. Re: list corruption (Paul J Stevens)
>
> ______________________________________________________________________
> From: Paul J Stevens <[EMAIL PROTECTED]>
> To: DBMAIL Developers Mailinglist <dbmail-dev@dbmail.org>
> Subject: Re: [Dbmail-dev] list corruption
> Date: Fri, 19 Nov 2004 09:31:37 +0100
>
>
>
> 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
>
--
|^^^ | | |^^| |^^^ Drew Northup, N1XIM |^^| | |^^^ \ / /^^\ /^^~
|__ | | | | | suoc.syr.edu |__| | |___ \/ |__| |__
| | | | | | savannah.nongnu.org/ | | | /\ | | | \
___| |__| |__| |___ projects/plex86/ | |___ |___ / \ \__/ \__/
