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.
Whew, glad I wasn't crazy. If mpatrol worked in 64bit OSes, I'd use it
to help you track this down... since it doesn't, may I suggest giving
it a try? Valgrind may help too, actually, but I've found mpatrol to
be more useful in debugging these kinds of problems.
http://www.cbmamiga.demon.co.uk/mpatrol/
Let me know if you have any questions. I normally use the flags:
--check-all --check-fork --edit --leak-table --list --log-all
--log-file mpatrol.log --prof --prof-
file mpatrol.prof --show-all --trace --trace-file mpatrol.trace
--use-debug
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?
Correct... Why not use your friendly TAILQ macros from sys/queue.h ala
queue(3)? They're pretty universal and well used. Just a thought.
-sc
--
Sean Chittenden
