Re: [Valgrind-users] Suspect "uninitialised value(s)" error
On 12/10/2023 08:53, Paul Floyd wrote:
On 11/10/2023 23:47, Karl Robillard via Valgrind-users wrote:
I'm getting the following error on struct members which should absolutely be
initialized:
Conditional jump or move depends on uninitialised value(s)
To begin investigating I did a memset of zero on the entire struct and the
error goes away. Now this C++ struct inherits another one and the error is
reported in C code expecting the base struct. If I only memset the base
struct the error is still reported, which should be impossible.
Code summary of the weirdness:
struct ListDrawState : public DrawState { ... };
extern "C" void draw_func(DrawState*);
ListDrawState ds;
memset(, 0, sizeof(DrawState)); // Error in draw_func()
I don't think that this is legal C++. You can't assume that a C++ class
object has the same kind of memory layout as a POD C struct.
That's not any part of the problem code though, so it's not
really relevant to the original problem.
There's no way we can comment on the original problem though
because we can't actually see any of the code, only a few top
level highlights which is nowhere near enough to tell us
anything about what is happening.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Does Valgrind support AMD Ryzen 5 5600X processors
That depends how you define support. I use it on a Ryzen all the time, but not with code compiled to target all the AMD specific extensions, which we do not currently have support for. Tom On 19/07/2023 12:39, Stuart Foster via Valgrind-users wrote: I am trying to find which of my systems will run valgrind, I know it will not run on my AMD FX-8370� and AMD FX-4350 systems. Does any one know if it should run on my AMD Ryzen 5 5600X (see failure below) ? I have access to an Intel core 7 laptop (Haswell), would I stand a better chance with that, I am reluctant to move my whole project to the laptop if there is no chance of Valgrind working there too. ==5096== Memcheck, a memory error detector ==5096== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==5096== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info ==5096== Command: QtWeather -s moira2 ==5096== vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0xDC 0xC9 0x48 0x39 0xD1 0x73 0x37 vex amd64->IR:�� REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR:�� VEX=1 VEX.L=1 VEX.n=0x0 ESC=0F38 vex amd64->IR:�� PFX.66=1 PFX.F2=0 PFX.F3=0 ==5096== valgrind: Unrecognised instruction at address 0x5ee6282. ==5096==��� at 0x5EE6282: aeshash256_ge32(long long __vector(4), unsigned char const*, unsigned long) (in /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0) ==5096==��� by 0x5FEBFD1: QFactoryLoaderPrivate::updateSinglePath(QString const&) (in /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0) ==5096==��� by 0x5FE8403: QFactoryLoader::update() (in /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0) ==5096==��� by 0x5FE8906: QFactoryLoader::QFactoryLoader(char const*, QString const&, Qt::CaseSensitivity) (in /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0) ==5096==��� by 0x54DC115: QPlatformIntegrationFactory::keys(QString const&) (in /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0) ==5096==��� by 0x54A1A36: init_platform(QString const&, QString const&, QString const&, int&, char**) (in /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0) ==5096==��� by 0x54A58DF: QGuiApplicationPrivate::createPlatformIntegration() (in /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0) ==5096==��� by 0x54A6517: QGuiApplicationPrivate::createEventDispatcher() (in /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0) ==5096==��� by 0x5F64804: QCoreApplicationPrivate::init() (in /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0) ==5096==��� by 0x54A9979: QGuiApplicationPrivate::init() (in /opt/qt-6.4.0/lib/libQt6Gui.so.6.4.0) ==5096==��� by 0x4C28708: QApplicationPrivate::init() (in /opt/qt-6.4.0/lib/libQt6Widgets.so.6.4.0) ==5096==��� by 0x124098: main (in /usr/bin/QtWeather) ==5096== Your program just tried to execute an instruction that Valgrind ==5096== did not recognise.� There are two possible reasons for this. ==5096== 1. Your program has a bug and erroneously jumped to a non-code ==5096==��� location.� If you are running Memcheck and you just saw a ==5096==��� warning about a bad jump, it's probably your program's fault. ==5096== 2. The instruction is legitimate but Valgrind doesn't handle it, ==5096==��� i.e. it's Valgrind's fault.� If you think this is the case or ==5096==��� you are not sure, please let us know and we'll try to fix it. ==5096== Either way, Valgrind will now raise a SIGILL signal which will ==5096== probably kill your program. ==5096== ... Thanks ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgrind gets fatal signal when particular syscall is made by an executable
On 03/07/2023 10:42, Daniel Fishman wrote: Thanks for the pointer. I just commented out the line for the mentioned syscall number from valgrind's syscall table, and this workaround was enough to solve the problem. Since the custom syscall doesn't modify its parameters and doesn't seem to write anything in user space, it seems that writing a wrapper for it is not strictly necessary - or very useful for that matter, since in any case it won't be possible to submit a valgrind patch for the problem. Well pread will be reading user memory so the wrapper would be checking that the memory it was given was valid, and that the file descriptor argument is valid. Not doing that won't break anything of course, it just means you may not detect some problems in your program. Beyond this problem, maybe it could be useful if upon encountering an impossible problem (the one when valgrind writes: "valgrind: the 'impossible' happened"), valgrind will send a user to read the file README_MISSING_SYSCALL_OR_IOCTL in addition to telling him to read FAQ. Had I been aware of this file before, I would have known how to solve the problem myself. Well sure, but the chances that a random SEGV in valgrind are caused by a syscall issue are probably less than 1% so doing that would mostly just be completely misleading. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind not finding issue with writing/reading past array?
This is in fact documented in the FAQ here:
https://valgrind.org/docs/manual/faq.html#faq.overruns
The fact it's an array is not actually important - there is no
overrun detection for any global or stack variables.
The reason is that because valgrind is operating on an existing
binary there is no way to insert guards between variables because
the compiler has already fixed the layout - for the heap valgrind
can replace the allocate with one that adds guards around each
allocated block.
The tool Philippe refers to tried to use debug information where
possible to spot out of bounds writes but it wasn't very successful.
Better is to use address sanitizer, which requires recompilation
but because of that it is able to add guards around variables.
Tom
On 26/09/2022 21:20, Philippe Waroquiers wrote:
Valgrind does not check out of bound write in arrays, unless these arrays are
malloc-ed
(and so valgrind can detect the write out of the limit of the malloc-ed block).
Valgrind used to contain an experimental tool (sgcheck) that did such stack
array checks,
but it had several limitations and problems, and was removed.
Thanks
Philippe
On Mon, 2022-09-26 at 14:13 -0600, Grant Schoep wrote:
So I noticed something in my code that looked wrong to me, but valgrind didn't
report
anything. I made a small example of it, and still no findings. I'm sure this
code is
reading/writing past its array. But valgind doesn't say anything.
I'm I not understanding something or is this a bug.
Using:
valgrind-3.19.0, gcc 4.8.5, CentOS 7
I also tried
valgrind-3.19.0, gcc 7.3.1, Amazon Linux 2
Here is the code.
--
#include
#include
int main()
{
char retStr[32];
// this is bad right? 40 bytes when above was 32?
memset(retStr, 'F', 40);
// These are "writing" past the allocated memory?
retStr[32] = 'A';
retStr[33] = 'B';
// These should be fine
printf("*** retStr is %c\n", retStr[30]);
printf("*** retStr is %c\n", retStr[31]);
// These are reading past allocated memory?
printf("*** retStr is %c\n", retStr[32]);
printf("*** retStr is %c\n", retStr[33]);
return 0;
}
---
Compiled:
"gcc filename.cxx"
Ran via this command
"valgrind ./a.out"
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] memcheck is getting SIGKILLed before leak report is output
On 01/09/2022 01:03, Bresalier, Rob (Nokia - US/Murray Hill) wrote: Don't understand why strace log has exit(0) without the underscore, I know for a fact that it was with the underscore. Because exit() and _exit() are C library functions but both call the SYS_exit system call and that is what strace shows. The difference is that _exit doesn't run atexit() handlers or do any other cleanup before calling SYS_exit. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] memcheck is getting SIGKILLed before leak report is output
On 05/08/2022 14:09, Bresalier, Rob (Nokia - US/Murray Hill) wrote: When running memcheck on a massive monolith embedded executable (237MB stripped, 1.8GiB unstripped), after I stop the executable under valgrind I see the “HEAP SUMMARY” but then valgrind dies before any leak reports are printed. The parent process sees that the return status of memcheck is that it was SIGKILLed (status returned in waitpid call is ‘9’). I am 99.9% sure that the parent process is not the one sending the SIGKILL. Is it possible that valgrind SIGKILLs itself? Is there a reason that the linux kernel (Wind River Linux) could be sending a SIGKILL to valgrind/memcheck? I do not see any messages about Out of Memory/OOM killer killing valgrind. Previous experience with this executable is that there are almost 3 million leak reports (most of them are “still reachable”), could that be occupying too much memory. Any ideas/advice to figure out what is going on? Almost certainly the kernel OOM kiied it. If you want to know for sure who killed it then strace it while it runs and it should show you who sends the signel but my bet is that it's the kernel. One thing I see in the logs is about “unhandled ioctl 0xa5 with no size/direction hints”. Could this be a trigger for this crash/sigkill? Not really, no. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] new error message from Valgrind
No, it's clone3: https://bugs.kde.org/show_bug.cgi?id=420906 Tom On 03/08/2022 17:30, Mark Roberts wrote: Just tried running the Valgrind test suite on WSL2 (win 10, Ubuntu 22.04). I'm not surprised that there were lots of failures. But the majority were: WARNING: unhandled amd64-linux syscall: 435 I suspect WSL is not a platform you care much about, but looking at syswrap for Darwin I see this might be pid hibernate? Would it be difficult to add support for this? Thank you, Mark -Original Message- From: Mark Wielaard [mailto:m...@klomp.org] Sent: Monday, August 1, 2022 4:56 AM To: Tom Hughes ; Mark Roberts ; valgrind-users@lists.sourceforge.net Subject: Re: [Valgrind-users] new error message from Valgrind On Thu, 2022-07-28 at 22:22 +0100, Tom Hughes via Valgrind-users wrote: On 28/07/2022 21:39, Mark Roberts wrote: I recently upgraded from Ubutu 20.04 to 22.04 and am now getting a new error message from Valgrind: --915-- WARNING: unhandled amd64-linux syscall: 334 --915-- You may be able to write your own handler. --915-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --915-- Nevertheless we consider this a bug. Please report --915-- it at http://valgrind.org/support/bug_reports.html <http://valgrind.org/support/bug_reports.html>. Using same version of Valgrind as before (3.17). Any ideas as to what’s happening? Yes, your libc has started trying to use rseq. It's harmless - the next version of valgrind will silently reject it with ENOSYS which is what is happening now anyway just with a warning. Where the next version of valgrind is 3.19.0 which is already released (in April). So you might just want to upgrade your valgrind. If you want to backport to older versions then the commit that got rid of the warning was: commit 1024237358f01009fe233cb1294f3b8211304eaa Author: Mark Wielaard Date: Fri Dec 10 17:41:59 2021 +0100 Implement linux rseq syscall as ENOSYS This implements rseq for amd64, arm, arm64, ppc32, ppc64, s390x and x86 linux as ENOSYS (without warning). glibc will start using rseq to accelerate sched_getcpu, if available. This would cause a warning from valgrind every time a new thread is started. Real rseq (restartable sequences) support is pretty hard, so for now just explicitly return ENOSYS (just like we do for clone3). https://sourceware.org/pipermail/libc-alpha/2021-December/133656.html Cheers, Mark -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] new error message from Valgrind
On 28/07/2022 21:39, Mark Roberts wrote: I recently upgraded from Ubutu 20.04 to 22.04 and am now getting a new error message from Valgrind: --915-- WARNING: unhandled amd64-linux syscall: 334 --915-- You may be able to write your own handler. --915-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --915-- Nevertheless we consider this a bug. Please report --915-- it at http://valgrind.org/support/bug_reports.html <http://valgrind.org/support/bug_reports.html>. Using same version of Valgrind as before (3.17). Any ideas as to what’s happening? Yes, your libc has started trying to use rseq. It's harmless - the next version of valgrind will silently reject it with ENOSYS which is what is happening now anyway just with a warning. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] armhf: illegal hardware instruction
On 29/06/2022 15:49, Mathieu Malaterre wrote:
Here is what I get on first try:
Program received signal SIGILL, Illegal instruction.
vgPlain_am_startup (sp_at_startup=3204445696) at
m_aspacemgr/aspacemgr-linux.c:1626
1626 init_nsegment();
(gdb) x/i $pc
=> 0x58071090 : vmov.i32d16, #0 ; 0x
(gdb) x/12i $pc-6*4
0x58071078 :eoreq
r6, lr, r4, lsr #6
0x5807107c : push{r4, r5, r6, r7, r8,
r9, r10, r11, lr}
0x58071080 : sub sp, sp, #68 ; 0x44
0x58071084 : add r8, sp, #8
0x58071088 : mov r4, r0
0x5807108c : bl 0x5807611c
=> 0x58071090 : vmov.i32d16, #0 ; 0x
0x58071094 : mov lr, r8
0x58071098 : mov r3, #0
0x5807109c : mov r10, #1
0x580710a0 : str r3, [sp, #56] ; 0x38
0x580710a4 : mvn r2, #0
(gdb) x/12xw $pc-6*4
0x58071078 :
0x002e6324 0xe92d4ff0 0xe24dd044 0xe28d8008
0x58071088 : 0xe1a04000 0xeb001422
0xf2c00010 0xe1a0e008
0x58071098 : 0xe3a03000 0xe3a0a001
0xe58d3038 0xe3e02000
(gdb) info reg
r0 0x4 4
r1 0x0 0
r2 0x5850a0e8 1481679080
r3 0x5850a0f8 1481679096
r4 0xbefff600 3204445696
r5 0x58606388 1482711944
r6 0xbefff600 3204445696
r7 0x5826 1478885376
r8 0x58708258 1483768408
r9 0x58708354 1483768660
r100x0 0
r110x587083ac 1483768748
r120x5870a3b4 1483776948
sp 0x58708250 0x58708250
lr 0x58071090 1476858000
pc 0x58071090 0x58071090
cpsr 0x8010 -2147483632
fpscr 0x0 0
(gdb) x/16xw $sp
0x58708250 : 0x
0x 0x 0x
0x58708260 : 0x
0x 0x 0x
0x58708270 : 0x
0x 0x 0x0013296c
0x58708280 : 0xbefff604
0xbefff600 0x5826 0x581fea9c
As a reminder I do not have neon on this machine:
Features: half thumb fastmult vfp edsp thumbee vfpv3 tls idiva
idivt vfpd32 lpae
Right but you are apparently using a valgrind that was compiled
to target a machine that does have neon, hence your problem.
If you compiled it yourself then you need to change your compiler
options to correctly target the architecture you are running on
and if you got precompiled binaries from somewhere then I'm afraid
they're not compatible with your machine.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] How to do handle SIGILL nostop in valgrind?
On 26/06/2022 09:13, ellie wrote: How do I run openssl programs in valgrind on processors where it causes SIGILL? https://www.openssl.org/docs/faq.html#PROG17 In what way is it not working? When valgrind encounters an instruction it doesn't understand it logs the details and then passes the SIGILL to and signal handler which the application has registered exactly as openssl appears to be expecting. Are you sure the SIGILL you're seeing is caused by openssl processor feature detection and isn't just some other random instruction that valgrind doesn't implement yet? What architecture is this? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Question about Valgrind tool in Intel new platform
On 20/04/2022 13:41, Tom Hughes via Valgrind-users wrote: Again until we know what "AMX features" are it's impossible to comment in any detail. So apparently AMX is this: https://en.wikipedia.org/wiki/Advanced_Matrix_Extensions So not only is it new instructions, it is new two dimensional registers so it's likely to be a huge task to add support. I think we're still trying to get the AVX512 support merged so that might give you some idea of the timelines on this sort of change. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Question about Valgrind tool in Intel new platform
On 20/04/2022 13:18, Yang Zhong wrote: On Wed, Apr 20, 2022 at 09:37:17AM +0100, Tom Hughes wrote: On 20/04/2022 09:01, Yang Zhong wrote: So, from above issue in Intel new platform, the valgrind need do some enablings to be compatible with on new platform? Seems valgrind tool can't identify the real HW platform because cpuid can't read correct register value. thanks! When running under valgrind you are running on an emulated CPU not the real CPU and the results of cpuid will reflect the capabilities of that emulated CPU rather than the real CPU. Do the bits that you are trying to check reflect something (like new instructions) that valgrind will need to be concerned about? Thanks Tom for your quickly response! The AMX is the NEW feature in Intel new platform and from host, we can find below cpu flags: amx_bf16, amx_tile, amx_int8 That tells me nothing. The SPEC can be found in: https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf No I'm not going to spend my day digging through thousands of pages of the latest instruction set reference trying to figure out what exactly this feature is... The issue I mentioned should be related with AMX features missed in valgrind emulated CPU. If someone will implement this feature on valgrind, I can help verify. Thanks! Again until we know what "AMX features" are it's impossible to comment in any detail. If AMX features involved new instructions then yes it will definitely need somebody to do the work to add support for them. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Question about Valgrind tool in Intel new platform
On 20/04/2022 09:01, Yang Zhong wrote: So, from above issue in Intel new platform, the valgrind need do some enablings to be compatible with on new platform? Seems valgrind tool can't identify the real HW platform because cpuid can't read correct register value. thanks! When running under valgrind you are running on an emulated CPU not the real CPU and the results of cpuid will reflect the capabilities of that emulated CPU rather than the real CPU. Do the bits that you are trying to check reflect something (like new instructions) that valgrind will need to be concerned about? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] CPU simulation and instruction simulation
On 06/02/2021 07:59, Muhui Jiang wrote: I am new to Valgrind and have some questions about the principles of Valgrind. According to the manual, https://valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes <https://valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes> "Your program is then run on a synthetic CPU provided by the Valgrind core." "Valgrind simulates every single instruction your program executes" I am curious that as a binary instrumentation framework, why Valgrind needs to simulate the CPU and instruction execution. It seems that the host and guest architecture must be the same due to the multiple syscalls. If so, why not use the host CPU to run the translated binary directly instead of simulation? Simulated instruction execution might be different from the execution on physical devices. It does run on the native CPU because valfrind is a JIT that converts the original instructions to an internal form which it analyses and instruments and then converts the instrumented code back into native code which is then run on the real processor. But from the point of view of the program it is running on valgrind's emulated CPU and can only use those instructions and features which valgrind knows how to emulate. The other question is that what part is simulated for a CPU except for the instruction execution. Are the memory model, cache, and registers all simulated/emulated. Any suggestions and comments are welcome. Many Thanks The cache is simulated in parallel for cachegrind/callgrind in order to generate estimated statistics for cache hit/misses. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] using valgrind to debug uninitialized mem in servern
On 04/02/2021 10:57, Matthias Apitz wrote:
El día jueves, febrero 04, 2021 a las 09:48:23a. m. +, Tom Hughes escribió:
On 04/02/2021 09:26, Matthias Apitz wrote:
At the moment we use the following "trick": the librarian runs in
parallel to the client on the desktop a second window with a "tail -f ..."
on valgrinds log file (STDOUT) and the full screen is recorded with
Microsoft teams functionality. So we can use the timestamps in the log
to go to the replay of the recording and can see what the user did
exactly, which data was entered and which button pressed etc.
Are there other ideas to bring together the valgrind log and the usage
of the application?
You could instrument the request processing logic to log details
of the request if any errors are detected while processing it, so
something like:
#include "valgrind/valgrind.h"
return_type process_request(...)
{
int errors = VALGRIND_COUNT_ERRORS;
// process request as normal
if (VALGRIND_COUNT_ERRORS > errors)
{
VALGRIND_PRINTF("Saw errors processing request %s", request_name);
}
}
Obviously you can change it to log whatever details you want.
Thanks, this looks like a good plan!
The above are macros, are there additional shared libs to link with our
process?
No - the valgrind client directives work by generating a special
sequence of assembly language instructions that is spotted by the
valgrind virtual machine and causes valgrind to generate a call to
an internal routine.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] using valgrind to debug uninitialized mem in servern
On 04/02/2021 09:26, Matthias Apitz wrote:
At the moment we use the following "trick": the librarian runs in
parallel to the client on the desktop a second window with a "tail -f ..."
on valgrinds log file (STDOUT) and the full screen is recorded with
Microsoft teams functionality. So we can use the timestamps in the log
to go to the replay of the recording and can see what the user did
exactly, which data was entered and which button pressed etc.
Are there other ideas to bring together the valgrind log and the usage
of the application?
You could instrument the request processing logic to log details
of the request if any errors are detected while processing it, so
something like:
#include "valgrind/valgrind.h"
return_type process_request(...)
{
int errors = VALGRIND_COUNT_ERRORS;
// process request as normal
if (VALGRIND_COUNT_ERRORS > errors)
{
VALGRIND_PRINTF("Saw errors processing request %s", request_name);
}
}
Obviously you can change it to log whatever details you want.
The only issue might be that if the code is multithreaded and can
process multiple requests in parallel then you won't know which
thread the errors came from.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] printing the values of arguments for strcpy(3), memmove(3), ...
On 26/01/2021 09:32, Matthias Apitz wrote:
So far so good. What would have helped me is that vg could print in its
replacement functions for memmove(3) ... (vg_replace_strmem.c:1270)
the provided pointers and other args, and as well part of the src
buffer. For sure vg knows exactly these values to watch the illegal
memory access.
If the memory is uninitialised then printing it's contents
shouldn't really be useful as they will have no meaning...
Presumably it was partially initialised in this case but it
sounds like quite an edge case and it's easy enough to add
some custom debugging to your code when it does help in cases
like this. I'm not clear if you just printed everything but
you can conditionalise it to only print the failing case:
if ( VALGRIND_CHECK_MEM_IS_DEFINED( src, n ) )
{
fprintf( stderr, "ERROR: %.*s\n", n, src );
}
if you want to get really clever you can limit it to printing
the valid part:
const char *fail = VALGRIND_CHECK_MEM_IS_DEFINED( src, n );
if ( fail )
{
fprintf( stderr, "ERROR: %.*s\n", fail - src, src );
}
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [Need Help] Valgrind on Cavium-Octeon-3
No idea - that will be down to your cross build toolchain. Tom On 10/01/2021 18:21, mihir amrelia wrote: Tom, Thanks a lot for your response. Yes, it doesn't look like the one I should be expecting.. file /var/tmp/cavium/bin/valgrind /var/tmp/cavium/bin/valgrind: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), dynamically linked, interpreter /lib64-f, for GNU/Linux 2.6.32, not stripped How to fix this? -Mihir On Thursday, 7 January, 2021, 04:36:45 pm IST, Tom Hughes wrote: On 07/01/2021 10:54, mihir amrelia via Valgrind-users wrote: > I am trying to get valgrind running on cavium octeon 3 processor. > > > Couldn't find any specific build configs for this other than some hints > on the valgrind wiki. > * > * > * > The steps executed to build valgrind for cavium were (on x86_64 host): > *export CC=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-gcc > export CXX=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-g++ > export PATH=$PATH:/opt/cavium-64bit/tools-3535/bin/ > ./configure --host=mips64-linux-gnu --target=mips64-octeon-linux > --prefix=/home/mihira/workspace/mylab/valgrind/cavium > --exec-prefix=/var/tmp/cavium --disable-tls > make && make install > > *While trying to run it on target (copied the elfs to /var/tmp/cavium/ > dir on the target):* > export VALGRIND_LIB=/var/tmp/cavium/lib/valgrind/ > export PATH=$PATH:/var/tmp/cavium/bin/ > valgrind -h > -bash: /var/tmp/cavium/bin/valgrind: No such file or directory > > > What's that blunder I am doing? At a guess the ELF interpreter specified in the compiled valgrind launcher doesn't exist - that can lead to that confusing error when running a executable that exists. Try "file /var/tmp/cavium/bin/valgrind" and see what it says about it - part of the result should be something like this: interpreter /lib64/ld-linux-x86-64.so.2 which will tell what interpreter it is using. Tom -- Tom Hughes (t...@compton.nu <mailto:t...@compton.nu>) http://compton.nu/ <http://compton.nu/> -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Integrating Valgrind into code
On 07/01/2021 19:15, Aaron Boxer wrote: I am hunting for an uninitialized memory issue. I have integrated valgrind into my code, using cmake find_package, but when I call |VALGRIND_CHECK_MEM_IS_DEFINED| it always returns 0 no matter what I pass in. For example |VALGRIND_CHECK_MEM_IS_DEFINED(0x00,0xFF)| returns zero. Am I missing something ? Well address zero is likely uninitialised so you would expect it to return zero as that is the address of the first uninitialised byte in the block - obviously that is unhelpful because it's the same response as if the whole block was defined but real systems will never use address zero for anything. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [Need Help] Valgrind on Cavium-Octeon-3
On 07/01/2021 10:54, mihir amrelia via Valgrind-users wrote: I am trying to get valgrind running on cavium octeon 3 processor. Couldn't find any specific build configs for this other than some hints on the valgrind wiki. * * * The steps executed to build valgrind for cavium were (on x86_64 host): *export CC=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-gcc export CXX=/opt/cavium-64bit/tools-3535/bin/mips64-octeon-linux-gnu-g++ export PATH=$PATH:/opt/cavium-64bit/tools-3535/bin/ ./configure --host=mips64-linux-gnu --target=mips64-octeon-linux --prefix=/home/mihira/workspace/mylab/valgrind/cavium --exec-prefix=/var/tmp/cavium --disable-tls make && make install *While trying to run it on target (copied the elfs to /var/tmp/cavium/ dir on the target):* export VALGRIND_LIB=/var/tmp/cavium/lib/valgrind/ export PATH=$PATH:/var/tmp/cavium/bin/ valgrind -h -bash: /var/tmp/cavium/bin/valgrind: No such file or directory What's that blunder I am doing? At a guess the ELF interpreter specified in the compiled valgrind launcher doesn't exist - that can lead to that confusing error when running a executable that exists. Try "file /var/tmp/cavium/bin/valgrind" and see what it says about it - part of the result should be something like this: interpreter /lib64/ld-linux-x86-64.so.2 which will tell what interpreter it is using. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind-3.16.0.RC2 is available for testing
That's correct as AVX512 is not currently supported in valgrind so you will need a version that doesn't use that for valgrind use. Progress on adding AVX512 support is being tracked here: https://bugs.kde.org/show_bug.cgi?id=383010 Tom On 26/05/2020 10:07, Patrick Bégou wrote: Thanks all for these precisions. I have deployed OpenMPI myself. So I have to build it again, disabling AVX512 optimizations. This level of optimization is used in all our CFD codes and libraries as it improve the global code performances. Patrick Le 26/05/2020 à 10:45, Tom Hughes a écrit : Sorry, I misunderstood what you meant by "as previous version" there. I thought you meant the previous version worked but you actually meant that it failed. As Julian says there is no easy fix - you have a library installed that has been compiled to assume certain instructions are available that are not in fact available under valgrind at the moment. Tom On 26/05/2020 09:26, Patrick Bégou wrote: Hi Tom, I'm a new user of Valgrind. I was needing it to check a large mpi code. So I downloaded 3.15 version but even if hardware and software are 2 to 3 years old, valgrind does'nt work for me. Nor gcc7, nor OpenMPI, nor my application (even the small test) used specific option when they were built. If this unsupported instruction (I do not know what is an EVEX prefix, sorry) is the problem, how can I avoid it to use valgrind ? I was just thinking that 3.16 could solve my problem Patrick Le 26/05/2020 à 10:12, Tom Hughes a écrit : On 26/05/2020 09:06, Patrick Bégou wrote: valgrind-3.16.0.RC2 doesn't work for me (as previous version on this server). Are you saying that it fails on a binary that worked before? vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5 0x25 0xA8 0x18 0x0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==306850== valgrind: Unrecognised instruction at address 0x6ddf581. vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5 0x25 0xA8 0x18 0x0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 Because this is an instruction with an EVEX prefix that is not supported by any version of valgrind ever so I don't see how this binary can have worked with the previous version of valgrind. I suspect that you have in fact recompiled the program with a different compiler or different optimization settings since the time when it worked? Tom ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind-3.16.0.RC2 is available for testing
Sorry, I misunderstood what you meant by "as previous version" there. I thought you meant the previous version worked but you actually meant that it failed. As Julian says there is no easy fix - you have a library installed that has been compiled to assume certain instructions are available that are not in fact available under valgrind at the moment. Tom On 26/05/2020 09:26, Patrick Bégou wrote: Hi Tom, I'm a new user of Valgrind. I was needing it to check a large mpi code. So I downloaded 3.15 version but even if hardware and software are 2 to 3 years old, valgrind does'nt work for me. Nor gcc7, nor OpenMPI, nor my application (even the small test) used specific option when they were built. If this unsupported instruction (I do not know what is an EVEX prefix, sorry) is the problem, how can I avoid it to use valgrind ? I was just thinking that 3.16 could solve my problem Patrick Le 26/05/2020 à 10:12, Tom Hughes a écrit : On 26/05/2020 09:06, Patrick Bégou wrote: valgrind-3.16.0.RC2 doesn't work for me (as previous version on this server). Are you saying that it fails on a binary that worked before? vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5 0x25 0xA8 0x18 0x0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==306850== valgrind: Unrecognised instruction at address 0x6ddf581. vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5 0x25 0xA8 0x18 0x0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 Because this is an instruction with an EVEX prefix that is not supported by any version of valgrind ever so I don't see how this binary can have worked with the previous version of valgrind. I suspect that you have in fact recompiled the program with a different compiler or different optimization settings since the time when it worked? Tom ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind-3.16.0.RC2 is available for testing
On 26/05/2020 09:06, Patrick Bégou wrote: valgrind-3.16.0.RC2 doesn't work for me (as previous version on this server). Are you saying that it fails on a binary that worked before? vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5 0x25 0xA8 0x18 0x0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==306850== valgrind: Unrecognised instruction at address 0x6ddf581. vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5 0x25 0xA8 0x18 0x0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 Because this is an instruction with an EVEX prefix that is not supported by any version of valgrind ever so I don't see how this binary can have worked with the previous version of valgrind. I suspect that you have in fact recompiled the program with a different compiler or different optimization settings since the time when it worked? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Program crashes with valgrind
On 20/05/2020 17:01, James Read wrote: On Wed, May 20, 2020 at 2:31 PM Tom Hughes <mailto:t...@compton.nu>> wrote: On 20/05/2020 14:23, James Read wrote: > I'm trying to use valgrind to track down a memory leak in my web > crawling application. The problem is my application runs just fine > without valgrind but when I run it under valgrind the program crashes > before it has a chance to crawl any websites. Any ideas why this > behaviour could happen? On the basis of the information supplied I'd say it was caused by excess neutron flux in the discombobulator. Seriously, if you want anybody to actually try and answer your question then you'll have to provide some actual information like, what exactly it says... A typical run of my program gives the following output: Redis server: :0 Mongo server: 127.0.0.1:27017 <http://127.0.0.1:27017> URL file: links/links-2 Max connections: 1000 Selected JUST CRAWLER MODE Parsed sites: 132 ^C Crawler thread exiting. Exiting. But with valgrind ./crawler -c I get the following output: ==415433== Memcheck, a memory error detector ==415433== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==415433== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==415433== Command: ./crawler -c ==415433== Redis server: :0 Mongo server: 127.0.0.1:27017 <http://127.0.0.1:27017> URL file: links/links-2 Max connections: 1000 Selected JUST CRAWLER MODE ==415433== Warning: ignored attempt to set SIGKILL handler in sigaction(); ==415433== the SIGKILL signal is uncatchable setrlimit() failed ==415433== ==415433== HEAP SUMMARY: ==415433== in use at exit: 37,773 bytes in 92 blocks ==415433== total heap usage: 6,112 allocs, 6,020 frees, 460,106 bytes allocated ==415433== ==415433== LEAK SUMMARY: ==415433== definitely lost: 0 bytes in 0 blocks ==415433== indirectly lost: 0 bytes in 0 blocks ==415433== possibly lost: 0 bytes in 0 blocks ==415433== still reachable: 37,773 bytes in 92 blocks ==415433== suppressed: 0 bytes in 0 blocks ==415433== Rerun with --leak-check=full to see details of leaked memory ==415433== ==415433== For lists of detected and suppressed errors, rerun with: -s ==415433== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) As you can see no Parsed sites: value message just crashes and burns. I don't see any crash there, just a program that has chosen to exit. Does your code exit when setrlimit fails? What sort of limit is it trying to set? My guess is that it's trying to play with RLIMIT_NOFILE in a way that would encroach on valgrind's reserved descriptors so valgrind is refusing the request and your program is then chooding to exist rather than continue. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Program crashes with valgrind
On 20/05/2020 14:23, James Read wrote: I'm trying to use valgrind to track down a memory leak in my web crawling application. The problem is my application runs just fine without valgrind but when I run it under valgrind the program crashes before it has a chance to crawl any websites. Any ideas why this behaviour could happen? On the basis of the information supplied I'd say it was caused by excess neutron flux in the discombobulator. Seriously, if you want anybody to actually try and answer your question then you'll have to provide some actual information like, what exactly it says... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] New user and first problem
On 18/05/2020 18:48, Julian Seward wrote: Program received signal SIGILL: Illegal instruction. Backtrace for this error: vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5 0x25 0xA8 0x18 0x0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==377969== valgrind: Unrecognised instruction at address 0xabf9581. ==377969== at 0xABF9581: opal_pointer_array_construct (in /opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3) It sounds like there's an instruction in libopen-pal.so.40.10.3 that Valgrind doesn't like. What CPU does the machine have? 0x62 is an EVEX prefix from the AVX512 extensions, so isn't supported yet. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Write new tool in C++?
On 04/03/2020 14:46, Derrick McKee wrote: Is it possible to write a tool using C++ instead of just C? In theory, maybe, but the problem you're going to have is that you have no run time library support - no libstdc+++ and not even any libc. So there are probably various things that need run time support that just aren't going to work and you're not going to have any of the normal library data structures and things. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Invalid read well inside a block alloc'd
On 14/01/2020 19:15, Paul-Antoine Arras wrote: Le 14/01/2020 à 20:01, Tom Hughes a écrit : Using it as a thread stack could also do it, though it looks a bit small for that, or some sort or whacky stack pointer stunts that lead to valgrind thinking it's part of the stack. That's interesting. The block in question is not a thread stack but a regular struct. However, at other places the code does play with manually-allocated thread stacks, hence stack pointer switches that might confuse Valgrind. Can you see a way to confirm this conjecture? In other words, how can I ensure this is a legitimate false positive? I wouldn't expect it to go wrong with straightforward use where malloced blocks are passed to clone as a thread stack, at least if the correct size is passed, but if you start doing some sort of coroutines or green thread type stuff and doing context switching in user space then that's another story. Basically when valgrind thinks the stack pointer is moving upwards on return from a function it will mark the memory between the old and new pointers as invalid, but the problem is that there's no way to be sure from a write to the stack pointer if that is it being increased/decreased or if it's a switch to a new stack so valgrind has to employ heuristics and assume that big changes (for some value of big) are switches and small changes are moving up/down the stack. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Invalid read well inside a block alloc'd
On 14/01/2020 18:55, Paul-Antoine Arras wrote: Le 14/01/2020 à 19:51, Tom Hughes a écrit : On 14/01/2020 16:53, Paul-Antoine Arras wrote: [...] I struggle to understand how a read into a block of properly alloc'd memory can be invalid, given that the application doesn't use client requests. [...] How can a block of dynamically-allocated memory be marked unaddressable without having been freed? By using the VALGRIND_MAKE_MEM_NOACCESS macro. Sure, but as I mentioned in my message, the application code does not use client requests. Using it as a thread stack could also do it, though it looks a bit small for that, or some sort or whacky stack pointer stunts that lead to valgrind thinking it's part of the stack. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Invalid read well inside a block alloc'd
On 14/01/2020 16:53, Paul-Antoine Arras wrote: I'm stumbling upon a weird message from Valgrind when run on my application as follows: $ valgrind --vgdb=yes --vgdb-error=0 --undef-value-errors=no $my_app So Valgrind reports: ==1644== Thread 9: ==1644== Invalid read of size 8 ==1644== at 0x4A39B40: PR_int__give_lang_env_for_slave (PR__int.c:348) ==1644== Address 0x12d152c8 is 24 bytes inside a block of size 104 alloc'd ==1644== at 0x483577F: malloc (vg_replace_malloc.c:309) ==1644== by 0x4A3C4B4: [...] I struggle to understand how a read into a block of properly alloc'd memory can be invalid, given that the application doesn't use client requests. To be sure, I double-checked the status of the entire buffer under vgdb: (gdb) mo xb 0x12d152b0 104 [...] Address 0x12D152B0 len 104 has 104 bytes unaddressable How can a block of dynamically-allocated memory be marked unaddressable without having been freed? By using the VALGRIND_MAKE_MEM_NOACCESS macro. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Running Valgrind on ndmp
On 12/09/2019 14:00, Eliot Moss wrote: On 9/12/2019 5:45 AM, Pallavi Shinde wrote: We ran valgrind on ndmp by inserting the valgrind command within /etc/init.d/ndmpd, the script that starts ndmpd. valgrind did indeed run on ndmpd and we did get a memory check report, but it didn't keep itself attached to ndmpd. valgrind dumps the memory check log and exits. The exit status is '1'. Don't know how to 'keep valgrind attached' to ndmpd. Would there be any guidance on how to keep valgrind attached to ndmp? What do you mean by "keep itself attached"? From what you say, it sounds as if ndmpd ran and finished, so naturally valgrind finished. Everything went as you asked. As I explained at some length in my previous email what almost certainly happened is that ndmpd did what most daemons do, and forked itself into the background with the original process then exiting. Now because valgrind follows fork (but not exec) by default it would normally still follow the other process so I'm guessing that it actually re-execed, or execed some other program. Pallavi is the one debugging ndmpd though so I would hope he knows more abut how it starts up than we do! So, to repeat myself, either find a way to stop it forking like that, or find what it is execing and run that directly, or try --trace-children=yes to make valgrind follow exec. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Running Valgrind on ndmp
Probably not unless there happens to be somebody here that is familiar with "ndmpd" and how it starts up. You need to make sure that valgrind manages to wind up running the actual daemon so if there is some kind of launcher process that starts it then you need to try and avoid that and start the daemon directly. Many daemons have some kind of switch to do exactly that for debugging purpose, but you are probably more familiar with this program and how it starts than anybody here. You can also try --trace-children=yes but that will follow across all execs not just the one you are interested in. Tom On 09/09/2019 07:08, Pallavi Shinde wrote: Hi, Can we get any help here ? Thanks, Pallavi On Thu, Sep 5, 2019, 4:28 PM Pallavi Shinde <mailto:shinde.pa...@gmail.com>> wrote: Hi, Comments prefixed with [PS] below. > 1. service ndmpd stop > 2. service ndmpd start > 3. valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log --leak-check=full /usr/local/ndmp/ndmpd > > echo $? Returns 1 after the 3rd command. Does running ndmpd "by hand" work as the third step? 3. /usr/local/ndmp/ndmpd & # start in background, note the PID 4. ps -ef # does ndmpd show with the same PID as given by the shell? [PS] In step 3, the process, if run by hand (/usr/local/ndmp/ndmpd &) exits immideiately. If "service ndmpd start" does anything other than execute /usr/local/ndmp/ndmpd, then it may be necessary to add a level of indirection through a shell script that runs valgrind: 1. service ndmpd stop 2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real 3. cat >/usr/local/ndmp/ndmpd <mailto:jrei...@bitwagon.com>> wrote: > 1. service ndmpd stop > 2. service ndmpd start > 3. valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log --leak-check=full /usr/local/ndmp/ndmpd > > echo $? Returns 1 after the 3rd command. Does running ndmpd "by hand" work as the third step? 3. /usr/local/ndmp/ndmpd & # start in background, note the PID 4. ps -ef # does ndmpd show with the same PID as given by the shell? If "service ndmpd start" does anything other than execute /usr/local/ndmp/ndmpd, then it may be necessary to add a level of indirection through a shell script that runs valgrind: 1. service ndmpd stop 2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real 3. cat >/usr/local/ndmp/ndmpd <-- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net <mailto:Valgrind-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/valgrind-users ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Getting SIGKILL to work in MariaDB
On 12/08/2019 13:15, Michael Widenius wrote: The request I would like you to consider is to do one of the following: - Ensure that sending a sigkill works and in this case there should not be any valgrind leak report. - Add an api call where we could specify that we don't want any leak reports from now on. If this would exist then I could call this when we are about to send the SIGFPE/SIGKILL signal to the server. Please open a bug at https://bugs.kde.org/enter_bug.cgi?product=valgrind and attach a minimal test case if at all possible. Also the output of running valgrind with --trace-signals=yes would be a good thing to provide. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Mencheck not giving detailed info on routines in Shared Libraries:
On 10/07/2019 16:17, Julian Seward wrote: > Valgrind-3.13 (actually I compiled 3.15, but it says 3.13 with Valgrind > --version) In that case you're not running the version you compiled. Try running 3.15 and give it the flag --keep-debuginfo=yes. Does that help? If it was an so that had been unloaded then I don't think it would even show the name would it? So I'm not sure --keep-debuginfo=yes will help... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Mencheck not giving detailed info on routines in Shared Libraries:
On 10/07/2019 15:46, robert somerville wrote: Although I can debug this fine with Totalview, and even use Totalview memory debugger to find detailed location info on memory leaks, Valgrind (memcheck) is only giving me the vaguest info such as (below) : Valgrind-3.13 (actually I compiled 3.15, but it says 3.13 with Valgrind --version) It should be possible to get more detailed info out of Valgrind(memcheck), such as routine and line numbers ?? Well sure, if the files are compiled with debug information. Apparently they aren't, so you don't get anything more. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Master and -Wformat-overflow warning
On 02/05/2019 17:02, Mark Wielaard wrote: Hi Jeffrey, On Tue, 2019-04-30 at 20:43 -0400, Jeffrey Walton wrote: It looks like GCC has one squawk: vgdb.c: In function ‘standalone_send_commands’: vgdb.c:1008:21: warning: ‘%02x’ directive writing between 2 and 8 bytes into a r egion of size 3 [-Wformat-overflow=] sprintf(hex, "%02x", cksum); ^~~~ vgdb.c:1008:20: note: directive argument in the range [0, 2147483647] sprintf(hex, "%02x", cksum); ^~ But cksum is an unsigned char, so value is be between [0, 255]. Which is max 2 hex chars. It is, but it is technically promoted to int by being passed to a varargs function I think... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion 'sizeof(TTEntryC) <= 88' failed.
On 18/03/2019 09:25, Jeffrey Walton wrote: I think the projects bug reporter is broken. I searched for the terms and got 0 results. This has happened in the past for me, too. Searching for TTEntryC (for example) worked or me once I included closed bugs in the search - note that by default searches are limited to bugs that are still open. That's standard for bugzilla. Do you think the project will ever fix the bug reporter, or will it continue to waste my time and your time? Well it's not our bug reporter, it's the KDE one that we are just "borrowing" so management of it is outside our control for the most part. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] pls help me explaining some valgrind complaints
On 16/03/2019 11:42, Matthias Apitz wrote: El día sábado, marzo 16, 2019 a las 09:23:06a. m. +0100, Matthias Apitz escribió: What is the value of MAX_FSTAB_ROWS ? #define MAX_FSTAB_ROWS 3000 I set a gdb breakpoint at the entry of FstabInit(). The size of the array is: (gdb) p sizeof(t_sik_fstab) $4 = 950 (gdb) p sizeof(myFSTABrows) $5 = 285 and as well I can not see anything unusual while stepping through the init sequence of the function. That's nearly 3Mbytes that you are creating on the stack which is quite a lot... More importantly it is more than the default value that valgrind uses for --max-stackframe so it is likely to lead to confusion - do you get a warning about a stack switch being assumed before those other messages? Try using --max-stackframe=400 or something to specify a larger maximum stack frame size and see if that helps. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin
Right but how does your program get control? Does it manage to see all the allocations done by the dynamic linker before main is entered? Tom On 08/02/2019 18:58, Ahmad Nouralizadeh wrote: By image, I mean the binary code of the program to be traced and all the shared libraries accessed by that program. As soon as they are loaded, they will be searched for calls to malloc,... and some code will be added before and after each call. The code is used to store stats, such as the allocation size. How is it possible to miss an allocation? Every possible malloc,... call point is covered. On Fri, Feb 8, 2019 at 10:14 PM David Faure <mailto:fa...@kde.org>> wrote: LOL that was the risk, getting a third, completely different, number ;) Well, you mention that your tool only looks at "each loaded image", while heaptrack and valgrind look at ALL allocations. On vendredi 8 février 2019 18:32:01 CET Ahmad Nouralizadeh wrote: > Thanks David, > But heaptrack even reports a larger number: 153 MB! > > On Fri, Feb 8, 2019 at 8:09 PM David Faure mailto:fa...@kde.org>> wrote: > > On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote: > > > Hi, > > > I wrote a really simple Pin tool to calculate the number of dynamically > > > allocated bytes in a program. I instrumented GIMP with this tool and it > > > reported 77 MB of allocations. I did the same experiment with Valgrind > > > which reported 117 MB. > > > My Pin tool is similar to the example in Pin. It searches for malloc(), > > > calloc() and memalign() in each loaded image and adds instructions > > > before > > > them to calculate the total size of the allocations. > > > I am really confused and need help! > > > > If you're on Linux, I recommend using heaptrack for this :-) > > https://github.com/KDAB/heaptrack > > > > This doesn't really answer your question, sorry about that, but you might > > want > > to see which of those tools heaptrack agrees with, it might help finding > > out > > who is wrong... > > > > -- > > David Faure, fa...@kde.org <mailto:fa...@kde.org>, http://www.davidfaure.fr > > Working on KDE Frameworks 5 -- David Faure, fa...@kde.org <mailto:fa...@kde.org>, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] What is the memory ( RAM ) requirement for running valgrind
On 25/01/2019 10:00, Padala Dileep wrote: My system has 4GB memory ( arm-linux ) . But when I try to run the valgrind, the process becomes very slow, and it gets rebooted with a message "valgrind: the 'impossible' happened' How much RAM is expected to be present in the system to run valgrind for 15-20 mins atleast. There's no fixed number because it entirely depends on what you are running valgrind on and which tool you are using. Using the default tool (memcheck) which you appear to be you will typically need a litle over double the memory your program would need without valgrind because memcheck is keeping shadow state to tell it which bits of your programs memory are initialised. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] mremap and external address
On 06/11/2018 17:50, Rafael Antognolli wrote: Oh, so this would be in valgrind's code, right? Yes. I do see VKI_DRM_IOCTL_I915_GEM_MMAP_GTT in the code, but the ioctl in question (that I can't find there) is DRM_IOCTL_I915_GEM_MMAP. So maybe with that it should work? Oh if there's no handling for it at all then it's definitely not going to work ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] mremap and external address
On 06/11/2018 17:38, Rafael Antognolli wrote: On Tue, Nov 6, 2018 at 9:25 AM Tom Hughes <mailto:t...@compton.nu>> wrote: On 06/11/2018 17:02, Rafael Antognolli wrote: > My (limited) understanding is that valgrind's mremap doesn't let me > remap an address that was allocated by the ioctl, since valgrind doesn't > "own" that memory. Is there some way around this, or this is never > supposed to work? I don't see any reason why it shouldn't IF the ioctl wrapper is correctly written to update valgrind's internal state and record the mapping that it creates. By that, do you mean using VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK? If so, that's already happening but no luck so far. No I mean that internally valgrind keeps track of the mappings in the process address space in the aspacemgr component and if a system calls creates a mapping then the post handler for that system call needs to update that. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] mremap and external address
On 06/11/2018 17:02, Rafael Antognolli wrote: My (limited) understanding is that valgrind's mremap doesn't let me remap an address that was allocated by the ioctl, since valgrind doesn't "own" that memory. Is there some way around this, or this is never supposed to work? I don't see any reason why it shouldn't IF the ioctl wrapper is correctly written to update valgrind's internal state and record the mapping that it creates. If the wrapper doesn't do that then you probably have bigger problems than whether you can remap it because it will mean valgrind's state is out of sync with the kernel. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind and c++ atomic_flag
On 25/09/2018 05:44, John Perry wrote: When run in helgrind, the C++ example programs at en.cppreference.com/w/cpp/atomic/atomic_flag and www.cplusplus.com/reference/atomic/atomic_flag/ report a bunch of possible data races. For instance, ==24483== Possible data race during read of size 1 at 0x6051F1 by thread #3 ==24483== Locks held: none ==24483==at 0x400E8F: test_and_set (atomic_base.h:176) ==24483==by 0x400E8F: f(int) (helgrind_spinlock2.cpp:11) ... ==24483== This conflicts with a previous write of size 1 by thread #2 ==24483== Locks held: none ==24483==at 0x400EE6: clear (atomic_base.h:193) ==24483==by 0x400EE6: f(int) (helgrind_spinlock2.cpp:14) Is it correct to conclude that these are false positives? I found a lot of discussion in the mailing list on atomic operations but nothing "recent" seemed to address the C++ standard library. I don't believe helgrind makes any attempt to observe atomic operations so it is entirely unaware of them and of any effect they might have on the thread correctness of a program. It would be hard to do because where the compiler is able to generate direction instructions for the atomic there will be no function call to intercept, and as there won't necessarily be a one-one mapping from atomic operations to CPU instructions it is hard to determine what the original operation was by observing the instruction stream. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind seems to give false "Invalid read" positive with vsnprintf
On 17/09/2018 10:16, Mohamed BELAOUAD wrote: I seem to have encountered a false positive with valgrind-3.13.0 with the program below. https://pastebin.com/XPHsM2sF Valgrind gives "invalid read" errors show the following pastebin: https://pastebin.com/a4vzNMvW. The error is reported during the second call to w_strdup_printf on address of string a (which is created during the first call). If I uncomment the printf calls, the errors disappear. If I move free(a) next to free(b), the errors also disappear. I am not sure if I am missing something in my program or if those are real false positives. You have used ap twice, the second time after va_end. I think you meant to pass ap_copy to the vsnprintf calls (and to the va_end calls). Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] how to change the a register value of guest code in dirty call
On 17/08/18 10:11, shuai xi wrote: Follow the memcheck's code, i insert a dirty call in IRSB. Now i want to get and change a register(like rax) value in this dirty call. In vex , Register often shows as 't19 = GET:I64(16)' or 'PUT(16) = t22'. Can i get the register's real address and change its value by the num 16? i read the code of vex's translate. I seems that there has no global values to store this information. Is there some ways to get this value? Look at the amd64g_dirtyhelper_CPUID_* helpers as an example of something that does this. They are given a guest state pointer as the first argument and that state contains the register values. The IR is built so as to pass that pointer as the argument to the helper. Alternatively I think the helper can just return a value and then you can construct IR that will save the returned value to a register. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] About how to hook malloc to do sth and execute the original malloc
Yes because printf will invoke malloc which will call your wrapper
which will call printf etc etc until the stack is exhausted.
You can't use anything in your wrapper that might use malloc.
Tom
On 12/07/18 13:07, shuai xi wrote:
thank you for your answer.
But when i use  _WRAP_ macros like following code, it gives me an error.
*code:*
long I_WRAP_SONAME_FNNAME_ZU(libcZdsoZd6,malloc) ( long n )
{
  char * r;
  OrigFn fn;
  printf("1\n");
  VALGRIND_GET_ORIG_FN(fn);
  CALL_FN_W_W(r, fn, n);
  //printf("in wrapper1-post: fact(%d) = %x\n", n, r);
  return r;
}
/* --- */
int main ( void )
{
  char * r , *x, *y;
  //printf("computing fact(5)\n");
  //r = fact(5);
  r = malloc(0x20);
  x = malloc(0x20);
  printf("malloc(0x20) = %x \n",r );
  printf("malloc(0x20) = %x \n",x );
 Â
  return 0;
}
*error:*
==14498== Stack overflow in thread #1: can't grow stack to 0xfe04d000
==14498==Â
==14498== Process terminating with default action of signal 11 (SIGSEGV)
==14498==Â Access not within mapped region at address 0xFE04DFFC
==14498== Stack overflow in thread #1: can't grow stack to 0xfe04d000
==14498==Â Â at 0x40B1183: _IO_doallocbuf (genops.c:394)
==14498==Â If you believe this happened as a result of a stack
==14498==Â overflow in your program's main thread (unlikely but
==14498==Â possible), you can try to increase the size of the
==14498==Â main thread stack using the --main-stacksize= flag.
==14498==Â The main thread stack size used in this run was 8388608.
But when i comment out the ' printf("1\n"); ', It seems ok.
On Thu, Jul 12, 2018 at 7:24 PM Tom Hughes <mailto:t...@compton.nu>> wrote:
On 12/07/18 10:26, shuai xi wrote:
> I know that 'Memcheck's implementation of malloc has "nothing to do"
> with glibc's implementation' after readind some code of valgrind,
but i
> want to use the glibc's malloc to avoid changing heap layout.
> Memcheck sets the VG_(needs_malloc_replacement) to hook malloc
and exec
> MC_(malloc) instead of real malloc. It's very convenient. So can i
> get the address of the original malloc in MC_(malloc) and exec it?
> if not,can i use I_WRAP_SONAME_FNNAME_ZU function to hook malloc
in my
> valgrind tool's code?
Yes if you want to wrap the function rather than replacing it
then use the _WRAP_ macros and then your wrapper can get the
original address and call it.
Tom
--
Tom Hughes (t...@compton.nu <mailto:t...@compton.nu>)
http://compton.nu/
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] About how to hook malloc to do sth and execute the original malloc
On 12/07/18 10:26, shuai xi wrote: I know that 'Memcheck's implementation of malloc has "nothing to do" with glibc's implementation' after readind some code of valgrind, but i want to use the glibc's malloc to avoid changing heap layout. Memcheck sets the VG_(needs_malloc_replacement) to hook malloc and exec MC_(malloc) instead of real malloc. It's very convenient. So can i get the address of the original malloc in MC_(malloc) and exec it? if not,can i use I_WRAP_SONAME_FNNAME_ZU function to hook malloc in my valgrind tool's code? Yes if you want to wrap the function rather than replacing it then use the _WRAP_ macros and then your wrapper can get the original address and call it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?
The sourceware git repo is the canonical one: https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=summary Tom On 18/06/18 14:56, Alan Corey wrote: Um, dumb question probably but you checked it in where? Looks like there are at least 4 forks of Valgrind on Github, on sourceware.org I just see releases, nothing since 3.13. On 6/18/18, Mark Wielaard wrote: On Sat, 2018-06-16 at 21:30 -0400, Alan Corey wrote: OK, thanks, I ran Valgrind 3.13.0 on a 32-bit Raspberry Pi and it worked fine.  Found bugs anyway.  KDE and Fedora are way off my beaten path.  Oh, I see even Raspbian Stretch finally got 3.13, they had one that didn't do arm at all. For now I checked in the workaround so that valgrind from git trunk should work on your arm64 environment. I kept the bug open since it needs someone with a bit more arm64 knowledge to properly fix it. https://bugs.kde.org/show_bug.cgi?id=381556 Cheers, Mark -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgrind "error: -mpreferred-stack-boundary=2 is not between 3 and 12"
On 20/05/18 21:15, John Reiser wrote: This is peculiar: "I am working on ... x86_64" but invoking "gcc -m32" which requests "generate code for i686". Also, if the value is not at least 4 then some generated SSE instructions (even on i686) will fault because they demand 16-byte alignment, and any call involving a variable number of arguments which includes any argument that requires 16-byte alignment will generate incorrect code. The best strategy is to omit "-mpreferred-stack-boudnary" entirely. It's not peculiar really - by default when building on x86_64 valgrind will try and build both the x86 and x86_64 backends. Use --enable-only64bit to configure if you want to stop it trying to build the 32 bit backend. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unhandled instruction bytes (C++, x86 on amd64)
On 16/03/18 17:16, John Reiser wrote: On 03/16/2018 1439 UTC, Zack Weinberg wrote: On Fri, Mar 16, 2018 at 1323 UTC, John Reiser wrote: The code 0x67 0xE8 0x7D 0xFF is "addr32 callq ...". Valgrind is complaining about the 'addr32' opcode prefix. The compiler for locale_init.cc did a not-so-good job. The addr32 prefix is a total waste; remove it. This _could_ be an alignment hack. I don't see any of these prefixes in my copy of libstdc++ but the compiler could plausibly be trying to make the instruction right after the call be on a tidy address boundary. The 0x67 was at 0x48cc63d which is (-3 mod 16), so the following instruction is at (+3 mod 16) [1 for the 0x67, 1 for the 0xE8, 4 for the 32-bit displacement]. Alignment was not close to any auspicious boundary. We figured out the cause on IRC and it's all down to this: https://sourceware.org/ml/binutils/2016-05/msg00322.html Basically code compiled with -fno-plt causes the linker to do it when it needs to patch an indirect call without changing the length of the instruction. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgind with LD_PRELOAD
-- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net <mailto:Valgrind-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net <mailto:Valgrind-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unsupported Clone Flags: 0x800600
If I'm reading that right it is coming from the breakpad exception handler which I can well believe is using clone with some odd flag set to do some crazy stuff. Of course if you've got there then the process is already dead anyway so I'm not sure how much it matters? Tom On 07/02/18 21:25, Adam Scott wrote: Even with the patches from that bug the error still occurred. On Wed, Feb 7, 2018 at 3:16 PM, Adam Scott <adamjs@gmail.com <mailto:adamjs@gmail.com>> wrote: I am using the latest version 3.13. I will pull down that patch and try it out. On Wed, Feb 7, 2018 at 3:03 PM, Philippe Waroquiers <philippe.waroqui...@skynet.be <mailto:philippe.waroqui...@skynet.be>> wrote: Which version are you using ? Some improvements to clone handling was done in 3.13 : * On Linux, clone handling has been improved to honour CLONE_VFORK that involves a child stack. Note however that CLONE_VFORK | CLONE_VM is handled like CLONE_VFORK (by removing CLONE_VM), so applications that depend on CLONE_VM exact semantics will (still) not work. Otherwise, I am sure we have still a bunch of clone related bugs opened. E.g. https://bugs.kde.org/show_bug.cgi?id=183406 <https://bugs.kde.org/show_bug.cgi?id=183406> and https://bugs.kde.org/show_bug.cgi?id=386427 <https://bugs.kde.org/show_bug.cgi?id=386427> which has a patch, and might be what you have encountered. Philippe On Wed, 2018-02-07 at 14:51 -0600, Adam Scott wrote: > I'm hoping someone else has seen this issue and is able to help me. I have search all over the internet for a solution and haven't been able to find one. I am trying to run Valgrind on armv7 architecture, and after compiling Valgrind and getting it onto the target I am able to run Valgrind successfully on 'ls -l' but when I run Valgrind on my executable it starts and then always fails after printing out this error: > > ==2333== Unsupported clone() flags: 0x800600 > ==2333== > ==2333== The only supported clone() uses are: > ==2333== - via a threads library (LinuxThreads or NPTL) > ==2333== - via the implementation of fork or vfork > ==2333== > ==2333== Valgrind detected that your program requires > ==2333== the following unimplemented functionality: > ==2333== Valgrind does not support general clone(). > ==2333== This may be because the functionality is hard to implement, > ==2333== or because no reasonable program would behave this way, > ==2333== or because nobody has yet needed it. In any case, let us know at > ==2333== www.valgrind.org <http://www.valgrind.org> and/or try to work around the problem, if you can. > ==2333== > ==2333== Valgrind has to exit now. Sorry. Bye! > ==2333== > > sched status: > running_tid=9 > > The thread that has the crash has the following stack: > Thread 9: status = VgTs_Runnable (lwpid 2354) > ==2333== at 0x6C5BCC: sys_clone (linux_syscall_support.h:2666) > ==2333== by 0x6C5BCC: google_breakpad::ExceptionHandler::GenerateDump(google_breakpad::ExceptionHandler::CrashContext*) (exception_handler.cc:527) > ==2333== by 0x6C60C3: google_breakpad::ExceptionHandler::SignalHandler(int, siginfo_t*, void*) (exception_handler.cc:368) > ==2333== by 0x4CE5ACF: ??? (in /lib/libc-2.22.so <http://libc-2.22.so>) > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net <mailto:Valgrind-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/valgrind-users <https://lists.sourceforge.net/lists/listinfo/valgrind-users> -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Tom Hughes (t...@compton.nu) http://compton.nu/ -
Re: [Valgrind-users] Support bpf syscall in amd64 Linux
On 10/01/18 14:43, Zexuan Luo wrote: I just wrote a patch to support bpf syscall in amd64 Linux, following this guide: http://valgrind.org/docs/manual/dist.readme-missing.html It is my first time to hack valgrind, please let me know if I made any mistake. I am glad to see this patch could be reviewed and accepted. Please open a bug and attach the patch. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] problems with Ubuntu 17.10
On 02/01/18 16:20, Mark Roberts wrote: But the larger, more pervasive problem is with this release of Ubuntu the gcc (7.2.0) compiler has changed to emitting position independent code by default. I have tried to add -no-pie to compiler options but have not been successful. Why is that a problem? Fedora 27 uses gcc 7.2 as well and I have no trouble building valgrind there. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] SSE2 and "__memcmp_sse4_1 (vg_replace_strmem.c:1099)"
On 28/11/17 12:05, Jeffrey Walton wrote: I suspect it is a valid finding but it kind of strikes me as odd that x86_64 without any -march or -m options is using SSE4. In fact, we build without -march and -m options because that's how distros want it. That's fine - glibc has multiple versions of memcmp and other similar routines and selects the best one dynamically at run time based on the capabilities of the CPU that it is running one. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Error during configure sparc sun4v
On 11/10/17 16:04, Tom Hughes wrote: On 11/10/17 15:58, Daniel Nuño wrote: I'm trying to compile valgrind-3.13.0 or valgrind-3.2.1 on the following architecture: $ uname -a SunOS slc11gbh 5.11 11.3 sun4v sparc sun4v And I'm having the following error: checking build system type... sparc-sun-solaris2.11 checking host system type... sparc-sun-solaris2.11 checking for a supported CPU... no (sparc) configure: error: Unsupported host architecture. Sorry Any help that you could provide? Well I'm not sure you'll consider it help as such... Sparc is not, and never has been, a supported platform. The list of supported platforms can be found here: http://valgrind.org/info/platforms.html Note at the bottom that there are details of an out of tree attempt at a port, but there is no support in the main valgrind release. Oh and that is sparc/linux anyway, not sparc/solaris. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Error during configure sparc sun4v
On 11/10/17 15:58, Daniel Nuño wrote: I'm trying to compile valgrind-3.13.0 or valgrind-3.2.1 on the following architecture: $ uname -a SunOS slc11gbh 5.11 11.3 sun4v sparc sun4v And I'm having the following error: checking build system type... sparc-sun-solaris2.11 checking host system type... sparc-sun-solaris2.11 checking for a supported CPU... no (sparc) configure: error: Unsupported host architecture. Sorry Any help that you could provide? Well I'm not sure you'll consider it help as such... Sparc is not, and never has been, a supported platform. The list of supported platforms can be found here: http://valgrind.org/info/platforms.html Note at the bottom that there are details of an out of tree attempt at a port, but there is no support in the main valgrind release. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Spam (9.229): Problem with suppressions
Suppression can't really help with this - even if you can stop one or two complaints the undefined bits tend to propagate through the encryption state and hence to everything encrypted or decrypted using the state that is (partially) derived from the undefined data. Tom On 30/08/17 16:51, Dominik Straßer wrote: Hi Julian, similar to my answer to John: why isn't suppression working here ? Regards Dominik Am 30.08.2017 um 17:32 schrieb Julian Seward: As these seem OK to me (cryprography intentionally works with uninitialized values) I would like to suppress them. Another thing you could consider doing, if you really have to use undefined values, is to figure out where they come from (heap or stack allocation, use --track-origins) and then add a VALGRIND_MAKE_DEFINED (or whatever it is called) client request. This lies to Memcheck, claiming the inputs are defined when they are not really. But at least it will not complain about undefinedness from them alone, after that. See . J -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Fwd: valgrind/memcheck support for skipping a function
On 24/05/17 16:55, Rukhsana Ansari wrote: > Is there a mechanism in valgrind to entirely skip memcheck on a > particular function? No, because it doesn't make any sense. In order for memcheck to work it needs to track the status of every individual bit of memory - as soon as code was allowed to run outside of memcheck changes could be made to memory that memcheck wouldn't know about and from then on all it's reports would be worthless. You would get false alerts about uninitialised memory where that memory had in fact been initialised while memcheck was disabled and wouldn't get alerts about memory that, for example, was freed during that period. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Migrating Valgrind sources from SVN to GIT
On 28/02/17 20:56, Ivo Raisr wrote: > So we decided to stick with existing (SVN) workflow which translates to > "rebased branches at the top of the tree". > Our valgrind.git config will have (after the final migration happens): > > [receive] > denyNonFastforwards = true That doesn't actually prevent people pushing merges though, it just stops history being rewritten - the push to the remote can only move the remote forward but the pushed commits can include merges. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Problem of running mozilla thunderbird under valgrind on Debian GNU/Linux 4.x kernel.
On 15/02/17 13:34, ISHIKAWA,chiaki wrote: > When I tried to run mozilla thunderbird mail client, which I create > under Debian GNU/Linux 64-bit, > under valgrind, valgrind mysteriously crashed and gdb was not much help. Well valgrind almost never "mysteriously crashes". In fact it is usually very verbose when anything goes wrong. So the first thing you should do is to tell us in detail exactly what it said when it stopped. > This happened under the latest 4.8.x kernel which Debian distributed as > part of its testing repository. > > I tried a few things but subsequently reverted to kernel 3.19.5. > Now thunderbird under valgrind works (!). So most likely this is just a new system call that valgrind doesn't handle or something, in which case valgrind will have reported all the details needed to fix it when it stopped. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgrinding a SSL application
On 05/01/17 15:46, Ivo Raisr wrote: > 2017-01-05 12:54 GMT+01:00 Matthias Apitz <g...@unixarea.de > <mailto:g...@unixarea.de>>: > > I'm 'valgrinding' a huge client/server application, where the server > runs on Linux (SLES 12) and uses SSL (OpenSSL) to communicate with the > clients. > > Valgrind is complaining a lot on any SSL function call (some 20.000 > lines) before the first data is exchanged, i.e. on creating the SSL > socket and accepting the connection. > > I know how to suppress such complaints which I can not solve because the > full function stack is inside the libssl.so or libcrypto.so > > But, when I read bytes in clear text from the SSL connection the > resulting returned 'buf' is invalid too and this goes up the way as > invalid into my application layers. See the example below and the > resulting valgrind complaints. It does not even help to strncpy(3) the > buffer and work with the result. The data in it remains > invalid/uninitialized. > > What is the correct way to deal with this? > > One of the straightforward ways (workarounds) will be to use a Valgrind > client request to explicitly set the data buffer as defined. > See memcheck.h, VALGRIND_MAKE_MEM_DEFINED. Doing that at the top level is going to be messy though and you probably wont get rid of everything. The underlying problem is likely to be that OpenSSL deliberately mixes uninitialised memory into the entropy pool for it's random number generator which then pollutes everything derived from that. It's a fairly well known issue, as anybody that remembers the infamous Debian incident where the valgrind warnings were "fixed" by stopping it mixing in that uninitialised memory (and in the process destroying the randomness) will know... The ideal solution would be to alter OpenSSL to call VALGRIND_MAKE_MEM_DEFINED on that unitialised memory when it adds it to the entropy pool so that valgrind thinks it is defined. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
On 29/11/16 09:42, Alex Bligh wrote: >> On 29 Nov 2016, at 01:29, Danny Wilson <da...@torquevideo.tv> wrote: >> >> Hi Alex, rebuilding the standard libraries is a little beyond our scope (and >> I'd figure it unlikely that such a basic function of the c++ library had a >> memory leak. Something like that would be well published). As Tom pointed >> out, it could also be from a std template compiled in from my program. >> >> Good question now is how to disable generation of the unsupported >> instructions... > > I'm not saying the leak is in the standard library, just that the > instructions that are traced are in the standard library. I'm also not saying > you necessarily need to recompile (just that recompiling the application > won't fix it if the instructions that are problematic are in the standard > library) - rather I'm suggesting you attempt to obtain a precompiled version > of the standard library for a lesser processor. Except that much of the C++ standard library is templates that compiles as part of his application and not a library in the traditional sense. > Depending on your distribution, recompilation should actually be pretty > trivial. On Debian compatible distros its as simple as getting the source > (one command) and using 'debuild'. On RPM distros, from memory you get the > srpm and go from there. No distribution that does precompiled packages is going to have built with AVX enabled so trying to recompile distro provided libraries is almost certainly a red herring. Danny - what distro are you using, and what architecture flags are you specifying when building your own program? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
On 27/11/16 10:28, Danny Wilson wrote: > The build machine is a core2 duo running 32-bit Centos 6.6 and custom > kernel 3.10. > > I recompiled the app using --march=native and --march=pentiumpro, but > got the same error. Don't use -march=native - that is telling the compiler to use everything machine has to offer! > I'll try the SIGKILL handler now. That is not going to work. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
On 27/11/16 03:46, Danny Wilson wrote: > It is a huge application, 1.5M lines not including big external dependencies > like ACE/TAO. Porting over to 64bit mode would probably take months. Any > other suggestion? Perhaps disabling the generation of the offending AVX > instructions with some compiler flag? > > (Not sure that will work since it reports the failure inside the std:: > library...) Yes compiling with a different CPU target is the other option, but as you say you may need to do the libraries as well. If you're using standard distro then it's likely the system libraries are OK already though as a distro will compile for a fairly basic processor to get maximum compatibility. It's only if you're using gentoo or something that build from source that you might have an issue. Don't forget that a lot of libstdc++ is templates that will actually compile as part of your program... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
On 26/11/16 15:36, Jeffrey Walton wrote: > On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson <da...@torquevideo.tv> wrote: >> I am trying to find a memory leak in a large C++ program which utilizes >> multiple shared libraries. >> >> Unfortunately, valgrind fails with "unhandled instruction bytes: 0xC5 0xF9 >> 0x6E 0x45" >> >> It says the illegal instruction is inside std::tr1::__detail, inside a >> standard library... >> >> Is there anything I can do about this? I've posted the valgrind output and >> platform information below. > > Looks very similar to https://bugs.kde.org/show_bug.cgi?id=301967 . Yes that looks like an AVX instruction and those are not supported by valgrind in 32 bit code - try 64 bit instead. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Memory mapping and READ_IMPLIES_EXEC
On 20/06/16 09:56, Schmidt, Adriaan wrote: > I figured out that in native execution, my application only works because it > states in its ELF header that it needs executable stacks, and Linux' way of > providing this is with the READ_IMPLIES_EXEC property in the process > personality, i.e., by simply making all readable memory also executable. > Valgrind is more strict, and does not implement READ_IMPLIES_EXEC. > > Is this a bug, so should Valgrind show the same behavior as in native > execution? Yes it's a bug. In your program ;-) Even without valgrind not all platforms will do what you say to start with - the only thing that PT_GNU_STACK in the ELF guarantees is that the stack will have those permissions and valgrind does do that. The read-implies-exec behaviour you describe is, in general, only true for those CPUs (like older 32 bit x86 and ARM) that don't actually support a separate execute permission. In the case of ARM that appears to mean things before ARMv6 as far as I can see. So your problem is quite likely to fail anyway when run on newer hardware so be glad valgrind has found your problem now ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Fwd: ASan error using memcheck tool
On 25/04/16 17:11, Николай Жосов wrote: > I have a problem trying to check my programme with memcheck. > Some details about programme: > It consist of 2 DLLs and executable, implicitly linked using -rpath to > add location of DLLs to executable. Also one of DLLs was linked with the > first the same way. > So I start the check with such line: > > valgrind --tool=memcheck ./L1 Graph.txt > > and caught the error message and valgrind report: > > ==14553== Memcheck, a memory error detector > ==14553== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==14553== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info > ==14553== Command: ./L1 Graph.txt > ==14553== > ==14553==Shadow memory range interleaves with an existing memory > mapping. ASan cannot proceed correctly. ABORTING. It looks like you have compiled your program with -fsanitize=address but that conflicts with valgrind as both are essentially trying to do more or less the same thing. Build your program normally and you should find it works... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Not able to get the Leak summery details in ARM architecture
On 12/04/16 11:52, venkat konamki wrote: > I have compiled the above program using below commands > > arm-linux-gnueabi-gcc -o test-arm -g test.c > arm-linux-gnueabi-gcc -o test-arm-static -g test.c > > when i am running in my ARM architecture with valgrind So that looks like you are cross compiling? But you are actually running valgrind on the target machine, not on the host where you do the compil? > 1) valgrind --tool=memcheck --leak-check=yes --show-reachable=yes ./test-arm > > valgrind: m_ume.c: can't open interpreter Well that means whatever ELF interpreter your program is declaring can't be opened by valgrind. Run "file ./test-arm" and see what interpreter it says it is using. > 2) /writable/valgrind/bin/valgrind --tool=memcheck --leak-check=yes > --show-reachable=yes ./test-arm-static > > ==8118== Memcheck, a memory error detector ==8118== Copyright (C) > 2002-2013, and GNU GPL'd, by Julian Seward et al. ==8118== Using > Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==8118== > Command: ./test-arm-static ==8118== Enter number of elements: 1 Enter > elements of array: 1 Sum=1==8118== ==8118== HEAP SUMMARY: ==8118== in > use at exit: 0 bytes in 0 blocks ==8118== total heap usage: 0 allocs, 0 > frees, 0 bytes allocated ==8118== ==8118== All heap blocks were freed -- > no leaks are possible ==8118== ==8118== For counts of detected and > suppressed errors, rerun with: -v ==8118== ERROR SUMMARY: 0 errors from > 0 contexts (suppressed: 0 from 0) > > In both the cases i didn't get LEAK SUMMERY , but in my linux machine i > am able to get the valgrind report. can you suggest me the how to > resolve this on ? You won't be able to get a leak report for a statically linked program because valgrind won't be able to intercept calls to malloc and free. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] 0 bytes inside a block of size 30,121
On 26/03/16 19:15, Burlen Loring wrote: > I like to understand better the following reports. I have a buffer that > I allocated and that gets filled by MPI recv. However, for every access > to the buffer valgrind produce a report similar to the following first > report shown here: > > Invalid read of size 4 > Address 0x1788a6d0 is 0 bytes inside a block of size 30,121 alloc'd > > in subsequent reports "0 bytes inside" the 0 is replaced with the offset > of the access in the buffer. Full output of the first few reports are > shown below. That does look odd. The only obvious way I can think of to get a report like that is if you had explicitly told valgrind to consider that memory as inaccessible with the VALGRIND_MAKE_MEM_NOACCESS call. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind is broken on recent linux kernel
On 11/01/16 08:29, Mike Krinkin wrote: > recently i have faced the problem that valgrind fails to start on my > linux amd64 laptop with the following error (specific mmap address may > change depending on checked app, this one for simple "Hello, World"): > > valgrind: mmap(0x60, 8192) failed in UME with error 12 (Cannot > allocate memory). Please open a ticket in bugzilla so we can track this. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unrecognized Instruction in Ubuntu ARM library
On 09/01/16 22:34, Jim Starkey wrote: > Running Ubuntu/Mate on a Raspberry Pi 2, I get the following error: > > disInstr(arm): unhandled instruction: 0xF1010200 > cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0) See https://bugs.kde.org/show_bug.cgi?id=322935 but the short version is that the code has an insane "optimisation" that temporarily changes the endianism of the processor and there's no way it's ever likely to be supported in valgrind. I believe, from a brief examination when somebody hit this the other day, that libarmmem is just optimised version of some routines like memcpy that are already in the normal C library, so you can just drop it and use the normal C library versions when valgrinding. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] POW() function behaving different when running in valgrind?
On 07/12/15 11:40, Wilfried Goesgens wrote: > Does valgrind replace mathematical functions? No, but see the section on x86/AMD64 floating point support in the manual: http://valgrind.org/docs/manual/manual-core.html#manual-core.limits Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind Bad option: --vgdb-error=0
On 21/10/15 15:36, Ulrich-Lorenz Schlüter wrote: > With: > valgrind --vgdb=yes --vgdb-error=0 --track-origins=yes --leak-check=full > ./program > I get the following error: > valgrind: Bad option: --vgdb=yes > > What am I doing wrong? If I had to guess I'd say you're using a really old version of valgrind. What does "valgrind --version" say? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Strange (at least to me) valgrind messages
On 21/09/15 23:04, Tyson Whitehead wrote: > ==32704== Unaddressable byte(s) found during client check request > ... > ==32704== Address 0x243e6040 is 16,384 bytes inside a block of size > 1,048,576 alloc'd > ... > > and > > ==32704== Invalid read of size 8 > ... > ==32704== Address 0x22fe2040 is 0 bytes inside a block of size 1,048,576 > alloc'd > ... > > and > > ==32704== Invalid write of size 8 > ... > ==32704== Address 0x22fe2048 is 8 bytes inside a block of size 1,048,576 > alloc'd > ... > > and on and on and on ... > > Are these valid errors? Everything I found online seemed to indicate that > error addresses should not fall entirely inside allocated blocks. Why should they not be valid? It probably just means somebody has used a client request to mark that address as invalid. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD
On 08/09/15 07:43, Yue Chen wrote: > I mean the result from > > "valgrind --trace-syscalls=yes ./myprogram" VS "truss ./myprogram" > are different; > > NOT > "truss valgrind --trace-syscalls=yes ./program" VS "truss ./program". > > Can I modify some Valgrind source code to mark the syscalls issued from > Valgrind itself? You're confused. The --trace-syscalls flag only shows system calls issued by your program. The only thing that would show those issued by valgrind itself is trussing valgrind, ie the first option in your second version. Many things might be influencing which system calls the C library uses to implement a given library call however, and it may be that the environment valgrind provides is different in some way that causes the library to make a different choice. I really wouldn't worry too much if you see odd differences here, but if you really want us to comment on possible reasons you will likely need to provide concrete examples. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:
On 28/08/15 15:06, John OSullivan wrote: I have a problem running valgrind on my embedded system, you can see the detail below but essentially the problem is that Valgrind fails with: FATAL: aspacem assertion failed The problem is caused by valgrind detecting a inode number of zero for libc b6dae000-b6eea000 r-xp 00:00 8937 /lib/libc-2.13.so ^ dev ino are always zero My system boots from nand and copies the file system to ram, so the file system runs from ram, as far as I can determine when running from ram the device and inode number are going to always be zero. I tried a similar exercise with the Raspberry PI, if the PIs file system reside in Ram (Volatile) then the device and inodes will always be zero, if I put the PIs file system on the SD Card (non volatile) then I get non-zero device and inodes for the relevant sections. My question is how am I going to use valgrind on a ram based file system when device numbers are going to be zero for libc, is there a configuration or setting that I am missing. Surely the filesystem is still on a device, even if that device is a ramfs device? and that device should have major and minor numbers? Unfortunately unix semantics mean that you always have to have unique device numbers otherwise there is no way to tell if two identical inodes refer to the same file or not. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Can I integrate my program's reimplemented execve with Valgrind?
On 14/08/15 15:48, John Reiser wrote: Can I integrate my program's reimplemented execve with Valgrind? Call it 'execve', put it in a shared library, then change the filename of the shared library where valgrind expects to find execve from glibc to the name of your .so. Except that valgrind traps the system call, not the library function ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind can't catch memory breaking by overwriting global valuable and local valuable ???
On 25/05/15 12:26, Jack wrote: so i wrote an test program on pc to test valgrind ability of program internal memory breaking but somehow it seems can't fetch program internal over-writing and under-writing global or local valuable?? http://valgrind.org/docs/manual/faq.html#faq.overruns Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?
On 19/05/15 17:26, Carl Ponder wrote: So it shuts off the warning message *==21898== Warning: noted but unhandled ioctl 0x3001 with no size/direction hints.* ==21898== This could cause spurious value errors to appear. ==21898== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. but doesn't do anything to manage the memory state. The output I'm getting from--trace-syscalls=yes is SYSCALL[20867,1](16) *sys_ioctl ( 38, 0x3001, 0x0 *) -- [async] ... SYSCALL[20867,1](16) ... [async] -- Success(0x0:0x0) so it doesn't look like any memory-range is being passed in. I'm checking with our engineers to see if there is any special processing that needs to happen here, and we'll also have to watch and see if any other NVIDIA-specific calls are happening. Yes you will need to find out if it reads/writes any memory, though it looks unlikely in this case. One question to you: does it make sense to be hard-coding the *0x3001* case into the generalioctl handler, or should there be an NVIDIA-specific file in the coregrind/m_syswrap directory? Thanks, Well I'm not sure there's much precedent as we don't normally take system calls that aren't in the upstream kernel. There may be a few ARM ones as precedent. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?
On 18/05/15 15:12, Carl Ponder wrote:
*On 01/28/2015 09:27 PM, Carl Ponder wrote:*
I ran into this output from valgrind
*==21898== Warning: noted but unhandled ioctl 0x3001 with no
size/direction hints.*
==21898== This could cause spurious value errors to appear.
==21898== See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
*On 03/17/2015 03:44 AM, Julian Seward wrote: *
A more fundamental question is, are you running a kernel with
NVidia-specific hacks? What is this ioctl 0x3001 ? What does it do?
Is it in the mainline linux kernel sources?
I had to postpone this thread while I was working on other things, but
am back looking atvalgrind output again.
We're running standard Centos 6.6 but loading-in custom kernel extensions.
The ioctl call is to UvmInitialize, which maps the GPU memory into the
process address-space.
But this ioctl is implemented by that extra kernel module I assume?
The right place to add it is PRE(sys_ioctl) and POST(sys_ioctl).
I tried inserting print-statements into this function in the
filecoregrind/m_syswrap/syswrap-linux.c
5406 PRE(sys_ioctl)
5407 {
5408*flags |= SfMayBlock;
5409
5410ARG2 = (UInt)ARG2;
5411
*5412 PRINT(ioctl ARG1=0x%lx\n, (unsigned long) ARG1 );**
**5413 PRINT(ioctl ARG2=0x%lx\n, (unsigned long) ARG2 );**
**5414 PRINT(ioctl ARG3=0x%lx\n, (unsigned long) ARG3 );*
but didn't see any output, it looks like this function doesn't get
called on ioctl0x3001.
You know PRINT only prints when --trace-syscalls=yes is used?
The Warning at the top looks like it came from the
So I still don't understand how to get it to handle 0x3001, given
that it never gets to thePRE(sys_ioctl).
It must be getting intercepted somewhere higher in the call-chain and
passed down toPRE_unknown_ioctlinstead.
Well you have clearly done something wrong, as unknown_ioctl is invoked
from the default clause in sys_ioctl, so it must be getting called.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgrind out of memory error
On 13/04/15 21:57, Zhu, Yanwen wrote: Can you please confirm if mabi=n32 is currently supported by valgrind or not in MIPS64 platform? My Linux kernel is 64-bits, but our applications have to be built for 32-bits. So I need to get valgrind with mabi=n32 to work in our platform. No, the n32 ABI is not supported currently. There are patches in the bug tracker for it (https://bugs.kde.org/show_bug.cgi?id=345763) but they have not been applied yet. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?
On 17/03/15 08:44, Julian Seward wrote:
I added this entry to the filecoregrind/m_syswrap/syswrap-linux.c :
10166 PRE(0x3001)
10167 {
10168 PRINT(NVIDIA UvmInitialize ioctl);
10169 }
The right place to add it is PRE(sys_ioctl) and POST(sys_ioctl).
A more fundamental question is, are you running a kernel with NVidia-
specific hacks? What is this ioctl 0x3001 ? What does it do? Is
it in the mainline linux kernel sources?
There were a couple of previous threads back in January but I don't we
ever really got to the bottom of that question...
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind: Recursive Locing of normal mutex
On 25/02/15 06:05, SHEHAB ZAINELDINE wrote: That would mean, that locking the same lock twice in a row should trigger helgrind to stop the program and give me the error, but what happens is that the deadlock is allowed to happen. I there something that I am missing, or is that a bug? Why do you think that is what should happen? That is not how valgrind handles errors - it reports problems and then allows execution to continue. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind: Recursive Locing of normal mutex
On 19/02/15 15:44, SHEHAB ZAINELDINE wrote: When you say recursively locking a non-recursive mutex what is it exactly that you mean. Is it even possible to recursively lock a non-recursive mutex? When I try it the computer enters into a deadlock, and the thread is unable to aquire the lock the second time. Well that's kind of the point, and why helgrind is telling you about it, because it's not allowed! What it means is that your program is trying to lock a mutex that is already locked and which was not declared as a recursive mutex. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] version number?
On 17/02/15 19:38, Mark Roberts wrote: In the repository - revision change r14522 which is prior to the 10.1 release tag r14786. Well 3.10.1 was made from a different branch, so it isn't prior on that branch. The trunk is (or will be) 3.11 which is why it is set to that. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] version number?
On 17/02/15 20:13, Mark Roberts wrote: Ok - I see it's been modified in the tar ball to 10.1. No, it hasn't been modified in the tar ball. The tar ball was created from the 3.10 branch: svn://svn.valgrind.org/valgrind/branches/VALGRIND_3_10_BRANCH not from the trunk: svn://svn.valgrind.org/valgrind/trunk The branch was taken when 3.10.0 was released, and AC_INIT has never been changed on that branch. Question: We (UW PLSE) have been making releases of our tools Fjalar and Kvasir (based on Valgrind) for quite some time. We've always just sync'd our copy of the Valgrind repository to the appropriate revision and merged into our source tree. Can you think of any problems (other than AC_INIT) with doing it this way instead of using the tar ball? If you want to use svn, but get a version that corresponds to a given upstream release, then use the appropriate tag, for example: svn://svn.valgrind.org/valgrind/tags/VALGRIND_3_10_1 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] version number?
On 17/02/15 18:57, Mark Roberts wrote: The web site says 3.10.1 but the AC_INIT value in configure.ac is 3.11.0 - why is that? In the tar ball? or the repository? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Empty stack shown by Valgrind
On 02/01/15 13:36, Philippe Waroquiers wrote: On Fri, 2015-01-02 at 17:14 +0530, Austin Einter wrote: ==28501== 7 bytes in 1 blocks are indirectly lost in loss record 33 of 152 ==28501==at 0x402CFC7: malloc (vg_replace_malloc.c:296) ==28501==by 0x40AF985: ??? ==28501==by 0x40AE2A1: ??? ==28501==by 0x40ADB1B: ??? ==28501==by 0x40ADAAC: ??? ==28501==by 0x40C3B24: ??? ==28501==by 0x40BDAE2: ??? ==28501==by 0x40BDFA7: ??? ==28501==by 0x40BE6F2: ??? ==28501==by 0x40BF290: ??? ==28501==by 0x40BF483: ??? ==28501==by 0x40E63C0: ??? ==28501== My query is, why stack trace is empty. In such situations how do I catch where from problem origins. Usually, when Valgrind cannot show function name, file name and linenr, it is because there is no debug information for this part of the code. So, probably you did not compile with debug info (-g option). Given that this is a leak report the other likely cause is that the addresses are in a shared object that has been unloaded, though it's surprising that none at all are translatable. Otherwise I would at least expect to see the object name. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] suppress warning repetition
On 02/01/15 19:15, João M. S. Silva wrote: Spoke too early. Sorry for the noise. -fsanitize=address does not seem to work on armv7l, it seems to crash on runtime (I thought it worked on compile-time only): ==1280== ERROR: AddressSanitizer: stack-buffer-overflow on address 0xbe99efb0 at pc 0x29483 bp 0xbe99ef38 sp 0xbe99ef3c WRITE of size 4 at 0xbe99efb0 thread T0 #0 0x29481 (/home/ubuntu/fidelio/software/test+0x29481) #1 0x3376d (/home/ubuntu/fidelio/software/test+0x3376d) (...) #251 0x3376d (/home/ubuntu/fidelio/software/test+0x3376d) #252 0x3376d (/home/ubuntu/fidelio/software/test+0x3376d) ==1280== AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asan_report.cc:250 ((name_end)) != (0) (0x0, 0x0) #0 0xb594dc61 (/usr/lib/arm-linux-gnueabihf/libasan.so.0.0.0+0xdc61) #1 0xb5953353 (/usr/lib/arm-linux-gnueabihf/libasan.so.0.0.0+0x13353) (...) #254 0x3376d (/home/ubuntu/fidelio/software/test+0x3376d) Or is this the expected behavior? That's not a crash it's address sanitizer telling you it has found a problem in your program. Unlike valgrind it stops as soon as it finds a problem - in this case you have overflowed a buffer on the stack. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] suppress warning repetition
On 01/01/15 17:52, João M. S. Silva wrote: I've searched in the documentation, Internet and mailing list archive, but could not find a way to address the following issue: How can I suppress the repetition of warnings, e.g.: ==1830== Warning: invalid file descriptor 29541 in syscall read() which in my case appears thousands of times in the screen or log file and makes severely hinders performance? The warning is shown for each read() invocation, which occurs very frequently, but flooding the screen or log file with the same line is not only inefficient but also makes the log file very difficult to analyze. Is there a way to workaround this or should this consist in an improvement? Surely the easy fix is to fix your program to stop it trying to read from an invalid file descriptor? Surely that is a bug that you will want to fix anyway? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] suppress warning repetition
On 01/01/15 23:16, João M. S. Silva wrote: The problem is in: char command[128]; sprintf(command, first part of command %s second part of command, filename.c_str()); The string is larger than 128 bytes. But valgrind does not detect this? Am I missing something? No. Stack overruns are not detected because there is no guard space between stack variables like there is between heap variables. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] source file location
On 08/12/14 19:09, João M. S. Silva wrote: Can I provide valgrind with source files so that source code lines of libraries compiled without -g are still shown? For example, I get this memory leak warning: [ snipped ] but I can't tell exactly where it comes from. If I was able to tell valgrind that the source code for tesseract is somewhere, it would avoid having to recompile all my code against tesseract sources? How would that work? Valgrind would still need the debug information in order to know which addresses in your compiled code map to each line in the source files... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] source file location
On 08/12/14 20:12, João M. S. Silva wrote: I'm using Ubuntu and I can't seem to find an exact equivalent of Fedora's debuginfo, except -dbg packages. However, tesseract does not have a -dbg package. My code uses tesseract library, i.e. libtesseract-dev. Since a libtesseract-dbg package is not available, I probably have to compile it myself. As far as I know the Ubuntu dbg packages are built automatically just as the Fedora debuginfo ones are, so I would have expected one to exist... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Spam (7.009):Re: valgrind-3.10 does not link on
On 29/10/14 10:29, Julian Seward wrote: On 10/29/2014 09:24 AM, Florian Krohm wrote: I've fixed this in revision 14673. Curious, what GCC version have you been using? I think the deciding factor might be, not the gcc version, but the CPU variant being compiled for. In particular that some AMDs do or don't have special variants of these in hardware, or some such. That was my initial assumption, but I'm not sure it can be true because a fairly generic build that just targets any old x86_64 or whatever does work. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] ulimit under valgrind
On 06/10/14 16:08, Skarakis, Konstantinos wrote: I am having trouble running programs that need to use ulimit under valgrind. For instance, here is a simple script that changes the limit of open files to 10. All commands below are executed as root: cat foo #!/bin/sh ulimit -n 10 I can run it fine on its own. ./foo echo $? 0 But under valgrind I get blocked with Operation not permitted: Because valgrind needs to reserve a few file descriptors for it's own use it effectively reduces the hard limit slightly, so you won't be able to raise your own soft limit above that reduced hard limit. If you query the hard limit with getrlimit and then increase your soft limit to that then you should find it works. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] ulimit under valgrind
On 06/10/14 16:22, Tom Hughes wrote: On 06/10/14 16:08, Skarakis, Konstantinos wrote: I am having trouble running programs that need to use ulimit under valgrind. For instance, here is a simple script that changes the limit of open files to 10. All commands below are executed as root: cat foo #!/bin/sh ulimit -n 10 I can run it fine on its own. ./foo echo $? 0 But under valgrind I get blocked with Operation not permitted: Because valgrind needs to reserve a few file descriptors for it's own use it effectively reduces the hard limit slightly, so you won't be able to raise your own soft limit above that reduced hard limit. Actually it's worse than that, we allocate the 10 reserved descriptors immediately above the soft limit (assuming there is space) and effectively convert the initial soft limit to a hard limit. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Using valgrind with lxc
On 29/09/14 15:41, Vallevand, Mark K wrote: Our program is designed to close all open file descriptors in the child process before calling lxc_start(). That code can try to close all file descriptors to make sure something doesn’t sneak through. However, closing the file descriptors associated with valgrind does not work. I get errno=0 Bad File Descriptor. Valgrind really has them held open. I am running as root in all these tests. Yes, we refuse to let them be closed because that would, for example, break logging as it would close our log stream. We do however also lie when asked with getrlimit how many file descriptors there are, so lxc is obviously just guessing some high upper limit rather than actually asking what the limit is. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Problems with valgrind after a fork() and starting a container
On 24/09/14 22:04, Vallevand, Mark K wrote: We don’t care about valgrind in the child process. We need to get the child to detach from valgrind before it calls the lxc library. So, how can this be done? It can't - valgrind is a fundamental part of the process and the only way to get rid of it is to exec into a different binary. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
