| Summary: | valgrind stuck after redirecting "memcpy" | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Peter <pwang.sy> |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | philippe.waroquiers |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | valgrind prints | ||
|
Description
Peter
2016-07-07 18:21:59 UTC
With just the provided info, there is not much we can say.
Several things can be done to investigate what goes wrong:
1. add some traces e.g. start valgrind with
-v -v -v -d -d -d
2. assuming that your application is started up, you can investigate what it is doing under valgrind
using valgrind+vgdb + gdb.
3. finally, you could try to debug valgrind itself by using gdb and attach to the memcheck-ppc32 program, do a backtrace and report what it does
Created attachment 99955 [details]
valgrind prints
thanks for the quick reply. I tried with -v -v -v -d -d -d and you can see much details in attached "valgrind prints.txt". However, it was no help and last prints is still "redirected to 0xffbb644 (mempcpy) " and then valgrind just stopped printing anything. I am sure that my application was not started by valgrind. Actually, I tried many application on my linux platform and none of them worked fine with valgrind. Valgrind just printed "redirected to 0xffbb644 (mempcpy)" as the last message and was stuck there without launching my applications.
I also tried debugging valgrind with gdb and the stack call trace is below. I have no idea what's going on.
Attaching to process 1399
Reading symbols from /usr/lib/valgrind/memcheck-ppc32-linux...done.
0x6337d3d0 in ?? ()
(gdb) t a a bt
#0 0x6337d3d0 in ?? ()
#1 0x3809f8d4 in run_thread_for_a_while (two_words=0x62930020, dispatchCtrP=0x0, tid=1664228688, alt_host_addr=1658819056, use_alt_host_addr=<optimized out>)
at m_scheduler/scheduler.c:947
#2 0x00000000 in ?? ()
Effectively, there is not a lot more info. It looks however that (some) user level code is being executed, as the user stack is being extended. So, you might try to attach to the valgrind gdb server by doing gdb <your executable> and then (gdb) target remote | /usr/lib/valgrind/../../bin/vgdb --pid=XXXXX (as instructed by gdb). Assuming the above does not work or give any info, you might try with the none tool: --tool=none Also maybe try with the smallest simplest executable you have (maybe and "hello world" program, or date, or similar). Other possible options to trace are --trace-signals=yes --trace-syscalls=yes --trace-flags=00100000 --trace-notbelow=1 Just to see if something happens. But for sure, we shoot in the dark with the above NB/ when adding additional trace, still keep the -v -v -v -d -d -d Peter, can you re-run with --trace-signals=yes --trace-syscalls=yes --trace-flags=10000000 --trace-notbelow=1 ? That might give some more information. What CPU is this running on? What CPU are you running on here? Freescale MPC8377 |