You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(9) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Mallove, E. A <eth...@in...> - 2021-06-29 16:21:16
|
Hello, I've intentionally created a memory leak in my application by adding a malloc() without a corresponding free(), but it seems to be suppressed by this block of my .supp file: { libc-2 Memcheck:Leak ... obj:*/libc-2.17.so } When I remove the above from my suppression file, I see the <error> leak in the output XML. But when the libc suppression is active, why isn't there a "used_suppression" line in the -v output? Thank you, Ethan |
From: gangadhara r. c. <mee...@gm...> - 2021-06-01 11:34:20
|
Thank you Paul for your detailed response which gives a clear understanding of valgrind. Thanks, Gangadhar On Tue, Jun 1, 2021 at 3:18 PM Paul Floyd <pj...@wa...> wrote: > > > > On 1 Jun 2021, at 06:46, gangadhara reddy chavva < > mee...@gm...> wrote: > > > > Hi, > > > > I am working on network routers where there will be multiple protocols > running as different processes. if i want to attach the valgrind for more > than one process at the same time what is the command/option to use. > > > Hi > > Valgrind does not “attach” to a process, in the same way that debuggers > like GDB do using the ptrace syscall. > > When Valgrind runs, there is only one process - the Valgrind tool. The > guest application “runs” on a virtual machine within Valgrind. And this can > only be done by starting the guest application. Transferring an already > running process image into Valgrind (to be able to “attach”) would be > fraught with serious problems (for instance, memcheck would not have the > history of allocations and the init state of memory, DRD and Helgrind would > not have the history of mutex locking). > > As already mentioned, it is possible to have Valgrind instrument child > processes. > > A+ > Paul > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
From: gangadhara r. c. <mee...@gm...> - 2021-06-01 11:31:08
|
Thank you John for your quick response. So I have to invoke separate valgrind command for each process for which I want to check the process memory. Thanks, Gangadhar On Tue, Jun 1, 2021 at 10:53 AM John Reiser <jr...@bi...> wrote: > if i want to attach the valgrind for more than one process at the same > time what is the command/option to use. > > There is no such command or option. Each valgrind tool applies to only > one process. > The closest you can come is to invoke each process using a (separate) > valgrind tool. > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
From: Paul F. <pj...@wa...> - 2021-06-01 09:47:12
|
> On 1 Jun 2021, at 06:46, gangadhara reddy chavva <mee...@gm...> wrote: > > Hi, > > I am working on network routers where there will be multiple protocols running as different processes. if i want to attach the valgrind for more than one process at the same time what is the command/option to use. Hi Valgrind does not “attach” to a process, in the same way that debuggers like GDB do using the ptrace syscall. When Valgrind runs, there is only one process - the Valgrind tool. The guest application “runs” on a virtual machine within Valgrind. And this can only be done by starting the guest application. Transferring an already running process image into Valgrind (to be able to “attach”) would be fraught with serious problems (for instance, memcheck would not have the history of allocations and the init state of memory, DRD and Helgrind would not have the history of mutex locking). As already mentioned, it is possible to have Valgrind instrument child processes. A+ Paul |
From: John C. <joh...@ta...> - 2021-06-01 05:30:50
|
If a script or something fires off all processes, you can use --trace-children=yes to grind the child processes as well. You can also ... --trace-children-skip=patt1,patt2,... specifies a list of executables that --trace-children=yes should not trace into --trace-children-skip-by-arg=patt1,patt2,... same as --trace-children-skip= but check the argv[] entries for children, rather than the exe name, to make a follow/no-follow decision On Tue, Jun 1, 2021 at 4:47 PM gangadhara reddy chavva < mee...@gm...> wrote: > Hi, > > I am working on network routers where there will be multiple protocols > running as different processes. if i want to attach the valgrind for more > than one process at the same time what is the command/option to use. > > Thank you. > > Thanks, > Gangadhar > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand -- This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.taitradio.com/email_disclaimer <http://www.taitradio.com/email_disclaimer> |
From: John R. <jr...@bi...> - 2021-06-01 05:22:12
|
if i want to attach the valgrind for more than one process at the same time what is the command/option to use. There is no such command or option. Each valgrind tool applies to only one process. The closest you can come is to invoke each process using a (separate) valgrind tool. |
From: gangadhara r. c. <mee...@gm...> - 2021-06-01 04:47:04
|
Hi, I am working on network routers where there will be multiple protocols running as different processes. if i want to attach the valgrind for more than one process at the same time what is the command/option to use. Thank you. Thanks, Gangadhar |
From: John R. <jr...@bi...> - 2021-05-27 07:20:58
|
For the example given, the backtrace command of gdb-8.3 already displays 80% of the requested information for code compiled by g++-9.3.1 using -g. The request: > If compiled with -g, the debug output will display > (1) C/C++ names down into the standard library > (2) source code names and signatures > (3) including template instantiations > (4) file names > (5) line numbers (gdb) backtrace #0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff7aac895 in __GI_abort () at abort.c:79 #2 0x0000000000401144 in bar () at traceback-test.c:6 #3 0x0000000000401154 in foo<int> () at traceback-test.c:12 #4 0x0000000000401134 in main () at traceback-test.c:17 valgrind-3.17.0: ==16820== Process terminating with default action of signal 6 (SIGABRT): dumping core ==16820== at 0x4BFCE35: raise (raise.c:51) ==16820== by 0x4BE7894: abort (abort.c:79) ==16820== by 0x401143: bar() (traceback-test.c:6) ==16820== by 0x401153: void foo<int>(int) (traceback-test.c:12) ==16820== by 0x401133: main (traceback-test.c:17) In this example, item (3) is the only essential difference. valgrind: void foo<int>(int) (traceback-test.c:12) contains result type and argument type, while gdb: in foo<int> () at traceback-test.c:12 lacks "void" and "(int)". For items (1), (2), (4), and (5) the gdb output contains the same information as the valgrind output. In addition, gdb gives more information for (1): the complete internal path for standard library code ../sysdeps/unix/sysv/linux/raise.c:50 in contrast to valgrind's (raise.c:51) So, any request for a better backtrace should be much more explicit than what was posted originally. On 5/26/21, Martin Licht via Valgrind-users wrote: > Addressing the first point: what Valgrind's tracer does better than others is fetching more source code information and semantics. This can shown immediately with the following example: > > ``` > #include <assert.h> > #include <stdlib.h> > > inline void bar() > { > abort(); > } > > template<typename T> > inline void foo(T) > { > bar(); > } > > int main() > { > foo(5); > return 0; > } > ``` > > If compiled with -g, the debug output will display (1) C/C++ names down into the standard library (2) source code names and signatures (3) including template instantiations (4) file names (5) line numbers, among other things. I would be great to have a stack tracer like that. > > The prettiest alternatives without Valgrind go along the lines of > https://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/ > using libunwind and cxxabi. This still is not as close to the source as Valgrind's output. |
From: Martin L. <ml...@uc...> - 2021-05-27 03:31:27
|
Addressing the first point: what Valgrind's tracer does better than others is fetching more source code information and semantics. This can shown immediately with the following example: ``` #include <assert.h> #include <stdlib.h> inline void bar() { abort(); } template<typename T> inline void foo(T) { bar(); } int main() { foo(5); return 0; } ``` If compiled with -g, the debug output will display (1) C/C++ names down into the standard library (2) source code names and signatures (3) including template instantiations (4) file names (5) line numbers, among other things. I would be great to have a stack tracer like that. The prettiest alternatives without Valgrind go along the lines of https://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/ using libunwind and cxxabi. This still is not as close to the source as Valgrind's output. Best, Martin On Mon, May 24, 2021 at 3:09 PM John Reiser <jr...@bi...> wrote: > On 5/24/21, Martin Licht via Valgrind-users wrote: > > > I think the Valgrind stack tracer is pretty great and I would like to > use it as a substitute for `backtrace` in my C++ debug builds. > > It would help to give an explicit list of why valgrind's backtrace() is > "pretty great" > in contrast to GNU's. The comment > > https://urldefense.com/v3/__https://blog.mozilla.org/nnethercote/2011/01/11/using-valgrind-to-get-stack-traces/*comment-438__;Iw!!Mih3wA!UfTEqXmRbG-pQAMC4pm54vloAenaAZoBw-abVILaGfvzVPS2T4cKVx6_eFTqAPk$ > identifies one item: GNU backtrace() shows only global (non-static) > symbols. > What else? > > Also, a detailed list would make a good request for enhancement > at > https://urldefense.com/v3/__https://www.gnu.org/software/libc/bugs.html__;!!Mih3wA!UfTEqXmRbG-pQAMC4pm54vloAenaAZoBw-abVILaGfvzVPS2T4cKVx6_Yz5dunc$ > , > especially if accompanied by an actual test case > that shows how much better valgrind backtrace() is currently. > > -- > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/valgrind-users__;!!Mih3wA!UfTEqXmRbG-pQAMC4pm54vloAenaAZoBw-abVILaGfvzVPS2T4cKVx6_dyjVF6g$ > |
From: John R. <jr...@bi...> - 2021-05-24 22:08:55
|
On 5/24/21, Martin Licht via Valgrind-users wrote: > I think the Valgrind stack tracer is pretty great and I would like to use it as a substitute for `backtrace` in my C++ debug builds. It would help to give an explicit list of why valgrind's backtrace() is "pretty great" in contrast to GNU's. The comment https://blog.mozilla.org/nnethercote/2011/01/11/using-valgrind-to-get-stack-traces/#comment-438 identifies one item: GNU backtrace() shows only global (non-static) symbols. What else? Also, a detailed list would make a good request for enhancement at https://www.gnu.org/software/libc/bugs.html , especially if accompanied by an actual test case that shows how much better valgrind backtrace() is currently. -- |
From: Philippe W. <phi...@sk...> - 2021-05-24 21:16:24
|
On Mon, 2021-05-24 at 10:31 -0700, Martin Licht via Valgrind-users wrote: > Hello, > > I think the Valgrind stack tracer is pretty great and I would like to use it as a substitute for `backtrace` in my C++ debug builds. > > A blog post by Nicholas Nethercote (Using Valgrind to get stack traces) describes a similar idea: > https://blog.mozilla.org/nnethercote/2011/01/11/using-valgrind-to-get-stack-traces/ > > However, while this is already fairly elegant, I am wondering whether this can be done without invoking the program under valgrind. > > If the Valgrind stack tracer were a simple #include that would be best. > Alternatively, a means of including any necessary valgrind framework into the debug build would be helpful. I appreciate your feedback. The valgrind unwinder is very fast, so having it as a "standalone" library that can be linked to a normal executable and used outside of the valgrind JIT framework would be really nice. However, I think this unwind logic/code has a lot of dependencies to other parts of valgrind (debug info reader, address space manager, valgrind own malloc library, valgrind log and debug framework, ...). So, clearly not a small task to 'cleanly' lib-ify the valgrind unwinder, in particular if this library must then be usable both in a valgrind context and in a 'native' context. Philippe |
From: Martin L. <ml...@uc...> - 2021-05-24 19:37:22
|
Hello, I think the Valgrind stack tracer is pretty great and I would like to use it as a substitute for `backtrace` in my C++ debug builds. A blog post by Nicholas Nethercote (Using Valgrind to get stack traces) describes a similar idea: https://blog.mozilla.org/nnethercote/2011/01/11/using-valgrind-to-get-stack-traces/ However, while this is already fairly elegant, I am wondering whether this can be done without invoking the program under valgrind. If the Valgrind stack tracer were a simple #include that would be best. Alternatively, a means of including any necessary valgrind framework into the debug build would be helpful. I appreciate your feedback. Regards, Martin |
From: Alan C. <ala...@gm...> - 2021-05-07 01:51:13
|
Oh, fft_r[] and fft_l[] are similar memory areas from calloc which hold the FFT output data once it's moved from the fft3w output array. I pick left and right channels out of the PCM data and FFT them individually, then plot them separately on the same frame image. On 5/6/21, Alan Corey <ala...@gm...> wrote: > This is under Debian Bullseye Linux on a PineBook Pro so ARM 64-bit I > think although sizeof(int) is still 4. It's a fairly complicated > program at 750 lines in it's almost-done state so I'm not posting the > whole thing. I have this program that does audiograms > https://sourceforge.net/projects/audiogram-c/ and I got the bright > idea of adding FFT plots to the video generated. I read a wav file > into RAM, draw the envelope of the audio. Then move a cursor bar over > it by generating frames at different times, saving as jpegs and > calling ffmpeg at the end to make a video. Originally it was a > work-around for not being able to post audio files to social media > sites. > > The FFT version works with the PCM data in the wav file in memory and > draws more onto the same frames. tmpbuf is a per-frame output drawing > area allocated with calloc and then cleared with bzero but I still get > these uninitialized warnings: > > ==26220== > ==26220== Invalid write of size 1 > ==26220== at 0x402460: plot (agf.c:573) > ==26220== by 0x402B9F: main (agf.c:713) > ==26220== Address 0x4d2b993 is 13 bytes before an unallocated block > of size 3,278,400 in arena "client" > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220== at 0x401504: plotffts (agf.c:301) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220== at 0x40153C: plotffts (agf.c:303) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220== at 0x401598: plotffts (agf.c:307) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220== at 0x4015D0: plotffts (agf.c:309) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220== at 0x40165C: plotffts (agf.c:315) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220== at 0x401678: plotffts (agf.c:317) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Use of uninitialised value of size 8 > ==26220== at 0x4016E0: plotffts (agf.c:328) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Use of uninitialised value of size 8 > ==26220== at 0x4016F8: plotffts (agf.c:329) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Use of uninitialised value of size 8 > ==26220== at 0x401710: plotffts (agf.c:330) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220== at 0x401788: plotffts (agf.c:337) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Conditional jump or move depends on uninitialised value(s) > ==26220== at 0x4017A4: plotffts (agf.c:339) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Use of uninitialised value of size 8 > ==26220== at 0x4017EC: plotffts (agf.c:342) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Invalid write of size 1 > ==26220== at 0x4017EC: plotffts (agf.c:342) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Address 0x4dbb9dc is 4 bytes before an unallocated block of > size 2,688,512 in arena "client" > ==26220== > ==26220== Use of uninitialised value of size 8 > ==26220== at 0x401804: plotffts (agf.c:343) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Invalid write of size 1 > ==26220== at 0x401804: plotffts (agf.c:343) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Address 0x4dbb9dd is 3 bytes before an unallocated block of > size 2,688,512 in arena "client" > ==26220== > ==26220== Use of uninitialised value of size 8 > ==26220== at 0x40181C: plotffts (agf.c:344) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Uninitialised value was created by a heap allocation > ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) > ==26220== by 0x40125B: fft_init (agf.c:173) > ==26220== by 0x402B63: main (agf.c:707) > ==26220== > ==26220== Invalid write of size 1 > ==26220== at 0x40181C: plotffts (agf.c:344) > ==26220== by 0x401DDF: makeframes (agf.c:442) > ==26220== by 0x402BA3: main (agf.c:714) > ==26220== Address 0x4dbb9de is 2 bytes before an unallocated block of > size 2,688,512 in arena "client" > ==26220== > > The invalid writes I can't figure out either. The code section looks like > this: > > void plotffts(void) { // draw to tmpbuf > int i = 0; // initialize everything for Valgrind > int ofs = 0; > float min = -99999.9; // floats work better > float max = 99999.9; > int x = EDGESKIP; // start at left side > int y = 0; > int oldx = EDGESKIP; > int oldy = 0; > int first = 1; > half = HEIGHT/2; // redundant > for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // common values for both > L&R > if (fft_r[i] < min) // unitialized value > min = fft_r[i]; > if (fft_r[i] > max) // something not initialized > max = fft_r[i]; > } > for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // read other channel > if (fft_l[i] > max) // uninit > max = fft_l[i]; > if (fft_l[i] < min) // uninit > min = fft_l[i]; > } > for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // right channel > x = i; // correct? > y = ((fft_r[i] - min) / max) * half; > if (y > half) // uninit > y = half; > if (y < 0) // uninit > y = 0; > if (first > 0) { > oldy = y; > first = 0; > } > // line(oldx,oldy,x,y); > oldx = x; > oldy = y; > ///* > ofs = (y * WIDTH * 3) + (x * 3); > tmpbuf[ofs] = 0x01; // Use of uninitialised value of size 8 > tmpbuf[ofs+1] = 0xf5; // Use of uninitialised value of size 8 > tmpbuf[ofs+2] = 0xf6; // Use of uninitialised value of size 8 > //*/ > } > oldx = EDGESKIP; > for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // left channel > x = i; > y = ((fft_l[i] - min) / max) * half; > if (y > half) // uninit > y = half; > if (y < 0) // uninit > y = 0; > ofs = ((y + half)* WIDTH * 3) + (x * 3); > tmpbuf[ofs] = 0x01; // uninitialised value of size 8 & Invalid > write of size 1 > tmpbuf[ofs+1] = 0xf5; // uninitialised value of size 8 & Invalid > write of size 1 > tmpbuf[ofs+2] = 0xf6; // uninitialised value of size 8 & Invalid > write of size 1 > } > // lines instead of dots would work better > } > > I've looked up the line numbers given in the Valgrind error messages > and put comments on those lines above. tmpbuf is where I'm doing > graphics, it's a chunk of RAM from calloc with an int8_t pointer > making it accessible. It's not live graphics but a buffer of 24-bit > color values which get written out to jpegs. Maybe I should use > 32-bit color? This code does work, but I'm adding to it (Bresenham > line drawing) and the error messages are distracting me from errors in > the new code I'm working on. My hunch is that something is still > incomplete in Valgrind on aarch64 platforms. > > Alan > -- > ------------- > Education is contagious. > -- ------------- Education is contagious. |
From: Alan C. <ala...@gm...> - 2021-05-07 01:44:19
|
This is under Debian Bullseye Linux on a PineBook Pro so ARM 64-bit I think although sizeof(int) is still 4. It's a fairly complicated program at 750 lines in it's almost-done state so I'm not posting the whole thing. I have this program that does audiograms https://sourceforge.net/projects/audiogram-c/ and I got the bright idea of adding FFT plots to the video generated. I read a wav file into RAM, draw the envelope of the audio. Then move a cursor bar over it by generating frames at different times, saving as jpegs and calling ffmpeg at the end to make a video. Originally it was a work-around for not being able to post audio files to social media sites. The FFT version works with the PCM data in the wav file in memory and draws more onto the same frames. tmpbuf is a per-frame output drawing area allocated with calloc and then cleared with bzero but I still get these uninitialized warnings: ==26220== ==26220== Invalid write of size 1 ==26220== at 0x402460: plot (agf.c:573) ==26220== by 0x402B9F: main (agf.c:713) ==26220== Address 0x4d2b993 is 13 bytes before an unallocated block of size 3,278,400 in arena "client" ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220== at 0x401504: plotffts (agf.c:301) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220== at 0x40153C: plotffts (agf.c:303) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220== at 0x401598: plotffts (agf.c:307) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220== at 0x4015D0: plotffts (agf.c:309) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220== at 0x40165C: plotffts (agf.c:315) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220== at 0x401678: plotffts (agf.c:317) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Use of uninitialised value of size 8 ==26220== at 0x4016E0: plotffts (agf.c:328) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Use of uninitialised value of size 8 ==26220== at 0x4016F8: plotffts (agf.c:329) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Use of uninitialised value of size 8 ==26220== at 0x401710: plotffts (agf.c:330) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220== at 0x401788: plotffts (agf.c:337) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Conditional jump or move depends on uninitialised value(s) ==26220== at 0x4017A4: plotffts (agf.c:339) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Use of uninitialised value of size 8 ==26220== at 0x4017EC: plotffts (agf.c:342) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Invalid write of size 1 ==26220== at 0x4017EC: plotffts (agf.c:342) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Address 0x4dbb9dc is 4 bytes before an unallocated block of size 2,688,512 in arena "client" ==26220== ==26220== Use of uninitialised value of size 8 ==26220== at 0x401804: plotffts (agf.c:343) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Invalid write of size 1 ==26220== at 0x401804: plotffts (agf.c:343) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Address 0x4dbb9dd is 3 bytes before an unallocated block of size 2,688,512 in arena "client" ==26220== ==26220== Use of uninitialised value of size 8 ==26220== at 0x40181C: plotffts (agf.c:344) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Uninitialised value was created by a heap allocation ==26220== at 0x4849E4C: malloc (vg_replace_malloc.c:307) ==26220== by 0x40125B: fft_init (agf.c:173) ==26220== by 0x402B63: main (agf.c:707) ==26220== ==26220== Invalid write of size 1 ==26220== at 0x40181C: plotffts (agf.c:344) ==26220== by 0x401DDF: makeframes (agf.c:442) ==26220== by 0x402BA3: main (agf.c:714) ==26220== Address 0x4dbb9de is 2 bytes before an unallocated block of size 2,688,512 in arena "client" ==26220== The invalid writes I can't figure out either. The code section looks like this: void plotffts(void) { // draw to tmpbuf int i = 0; // initialize everything for Valgrind int ofs = 0; float min = -99999.9; // floats work better float max = 99999.9; int x = EDGESKIP; // start at left side int y = 0; int oldx = EDGESKIP; int oldy = 0; int first = 1; half = HEIGHT/2; // redundant for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // common values for both L&R if (fft_r[i] < min) // unitialized value min = fft_r[i]; if (fft_r[i] > max) // something not initialized max = fft_r[i]; } for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // read other channel if (fft_l[i] > max) // uninit max = fft_l[i]; if (fft_l[i] < min) // uninit min = fft_l[i]; } for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // right channel x = i; // correct? y = ((fft_r[i] - min) / max) * half; if (y > half) // uninit y = half; if (y < 0) // uninit y = 0; if (first > 0) { oldy = y; first = 0; } // line(oldx,oldy,x,y); oldx = x; oldy = y; ///* ofs = (y * WIDTH * 3) + (x * 3); tmpbuf[ofs] = 0x01; // Use of uninitialised value of size 8 tmpbuf[ofs+1] = 0xf5; // Use of uninitialised value of size 8 tmpbuf[ofs+2] = 0xf6; // Use of uninitialised value of size 8 //*/ } oldx = EDGESKIP; for (i=EDGESKIP; i<(FFTSIZE-EDGESKIP); i++) { // left channel x = i; y = ((fft_l[i] - min) / max) * half; if (y > half) // uninit y = half; if (y < 0) // uninit y = 0; ofs = ((y + half)* WIDTH * 3) + (x * 3); tmpbuf[ofs] = 0x01; // uninitialised value of size 8 & Invalid write of size 1 tmpbuf[ofs+1] = 0xf5; // uninitialised value of size 8 & Invalid write of size 1 tmpbuf[ofs+2] = 0xf6; // uninitialised value of size 8 & Invalid write of size 1 } // lines instead of dots would work better } I've looked up the line numbers given in the Valgrind error messages and put comments on those lines above. tmpbuf is where I'm doing graphics, it's a chunk of RAM from calloc with an int8_t pointer making it accessible. It's not live graphics but a buffer of 24-bit color values which get written out to jpegs. Maybe I should use 32-bit color? This code does work, but I'm adding to it (Bresenham line drawing) and the error messages are distracting me from errors in the new code I'm working on. My hunch is that something is still incomplete in Valgrind on aarch64 platforms. Alan -- ------------- Education is contagious. |
From: Paul F. <pj...@wa...> - 2021-04-27 07:12:42
|
On 4/26/21 8:23 PM, Kyryl Melekhin wrote: > Hello valgrind community! > > This is my first message ever to this mailing list. > > I am currently experiencing a weird bug in valgrind, where it > mistakenly does not recognize malloc/free/realloc function and also produces > weird warnings. But only on musl linux x86_64 version 1.2.2 Probably the same as this issue in bugzilla: https://bugs.kde.org/show_bug.cgi?id=435441 A+ Paul |
From: <k.m...@gm...> - 2021-04-27 00:23:42
|
Hello valgrind community! This is my first message ever to this mailing list. I am currently experiencing a weird bug in valgrind, where it mistakenly does not recognize malloc/free/realloc function and also produces weird warnings. But only on musl linux x86_64 version 1.2.2 Consider this simple C program: #include "stdio.h" #include "stdlib.h" int main() { char *mem = malloc(123); *mem = 5; *(mem+1) = 5; *(mem+2) = 5; mem = realloc(mem, 400); *(mem+1) = 5; *(mem+2) = 5; free(mem); return 0; } As you can see there can't be any bugs in this code, everything is within bounds. However when I run $ valgrind ./a.out ==486== Memcheck, a memory error detector ==486== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==486== Using Valgrind-3.18.0.GIT and LibVEX; rerun with -h for copyright info ==486== Command: ./a.out ==486== ==486== Invalid free() / delete / delete[] / realloc() ==486== at 0x48C589F: realloc (vg_replace_malloc.c:1192) ==486== by 0x109298: main (in /root/test/a.out) ==486== Address 0x48baf80 is in a rw- mapped file /usr/local/libexec/valgrind/vgpreload_core-amd64-linux.so segment ==486== ==486== Invalid write of size 1 ==486== at 0x1092A5: main (in /root/test/a.out) ==486== Address 0x1 is not stack'd, malloc'd or (recently) free'd ==486== ==486== ==486== Process terminating with default action of signal 11 (SIGSEGV) ==486== Access not within mapped region at address 0x1 ==486== at 0x1092A5: main (in /root/test/a.out) ==486== If you believe this happened as a result of a stack ==486== overflow in your program's main thread (unlikely but ==486== possible), you can try to increase the size of the ==486== main thread stack using the --main-stacksize= flag. ==486== The main thread stack size used in this run was 8388608. ==486== ==486== HEAP SUMMARY: ==486== in use at exit: 0 bytes in 0 blocks ==486== total heap usage: 1 allocs, 1 frees, 400 bytes allocated ==486== ==486== All heap blocks were freed -- no leaks are possible ==486== ==486== For lists of detected and suppressed errors, rerun with: -s ==486== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) Segmentation fault This happens. ----------------------------- musl version is 1.2.2 from KISS linux https://github.com/kiss-community/repo-main/tree/master/core/musl I built valgrind myself from source without any special configuration. I also tested it on Valgrind-3.16.0.RC1 940ec1ca6 and same results. $ autogen.sh $ configure $ make install OK. Now when I use the musl 1.2.1 version this should be the correct output from valgrind. ==918== Memcheck, a memory error detector ==918== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==918== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==918== Command: ./a.out ==918== ==918== ==918== HEAP SUMMARY: ==918== in use at exit: 468 bytes in 4 blocks ==918== total heap usage: 7 allocs, 3 frees, 1,031 bytes allocated ==918== ==918== LEAK SUMMARY: ==918== definitely lost: 0 bytes in 0 blocks ==918== indirectly lost: 0 bytes in 0 blocks ==918== possibly lost: 0 bytes in 0 blocks ==918== still reachable: 468 bytes in 4 blocks ==918== suppressed: 0 bytes in 0 blocks ==918== Rerun with --leak-check=full to see details of leaked memory ==918== ==918== For lists of detected and suppressed errors, rerun with: -s ==918== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Is this a bug in musl or a bug on valgrind side? Regards, Kyryl |
From: Nikhil A. <nik...@gm...> - 2021-04-22 06:49:54
|
Hi everyone, I want to use Valgrind to get the dynamic instruction trace for the Android Apps. I installed Valgrind through termux app (using apt-get) and I confirmed the installation’s success by executing the command *./valgrind --help *and also from Valgrind version 3.16.1 (./valgrind --version). The output of the command is showing the desired usage. I am also successful in executing the ls binary by executing *./valgrind --tool=memcheck -- ls* and I got the equivalent output. But when I wanted to use Valgrind for the *android App* by executing the command *./valgrind --tool=memcheck -- /path/to/the/app’s/odex/file* I am getting Segmentation fault: ==30335== Memcheck, a memory error detector ==30335== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==30335== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==30335== Command: /data/app/com.khaalijeb.inkdrops-aKgulq0D9iHWWdZa1l-EBA==/oat/arm64/base.odex ==30335== ==30335== ==30335== Process terminating with default action of signal 11 (SIGSEGV) ==30335== Bad permissions for mapped region at address 0x108000 ==30335== at 0x108000: ??? (in /data/app/com.khaalijeb.inkdrops-aKgulq0D9iHWWdZa1l-EBA==/oat/arm64/base.odex) ==30335== ==30335== HEAP SUMMARY: ==30335== in use at exit: 0 bytes in 0 blocks ==30335== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==30335== ==30335== All heap blocks were freed -- no leaks are possible ==30335== ==30335== For lists of detected and suppressed errors, rerun with: -s ==30335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Segmentation fault *Device Configuration*: LG Nexus 5x rooted device 64-bit machine with arm64-v8a architecture. I wanted to know why I am getting the segmentation fault? I am not getting the segmentation fault when I am attaching the ls binary with Valgrind. May I know the reasons behind it. Thank you for helping in my research journey. -- Nikhil Agrawal, MTech(Research) Student, Computer Science and Automation Department IISc Bangalore-560012 |
From: Philippe W. <phi...@sk...> - 2021-04-07 21:56:49
|
It is a very long time I did not compile valgrind for android (and when I did it years ago, I used an android emulator), so likely I will not be able to help much. Did you read and follow the README.android instructions ? (sounds a little bit unexpected that the below error message seems to indicate you have a rooted x86-linux smartphone). So, in particular, check the output of the configure step, as mentioned in README.android. Philippe On Thu, 2021-04-08 at 05:07 +0530, Nikhil Agrawal wrote: > Hi everyone, > I am new to the usage of Valgrind. I am getting this error when I executed ./valgrind on my adb shell on rooted smartphone. > > valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory > > May I know how to resolve it. It will be a big help for my research work. > -- > Nikhil Agrawal, > MTech(Research) Student, > Computer Science and Automation Department > IISc Bangalore-560012 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
From: Nikhil A. <nik...@gm...> - 2021-04-07 18:07:23
|
Hi everyone, I am new to the usage of Valgrind. I am getting this error when I executed ./valgrind on my adb shell on rooted smartphone. > valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No > such file or directory May I know how to resolve it. It will be a big help for my research work. -- Nikhil Agrawal, MTech(Research) Student, Computer Science and Automation Department IISc Bangalore-560012 |
From: Philippe W. <phi...@sk...> - 2021-03-26 18:37:32
|
Looks a little bit difficult to tell anything precise based on the info you provide. As general guidelines: * If the server segfaults, you should have a core dump to debug and see what went wrong. If core dump is disabled (e.g. check ulimit -a), you might also just attach with gdb and have gdb stop when the segfault is encountered. * And of course, you can try to run your program under valgrind. Philippe On Fri, 2021-03-26 at 13:22 -0400, John A wrote: > Hey y'all, > > I am attempting to solve a unique problem with our inhouse software. The > main client and server are C/C++. There is also a GUI server using wxWidgets > 3.1. > > Any guidance to this would be helpful: many or 1 client(s) are begun and > connect locally or via TCP to the server GUI instance. When a client > disconnects, the server GUI segfaults. > > We're using Boost 1.74/1.76 (rc2) > > Best regards, > John > > aronetics.com > We Speak ITR > +1-216/307-5760 > > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
From: John A <jo...@ar...> - 2021-03-26 17:41:21
|
Hey y'all, I am attempting to solve a unique problem with our inhouse software. The main client and server are C/C++. There is also a GUI server using wxWidgets 3.1. Any guidance to this would be helpful: many or 1 client(s) are begun and connect locally or via TCP to the server GUI instance. When a client disconnects, the server GUI segfaults. We're using Boost 1.74/1.76 (rc2) Best regards, John aronetics.com We Speak ITR +1-216/307-5760 |
From: Mark W. <ma...@kl...> - 2021-03-22 13:25:21
|
We are pleased to announce a new release of Valgrind, version 3.17.0, available from http://valgrind.org/downloads/current.html. The source tarball is signed with the PGP key at the bottom of this message. 3.17.0 fixes a number of bugs and adds some functional changes: support for GCC 11, Clang 11, DWARF5 debuginfo, the 'debuginfod' debuginfo server, and some new instructions for Arm64, S390 and POWER. There are also some tool updates. Our thanks to all those who contribute to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy and productive debugging and profiling, -- The Valgrind Developers Release 3.17.0 (19 Mar 2021) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.17.0 fixes a number of bugs and adds some functional changes: support for GCC 11, Clang 11, DWARF5 debuginfo, the 'debuginfod' debuginfo server, and some new instructions for Arm64, S390 and POWER. There are also some tool updates. This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris and AMD64/MacOSX 10.12. There is also preliminary support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. * ==================== CORE CHANGES =================== * DWARF version 5 support. Valgrind can now read DWARF version 5 debuginfo as produced by GCC 11. * Valgrind now supports debuginfod, an HTTP server for distributing ELF/DWARF debugging information. When a debuginfo file cannot be found locally, Valgrind is able to query debuginfod servers for the file using its build-id. See the user manual for more information about debuginfod support. * ================== PLATFORM CHANGES ================= * arm64: - Inaccuracies resulting from double-rounding in the simulation of floating-point multiply-add/subtract instructions have been fixed. These should now behave exactly as the hardware does. - Partial support for the ARM v8.2 instruction set. v8.2 support work is ongoing. Support for the half-word variants of at least the following instructions has been added: FABS <Hd>, <Hn> FABS <Vd>.<T>, <Vn>.<T> FNEG <Hd>, <Hn> FNEG <Vd>.<T>, <Vn>.<T> FSQRT <Hd>, <Hn> FSQRT <Vd>.<T>, <Vn>.<T> FADDP * s390: - Implement the new instructions/features that were added to z/Architecture with the vector-enhancements facility 1. Also cover the instructions from the vector-packed-decimal facility that are defined outside the chapter "Vector Decimal Instructions", but not the ones from that chapter itself. For a detailed list of newly supported instructions see the updates to `docs/internals/s390-opcodes.csv'. Since the miscellaneous instruction extensions facility 2 was already added in Valgrind 3.16.0, this completes the support necessary to run general programs built with `--march=z14' under Valgrind. The vector-packed-decimal facility is currently not exploited by the standard toolchain and libraries. * ppc64: - Various bug fixes. Fix for the sync field to limit setting just two of the two bits in the L-field. Fix the write size for the stxsibx and stxsihx instructions. Fix the modsw and modsd instructions. - Partial support for ISA 3.1 has been added. Support for the VSX PCV mask instructions, bfloat16 GER instructions, and bfloat16 to/from float 32-bit conversion instructions are still missing. * ==================== TOOL CHANGES ==================== * General tool changes - All the tools and their vgpreload libraries are now installed under libexec because they cannot be executed directly and should be run through the valgrind executable. This should be an internal, not user visible, change, but might impact valgrind packagers. - The --track-fds option now respects -q, --quiet and won't output anything if no file descriptors are leaked. It also won't report the standard stdin (0), stdout (1) or stderr (2) descriptors as being leaked with --trace-fds=yes anymore. To track whether the standard file descriptors are still open at the end of the program run use --trace-fds=all. * DHAT: - DHAT has been extended, with two new modes of operation. The new --mode=copy flag triggers copy profiling, which records calls to memcpy, strcpy, and similar functions. The new --mode=ad-hoc flag triggers ad hoc profiling, which records calls to the DHAT_AD_HOC_EVENT client request in the new dhat/dhat.h file. This is useful for learning more about hot code paths. See the user manual for more information about the new modes. - Because of these changes, DHAT's file format has changed. DHAT output files produced with earlier versions of DHAT will not work with this version of DHAT's viewer, and DHAT output files produced with this version of DHAT will not work with earlier versions of DHAT's viewer. * ==================== FIXED BUGS ==================== The following bugs have been fixed or resolved. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. We encourage you to file bugs in bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX where XXXXXX is the bug number as listed below. 140178 open("/proc/self/exe", ...); doesn't quite work 140939 --track-fds reports leakage of stdout/in/err and doesn't respect -q 217695 malloc/calloc/realloc/memalign failure doesn't set errno to ENOMEM 338633 gdbserver_tests/nlcontrolc.vgtest hangs on arm64 345077 linux syscall execveat support (linux 3.19) 361770 Missing F_ADD_SEALS 369029 handle linux syscalls sched_getattr and sched_setattr 384729 __libc_freeres inhibits cross-platform valgrind 388787 Support for C++17 new/delete 391853 Makefile.all.am:L247 and @SOLARIS_UNDEF_LARGESOURCE@ being empty 396656 Warnings while reading debug info 397605 ioctl FICLONE mishandled 401416 Compile failure with openmpi 4.0 408663 Suppression file for musl libc 404076 s390x: z14 vector instructions not implemented 410743 shmat() calls for 32-bit programs fail when running in 64-bit valgrind (actually affected all x86 and nanomips regardless of host bitness) 413547 regression test does not check for Arm 64 features. 414268 Enable AArch64 feature detection and decoding for v8.x instructions 415293 Incorrect call-graph tracking due to new _dl_runtime_resolve_xsave* 422174 unhandled instruction bytes: 0x48 0xE9 (REX prefixed JMP instruction) 422261 platform selection fails for unqualified client name 422623 epoll_ctl warns for uninitialized padding on non-amd64 64bit arches 423021 PPC: Add missing ISA 3.0 documentation link and HWCAPS test. 423195 PPC ISA 3.1 support is missing, part 1 423361 Adds io_uring support on arm64/aarch64 (and all other arches) 424012 crash with readv/writev having invalid but not NULL arg2 iovec 424298 amd64: Implement RDSEED 425232 PPC ISA 3.1 support is missing, part 2 425820 Failure to recognize vpcmpeqq as a dependency breaking idiom. 426014 arm64: implement fmadd and fmsub as Iop_MAdd/Sub 426123 PPC ISA 3.1 support is missing, part 3 426144 Fix "condition variable has not been initialized" on Fedora 33. 427400 PPC ISA 3.1 support is missing, part 4 427401 PPC ISA 3.1 support is missing, part 5 427404 PPC ISA 3.1 support is missing, part 6 427870 lmw, lswi and related PowerPC insns aren't allowed on ppc64le 427787 Support new faccessat2 linux syscall (439) 427969 debuginfo section duplicates a section in the main ELF file 428035 drd: Unbreak the musl build 428648 s390_emit_load_mem panics due to 20-bit offset for vector load 428716 cppcheck detects potential leak in VEX/useful/smchash.c 428909 helgrind: need to intercept duplicate libc definitions for Fedora 33 429352 PPC ISA 3.1 support is missing, part 7 429354 PPC ISA 3.1 support is missing, part 8 429692 unhandled ppc64le-linux syscall: 147 (getsid) 429864 s390x: C++ atomic test_and_set yields false-positive memcheck diagnostics 429952 Errors when building regtest with clang 430354 ppc stxsibx and stxsihx instructions write too much data 430429 valgrind.h doesn't compile on s390x with clang 430485 expr_is_guardable doesn't handle Iex_Qop 431556 Complete arm64 FADDP v8.2 instruction support 432102 Add support for DWARF5 as produced by GCC11 432161 Addition of arm64 v8.2 FADDP, FNEG and FSQRT 432381 drd: Process STACK_REGISTER client requests 432552 [AArch64] invalid error emitted for pre-decremented byte/hword addresses 432672 vg_regtest: test-specific environment variables not reset between tests 432809 VEX should support REX.W + POPF 432861 PPC modsw and modsd give incorrect results for 1 mod 12 432870 gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64 432215 Add debuginfod functionality 433323 Use pkglibexecdir as vglibdir 433500 DRD regtest faulures when libstdc++ and libgcc debuginfo are installed 433629 valgrind/README has type "abd" instead of "and" 433641 Rust std::sys::unix::fs::try_statx Syscall param fstatat(file_name) 433898 arm64: Handle sp, lr, fp as DwReg in CfiExpr 434193 GCC 9+ inlined strcmp causes "Conditional jump or move [..] value" report n-i-bz helgrind: If hg_cli__realloc fails, return NULL. n-i-bz arm64 front end: avoid Memcheck false positives relating to CPUID (3.17.0.RC1: 13 Mar 2021) (3.17.0.RC2: 17 Mar 2021) (3.17.0: 19 Mar 2021) -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFy189QBCACxFf0SSSycE42ulnIYk7GNR9FnKlDN4rNZ9TExYWMh6cJIELgq W5eI9xoHJarfLc7uSKPagcGPIntThCMBw8dLnL8mFzsCOIrjQl/C9FZua53RwmzE t6+yvMJMcYz8Vqfh7J8w5+zlAMFSqbE5jAcWEzlaz8YMt8GTgixhFSC6eyy0j+4L k35+lKOvX1htUIjVYz9nfVgGmz6Vg+2dyjxoB6GHXtrAExRuoo0jqctLc8dZOp0U MMzVEQzJItcYj6/L1FEOYcrnhVri92sgB+AReMWy1ailt+OmNXmEkpV5L4vCJn2Y sThu7OnecBUoMMP13y2UB23h3vlxe0RyxuZNABEBAAG0H0p1bGlhbiBTZXdhcmQg PGpzZXdhcmRAYWNtLm9yZz6JATgEEwECACIFAly189QCGwMGCwkIBwMCBhUIAgkK CwQWAgMBAh4BAheAAAoJELoBZuaY+mA1ttoH/0MkIQcB4QohV2Z9Fkf95jm6uz/P rFewPS7iyRMLL9sPktjqXg0X1yxX5ShpEbtL18X+qbAVDIe98uTdyFb21b8DjP6n v2KnIZFDD+iZEceWJD6MAXcicvr4sv4LESzreNEIF6wHdWkWC4v57hQl+uywWXiI T4gnHUEJIu0cNP3vMcSjrgrzeaPW3z56B+BLBM1XncrZ0mbz77/FK9lQM1arLpcU dPNJlVMqNdbLLlIsmkZ8jfE7TCOCNuIrCHeNTRGY5NuY829pheGwutIlp4t+Pchz /cib3hZeilJrFuuqBOk4ipZ/s1PwS9DigGOk1I0egqIBhPdAsEY3gBXdOXyJAjME EAEKAB0WIQTsPP6I9soHiHdPXB0apEvmSd52CgUCXLYy8gAKCRAapEvmSd52CnJb D/45yMDDnSelx6MfBwQcowqkkK/BzZs+akR5hX76g5alMSA2MRBkudGO8R/G2fva sa9e2Js+3crmoyOxfL3PCun/N7/J2rX8PPT6d4hk1N3fluUWghUhCDMHmfPy1N5d WMTTW/EvZrYdh1dauGw/k+DP/M784FN8UU15hggMCcqM5LGNKuMOhFadntecj/Wr aAtroLD3Geq7eUAO18oYgJFRktdXtDkWGTG6+KhoLTIaW8xRAR1OiO6Oxua+3htU Zrk9AIDAJQymeA9budWyVAMPZSgnkSdMQBe8UnwsCx1X6xZP+wHihZ86oClydieh 3AtsLzjzZGNytAO7+BP7cNxvrWXBNUMTEQwAcMp8PbjV3NAK/96sfdQ++3wttvMw 4M4AI0hFxE67EkpTjk0rDhDINjOowyn/MBpNuuC2BuDlzrR7AV8jKq957OMko6uk S/NlJo9LUYeyLSU1lF5B6fh6tu3Tyv4yASTp6fyihh+G24azAbYi4WQu79ltuDQb Zg4fGVB/vcydsf1NxiEQMMSOyrcws+WNYjqGymZ70YZW+PDEBZcW4WE515RR0N3N 3YmLbvIywYQe2zKFOoLu2CDx/q/gqMX0W9I4h3sSKOoFIFkeY7Cr/6OdV6S1Re9d o/dGoKDzfjaXpTZf4Kv19wEizElnoi7S7tFrbLLMV1vQHrkBDQRctfPUAQgAtKTF G5HFIUs8kO3Cs3EysJhOe/pEIYhkdRwKn46ostfk7Ghd4YdwRYDscZaqrwCaY1lV VLKd33IPdFHpGwRQrM0RyLA+A6xfdoCoKO0vOLTEiEDI+C3FDSZ/vCeq13gMfYHN tuhmEjvA9MMwKx0/kfKc28fQWPDDDgnAQ6cyS+9t4s4j6JuRm/rq4blKWGK8f8Ob KrEFHt/J1uhLykGbgYFu0MSaldevjHJzqzkscHcifAA5SMWZuYn5dMCNJT+8Iadr u0TSCvZQeN3HceNCN2Liodpv/JqUn8qF5wGaUxZFcGdy5V+nR1PsQnguEd35Z1ai rfqdE27KZYRC3xzO8wARAQABiQEfBBgBAgAJBQJctfPUAhsMAAoJELoBZuaY+mA1 NSUH/jUd12imDneXAMKt3ThlqXh1v0tPnawugaNHD3vibvgFYcyqQ+YbPMhRgUoc hdTLbkqxkjEzfLhpzAA164AcP3/pDq+OCyyONNnt06LXxgGU2lJoTeRdSEsOFYxE RnOUoW8qQoPWWk8ZmnMh/2VEuXeIjXMHNvdAWMn0gUfKDEeeCILpqkn4f4Sx4H5P 1Yf4JzgwYTfFocXDsQSsFrboAPOJVEm4E7zJfp62Uzs72+9NueHnZEnr4pVzCUIm CxJrvQzGcJxc1eqbuCmI0zuFLRcgZUpO4a0IaDUsjhbG2PUTADgSAfgLihrvaiA+ xn/APcV8iSUjgKGcnQfuhhayxQk= =C8ND -----END PGP PUBLIC KEY BLOCK----- |
From: Arseny K. <ars...@gm...> - 2021-03-19 21:34:29
|
I'm investigating ways to integrate instrumentation-based profiling with cachegrind. When running a native program, cachegrind can measure estimated instruction counts and other metrics like cache misses etc., and attribute them to specific functions based on the debug information. However, sometimes this doesn't produce very useful results - for example, when the profiled program is an interpreter, this produces profiling data for the interpreter itself but not the interpreted program. What I'd like to do is to be able to query some data - instruction counters, cache misses, anything else of that sort that might be available - from the guest, assuming it knows it's running under cachegrind. I was initially hoping to be able to query instruction counters using rdtsc, but rdtsc is implemented using the host rdtsc instruction, so it generates very noisy data - I was hoping to be able to use internal simulated counters to produce stable results. Is there a way to do something like this without modifying cachegrind? (of course I could hack rdtsc to do what I want in theory but that'd require using custom binaries) Arseny |
From: Mark W. <ma...@kl...> - 2021-03-17 17:00:17
|
Hi Carl, On Wed, 2021-03-17 at 09:36 -0700, Carl Love wrote: > On Wed, 2021-03-17 at 13:08 +0100, Mark Wielaard wrote: > The testing on the ISA 3.1 because the file > none/tests/ppc64/isa_3_1_register_defines.h is missing from RC2. I > checked and it is also missing from RC1. The file does exist in the > Vaglrind git tree. Not sure why it is missing in the RCs. Not sure > why I didn't pick that up with the previous RC1 testing. Sorry about > that. Oops. It looks like that was missed because it isn't used unless building for ISA3.1. I committed the following to make sure it will be in the final release tarball: commit 8616808ab3cc691699bd1f733eb9b3106a1a6256 Author: Mark Wielaard <ma...@kl...> Date: Wed Mar 17 17:56:07 2021 +0100 Add isa_3_1_register_defines.h to Makefile.am noinst_HEADERS Make sure isa_3_1_register_defines.h ends up in the dist tarball. diff --git a/none/tests/ppc64/Makefile.am b/none/tests/ppc64/Makefile.am index 23a22d922..38a3dc483 100644 --- a/none/tests/ppc64/Makefile.am +++ b/none/tests/ppc64/Makefile.am @@ -3,7 +3,7 @@ include $(top_srcdir)/Makefile.tool-tests.am dist_noinst_SCRIPTS = filter_stderr -noinst_HEADERS = ppc64_helpers.h isa_3_1_helpers.h +noinst_HEADERS = ppc64_helpers.h isa_3_1_helpers.h isa_3_1_register_defines.h EXTRA_DIST = \ jm-int.stderr.exp jm-int.stdout.exp jm-int.vgtest jm-int.stdout.exp-LE \ Thanks, Mark |
From: Mark W. <ma...@kl...> - 2021-03-17 12:08:51
|
Greetings. A second release candidate for 3.17.0 is available at https://sourceware.org/pub/valgrind/valgrind-3.17.0.RC2.tar.bz2 (md5 = 5dcf7c42635e19b074714c53f3a57580) Thanks for the testing of RC1. The changes between RC1 and RC2 are minimal: - debuginfod-check.pl is now included to fix make regtest. - libmpiwrap.c now compiles whether or not openmpi has MPI1 support. - Two fixes for make check on Darwin/MacOS X are included. Please give it a try on platforms that are important for you. If no serious issues are reported, the 3.17.0 final release will happen on 19 March, that is, on Friday of this week. |