list_nodeadd prepends nodes, so the nextnode actually points to the former
first node in the list. But you're right on the problem: no NULL at the
end. Why? There's no list_init to be found anyplace in pop* at all!
Aaron
Drew Northup <[EMAIL PROTECTED]> said:
> 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/ | |___ |___ / \ \__/ \__/
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
--
