In December of 2001, Ben Jackson <ben@ben.com> posted a note to this list about trn crashes that he was having when he switched to using news.attbi.com as his news server. At the time, he posted a proposed change to list.c which received no response on this list. I also have an AT&T cable modem connection and started having problems about then as well. Recently, I looked into my own problems and found I was seeing clearly wrong values in the structures maintained by list.c. I exchanged e-mail with Ben and he sent me the patch that he's using which changes the calculation for node->low when a new node is allocated in listnum2listitem(). Ben's change looks like an improvement, but the more I look at the function in question - listnum2listitem() - the more I can't understand what functionality it or the rest of list.c is trying to support. In general, it seems to be implementing dynamically and sparsely allocated arrays. It makes some effort to allow the upper end of the allocated range (list->high) to increase beyond that specified when the array was originally created, but an incomplete effort to support a reduction in the low end (list->low). I've run trn under gdb with breakpoints in listnum2listitem() and I can say for a fact that under some circumstances when the list is article_list that attempts are made to access indices below the current list->low. Also, I am not sure what the flag LF_SPARSE means. In general, lists appear to always be sparsely allocated. As currently written, I don't think list.c fully implements the functionality required by the code that calls it. I'm happy to work on fixing that, but can't without a better idea of what its expected operating parameters are. Can somebody with a more general knowledge of the trn source code say something about this? Thanks, Bill Bogstad bogstad@pobox.com P.S. The SEGVs for me occur in walk_list() when an article_list is being deallocated. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
