On Thu, 27 Sep 2001, Gilles Detillieux wrote:
>According to Peter L. Peres: >> Ok, I got another core ;(. This is from snapshot 3.1.6: >> >> here is gdb info: >> >> This GDB was configured as "i686-pc-linux-gnu"... >> Core was generated by `./htdig -ias -v -c ../conf/htdig.conf'. >> Program terminated with signal 11, Segmentation fault. >> Reading symbols from /usr/lib/libz.so.1...done. >> Reading symbols from /usr/lib/libstdc++.so.2.9...done. >> Reading symbols from /lib/libm.so.6...done. >> Reading symbols from /lib/libc.so.6...done. >> Reading symbols from /lib/ld-linux.so.2...done. >> Reading symbols from /lib/libnss_files.so.1...done. >> #0 0x400c84ff in chunk_free (ar_ptr=0x40122300, p=0x81d6850) at >> malloc.c:2948 >> malloc.c:2948: No such file or directory. >> >> Do you have further suggestions ? > >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(). >> This time the core file is also the same >> size as the previous time: >> >> 137723904 Sep 27 16:40 core 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. >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... thanks, Peter _______________________________________________ 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
