|
From: Sunny D. <int...@ya...> - 2012-07-16 19:24:04
|
You are a life saver Tom. Indeed, pth wasn't built correctly. Once that was taken care of, I am up and running. Thanks a bunch! -Sunny ----- Original Message ----- From: Tom Hughes <to...@co...> To: Sunny Das <int...@ya...> Cc: "val...@li..." <val...@li...> Sent: Monday, July 16, 2012 3:07 AM Subject: Re: valgrind internal error On 16/07/12 01:36, Sunny Das wrote: > I need help with an issue while trying to run memcheck on one of our internal programs. These programs used to work in our earlier versions with valgrind 3.5 and glibc 2.11. We had to upgrade glibc to 2.13, and now, the latest valgrind versions as well as the SVN version are broken. The following is a run with the SVN code as of today. > > Core was generated by `valgrind --leak-check=full --num-callers=24 --error-limit=no --show-reachable=y'. > Program terminated with signal 11, Segmentation fault. > #0 vgPlain_get_StackTrace_wrk (tid_if_known=<optimized out>, ips=0x4030dd040, max_n_ips=100, > sps=0x0, fps=0x0, startRegs=<optimized out>, fp_max_orig=34342965240) at m_stacktrace.c:334 > 334 m_stacktrace.c: No such file or directory. The problem is that it has fallen back to a frame pointer based unwind, but that will generally fail on amd64 because the compiler will default to not using frame pointers, so when valgrind tries to dereference what it thinks is the frame pointer it will likely crash. This suggests that you have some code that hasn't been compiled with DWARF unwind information, as valgrind will use that in preference to doing a frame pointer based unwind. Given that you say this only happens with the pth library, maybe that is what doesn't have unwind information? Tom -- Tom Hughes (to...@co...) http://compton.nu/ |