According to Peter L. Peres: > On Thu, 27 Sep 2001, Gilles Detillieux wrote: > >Do you get anything useful from a "bt" command in gdb? It might help > >to know where the free() or delete statement is that's causing this > >chunk_free to fail. > > #0 0x400c84ff in chunk_free (ar_ptr=0x40122300, p=0x81d6850) at > malloc.c:2948 > malloc.c:2948: No such file or directory. > (gdb) bt > #0 0x400c84ff in chunk_free (ar_ptr=0x40122300, p=0x81d6850) at > malloc.c:2948 > #1 0x400c83c1 in __libc_free (mem=0x81d6858) at malloc.c:2872 > #2 0x4005b062 in __builtin_delete (ptr=0x81d6858) > #3 0x8061901 in Queue::pop (this=0x810675c) at Queue.cc:91 > #4 0x8054c8f in Server::pop (this=0x8106738) at Server.cc:273 > #5 0x80505be in Retriever::Start (this=0xbffff510) at Retriever.cc:315 > #6 0x8055acf in main (ac=5, av=0xbffff6c4) at htdig.cc:328 > > As you can see, not very usefull. Queue::pop works on lists, just like the > previous time. I suspect that this is a libc++ bug in new().
Problems like this are the hardest ones to track down! The trouble is heap corruption can happen just about anywhere. All it takes is a stray pointer or a buffer overrun somewhere (anywhere) in the code and blammo, the allocation heap is messed up. This may result in a failure in the allocation or freeing of memory, but the bug may be elsewhere. > My suspicion of running out of VM is based on this. If there is a bug in > new() somewhere and it does stupid things if running out of VM then that > would explain why both coredumps occured at the same size, both on pointer > deallocation or indirection. I will borrow more RAM and see if that helps. > This is reelatively easy to do now. It will take another three days to get > it over. Well, if there's a bug in new(), or malloc() - which I think is what new() may end up calling - it may not be just when running out of VM that it does something stupid. It would be something that happens infrequently, though, or it would have turned up in pre-release testing. It would be interesting to see if adding RAM helps. It may just make htdig run longer before crashing. Keep us posted when you try this. > >Hmmm. I don't think running out of VM would cause htdig to crash in > >chunk_free like this. More likely, the malloc heap is getting messed > >up somehow - possibly from a buffer overrun problem - but I don't know > >where to start looking for this. > > > >I see you're running Linux, but what distribution is it? Did you install > >all update packages available for the version you're running of this > >distribution? I know that Red Hat 7.0 had C library problems that were > >corrected in an update RPM. > > I run an ancient SuSe with kernel 2.2.5 at home but this has been > stress-tested over 1 1/2 years. I only upgrade when I have to (now ?) and > enjoy long uptimes and stable performance under load. Even htdig ran > nicely until I increased the document tree size by adding material... Well, 2.2.5 is a pretty early 2.2 kernel release. I think they're up to 2.2.19 or maybe higher by now. If you're suspecting a problem in memory allocation, rather than a pointer bug right in htdig, then you'd be wise to look for a kernel update for your SuSe system, as well as any C/C++ library updates that are available for it. Ancient and stable are neither synonyms nor antonyms. How old your SuSe release is isn't as important as whether they have fixed serious bugs in it since its release. Check with SuSe if they have an errata or something similar that describes updates made available for your release. -- Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil Dept. Physiology, U. of Manitoba Phone: (204)789-3766 Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930 _______________________________________________ htdig-general mailing list <[EMAIL PROTECTED]> To unsubscribe, send a message to <[EMAIL PROTECTED]> with a subject of unsubscribe FAQ: http://htdig.sourceforge.net/FAQ.html
