|
From: Julian S. <js...@ac...> - 2012-07-16 09:01:03
|
Can you try with r12748. There was a change relating to stack unwinding and segfaults at r12749 and I would like to be sure that this is not complicating matters. svn co -r12748 svn://svn.valgrind.org/valgrind/trunk to get a suitable tree. J On Monday, July 16, 2012, Sunny Das wrote: > Folks, > > 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. > (gdb) bt > #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 #1 > 0x00000000380456d3 in vgPlain_get_StackTrace (tid=1, ips=0x4030dd040, > max_n_ips=100, sps=0x0, fps=<optimized out>, first_ip_delta=0) at > m_stacktrace.c:1086 > #2 0x0000000038045889 in vgPlain_get_and_pp_StackTrace (tid=<optimized > out>, max_n_ips=<optimized out>) at m_stacktrace.c:1125 > #3 0x00000000380302d3 in vgPlain_show_sched_status () at > m_libcassert.c:213 #4 0x00000000380303b3 in report_and_quit > (report=0x3826e859 "www.valgrind.org", startRegsIN=<optimized out>) at > m_libcassert.c:253 > #5 0x000000003803043f in panic (name=0x38279d6b "valgrind", > report=0x3826e859 "www.valgrind.org", str=<optimized out>, > startRegs=0x4030dd7a0) at m_libcassert.c:319 #6 0x0000000038030649 in > vgPlain_core_panic_at (str=0x38ad2ae8 "\023v\277\n", startRegs=0x9) at > m_libcassert.c:324 > #7 0x0000000038044579 in sync_signalhandler_from_kernel (uc=0x4030dd800, > info=<optimized out>, sigNo=11, tid=1) at m_signals.c:2433 > #8 sync_signalhandler (sigNo=11, info=<optimized out>, uc=0x4030dd800) at > m_signals.c:2490 #9 0x0000000038042220 in ?? () > #10 0x0000000000000000 in ?? () > > Let me know if you need to see some variables or state. Unfortunately, I > can't ship the core or the binaries per company policy...:( Looks like the > program generated SEGV and valgrind is trying to print the program's stack > and that's when its dying. > > Any ways to work around this? Any other ideas? Can I make valgrind not try > to dump stack and just dump core? > > > One important piece of info: all the programs are dying with the same stack > trace and all of them link against GNU PTH library. > > Thanks! > -Sunny > > > --------------------------------------------------------------------------- > --- Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |