| Summary: | vgdb is blocked after several tries | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Fred M <dark_footix> |
| Component: | massif | Assignee: | Nicholas Nethercote <njn> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | philippe.waroquiers, pjfloyd |
| Priority: | NOR | ||
| Version First Reported In: | 3.22 GIT | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Other | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | valgrind -d -d -d logs | ||
|
Description
Fred M
2023-12-30 17:22:42 UTC
Are you trying to attach two vgdbs to the same massif process? On what are you running ? (processor, linux version, ...). The difference between the first and second vgdb trace is that in the second case, the threads are blocked in a system call, and vgdb has to do more complex operations to wake up valgrind. Also, you launch valgrind with --vgdb-error=0. This allows to do some gdb/vgdb operations before startup. What is the reason for this in your case ? If you put two -d options, vgdb will output more debugging info. Also, you might add debugging options (-v -v -v -d -d -d) at valgrind side to see what happens there. Created attachment 164625 [details]
valgrind -d -d -d logs
Hello,
[What is the reason for this in your case ?]
For no reason, I could retry without it if needed.
[chipset] Arm
[linux] kernel 4.9 glibc 2.24
I re-run, (Please find the log in attachment )
valgrind -v -v -v -d -d -d --tool=massif --time-unit=ms --vgdb=yes --trace-children=yes --threshold=0.01 --vgdb-error=0 my_progs > /tmp
/valgrind_log.txt 2>&1
// vgdb ok :
vgdb -d detailed_snapshot /tmp/test
15:27:55.768100 searching pid in directory /tmp/ format /tmp/vgdb-pipe-from-vgdb-to-
15:27:55.768392 check_trial 0
15:27:55.768578 vgdb: using /tmp/vgdb-pipe-from-vgdb-to-5313-by-root-on-??? /tmp/vgdb-pipe-to-vgdb-from-5313-by-root-on-??? /tmp/vgdb-pipe-shared-mem-vgdb-5313-by-root-on-???
15:27:55.768756 opening /tmp/vgdb-pipe-from-vgdb-to-5313-by-root-on-??? write to pid
15:27:55.768809 opened /tmp/vgdb-pipe-from-vgdb-to-5313-by-root-on-??? write to pid fd 4
15:27:55.768872 opening /tmp/vgdb-pipe-to-vgdb-from-5313-by-root-on-??? read cmd result from pid
15:27:55.769010 opened /tmp/vgdb-pipe-to-vgdb-from-5313-by-root-on-??? read cmd result from pid fd 5
sending command detailed_snapshot /tmp/test to pid 5313
--5313-- XT_massif_print detailed
--5313-- iteration 1
--5313-- XT_print_massif ms_ec n_ec 1
--5313-- XT_massif_print producing depth 0 groups
--5313-- depth 0 n_groups 1 n_insig 0
--5313-- XT_massif_print outputting 1 depth 0 groups
--5313-- depth 1 n_groups 0 n_insig 0
15:27:55.770032 OK packet rcvd
15:27:55.770083 nr received signals: sigint 0 sigterm 0 sighup 0 sigpipe 0
15:27:55.770118 joining with invoke_gdbserver_in_valgrind_thread
/root #
/root # ls -ltr /tmp/
[...]
prw------- 1 root root 0 Jan 2 15:27 vgdb-pipe-to-vgdb-from-5313-by-root-on-???
-rw------- 1 root root 36 Jan 2 15:27 vgdb-pipe-shared-mem-vgdb-5313-by-root-on-???
prw------- 1 root root 0 Jan 2 15:27 vgdb-pipe-from-vgdb-to-5313-by-root-on-???
-rw-r--r-- 1 root root 760 Jan 2 15:27 test
-rw-r--r-- 1 root root 1967966 Jan 2 15:28 valgrind_log.txt
// vgdb ko :
/root # vgdb -d detailed_snapshot /tmp/test
15:28:14.104760 searching pid in directory /tmp/ format /tmp/vgdb-pipe-from-vgdb-to-
15:28:14.105576 check_trial 0
15:28:14.105888 vgdb: using /tmp/vgdb-pipe-from-vgdb-to-5313-by-root-on-??? /tmp/vgdb-pipe-to-vgdb-from-5313-by-root-on-??? /tmp/vgdb-pipe-shared-mem-vgdb-5313-by-root-on-???
15:28:14.106192 opening /tmp/vgdb-pipe-from-vgdb-to-5313-by-root-on-??? write to pid
15:28:14.106279 opened /tmp/vgdb-pipe-from-vgdb-to-5313-by-root-on-??? write to pid fd 4
15:28:14.106459 opening /tmp/vgdb-pipe-to-vgdb-from-5313-by-root-on-??? read cmd result from pid
15:28:14.206649 attach to 'main' pid 5313
15:28:14.206929 attach main pid PTRACE_ATTACH pid 5313
15:28:14.206979 waitstopped attach main pid before waitpid signal_expected 19
15:28:14.212162 after waitpid pid 5313 p 5313 status 0x137f WIFSTOPPED 19
15:28:14.212292 examining thread entries from tid 1 to tid 499
15:28:14.212362 found tid 1 status VgTs_WaitSys lwpid 5313
15:28:14.212396 found tid 2 status VgTs_WaitSys lwpid 5425
15:28:14.212418 attach_thread PTRACE_ATTACH pid 5425
15:28:14.212453 waitstopped attach_thread before waitpid signal_expected 19
15:28:14.212574 after waitpid pid 5425 p 5425 status 0x137f WIFSTOPPED 19
15:28:14.212616 found tid 3 status VgTs_WaitSys lwpid 5499
15:28:14.212638 attach_thread PTRACE_ATTACH pid 5499
15:28:14.212665 waitstopped attach_thread before waitpid signal_expected 19
15:28:14.212742 after waitpid pid 5499 p 5499 status 0x137f WIFSTOPPED 19
15:28:14.212781 found tid 4 status VgTs_WaitSys lwpid 5431
15:28:14.212803 attach_thread PTRACE_ATTACH pid 5431
15:28:14.212828 waitstopped attach_thread before waitpid signal_expected 19
15:28:14.226020 after waitpid pid 5431 p 5431 status 0x137f WIFSTOPPED 19
15:28:14.226214 found tid 5 status VgTs_WaitSys lwpid 5438
15:28:14.226241 attach_thread PTRACE_ATTACH pid 5438
15:28:14.226282 waitstopped attach_thread before waitpid signal_expected 19
15:28:14.230184 after waitpid pid 5438 p 5438 status 0x137f WIFSTOPPED 19
15:28:14.234720 getregs regs_bsz 72
15:28:14.234895 PTRACE_GETREGSET defined, not used (yet?) by vgdb
15:28:14.234993 getregs PTRACE_GETREGS
15:28:14.235089 detected a working PTRACE_GETREGS
15:28:14.235182 setregs regs_bsz 72
15:28:14.235275 setregs PTRACE_SETREGS
15:28:14.235378 PTRACE_CONT to invoke
15:28:14.236057 waitstopped waitpid status after PTRACE_CONT to invoke before waitpid signal_expected 19
|