[valgrind] [Bug 383275] massif valgrind: m_xarray.c:162 (ensureSpaceXA): Assertion '!xa->arr' failed
https://bugs.kde.org/show_bug.cgi?id=383275 --- Comment #3 from Fred M <dark_foo...@yahoo.fr> --- not reproduced on the rev 16470 . -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383275] New: [mipsel] valgrind: m_xarray.c:162 (ensureSpaceXA): Assertion '!xa->arr' failed.
https://bugs.kde.org/show_bug.cgi?id=383275
Bug ID: 383275
Summary: [mipsel] valgrind: m_xarray.c:162 (ensureSpaceXA):
Assertion '!xa->arr' failed.
Product: valgrind
Version: 3.13.0
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Severity: crash
Priority: NOR
Component: massif
Assignee: n...@valgrind.org
Reporter: dark_foo...@yahoo.fr
Target Milestone: ---
Dear Valgrind,
By running the valgrind 3.13 on a mipsel chipset. I have the following crash.
It means to appear on the first "vgdb detailed_snapshot "
valgrind: m_xarray.c:162 (ensureSpaceXA): Assertion '!xa->arr' failed.
host stacktrace:
==1517==at 0x5800AF88: show_sched_status_wrk (m_libcassert.c:355)
==1517==by 0x5800B170: report_and_quit (m_libcassert.c:426)
==1517==by 0x5800B374: vgPlain_assert_fail (m_libcassert.c:492)
==1517==by 0x580366E4: vgPlain_addToXA (m_xarray.c:162)
==1517==by 0x58039C68: vgPlain_XT_massif_print (m_xtree.c:187)
==1517==by 0x580029A0: write_snapshots_to_file (ms_main.c:1764)
==1517==by 0x58002BF4: handle_snapshot_monitor_command (ms_main.c:1815)
==1517==by 0x58002DC8: handle_gdb_monitor_command.clone.2 (ms_main.c:1884)
==1517==by 0x58005AC0: ms_handle_client_request (ms_main.c:1636)
==1517==by 0x5802A360: wrap_tool_handle_client_request (m_tooliface.c:282)
==1517==by 0x580701C4: handle_gdb_monitor_command (server.c:599)
==1517==by 0x58070734: handle_query (server.c:777)
==1517==by 0x58071AAC: server_main (server.c:1225)
==1517==by 0x58069250: call_gdbserver (m_gdbserver.c:721)
==1517==by 0x5806A4C8: vgPlain_gdbserver (m_gdbserver.c:788)
==1517==by 0x58077E44: run_thread_for_a_while (scheduler.c:1025)
==1517==by 0x5807A178: vgPlain_scheduler (scheduler.c:1344)
==1517==by 0x58091018: run_a_thread_NORETURN (syswrap-linux.c:103)
==1517==by 0x580913D4: vgModuleLocal_start_thread_NORETURN
(syswrap-linux.c:320)
==1517==by 0x580CE718: ??? (in /usr/lib/valgrind/massif-mips32-linux)
sched status:
running_tid=2
Thread 1: status = VgTs_WaitSys (lwpid 1517)
==1517==at 0x56DE37C: __lll_lock_wait (lowlevellock.c:49)
==1517==by 0x56E213C: pthread_mutex_lock (pthread_mutex_lock.c:87)
==1517==by 0x6338E78: SefClientLoop_add (libsefclient-loop.c:323)
==1517==by 0x41E27C: APPINIT_InitStart (init_app.c:790)
==1517==by 0x420A38: main (main.c:171)
Thread 2: status = VgTs_Runnable (lwpid 1757)
==1517==at 0x56E37C0: pthread_equal (pthread_equal.c:27)
==1517==by 0x660C5B4: B_Mutex_Lock (in /usr/lib/libb_os.so)
Thread 3: status = VgTs_WaitSys (lwpid 1758)
==1517==at 0x64B8A84: __syscall_nanosleep (nanosleep.c:22)
==1517==by 0x64B8B2C: nanosleep (nanosleep.c:33)
==1517==by 0x59713B0: TIME_Sleep (time.c:260)
==1517==by 0x59739A0: TIME_TimerThread (timer.c:114)
==1517==by 0x56E6584: start_thread (pthread_create.c:297)
==1517==by 0x56DC0AC: __thread_start (clone.S:146)
Thread 4: status = VgTs_WaitSys (lwpid 1759)
==1517==at 0x64BA600: ioctl (ioctl.c:24)
==1517==by 0x48987B4: ioctl (libc_overload.c:325)
==1517==by 0x66BD950: ??? (in /usr/lib/libnexus.so)
Thread 5: status = VgTs_WaitSys (lwpid 1760)
==1517==at 0x56DF5E4: pthread_cond_timedwait (pthread_cond_timedwait.c:162)
==1517==by 0x679F6DC: BKNI_WaitForEvent (in /usr/lib/libnexus.so)
Thread 6: status = VgTs_WaitSys (lwpid 1761)
==1517==at 0x56DF5E4: pthread_cond_timedwait (pthread_cond_timedwait.c:162)
==1517==by 0x679F6DC: BKNI_WaitForEvent (in /usr/lib/libnexus.so)
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
==1517== Reset valgrind output to log (orderly_finish)
readchar: Got EOF
error reading packet
My execution method :
valgrind --tool=massif --threshold=0.1 --time-unit=ms --vgdb=yes
--vgdb-error=0 my_prog &
sleep 20
vgdb run
sleep 1
vgdb detailed_snapshot massif${DATE_TIME_OF_DAY}_${i}.out
By removing the argument : --vgdb=yes --vgdb-error=0 , the bug is not seen .
Regards,
Frédéric
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 391861] Massif Assertion 'n_ips >= 1 && n_ips <= VG_(clo_backtrace_size)'
https://bugs.kde.org/show_bug.cgi?id=391861 Fred M <dark_foo...@yahoo.fr> changed: What|Removed |Added CC||dark_foo...@yahoo.fr --- Comment #5 from Fred M <dark_foo...@yahoo.fr> --- confirmed resolved. Thanks Philippe -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 344802] disInstr(arm): unhandled instruction: 0xEC510F1E
https://bugs.kde.org/show_bug.cgi?id=344802 Fred M changed: What|Removed |Added CC||dark_foo...@yahoo.fr --- Comment #19 from Fred M --- Validated OK on the build git : commit 4c9bd311660bf4c1f9228519223214b6a50935ec from Wed Mar 21 23:24:09 2018 +0100 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 475208] error: cannot take snapshot before execution has started
https://bugs.kde.org/show_bug.cgi?id=475208 --- Comment #1 from Fred M --- I workarounded like this : sleep 10 vgdb detailed_snapshot my_output.out while [[ $? != 0 ]]; do sleep 60 vgdb detailed_snapshot my_output.out done -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 475208] New: error: cannot take snapshot before execution has started
https://bugs.kde.org/show_bug.cgi?id=475208 Bug ID: 475208 Summary: error: cannot take snapshot before execution has started Classification: Developer tools Product: valgrind Version: 3.22 GIT Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: massif Assignee: n...@valgrind.org Reporter: dark_foo...@yahoo.fr Target Milestone: --- SUMMARY By running valgrind memory leak with a heavy application : valgrind --tool=massif my_apps & The detail_snapshot is failing : vgdb detailed_snapshot /tmp/massif2023-10-04_12-21-23_0.out sending command detailed_snapshot /tmp/massif2023-10-04_12-21-23_0.out to pid 1941 error: cannot take snapshot before execution has started Instead of adding a temporization with "sleep" between the valgrind and vgdb command. Is there or could it have a function to wait that Valgrind is ready ? A blocking/sync wait argument to the vgdb? or an option/return vgdb to know everything is ready? I can do the detailed_snapshot. Regards, Frédéric SOFTWARE/OS VERSIONS Linux/KDE Plasma: ARM / linux -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 475634] New: valgrind is no starting
https://bugs.kde.org/show_bug.cgi?id=475634 Bug ID: 475634 Summary: valgrind is no starting Classification: Developer tools Product: valgrind Version: 3.22 GIT Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: massif Assignee: n...@valgrind.org Reporter: dark_foo...@yahoo.fr Target Milestone: --- SUMMARY I am running the git master version of 03 October 23. I am launching a heavy software Ran this : valgrind '--tool=massif' '--time-unit=ms' '--vgdb=yes' '--vgdb-error=0' '--trace-children=yes' '--threshold=0.01' '--main-stacksize=1000' my_soft & Valgrind is starting with this : ==2807== Massif, a heap profiler ==2807== Copyright (C) 2003-2017, and GNU GPL'd, by Nicholas Nethercote ==2807== Using Valgrind-3.22.0.GIT and LibVEX; rerun with -h for copyright info But as I have a backtrace and this warning : ==2807== If you believe this happened as a result of a stack ==2807== overflow in your program's main thread (unlikely but ==2807== possible), you can try to increase the size of the ==2807== main thread stack using the --main-stacksize= flag. ==2807== The main thread stack size used in this run was 10002432. I re-do : valgrind '--tool=massif' '--time-unit=ms' '--vgdb=yes' '--vgdb-error=0' '--trace-children=yes' '--threshold=0.01' '--main-stacksize=1200' my_soft & I have no more the starting log: "Massif, a heap profiler" and : vgdb detailed_snapshot /tmp/massif2023-10-15_00-02-50_0.out vgdb error: no FIFO found and no pid given It is as "valgrind is not started at all" and Strangely by removing the "&" at the end of the line valgrind '--tool=massif' '--time-unit=ms' '--vgdb=yes' '--vgdb-error=0' '--trace-children=yes' '--threshold=0.01' '--main-stacksize=1200' my_soft I see the "Massif, a heap profiler" boot log. SOFTWARE/OS VERSIONS Linux/KDE Plasma: ARM chipset -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 465176] New: disInstr(thumb): unhandled instruction: 0xF2AD 0x0440
https://bugs.kde.org/show_bug.cgi?id=465176 Bug ID: 465176 Summary: disInstr(thumb): unhandled instruction: 0xF2AD 0x0440 Classification: Developer tools Product: valgrind Version: 3.20.0 Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: dark_foo...@yahoo.fr Target Milestone: --- SUMMARY *** disInstr(thumb): unhandled instruction: 0xF2AD 0x0440 ==4476== valgrind: Unrecognised instruction at address 0xa8a2a49. ==4476==at 0xA8A2A48: ??? ==4476== Your program just tried to execute an instruction that Valgrind ==4476== did not recognise. There are two possible reasons for this. ==4476== 1. Your program has a bug and erroneously jumped to a non-code ==4476==location. If you are running Memcheck and you just saw a ==4476==warning about a bad jump, it's probably your program's fault. ==4476== 2. The instruction is legitimate but Valgrind doesn't handle it, ==4476==i.e. it's Valgrind's fault. If you think this is the case or ==4476==you are not sure, please let us know and we'll try to fix it. ==4476== Either way, Valgrind will now raise a SIGILL signal which will ==4476== probably kill your program. ==4476== ==4476== Process terminating with default action of signal 4 (SIGILL) ==4476== Illegal opcode at address 0xA8A2A49 ==4476==at 0xA8A2A48: ??? ==4476== (action on fatal signal) vgdb me ... *** STEPS TO REPRODUCE Hello, I am running a webkit for wayland on architecture ARM 32 bits with libc-2.24 / GCC 6.3 this message appears: disInstr(thumb): unhandled instruction: 0xF2AD 0x0440 and valgrind stops Is there anything I could add to help for the issue? If you have patches, I am ready to test. SOFTWARE/OS VERSIONS Linux : kernel 4.9 embedded system -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 465176] disInstr(thumb): unhandled instruction: 0xF2AD 0x0440
https://bugs.kde.org/show_bug.cgi?id=465176 --- Comment #1 from Fred M --- reproduced also with the current valgrind git master -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 465176] disInstr(thumb): unhandled instruction: 0xF2AD 0x0440
https://bugs.kde.org/show_bug.cgi?id=465176 --- Comment #2 from Fred M --- note to myself: linked to webkit, to workaround this issue, I can do : JavaScriptCoreUseJIT=0 JSC_useFTLJIT=0 valgrind WPE_X -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 475634] valgrind is not starting
https://bugs.kde.org/show_bug.cgi?id=475634 --- Comment #3 from Fred M --- Maybe, I found the root cause, After the vagrind & I do a "sleep" https://bugs.busybox.net/show_bug.cgi?id=15619 Bug 15631 - sleep command after '&' in a shell script has no effect The sleep is not executed. I am waiting a busybox > 1.36.1 to close the current bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 479191] New: vgdb is blocked after several tries
https://bugs.kde.org/show_bug.cgi?id=479191 Bug ID: 479191 Summary: vgdb is blocked after several tries Classification: Developer tools Product: valgrind Version: 3.22 GIT Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: massif Assignee: n...@valgrind.org Reporter: dark_foo...@yahoo.fr Target Milestone: --- Hello, I have a strange behavior with a specific program, on the second vgdb request, the vgdb is blocking. I runned with "vgdb -d" to have more log, maybe the current log would be clever for someone ? SUMMARY *** valgrind '--tool=massif' '--time-unit=ms' '--vgdb=yes' '--vgdb-error=0' '--trace-children=yes' '--threshold=0.01' '--detailed-freq=1' '--massif-out-file=/tmp/massif.out' '--peak-inaccuracy=0.0' '--max-snapshots=1000' my_progs ==4685== Massif, a heap profiler ==4685== Copyright (C) 2003-2017, and GNU GPL'd, by Nicholas Nethercote ==4685== Using Valgrind-3.22.0.GIT and LibVEX; rerun with -h for copyright info ==4685== Command: ==4685== (action at startup) vgdb me ... ==4685== target remote | /usr/libexec/valgrind/../../bin/vgdb --pid=4685 //first vgdb OK vgdb -d '--cmd-time-out=2' detailed_snapshot /tmp/massif2023-12-30_17-56-45_0.out 17:57:08.067721 searching pid in directory /tmp/ format /tmp/vgdb-pipe-from-vgdb-to- 17:57:08.069624 check_trial 0 17:57:08.070003 vgdb: using /tmp/vgdb-pipe-from-vgdb-to-5122-by-root-on-??? /tmp/vgdb-pipe-to-vgdb-from-5122-by-root-on-??? /tmp/vgdb-pipe-shared-mem-vgdb-5122-by-root-on-??? 17:57:08.070295 opening /tmp/vgdb-pipe-from-vgdb-to-5122-by-root-on-??? write to pid 17:57:08.070511 opened /tmp/vgdb-pipe-from-vgdb-to-5122-by-root-on-??? write to pid fd 4 17:57:08.070653 opening /tmp/vgdb-pipe-to-vgdb-from-5122-by-root-on-??? read cmd result from pid 17:57:08.070755 opened /tmp/vgdb-pipe-to-vgdb-from-5122-by-root-on-??? read cmd result from pid fd 5 sending command detailed_snapshot /tmp/massif2023-12-30_17-56-45_0.out to pid 5122 17:57:08.072446 OK packet rcvd 17:57:08.072597 nr received signals: sigint 0 sigterm 0 sighup 0 sigpipe 0 17:57:08.072647 joining with invoke_gdbserver_in_valgrind_thread //Second vgdb blocked vgdb -d '--cmd-time-out=2' detailed_snapshot /tmp/massif2023-12-30_17-56-45_1.out 18:02:11.219325 searching pid in directory /tmp/ format /tmp/vgdb-pipe-from-vgdb-to- 18:02:11.219495 check_trial 0 18:02:11.219752 vgdb: using /tmp/vgdb-pipe-from-vgdb-to-5122-by-root-on-??? /tmp/vgdb-pipe-to-vgdb-from-5122-by-root-on-??? /tmp/vgdb-pipe-shared-mem-vgdb-5122-by-root-on-??? 18:02:11.220031 opening /tmp/vgdb-pipe-from-vgdb-to-5122-by-root-on-??? write to pid 18:02:11.220079 opened /tmp/vgdb-pipe-from-vgdb-to-5122-by-root-on-??? write to pid fd 4 18:02:11.220127 opening /tmp/vgdb-pipe-to-vgdb-from-5122-by-root-on-??? read cmd result from pid 18:02:11.320018 IO for command started 18:02:11.421249 waitstopped attach main pid before waitpid signal_expected 19 - status 0x137f WIFSTOPPED 19 18:02:11.461675 examining thread entries from tid 1 to tid 499 18:02:11.461912 found tid 1 status VgTs_WaitSys lwpid 5122 18:02:11.461963 found tid 2 status VgTs_WaitSys lwpid 5171 18:02:11.461986 attach_thread PTRACE_ATTACH pid 5171 18:02:11.462028 waitstopped attach_thread before waitpid signal_expected 19 18:02:11.463665 after waitpid pid 5171 p 5171 status 0x137f WIFSTOPPED 19 18:02:11.463838 found tid 3 status VgTs_WaitSys lwpid 5274 18:02:11.463887 attach_thread PTRACE_ATTACH pid 5274 18:02:11.463924 waitstopped attach_thread before waitpid signal_expected 19 18:02:11.463953 after waitpid pid 5274 p 5274 status 0x137f WIFSTOPPED 19 18:02:11.463986 found tid 4 status VgTs_WaitSys lwpid 5184 18:02:11.464069 attach_thread PTRACE_ATTACH pid 5184 18:02:11.495196 waitstopped attach_thread before waitpid signal_expected 19 18:02:11.496582 after waitpid pid 5184 p 5184 status 0x137f WIFSTOPPED 19 18:02:11.496806 found tid 5 status VgTs_WaitSys lwpid 5204 CH pid 5204 18:02:11.496951 waitstopped attach_thread before waitpid signal_expected 19 18:02:11.497011 after waitpid pid 5204 p 5204 status 0x137f WIFSTOPPED 19 18:02:11.501070 getregs regs_bsz 72 18:02:11.501129 PTRACE_GETREGSET defined, not used (yet?) by vgdb 18:02:11.501151 getregs PTRACE_GETREGS 18:02:11.501173 detected a working PTRACE_GETREGS 18:02:11.501195 setregs regs_bsz 72 18:02:11.501216 setregs PTRACE_SETREGS 18:02:11.501237 PTRACE_CONT to invoke 18:02:11.501261 waitstopped waitpid status after PTRACE_CONT to invoke before waitpid signal_expected 19 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 479191] vgdb is blocked after several tries
https://bugs.kde.org/show_bug.cgi?id=479191 --- Comment #3 from Fred M --- Created attachment 164625 --> https://bugs.kde.org/attachment.cgi?id=164625=edit 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 root36 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 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 475634] valgrind is not starting
https://bugs.kde.org/show_bug.cgi?id=475634 Fred M changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are watching all bug changes.
[massif-visualizer] [Bug 488671] New: how to build with Ubuntu 24.04 ?
https://bugs.kde.org/show_bug.cgi?id=488671 Bug ID: 488671 Summary: how to build with Ubuntu 24.04 ? Classification: Frameworks and Libraries Product: massif-visualizer Version: master Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: massif-visuali...@kde.org Reporter: dark_foo...@yahoo.fr Target Milestone: 0.4 Hello, The INSTALL is telling to do : Build requirements: - kdelibs headers from KDE4 - optional: kgraphviewer 2.1: http://kde-apps.org/content/show.php/KGraphViewer+and+KGraphEditor?content=23999 Could you please update / detail how to do it in Ubuntu 24.04 , which apt-get install , which ppa ? in parallel, is there a verison usable on windows11 ? Thank you ! -- You are receiving this mail because: You are watching all bug changes.
[massif-visualizer] [Bug 488671] how to build with Ubuntu 24.04 ?
https://bugs.kde.org/show_bug.cgi?id=488671 --- Comment #2 from Fred M --- idem : sudo apt-get install qt6-base-dev CMake Error at CMakeLists.txt:35 (find_package): Could not find a configuration file for package "Qt6" that is compatible with requested version "6.5.0". The following configuration files were considered but not accepted: /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake, version: 6.4.2 /lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake, version: 6.4.2 -- You are receiving this mail because: You are watching all bug changes.
[massif-visualizer] [Bug 488671] how to build with Ubuntu 24.04 ?
https://bugs.kde.org/show_bug.cgi?id=488671 --- Comment #1 from Fred M --- from : https://launchpad.net/ubuntu/noble/+source/massif-visualizer , it seems to be : sudo apt install cmake debhelper-compat extra-cmake-modules libkchart-dev libkf5archive-dev libkf5config-dev libkf5coreaddons-dev libkf5i18n-dev libkf5kio-dev libkf5parts-dev libqt5svg5-dev libqt5xmlpatterns5-dev pkg-kde-tools python3-docutils qtbase5-dev xauth xvfb But : Massif-visualizer is requesting : extra-cmake-modules 6.0.0 But ubuntu 24.04 is using : extra-cmake-modules 5.115.0 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 488715] New: support on README_MISSING_SYSCALL_OR_IOCTL for an automatic method?
https://bugs.kde.org/show_bug.cgi?id=488715 Bug ID: 488715 Summary: support on README_MISSING_SYSCALL_OR_IOCTL for an automatic method? Classification: Developer tools Product: valgrind Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: dark_foo...@yahoo.fr Target Milestone: --- Hello, I am wondering if there is a generic automatic method to add ioctl value to the wrapper. For the documentation, there is PRE and POST to create : https://valgrind.org/docs/manual/dist.readme-missing.html But having a list of ioctl value in this format : #define my_ioctl "0x656460" Is there a way to include them, to have them automatically added in the list of wrappers? How to avoid to create a PRE / POST method for all my new ioctls ? Regards, Frédéric -- You are receiving this mail because: You are watching all bug changes.
