On 6/16/06, Pavel Roskin <proski@xxxxxxx> wrote:
Hi, Jon! On Fri, 2006-06-16 at 23:02 -0400, Jon Smirl wrote: > My parsecvs job died after 5 hours of CPU time. Does this tell you anything? > > Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created > > Error: branch cycle > *** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 *** > *** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 *** Obviously, memory corruption. Valgrind is likely to help, but it may take 50 hours rather than 5. It may still be worth it. Make sure to use the latest version of Valgrind and compile parsecvs without optimization with full debug information. If you can get debug info for libc, install it (on Fedora: "yum install glibc-debuginfo"). > /lib/libc.so.6(__libc_free+0x179)[0x45a554f0] > parsecvs[0x804dec8] You see, even some libc symbols can be found, but parsecvs is opaque. That's why debug information is useful. Make sure to keep the sources around for debugging.
Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols? The 'Error: branch cycle' message was critical, the app was in the process of doing exit clean up with the link list error was found. If the list is linked in a circle it is likely that the routine freeing it corrupted memory. So the real error is why did I get 'Error: branch cycle'.
-- Regards, Pavel Roskin
-- Jon Smirl jonsmirl@xxxxxxxxx - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html