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
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(6) |
2
(1) |
3
(2) |
4
|
5
|
|
6
(1) |
7
|
8
(1) |
9
(7) |
10
(7) |
11
(1) |
12
(2) |
|
13
(3) |
14
(1) |
15
(1) |
16
(3) |
17
(7) |
18
(2) |
19
|
|
20
(1) |
21
(3) |
22
(2) |
23
(2) |
24
|
25
(1) |
26
(4) |
|
27
|
28
(7) |
29
(23) |
30
(11) |
31
(9) |
|
|
|
From: Shamis, P. <sh...@or...> - 2011-03-15 21:19:51
|
Hey,
Valgrind doesn't work on systems that don't have "/tmp" directory. After some debug we found that the "/tmp" directory is actually hardcoded in the code. I changed the code to get the TMP directory from environment variable. As result it provides us a way to customize temporary directory location. If no value is specified, the default one ("/tmp") is used.
Please see attached patch. It really may be helpful to see some resolution for the problem in future Valgrind version.
|
|
From: Rainer G. <rge...@gm...> - 2011-03-14 10:52:45
|
sorry for bringing up this old thread again. I am once more stuck with a situation where I would need to know the memory address of the leaked item. I have just looked at the valgrind code, but have not found where exactly the "loss record" message (in text case) is being generated. I would deeply appreciate if someone could point me what I need to change in order to have valgrind display the address. Thanks, Rainer On Wed, Dec 1, 2010 at 7:44 PM, Michael Smith <ms...@xi...> wrote: > As far as I know, there's no way to do that. > > Last time I wanted this, I hacked it into my local copy of valgrind > (actually just tracking a single address, and printing out one - even > when multiple copies were leaked). Unfortunately, I've since lost that > patch. Fortunately, it was really simple - so doing something like > that yourself shouldn't be hard. > > Mike > > > On Wed, Dec 1, 2010 at 6:56 AM, Rainer Gerhards <rge...@gm...> wrote: >> Hi all, >> >> I am trying to find a well-hidden memory leak. To do so, it would be >> immensely useful to know the memory addresses of the leaked objects. >> Is there any way I can tell valgrind to show the addresses in its >> memory leak output (just like it does e.g. on access violations)? >> >> Thanks, >> Rainer >> >> ------------------------------------------------------------------------------ >> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >> Tap into the largest installed PC base & get more eyes on your game by >> optimizing for Intel(R) Graphics Technology. Get started today with the >> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >> http://p.sf.net/sfu/intelisp-dev2dev >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > |
|
From: Paulo C. P. de A. <pc...@ma...> - 2011-03-13 17:22:58
|
Tom Hughes wrote: > On 13/03/11 14:29, Paulo César Pereira de Andrade wrote: > >> I just switched development of my language, and its jit generation >> based on gnu lightning on a x86_64 computer, and this happens >> when running jit generated code under valgrind. >> >> (other valgrind messages about bug report, etc) > > It would have been helpful if you had included them... As it is you have > cut off some information that may have been important. Reproducing the problem I see: vex amd64->IR: unhandled instruction bytes: 0x45 0x63 0x6A 0x24 0x4C 0x8B ==25936== valgrind: Unrecognised instruction at address 0x9f14670. ==25936== Your program just tried to execute an instruction that Valgrind ==25936== did not recognise. There are two possible reasons for this. ==25936== 1. Your program has a bug and erroneously jumped to a non-code ==25936== location. If you are running Memcheck and you just saw a ==25936== warning about a bad jump, it's probably your program's fault. ==25936== 2. The instruction is legitimate but Valgrind doesn't handle it, ==25936== i.e. it's Valgrind's fault. If you think this is the case or ==25936== you are not sure, please let us know and we'll try to fix it. ==25936== Either way, Valgrind will now raise a SIGILL signal which will ==25936== probably kill your program. ==25936== ==25936== Process terminating with default action of signal 4 (SIGILL) ==25936== Illegal opcode at address 0x9F14670 ==25936== at 0x9F14670: ??? ==25936== ==25936== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- But it was a bug of mine, as the %r13d was pointing to some error (sign extending a 32 bit register...), that the cpu just happens to apparently use some default behavior, as no test cases in my language were failing. I just traced it, and it is caused when loading a variable typed uint32_t (the language is dynamically typed but also supports static typing), so, when correcting it to use implicit zero extension, it is disassembled as: mov 0x24(%r10),%r13d i.e. 0x45 0x8b 0x6a 0x24 and valgrind works. >> (gdb) x/20i 0x0000000009f14fd8-20 >> 0x9f14fc4: xor %rax,%rax >> 0x9f14fc7: rex.WB callq *%r13 >> 0x9f14fca: nopw 0x0(%rax,%rax,1) >> 0x9f14fd0: mov 0x20(%rbx),%r10 >> 0x9f14fd4: mov -0x28(%r10),%r10 >> => 0x9f14fd8: movslq 0x24(%r10),%r13d >> 0x9f14fdc: mov 0x28(%rbx),%r10 >> 0x9f14fe0: lea 0x18(%r10),%rax >> 0x9f14fe4: mov %rax,0x28(%rbx) >> 0x9f14fe8: movabs $0x1,%rax >> 0x9f14ff2: mov %eax,(%r10) >> 0x9f14ff5: mov %r13,0x8(%r10) >> >> (gdb) x/4x 0x9f14fd8 >> 0x9f14fd8: 0x45 0x63 0x6a 0x24 > > That instruction should be handled by valgrind, but then you are looking > at the output of valgrind there anyway, not the input, so it doesn't > really tell us much. > > If you are getting an "unhandled instruction bytes" message from > valgrind then you have almost certainly found a bug in valgrind and you > should report it in the bug tracker. Make sure you include all the > detail from at least that message onwards. > > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ Sorry for the noise, Paulo |
|
From: Tom H. <to...@co...> - 2011-03-13 15:52:12
|
On 13/03/11 14:29, Paulo César Pereira de Andrade wrote: > I just switched development of my language, and its jit generation > based on gnu lightning on a x86_64 computer, and this happens > when running jit generated code under valgrind. > > (other valgrind messages about bug report, etc) It would have been helpful if you had included them... As it is you have cut off some information that may have been important. I assume that among them was the text which you have included as the subject of this message? > ==16208== Process terminating with default action of signal 4 (SIGILL) > ==16208== Illegal opcode at address 0x9F14FD8 > ==16208== at 0x9F14FD8: ??? > ==16208== > ==16208== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y > > (gdb) x/20i 0x0000000009f14fd8-20 > 0x9f14fc4: xor %rax,%rax > 0x9f14fc7: rex.WB callq *%r13 > 0x9f14fca: nopw 0x0(%rax,%rax,1) > 0x9f14fd0: mov 0x20(%rbx),%r10 > 0x9f14fd4: mov -0x28(%r10),%r10 > => 0x9f14fd8: movslq 0x24(%r10),%r13d > 0x9f14fdc: mov 0x28(%rbx),%r10 > 0x9f14fe0: lea 0x18(%r10),%rax > 0x9f14fe4: mov %rax,0x28(%rbx) > 0x9f14fe8: movabs $0x1,%rax > 0x9f14ff2: mov %eax,(%r10) > 0x9f14ff5: mov %r13,0x8(%r10) > > (gdb) x/4x 0x9f14fd8 > 0x9f14fd8: 0x45 0x63 0x6a 0x24 That instruction should be handled by valgrind, but then you are looking at the output of valgrind there anyway, not the input, so it doesn't really tell us much. If you are getting an "unhandled instruction bytes" message from valgrind then you have almost certainly found a bug in valgrind and you should report it in the bug tracker. Make sure you include all the detail from at least that message onwards. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Paulo C. P. de A. <pc...@ma...> - 2011-03-13 15:02:50
|
Hi, I just switched development of my language, and its jit generation based on gnu lightning on a x86_64 computer, and this happens when running jit generated code under valgrind. (other valgrind messages about bug report, etc) ==16208== Process terminating with default action of signal 4 (SIGILL) ==16208== Illegal opcode at address 0x9F14FD8 ==16208== at 0x9F14FD8: ??? ==16208== ==16208== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y (gdb) x/20i 0x0000000009f14fd8-20 0x9f14fc4: xor %rax,%rax 0x9f14fc7: rex.WB callq *%r13 0x9f14fca: nopw 0x0(%rax,%rax,1) 0x9f14fd0: mov 0x20(%rbx),%r10 0x9f14fd4: mov -0x28(%r10),%r10 => 0x9f14fd8: movslq 0x24(%r10),%r13d 0x9f14fdc: mov 0x28(%rbx),%r10 0x9f14fe0: lea 0x18(%r10),%rax 0x9f14fe4: mov %rax,0x28(%rbx) 0x9f14fe8: movabs $0x1,%rax 0x9f14ff2: mov %eax,(%r10) 0x9f14ff5: mov %r13,0x8(%r10) (gdb) x/4x 0x9f14fd8 0x9f14fd8: 0x45 0x63 0x6a 0x24 (gdb) x/4t 0x9f14fd8 0x9f14fd8: 01000101 01100011 01101010 00100100 $ rpm -q valgrind valgrind-3.6.1-1-mdv2011.0.x86_64 Sorry if this is an error in the code generation, but since it works, load and sign extends a 32 bit integer from memory to a 64 bit register, I believe it should be correct to some extent... In case it is useful, sources can be browsed at https://code.google.com/p/exl/source/browse/ and/or https://code.google.com/p/exl/source/browse/trunk/lib/ejit_x86-cpu.c Thanks, Paulo |
|
From: Sky D. <sdn...@ya...> - 2011-03-12 16:12:01
|
Hi all,
Recently I am trying to understand the mechanism of ptrcheck, which can detect
the incorrect heap reference. There is one statements in manual, "Ptrcheck keeps
track of which heap block (if any) it was derived from". I thought that it means
every pointer has an associated struct (or something like that) to record such
information. Yet I failed to find such struct. So I couldn't understand the
implementation of ptrcheck's heap instrumentation.
Can anyone explain the implementation for me? Or tells me how ptrcheck can store
the association between the pointer and the heap block.
Any kind explanation is appreciated! Thank you in advance!
All the best,
Xuefeng Dai
|
|
From: Bart V. A. <bva...@ac...> - 2011-03-12 14:29:22
|
On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni <ama...@gm...> wrote: > I likely found a problem in the DRD when using the --free-is-write > option. The following test case reports an huge amount of errors that > are not expected. > [ ... ] Sorry that it took so long, but I think I have found and fixed the problem that was present in the previous implementation of the --free-is-write option in DRD. The new implementation is present on the trunk in r11636. Please have a look at the documented limitations in the updated manual too. Bart. |
|
From: Philip A. <phi...@sm...> - 2011-03-11 17:54:56
|
Hullo list, Are there any existing known issues surrounding the resolution of symbols inside dlopened modules when a process has dropped privileges using setuid/setgid? I've had terrible problems trying to debug a server daemon which is started as root (so that it can bind to privileged ports), then drops to an unprivileged user before loading several plugins using dlopen; primarily, that whenever a backtrace involves code inside a plugin, I just get "???" instead of symbol names for functions inside the plugins. The shared object files do have debug information, and I have taken care to disable dlclose in debug builds of the daemon so that the symbols aren't unloaded on exit. In fact the same problem applies for errors generated during execution, not just when outputting leak info on exit. By chance, I noticed that if I disable the daemon's privilege dropping, the symbol information suddenly becomes visible. Turning on the verbose flag, I can clearly see messages such as the following when dlopen happens (names changed to protect the innocent): --11038-- Reading syms from /usr/lib/hungrydaemon/bacon.so (0x731a000) When privilege dropping is enabled, these messages do not appear, but no errors or alternative output seem to appear in their place. On a semi-related note, I get a lot of reports of invalid reads of size 4 inside dlopen/dlsym. I'm using libltdl to perform module loading, and it seems to work (it's not the plugin loading I want to debug, rather the functionality of the plugins themselves); should it be safe to just suppress these errors? Regards -- Philip Allison Senior Developer phi...@sm... Smoothwall Ltd 1 John Charles Way, Leeds, LS12 6QA United Kingdom Telephone: USA: 1 800 959 3760 Europe: +44 (0) 8701 999500 http://www.smoothwall.net Smoothwall Limited is registered in England, Company Number: 4298247. This email and any attachments transmitted with it are confidential to the intended recipient(s) and may not be communicated to any other person or published by any means without the permission of Smoothwall Limited. Any opinions stated in this message are solely those of the author. |
|
From: James W. <jam...@gm...> - 2011-03-10 15:57:49
|
I doing the build as part of an Openembedded Bitbake recipe -> there are a lot of extra flags to shrink the size of image. I just did a straight cross-compile outside of OE and it looks to be okay. Thanks for your help. 2011/3/10 Julian Seward <js...@ac...> > > Strange that the link fails. It builds OK for me on Ubuntu 10.04 > on ARM (Cortex-A8). > > Do you have some custom CFLAGS? I see some gcc flags in there > that I don't immediately expect: > > > -fexpensive-optimizations -fomit-frame-pointer -frename-registers > > -mthumb-interwork -mno-thumb > > What happens if you build with no CFLAGS ? > > J > |
|
From: zhouxu(NUDT) <zho...@gm...> - 2011-03-10 12:29:49
|
Hi, I want to build a Valgrind tool which can instrument a multi-thread program. It seems I can't use pthread library (such as pthread_mutex_lock) directly in my tool. As to my understanding, when the hosted program is a multi-thread program, the Valgrind tool's code may race. So how can I lock a shared memory in my tool? Thank you. -- zhouxu |
|
From: Julian S. <js...@ac...> - 2011-03-10 11:53:43
|
Strange that the link fails. It builds OK for me on Ubuntu 10.04 on ARM (Cortex-A8). Do you have some custom CFLAGS? I see some gcc flags in there that I don't immediately expect: > -fexpensive-optimizations -fomit-frame-pointer -frename-registers > -mthumb-interwork -mno-thumb What happens if you build with no CFLAGS ? J |
|
From: Julian S. <js...@ac...> - 2011-03-10 11:46:55
|
> This is in an app that assembles and executes code, so it could be a > genuine error. Apps like that tend to die with very strange errors unless you run with --smc-check=all. Did you do that? J |
|
From: Julian S. <js...@ac...> - 2011-03-10 11:45:32
|
> valgrind and daemon exit shortly after launch, at some close but random Have you tried --trace-children=yes ? > One more. Valgrind also complains about unhandled system call, like that: > That's a sigwait() system call: That's difficult to fix because it interacts with the signals simulation. I looked recently at handling it properly in our MacOSX port, where (I believe) it is not handled correctly. If you really want to Valgrindify the app, can you run it on Linux for the time being? J |
|
From: Bart V. A. <bva...@ac...> - 2011-03-10 11:29:28
|
2011/3/9 Piotr Adaszyński <ad...@gm...> > > > > Strange. Does the output of "make -s regtest" on your setup match that > > of the nightly PPC build (available in the valgrind-developers mailing > > list archives) ? > > > > Unfortunately, it's impossible to run "make -s regtest" and perform > regression tests on my target platform because of limited resources > (no make, no perl etc.). > > Maybe the problem here is my processor ? It's MPC8548 (ppc e500) and I > have to use gcc 3.4.x . > gcc 3.4 should be fine, but don't think the PPC e500 is already supported by Valgrind. Bart. |
|
From: Venkatram <ven...@vi...> - 2011-03-10 04:31:32
|
Hi, While using valgrind Segmentation fault is coming why I Don't please help me out. root@visiontek /mnt/jffs2$ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=2 --track-fds=yes ./test ==1892== Memcheck, a memory error detector ==1892== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==1892== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==1892== Command: ./test ==1892== --1892-- WARNING: Serious error when reading debug info --1892-- When reading debug info from /mnt/jffs2/test: --1892-- Ignoring non-Dwarf2/3/4 block in .debug_info Segmentation fault Warm Regards, Venkatram <ven...@vi...> Linkwell Telesystems Pvt. Ltd. web : www.visiontek.co.in |
|
From: James W. <jam...@gm...> - 2011-03-09 23:32:32
|
I'm having problems building Valgrind for ARM. The specific application that is failing is memcheck. Here's the error: ../coregrind/link_tool_exe_linux 0x38000000 arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb -Wno-long-long -isystem/home/OE/oetmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb3 -Wno-pointer-sign -fno-stack-protector -L/home/OE/oetmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-rpath-link,/home/OE/oetmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-O1 -Wl,--hash-style=gnu -o memcheck-arm-linux -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -marm -O2 -static -nodefaultlibs -nostartfiles -u _start -Wl,--build-id=none memcheck_arm_linux-mc_leakcheck.o memcheck_arm_linux-mc_malloc_wrappers.o memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o memcheck_arm_linux-mc_errors.o ../coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a -lgcc | ../coregrind/libcoregrind-arm-linux.a(libcoregrind_arm_linux_a-m_main.o): In function `_start': | m_main.c:(.debug_macinfo+0x182e8): relocation truncated to fit: R_ARM_JUMP24 against symbol `_start_in_C_linux' defined in .text section in ../coregrind/libcoregrind-arm-linux.a(libcoregrind_arm_linux_a-m_main.o) | collect2: ld returned 1 exit status | make[3]: *** [memcheck-arm-linux] Error 1 any help would be greatly appreciated. Thanks, James |
|
From: Piotr A. <ad...@gm...> - 2011-03-09 21:33:54
|
> > Strange. Does the output of "make -s regtest" on your setup match that > of the nightly PPC build (available in the valgrind-developers mailing > list archives) ? > Unfortunately, it's impossible to run "make -s regtest" and perform regression tests on my target platform because of limited resources (no make, no perl etc.). Maybe the problem here is my processor ? It's MPC8548 (ppc e500) and I have to use gcc 3.4.x . -- Piotr |
|
From: John R. <jr...@bi...> - 2011-03-09 18:09:44
|
> vex amd64->IR: unhandled instruction bytes: 0xC0 0x36 0x7D 0x5A 0x0 0x0
The instruction bytes "C0 36" are officially undefined. The second byte
("modR/M" in the Intel nomenclature) 0x36 designates case 6==(0x7 & (0x36 >> 3))
which would be an 8-bit shift (SHL) with immediate constant shift count,
except that SHL and SAL are equivalent, so the case 4 is used for both,
and case 6 is undefined. The code generator forgot this special tweak.
--
|
|
From: Paul F. <pa...@fr...> - 2011-03-09 17:33:18
|
Hi I'm getting this error: ==9395== Use of uninitialised value of size 8 ==9395== at 0x5445E28: array_dyn_resize (vassign.c:1368) ==9395== by 0x1E92D537: ??? ==9395== by 0x1E830057: ??? ==9395== by 0x5A7A2E7F: ??? ==9395== by 0x1E7F030F: ??? ==9395== Uninitialised value was created by a stack allocation ==9395== at 0x4AEC3B0: exec_process (in [snipped].so) ==9395== vex amd64->IR: unhandled instruction bytes: 0xC0 0x36 0x7D 0x5A 0x0 0x0 ==9395== valgrind: Unrecognised instruction at address 0x5a7a2e88. This is in an app that assembles and executes code, so it could be a genuine error. That said, there are a lot of errors before this reaching this one. Does this look like a valid opcode? On RHEL53 64bit. A+ Paul |
|
From: Eugene M. Z. <eu...@zh...> - 2011-03-09 12:21:24
|
Hi. I'm trying to eliminate memory leaks in some C program; I run valgrind 3.6.0 under FreeBSD 8.2-PRERELEASE/i386. Actually it's a sendmail milter. It runs as a daemon, forking/detaching from terminal. It communicates with MTA via a unix socket, and sendmail uses its hooks in a threaded environment. I've read in docs that valgrind doesn't care about fork() calls and traces them too just because it creates a copy of a process, but in reality I have valgrind exiting in exactly the same moment as the parent does. I have done some googling and found that it's recommended to use foreground mode to trace daemons. This milter I'm debugging also has one, but the problem is that when in this mode both valgrind and daemon exit shortly after launch, at some close but random moment. However, being run without valgrind, daemon can run almost indefinitely (and there's no difference is it in foreground or daemon mode). I understand that all I'm describing is too common to receive some exact advice, so I wanted to ask for some directions about what to do in this situation. One more. Valgrind also complains about unhandled system call, like that: --3924-- WARNING: unhandled syscall: 429 --3924-- You may be able to write your own handler. --3924-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --3924-- Nevertheless we consider this a bug. Please report --3924-- it at http://valgrind.org/support/bug_reports.html. That's a sigwait() system call: grep [...] /usr/include/sys/syscall.h:#define SYS_sigwait 429 I've read that I should write my own wrapper, but I don't have a clue about where to start. Thanks. |
|
From: John R. <jr...@bi...> - 2011-03-09 05:07:54
|
> I am trying to use valgrind tool on linux-2.6.31 with arm9 core embedded system. > > Please let me know where did it went wrong with following command and how to fix this issue. The system administrator of your target machine has made it too hard for memcheck to work. The diagnosis is self-explanatory. [The ld-linux.so.3 on the target machine lacks a symbol 'memcpy'. Memcheck *MUST* find memcpy in ld-linux.so.3, else memcheck cannot do its job. Somebody removed the symbol, "stripped" it. Look for the invocation of /usr/bin/strip, "install -s", "objcopy -S -g -x -X --discard-locals", and/or build flags such as -s, -x, -X. If you want memcheck to work, then do *not* remove *any* symbols.] Do what the diagnosis says. [Install debuginfo for glibc, or do not remove any symbols from ld-linux.so.3 when building or installing glibc, or at any other time.] > > > /#valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./test / > > ==1893== Memcheck, a memory error detector > ==1893== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. > ==1893== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info > ==1893== Command: ./test > ==1893== > --1893-- WARNING: Serious error when reading debug info > --1893-- When reading debug info from ./test: > --1893-- Ignoring non-Dwarf2/3/4 block in .debug_info > > valgrind: Fatal error at startup: a function redirection > valgrind: which is mandatory for this platform-tool combination > valgrind: cannot be set up. Details of the redirection are: > valgrind: > valgrind: A must-be-redirected function > valgrind: whose name matches the pattern: memcpy > valgrind: in an object with soname matching: ld-linux.so.3 > valgrind: was not found whilst processing > valgrind: symbols from the object with soname: ld-linux.so.3 > valgrind: > valgrind: Possible fixes: (1, short term): install glibc's debuginfo > valgrind: package on this machine. (2, longer term): ask the packagers > valgrind: for your Linux distribution to please in future ship a non- > valgrind: stripped ld.so (or whatever the dynamic linker .so is called) > valgrind: that exports the above-named function using the standard > valgrind: calling conventions for this platform. The package you need > valgrind: to install for fix (1) is called > valgrind: > valgrind: On Debian, Ubuntu: libc6-dbg > valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo > valgrind: > valgrind: Cannot continue -- exiting now. Sorry. -- |
|
From: Venkatram <ven...@vi...> - 2011-03-09 03:40:55
|
Hi, I am trying to use valgrind tool on linux-2.6.31 with arm9 core embedded system. Please let me know where did it went wrong with following command and how to fix this issue. #valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./test ==1893== Memcheck, a memory error detector ==1893== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==1893== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==1893== Command: ./test ==1893== --1893-- WARNING: Serious error when reading debug info --1893-- When reading debug info from ./test: --1893-- Ignoring non-Dwarf2/3/4 block in .debug_info valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: memcpy valgrind: in an object with soname matching: ld-linux.so.3 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux.so.3 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Cannot continue -- exiting now. Sorry. -- Venkatram <ven...@vi...> Linkwell Telesystems Pvt. Ltd. web : www.visiontek.co.in |
|
From: Matt S. <mat...@re...> - 2011-03-08 12:50:20
|
Hello, If I use valgrind on a program that calls shmat() on a buffer that was allocated by shmget() using the SHM_HUGETLB flag, shmat() returns -1 and sets errno to EINVAL. The shmaddr argument to shmat() is NULL. This error is only reported when running under valgrind. This behavior is seen under RHEL5 and RHEL6 x86_64. If I remove the SHM_HUGETLB flag from shmget(), there is no error. I have tried this under RHEL-distributed valgrind 3.5 and compiled-from-source 3.6.1. Should this work? Thank you, Matt |
|
From: Sky D. <sdn...@ya...> - 2011-03-06 09:04:44
|
Hi all,
I wonder is it possible to get ExeContent or StackTrace anywhere I want. For
example, I want to get the stack trace when die_mem_stack wrapper is called or
right after every WrTmp IR is executed. Is it possible by using the public
interfaces provided by valgrind core? Or I have to build my own system to store
all the stack trace?
Every advice will be appreciated. Thank you in advance!
All the best,
Xuefeng Dai
|
|
From: Bart V. A. <bva...@ac...> - 2011-03-03 18:50:08
|
On Thu, Mar 3, 2011 at 7:28 PM, Tony Finch <do...@do...> wrote:
> On Thu, 3 Mar 2011, Bart Van Assche wrote:
>>
>> Does the patch below help ?
>
> Mostly, except it exposes an __attribute__ clause which also upsets
> standard-C compilers.
>
> I did the following patch which has the disadvantage of causing warnings
> about expressions without side-effects.
>
> [ ... ]
Does the second version of this patch (see below) work better ?
Index: include/valgrind.h
===================================================================
--- include/valgrind.h (revision 11577)
+++ include/valgrind.h (working copy)
@@ -4415,14 +4415,7 @@
is the number of characters printed, excluding the "**<pid>** " part at the
start and the backtrace (if present). */
-#if defined(NVALGRIND)
-
-# define VALGRIND_PRINTF(...)
-# define VALGRIND_PRINTF_BACKTRACE(...)
-
-#else /* NVALGRIND */
-
-#if !defined(_MSC_VER)
+#if defined(__GNUC__) || defined(__INTEL_COMPILER)
/* Modern GCC will optimize the static routine out if unused,
and unused attribute will shut down warnings about it. */
static int VALGRIND_PRINTF(const char *format, ...)
@@ -4434,6 +4427,9 @@
#endif
VALGRIND_PRINTF(const char *format, ...)
{
+#if defined(NVALGRIND)
+ return 0;
+#else /* NVALGRIND */
unsigned long _qzz_res;
va_list vargs;
va_start(vargs, format);
@@ -4452,9 +4448,10 @@
#endif
va_end(vargs);
return (int)_qzz_res;
+#endif /* NVALGRIND */
}
-#if !defined(_MSC_VER)
+#if defined(__GNUC__) || defined(__INTEL_COMPILER)
static int VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
__attribute__((format(__printf__, 1, 2), __unused__));
#endif
@@ -4464,6 +4461,9 @@
#endif
VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
{
+#if defined(NVALGRIND)
+ return 0;
+#else /* NVALGRIND */
unsigned long _qzz_res;
va_list vargs;
va_start(vargs, format);
@@ -4482,11 +4482,10 @@
#endif
va_end(vargs);
return (int)_qzz_res;
+#endif /* NVALGRIND */
}
-#endif /* NVALGRIND */
-
/* These requests allow control to move from the simulated CPU to the
real CPU, calling an arbitary function.
|