Visual Leak Detector observes a memory leak (a minor 40 bytes) in the following code..
...
void simulatememoryleak(){
boost::asio::io_service m_IOService;
boost::asio::serial_port m_SerialPort( m_IOService, "COM21" );;
m_SerialPort.cancel();
m_SerialPort.close();
m_IOService.stop();
m_IOService.reset();
}
..
Can anyone suggest why this is?
I have also posted questions to the VLD and boost communities..
On my linux box it only leaks when there is no permission to open the serial port (in which case it aborts with an exception).
Here's a valgrind of the working run ¹:
$ sudo valgrind --leak-check=full ./test
==21281== Memcheck, a memory error detector
==21281== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==21281== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==21281== Command: ./test
==21281==
==21281==
==21281== HEAP SUMMARY:
==21281== in use at exit: 0 bytes in 0 blocks
==21281== total heap usage: 10 allocs, 10 frees, 851 bytes allocated
==21281==
==21281== All heap blocks were freed -- no leaks are possible
==21281==
==21281== For counts of detected and suppressed errors, rerun with: -v
==21281== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
When not running as root I get
==21286== possibly lost: 331 bytes in 4 blocks
==21286== still reachable: 664 bytes in 8 blocks
¹ using /dev/ttyS0 or similar
Related
when running GEM5 X86 in SE mode, I am trying to run bzip2 from SPEC2006, at first it was failing because it says it can't run dynamic execution so I compiled it with -static flag.
now I get this error:
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Oct 27 2018 00:36:02
gem5 started Dec 22 2018 18:16:40
gem5 executing on Dan
command line: ./build/X86/gem5.opt configs/example/se.py -c /home/dan/SPEC2006/benchspec/CPU2006/401.bzip2/exe/bzip2_base.ia64-gcc42 -i /home/dan/SPEC2006/benchspec/CPU2006/401.bzip2/data/test/input/dryer.jpg
Could not import 03_BASE_FLAT
Could not import 03_BASE_NARROW
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (4096 Mbytes)
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
**** REAL SIMULATION ****
info: Entering event queue # 0. Starting simulation...
panic: Tried to write unmapped address 0xffffedd8. Inst is at 0x400da4
# tick 5500
[invoke:build/X86/arch/x86/faults.cc, line 160]
Memory Usage: 4316736 KBytes
Program aborted at tick 5500
Aborted (core dumped)
I am running gem5 on ubuntu 17.10.
I tried to find solutions in google but I didn't see any one referring to this problem, does anyone know how to fix the problem?
Please check your host machine configuration. Bzip2 does not work in a 32-bit machine. My desktop is dual core have 32-bit X86 architecture, I tried to run bzip2 it had shown same error.
During start valgrind prints the following and terminates silently. Why does that happen and what does it mean?
==2758== Memcheck, a memory error detector
==2758== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==2758== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==2758== Command: /usr/local/bin/bp_mat_00
==2758==
==2758== error writing 36 bytes to shared mem /tmp/vgdb-pipe-shared-mem-vgdb-2758-by-root-on-???
This means that valgrind attempts to write to a directory that is already full. See
df -h
However if the directory gets filled at a later stage of valgrind run then valgrind may not print that message, may not terminate, but still may work incorrectly...
How do you get Valgrind to show exactly where an error occured? I compiled my program (on a Windows machine over a Linux terminal via PuTTy) adding the -g debug option.
When I run Valgrind, I get the Leak and Heap summary, and I definitely have lost memory, but I never get information about where it happens (file name, line). Shouldn't Valgrind be telling me on what line after I allocate memory, it fails to deallocate later?
==15746==
==15746== HEAP SUMMARY:
==15746== in use at exit: 54 bytes in 6 blocks
==15746== total heap usage: 295 allocs, 289 frees, 11,029 bytes allocated
==15746==
==15746== LEAK SUMMARY:
==15746== definitely lost: 12 bytes in 3 blocks
==15746== indirectly lost: 42 bytes in 3 blocks
==15746== possibly lost: 0 bytes in 0 blocks
==15746== still reachable: 0 bytes in 0 blocks
==15746== suppressed: 0 bytes in 0 blocks
==15746== Rerun with --leak-check=full to see details of leaked memory
==15746==
==15746== For counts of detected and suppressed errors, rerun with: -v
==15746== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 8)
I've repeatedly gotten hosed on this, and couldn't figure out why '--leak-check=full' wasn't working for me, so I thought I'd bump up tune2fs comment.
The most likely problem is that you've (Not ShrimpCrackers, but whoever is reading this post right now) placed --leak-check=full at the end of your command line. Valgrind would like you to post the flag before you enter the actual command line to run your program.
i.e.:
valgrind --leak-check=full ./myprogram
NOT:
valgrind ./myprogram --leak-check=full
Try valgrind --leak-check=full
This normally prints more useful information.
Also add the -O0 flag when compiling so your code doesn't get optimized.
It's not an option related to valgrind. Instead, the code have to be compiled with -g options, in order to preserve the debug symbol.
cc -g main.c
valgrind --trace-children=yes --track-fds=yes --track-origins=yes --leak-check=full --show-leak-kinds=all ./a.out
Let me be more specific for other readers (i had the same problem but my arguments were in the right order):
I found out that valgrind needs the path to the executable, if you dont give this then it will run bu it won't give you the line numbers.
In my case the executable was in a different directory, which was in my PATH, but to get the line information you have to run
valgrind --leak-check=full path_to_myprogram/myprogram
In order for valgrind to show the lines where the errors occurred in the file,
I had to add -g to the END of my compile command.
For Example:
gcc -o main main.c -g
Then just run valgrind:
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./main
Killing the valgrind process itself leaves no report on the inner process' execution.
Is it possible to send a terminate signal to a process running inside valgrind?
There is no "inner process" as both valgrind itself and the client program it is running execute in a single process.
Signals sent to that process will be delivered to the client program as normal. If the signal causes the process to terinate then valgrind's normal exit handlers will run and (for example) report any leaks.
So, for example, if we start valgrind on a sleep command:
bericote [~] % valgrind sleep 240
==9774== Memcheck, a memory error detector
==9774== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==9774== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==9774== Command: sleep 240
==9774==
then kill that command:
bericote [~] % kill -TERM 9774
then the process will exit and valgrind's exit handlers will run:
==9774==
==9774== HEAP SUMMARY:
==9774== in use at exit: 0 bytes in 0 blocks
==9774== total heap usage: 30 allocs, 30 frees, 3,667 bytes allocated
==9774==
==9774== All heap blocks were freed -- no leaks are possible
==9774==
==9774== For counts of detected and suppressed errors, rerun with: -v
==9774== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
[1] 9774 terminated valgrind sleep 240
The only exception would be for kill -9 as in that case the process is killed by the kernel without ever being informed of the signal so valgrind has no opportunity to do anything.
If I compile a 32 bit executable in Mac 10.6, with the -m32 flag, like:
gcc -m32 test.c -o test
running valgrind on "test" fails with the error:
valgrind: ./test: cannot execute binary file
Are there any flags to pass to valgrind to execute this? Is the only option to compile valgrind in 32 bit mode?
Thanks
Blender, the -m32 flag just means to compile the file in 32-bit mode. Mac 10.6 runs 32-bit executables just fine.
I had this problem too, with valgrind built/installed by MacPorts. When I built it myself, however, the problem went away. I can confirm that a default build of valgrind with no extra configure options supports both 32-bit and 64-bit programs on Snow Leopard (used version 3.6.1.)
What version of Valgrind are you having trouble with?
On Linux and MacOS, a single build of Valgrind can automatically detect and do the right thing for both 32 and 64-bit binaries.
Here is what I see on Mac OS X 10.6.7 (10J869):
$ echo "int main() { free(1); return 0; }" | gcc -xc - -g -o a.out
$ echo "int main() { free(1); return 0; }" | gcc -xc - -g -o a.out32 -m32
$ valgrind --version
valgrind-3.7.0.SVN
$ valgrind ./a.out
==46102== Memcheck, a memory error detector
==46102== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==46102== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==46102== Command: ./a.out
==46102==
--46102-- ./a.out:
--46102-- dSYM directory is missing; consider using --dsymutil=yes
==46102== Invalid free() / delete / delete[] / realloc()
==46102== at 0x100010E9F: free (vg_replace_malloc.c:366)
==46102== by 0x100000F26: main (in ./a.out)
==46102== Address 0x1 is not stack'd, malloc'd or (recently) free'd
==46102==
==46102==
==46102== HEAP SUMMARY:
==46102== in use at exit: 88 bytes in 1 blocks
==46102== total heap usage: 1 allocs, 1 frees, 88 bytes allocated
==46102==
==46102== LEAK SUMMARY:
==46102== definitely lost: 0 bytes in 0 blocks
==46102== indirectly lost: 0 bytes in 0 blocks
==46102== possibly lost: 0 bytes in 0 blocks
==46102== still reachable: 0 bytes in 0 blocks
==46102== suppressed: 88 bytes in 1 blocks
==46102==
==46102== For counts of detected and suppressed errors, rerun with: -v
==46102== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
$ valgrind ./a.out32
==46103== Memcheck, a memory error detector
==46103== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==46103== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==46103== Command: ./a.out32
==46103==
--46103-- ./a.out32:
--46103-- dSYM directory is missing; consider using --dsymutil=yes
==46103== Invalid free() / delete / delete[] / realloc()
==46103== at 0xF7D8: free (vg_replace_malloc.c:366)
==46103== by 0x1F7B: main (in ./a.out32)
==46103== Address 0x1 is not stack'd, malloc'd or (recently) free'd
==46103==
==46103==
==46103== HEAP SUMMARY:
==46103== in use at exit: 320 bytes in 7 blocks
==46103== total heap usage: 7 allocs, 1 frees, 320 bytes allocated
==46103==
==46103== LEAK SUMMARY:
==46103== definitely lost: 0 bytes in 0 blocks
==46103== indirectly lost: 0 bytes in 0 blocks
==46103== possibly lost: 0 bytes in 0 blocks
==46103== still reachable: 260 bytes in 6 blocks
==46103== suppressed: 60 bytes in 1 blocks
==46103== Rerun with --leak-check=full to see details of leaked memory
==46103==
==46103== For counts of detected and suppressed errors, rerun with: -v
==46103== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)