Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: François-Xavier C. <fx....@ya...> - 2020-06-25 18:15:28
|
Hi, I have a program that calls exec without forking. I would like to run that program under valgrind and get a summary report for the code before the call to exec. I don't want to trace the exec'ed program, so the --trace-children option does not do what I want. Is there a way to have valgrind output the error/leak summary before exec (without tracing after exec)? Thanks, François-Xavier |
|
From: Julian S. <js...@ac...> - 2020-06-25 10:43:46
|
We are pleased to announce a new release of Valgrind, version 3.16.1, available from http://valgrind.org/downloads/current.html. The source tarball is signed with the PGP key at the bottom of this message. 3.16.1 updates support for existing platforms and reduces Memcheck's false positive rate on optimised code generated by Clang and GCC. There are, as ever, many refinements and bug fixes. The release notes below give more details. A 3.16.0 tarball does exist, but was never announced due to the late discovery of two critical bugs in it. These are fixed in 3.16.1. We recommend you use or distribute 3.16.1 and not 3.16.0. Our thanks to all those who contribute to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy and productive debugging and profiling, -- The Valgrind Developers Release 3.16.1 (22 June 2020) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.16.1 fixes two critical bugs discovered after 3.16.0 was frozen. It also fixes character encoding problems in the documentation HTML. 422677 PPC sync instruction L field should only be 2 bits in ISA 3.0 422715 32-bit x86: vex: the `impossible' happened: expr_is_guardable: unhandled expr (3.16.1, 22 June 2020, 36d6727e1d768333a536f274491e5879cab2c2f7) Release 3.16.0 (27 May 2020) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.16.0 is a feature release with many improvements and the usual collection of bug fixes. This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris and AMD64/MacOSX 10.12. There is also preliminary support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. * ==================== CORE CHANGES =================== * It is now possible to dynamically change the value of many command line options while your program (or its children) are running under Valgrind. To see the list of dynamically changeable options, run "valgrind --help-dyn-options". You can change the options from the shell by using vgdb to launch the monitor command "v.clo <clo option>...". The same monitor command can be used from a gdb connected to the valgrind gdbserver. Your program can also change the dynamically changeable options using the client request VALGRIND_CLO_CHANGE(option). * ================== PLATFORM CHANGES ================= * MIPS: preliminary support for nanoMIPS instruction set has been added. * ==================== TOOL CHANGES ==================== * DHAT: - The implicit memcpy done by each call to realloc now counts towards the read and write counts of resized heap blocks, making those counts higher and more accurate. * Cachegrind: - cg_annotate's --auto and --show-percs options now default to 'yes', because they are usually wanted. * Callgrind: - callgrind_annotate's --auto and --show-percs options now default to 'yes', because they are usually wanted. - The command option --collect-systime has been enhanced to specify the unit used to record the elapsed time spent during system calls. The command option now accepts the values no|yes|msec|usec|nsec, where yes is a synonym of msec. When giving the value nsec, the system cpu time of system calls is also recorded. * Memcheck: - Several memcheck options are now dynamically changeable. Use valgrind --help-dyn-options to list them. - The release 3.15 introduced a backward incompatible change for some suppression entries related to preadv and pwritev syscalls. When reading a suppression entry using the unsupported 3.14 format, valgrind will now produce a warning to say the suppression entry will not work, and suggest the needed change. - Significantly fewer false positive errors on optimised code generated by Clang and GCC. In particular, Memcheck now deals better with the situation where the compiler will transform C-level "A && B" into "B && A" under certain circumstances (in which the transformation is valid). Handling of integer equality/non-equality checks on partially defined values is also improved on some architectures. * exp-sgcheck: - The experimental Stack and Global Array Checking tool has been removed. It only ever worked on x86 and amd64, and even on those it had a high false positive rate and was slow. An alternative for detecting stack and global array overruns is using the AddressSanitizer (ASAN) facility of the GCC and Clang compilers, which require you to rebuild your code with -fsanitize=address. * ==================== OTHER CHANGES ==================== * New and modified GDB server monitor features: - Option -T tells vgdb to output a timestamp in the vgdb information messages. - The gdbserver monitor commands that require an address and an optional length argument now accepts the alternate 'C like' syntax "address[length]". For example, the memcheck command "monitor who_points_at 0x12345678 120" can now also be given as "monitor who_points_at 0x12345678[120]". * ==================== FIXED BUGS ==================== The following bugs have been fixed or resolved. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. We encourage you to file bugs in bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX where XXXXXX is the bug number as listed below. 343099 Linux setns syscall wrapper missing, unhandled syscall: 308 == 368923 WARNING: unhandled arm64-linux syscall: 268 (setns) == 369031 WARNING: unhandled amd64-linux syscall: 308 (setns) 385386 Assertion failed "szB >= CACHE_ENTRY_SIZE" at m_debuginfo/image.c:517 400162 Patch: Guard against __GLIBC_PREREQ for musl libc 400593 In Coregrind, use statx for some internal syscalls if [f]stat[64] fail 400872 Add nanoMIPS support to Valgrind 403212 drd/tests/trylock hangs on FreeBSD 404406 s390x: z14 miscellaneous instructions not implemented 405201 Incorrect size of struct vki_siginfo on 64-bit Linux architectures 406561 mcinfcallWSRU gdbserver_test fails on ppc64 406824 Unsupported baseline 407218 Add support for the copy_file_range syscall 407307 Intercept stpcpy also in ld.so for arm64 407376 Update Xen support to 4.12 (4.13, actually) and add more coverage == 390553 407764 drd cond_post_wait gets wrong (?) condition on s390x z13 system 408009 Expose rdrand and f16c even on avx if host cpu supports them 408091 Missing pkey syscalls 408414 Add support for missing for preadv2 and pwritev2 syscalls 409141 Valgrind hangs when SIGKILLed 409206 Support for Linux PPS and PTP ioctls 409367 exit_group() after signal to thread waiting in futex() causes hangs 409429 amd64: recognize 'cmpeq' variants as a dependency breaking idiom 409780 References to non-existent configure.in 410556 Add support for BLKIO{MIN,OPT} and BLKALIGNOFF ioctls 410599 Non-deterministic behaviour of pth_self_kill_15_other test 410757 discrepancy for preadv2/pwritev2 syscalls across different versions 411134 Allow the user to change a set of command line options during execution 411451 amd64->IR of bt/btc/bts/btr with immediate clears zero flag 412344 Problem setting mips flags with specific paths 412408 unhandled arm-linux syscall: 124 - adjtime - on arm-linux 413119 Ioctl wrapper for DRM_IOCTL_I915_GEM_MMAP 413330 avx-1 test fails on AMD EPYC 7401P 24-Core Processor 413603 callgrind_annotate/cg_annotate truncate function names at '#' 414565 Specific use case bug found in SysRes VG_(do_sys_sigprocmask) 415136 ARMv8.1 Compare-and-Swap instructions are not supported 415757 vex x86->IR: 0x66 0xF 0xCE 0x4F (bswapw) 416239 valgrind crashes when handling clock_adjtime 416285 Use prlimit64 in VG_(getrlimit) and VG_(setrlimit) 416286 DRD reports "conflicting load" error on std::mutex::lock() 416301 s390x: "compare and signal" not supported 416387 finit_module and bpf syscalls are unhandled on arm64 416464 Fix false reports for uninitialized memory for PR_CAPBSET_READ/DROP 416667 gcc10 ppc64le impossible constraint in 'asm' in test_isa. 416753 new 32bit time syscalls for 2038+ 417075 pwritev(vector[...]) suppression ignored 417075 is not fixed, but incompatible supp entries are detected and a warning is produced for these. 417187 [MIPS] Conditional branch problem since 'grail' changes 417238 Test memcheck/tests/vbit-test fails on mips64 BE 417266 Make memcheck/tests/linux/sigqueue usable with musl 417281 s390x: /bin/true segfaults with "grail" enabled 417427 commit to fix vki_siginfo_t definition created numerous regression errors on ppc64 417452 s390_insn_store_emit: dst->tag for HRcVec128 417578 Add suppressions for glibc DTV leaks 417906 clone with CLONE_VFORK and no CLONE_VM fails 418004 Grail code additions break ppc64. 418435 s390x: spurious "Conditional jump or move depends on uninitialised [..]" 418997 s390x: Support Iex_ITE for float and vector types 419503 s390x: Avoid modifying registers returned from isel functions 421321 gcc10 arm64 build needs __getauxval for linking with libgcc 421570 std_mutex fails on Arm v8.1 h/w n-i-bz Fix minor one time leaks in dhat. n-i-bz Add --run-cxx-freeres=no in outer args to avoid inner crashes. n-i-bz Add support for the Linux io_uring system calls n-i-bz sys_statx: don't complain if both |filename| and |buf| are NULL. n-i-bz Fix non-glibc build of test suite with s390x_features n-i-bz MinGW, include/valgrind.h: Fix detection of 64-bit mode (3.16.0.RC1: 18 May 2020, git 6052ee66a0cf5234e8e2a2b49a8760226bc13b92) (3.16.0.RC2: 19 May 2020, git 940ec1ca69a09f7fdae3e800b7359f85c13c4b37) (3.16.0: 27 May 2020, git bf5e647edb9e96cbd5c57cc944984402eeee296d) -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFy189QBCACxFf0SSSycE42ulnIYk7GNR9FnKlDN4rNZ9TExYWMh6cJIELgq W5eI9xoHJarfLc7uSKPagcGPIntThCMBw8dLnL8mFzsCOIrjQl/C9FZua53RwmzE t6+yvMJMcYz8Vqfh7J8w5+zlAMFSqbE5jAcWEzlaz8YMt8GTgixhFSC6eyy0j+4L k35+lKOvX1htUIjVYz9nfVgGmz6Vg+2dyjxoB6GHXtrAExRuoo0jqctLc8dZOp0U MMzVEQzJItcYj6/L1FEOYcrnhVri92sgB+AReMWy1ailt+OmNXmEkpV5L4vCJn2Y sThu7OnecBUoMMP13y2UB23h3vlxe0RyxuZNABEBAAG0H0p1bGlhbiBTZXdhcmQg PGpzZXdhcmRAYWNtLm9yZz6JATgEEwECACIFAly189QCGwMGCwkIBwMCBhUIAgkK CwQWAgMBAh4BAheAAAoJELoBZuaY+mA1ttoH/0MkIQcB4QohV2Z9Fkf95jm6uz/P rFewPS7iyRMLL9sPktjqXg0X1yxX5ShpEbtL18X+qbAVDIe98uTdyFb21b8DjP6n v2KnIZFDD+iZEceWJD6MAXcicvr4sv4LESzreNEIF6wHdWkWC4v57hQl+uywWXiI T4gnHUEJIu0cNP3vMcSjrgrzeaPW3z56B+BLBM1XncrZ0mbz77/FK9lQM1arLpcU dPNJlVMqNdbLLlIsmkZ8jfE7TCOCNuIrCHeNTRGY5NuY829pheGwutIlp4t+Pchz /cib3hZeilJrFuuqBOk4ipZ/s1PwS9DigGOk1I0egqIBhPdAsEY3gBXdOXyJAjME EAEKAB0WIQTsPP6I9soHiHdPXB0apEvmSd52CgUCXLYy8gAKCRAapEvmSd52CnJb D/45yMDDnSelx6MfBwQcowqkkK/BzZs+akR5hX76g5alMSA2MRBkudGO8R/G2fva sa9e2Js+3crmoyOxfL3PCun/N7/J2rX8PPT6d4hk1N3fluUWghUhCDMHmfPy1N5d WMTTW/EvZrYdh1dauGw/k+DP/M784FN8UU15hggMCcqM5LGNKuMOhFadntecj/Wr aAtroLD3Geq7eUAO18oYgJFRktdXtDkWGTG6+KhoLTIaW8xRAR1OiO6Oxua+3htU Zrk9AIDAJQymeA9budWyVAMPZSgnkSdMQBe8UnwsCx1X6xZP+wHihZ86oClydieh 3AtsLzjzZGNytAO7+BP7cNxvrWXBNUMTEQwAcMp8PbjV3NAK/96sfdQ++3wttvMw 4M4AI0hFxE67EkpTjk0rDhDINjOowyn/MBpNuuC2BuDlzrR7AV8jKq957OMko6uk S/NlJo9LUYeyLSU1lF5B6fh6tu3Tyv4yASTp6fyihh+G24azAbYi4WQu79ltuDQb Zg4fGVB/vcydsf1NxiEQMMSOyrcws+WNYjqGymZ70YZW+PDEBZcW4WE515RR0N3N 3YmLbvIywYQe2zKFOoLu2CDx/q/gqMX0W9I4h3sSKOoFIFkeY7Cr/6OdV6S1Re9d o/dGoKDzfjaXpTZf4Kv19wEizElnoi7S7tFrbLLMV1vQHrkBDQRctfPUAQgAtKTF G5HFIUs8kO3Cs3EysJhOe/pEIYhkdRwKn46ostfk7Ghd4YdwRYDscZaqrwCaY1lV VLKd33IPdFHpGwRQrM0RyLA+A6xfdoCoKO0vOLTEiEDI+C3FDSZ/vCeq13gMfYHN tuhmEjvA9MMwKx0/kfKc28fQWPDDDgnAQ6cyS+9t4s4j6JuRm/rq4blKWGK8f8Ob KrEFHt/J1uhLykGbgYFu0MSaldevjHJzqzkscHcifAA5SMWZuYn5dMCNJT+8Iadr u0TSCvZQeN3HceNCN2Liodpv/JqUn8qF5wGaUxZFcGdy5V+nR1PsQnguEd35Z1ai rfqdE27KZYRC3xzO8wARAQABiQEfBBgBAgAJBQJctfPUAhsMAAoJELoBZuaY+mA1 NSUH/jUd12imDneXAMKt3ThlqXh1v0tPnawugaNHD3vibvgFYcyqQ+YbPMhRgUoc hdTLbkqxkjEzfLhpzAA164AcP3/pDq+OCyyONNnt06LXxgGU2lJoTeRdSEsOFYxE RnOUoW8qQoPWWk8ZmnMh/2VEuXeIjXMHNvdAWMn0gUfKDEeeCILpqkn4f4Sx4H5P 1Yf4JzgwYTfFocXDsQSsFrboAPOJVEm4E7zJfp62Uzs72+9NueHnZEnr4pVzCUIm CxJrvQzGcJxc1eqbuCmI0zuFLRcgZUpO4a0IaDUsjhbG2PUTADgSAfgLihrvaiA+ xn/APcV8iSUjgKGcnQfuhhayxQk= =C8ND -----END PGP PUBLIC KEY BLOCK----- |
|
From: David C. <dcc...@ac...> - 2020-06-17 17:47:21
|
(please don't top-post - it is harder to follow the conversation) On 6/17/2020 10:20 AM, Kunal Chauhan wrote: > > On 17 Jun 2020 13:50, "Paul FLOYD" <pj...@wa... > <mailto:pj...@wa...>> wrote: > > > Hi Team, > > > Q.As for a valgrind usage , is valgrind only checks the memory > leakage of code which hits only? > > > Q As for a can valgrind checks the all the code of binary > without hitting rhe scenerio. In code? > > Kunal > > Broadly speaking, there are two categories of software analysis tools. > > 1. Static analysis tools. For instance, clang analyzer. See > https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis > <https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis> > > > These tools parse all the code to produce some sort of model and > then do lots of 'what-if' analysis on all code paths. > Advantages: does not depend on your test coverage, can check for > very many kinds of errors. > Disadvantages: tools have to make tradeoffs between runtime and > really checking all possibilities. Also the models > are usually limited in scope which can cause false positives. > > 2. Dynamic analysis tools like Valgrind. Again wikipedia has a > page listing tools > https://en.wikipedia.org/wiki/Dynamic_program_analysis > <https://en.wikipedia.org/wiki/Dynamic_program_analysis> > > These tools test running code. > Advantages: lower rate of false positives. > Disadvantage. Only as good as your tests - you should be measuring > your code coverage! Performance - usually there is a large memory > and/or runtime overhead, which can make running > dynamic tools on large applications/data imprectical. > > A+ > Paul > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > <mailto:Val...@li...> > https://lists.sourceforge.net/lists/listinfo/valgrind-users > <https://lists.sourceforge.net/lists/listinfo/valgrind-users> > > > Hi Team, > > 1. Is valgrind use particular format, to show memory leaks like double > free in c code. > > 2. If we have multiple pointers and some sig abort happens in code, is > valgrind works for that part also.? > > Thnks > Kunal > 1. The memcheck tool within valgrind will report repeated calls to free(): https://www.valgrind.org/info/tools.html 2. valgrind/memcheck will report the state of memory when the program exits, whatever the reason. If the error handler in your code does not clean up all memory before the program exits, valgrind will generate a very long report of the memory still in use. Because abort() calls can occur anywhere in the code, many developers do not attempt to clean up everything - the code to do so can be very complex. Item 2 sounds very limiting, but if your program is crashing because of one or more invalid memory accesses, valgrind will report where that occurred. You can fix the access error(s), ignore the report of memory still in use, then rerun valgrind. This is a very powerful debugging method. -- David Chapman dcc...@ac... Chapman Consulting -- San Jose, CA EDA Software Developer, Expert Witness www.chapman-consulting-sj.com 2018-2019 Chair, IEEE Consultants' Network of Silicon Valley |
|
From: Kunal C. <atk...@gm...> - 2020-06-17 17:20:15
|
Hi Team, 1. Is valgrind use particular format, to show memory leaks like double free in c code. 2. If we have multiple pointers and some sig abort happens in code, is valgrind works for that part also.? Thnks Kunal On 17 Jun 2020 13:50, "Paul FLOYD" <pj...@wa...> wrote: > Hi Team, > Q.As for a valgrind usage , is valgrind only checks the memory leakage of code which hits only? > Q As for a can valgrind checks the all the code of binary without hitting rhe scenerio. In code? Kunal Broadly speaking, there are two categories of software analysis tools. 1. Static analysis tools. For instance, clang analyzer. See https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis These tools parse all the code to produce some sort of model and then do lots of 'what-if' analysis on all code paths. Advantages: does not depend on your test coverage, can check for very many kinds of errors. Disadvantages: tools have to make tradeoffs between runtime and really checking all possibilities. Also the models are usually limited in scope which can cause false positives. 2. Dynamic analysis tools like Valgrind. Again wikipedia has a page listing tools https://en.wikipedia.org/wiki/Dynamic_program_analysis These tools test running code. Advantages: lower rate of false positives. Disadvantage. Only as good as your tests - you should be measuring your code coverage! Performance - usually there is a large memory and/or runtime overhead, which can make running dynamic tools on large applications/data imprectical. A+ Paul _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Paul F. <pj...@wa...> - 2020-06-17 08:18:46
|
> Hi Team, > Q.As for a valgrind usage , is valgrind only checks the memory leakage of code which hits only? > Q As for a can valgrind checks the all the code of binary without hitting rhe scenerio. In code? Kunal Broadly speaking, there are two categories of software analysis tools. 1. Static analysis tools. For instance, clang analyzer. See https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis These tools parse all the code to produce some sort of model and then do lots of 'what-if' analysis on all code paths. Advantages: does not depend on your test coverage, can check for very many kinds of errors. Disadvantages: tools have to make tradeoffs between runtime and really checking all possibilities. Also the models are usually limited in scope which can cause false positives. 2. Dynamic analysis tools like Valgrind. Again wikipedia has a page listing tools https://en.wikipedia.org/wiki/Dynamic_program_analysis These tools test running code. Advantages: lower rate of false positives. Disadvantage. Only as good as your tests - you should be measuring your code coverage! Performance - usually there is a large memory and/or runtime overhead, which can make running dynamic tools on large applications/data imprectical. A+ Paul |
|
From: David C. <dcc...@ac...> - 2020-06-16 17:19:39
|
On 6/16/2020 9:52 AM, Kunal Chauhan wrote:
> Hi Team,
>
>
> Q.As for a valgrind usage , is valgrind only checks the memory leakage
> of code which hits only?
> Q As for a can valgrind checks the all the code of binary without
> hitting rhe scenerio. In code?
>
>
> Thanks
> Kunal
The first supposition is correct. Coverage of all code paths requires a
set of test cases that execute all code paths. valgrind executes the
tested program and reports on memory problems during that execution.
--
David Chapman dcc...@ac...
Chapman Consulting -- San Jose, CA
EDA Software Developer, Expert Witness
www.chapman-consulting-sj.com
2018-2019 Chair, IEEE Consultants' Network of Silicon Valley
|
|
From: Kunal C. <atk...@gm...> - 2020-06-16 16:53:03
|
Hi Team, Q.As for a valgrind usage , is valgrind only checks the memory leakage of code which hits only? Q As for a can valgrind checks the all the code of binary without hitting rhe scenerio. In code? Thanks Kunal |
|
From: Paul F. <pj...@wa...> - 2020-06-08 06:58:01
|
On 6/7/20 16:11 UTC, James Read wrote: > I found the FAQ https://dev.mysql.com/doc/refman/8.0/en/faqs.html but couldn't find the answer you were referring to. > Any clues as to which part of the FAQ I should be looking in? I think that John was referring to the Valgrind FAQ https://www.valgrind.org/docs/manual/faq.html In particular item 5.2, "With Memcheck's memory leak detector, what's the difference between "definitely lost", "indirectly lost", "possibly lost", "still reachable", and "suppressed"?" A+ Paul |
|
From: John R. <jr...@bi...> - 2020-06-08 03:21:39
|
After a few private emails and --num-callers=50, then the original poster reports:
mysql_library_end() was missing. Error messages have gone now.
|
|
From: James R. <jam...@gm...> - 2020-06-07 19:47:04
|
On Sun, Jun 7, 2020 at 7:04 PM John Reiser <jr...@bi...> wrote: > On 6/7/20 16:11 UTC, James Read wrote: > > Any idea what this means?: > > > > ==56082== 16,528 bytes in 1 blocks are possibly lost in loss record 409 > of 409 > > Help yourself; that question is bad lazy. There is a manual with > extensive documentation. > A brief search of the web will reveal the answer. The manual contains FAQ > that answers this very question. > > > I found the FAQ https://dev.mysql.com/doc/refman/8.0/en/faqs.html but couldn't find the answer you were referring to. Any clues as to which part of the FAQ I should be looking in? James Read > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: John R. <jr...@bi...> - 2020-06-07 18:02:26
|
On 6/7/20 16:11 UTC, James Read wrote: > Any idea what this means?: > > ==56082== 16,528 bytes in 1 blocks are possibly lost in loss record 409 of 409 Help yourself; that question is bad lazy. There is a manual with extensive documentation. A brief search of the web will reveal the answer. The manual contains FAQ that answers this very question. |
|
From: James R. <jam...@gm...> - 2020-06-07 16:11:28
|
Any idea what this means?: ==56082== 16,528 bytes in 1 blocks are possibly lost in loss record 409 of 409 ==56082== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==56082== by 0x49D76F7: my_raw_malloc (my_malloc.cc:199) ==56082== by 0x49D76F7: my_malloc(unsigned int, unsigned long, int) (my_malloc.cc:81) ==56082== by 0x49E6199: allocate (malloc_allocator.h:98) ==56082== by 0x49E6199: allocate (alloc_traits.h:306) ==56082== by 0x49E6199: _M_allocate (stl_vector.h:343) ==56082== by 0x49E6199: _M_default_append (vector.tcc:635) ==56082== by 0x49E6199: resize (stl_vector.h:937) ==56082== by 0x49E6199: file_info::RegisterFilename(int, char const*, file_info::OpenType) (my_file.cc:196) ==56082== by 0x49D7CBB: my_open(char const*, int, int) (my_open.cc:84) ==56082== by 0x49D0954: inline_mysql_file_open (mysql_file.h:993) ==56082== by 0x49D0954: my_read_charset_file(MY_CHARSET_LOADER*, char const*, int) (charset.cc:378) ==56082== by 0x49D15E1: init_available_charsets() (charset.cc:448) ==56082== by 0x55C647E: __pthread_once_slow (pthread_once.c:116) ==56082== by 0x49D107D: __gthread_once (gthr-default.h:700) ==56082== by 0x49D107D: void std::call_once<void (&)()>(std::once_flag&, void (&)()) (mutex:683) ==56082== by 0x49D2022: my_charset_get_by_name(MY_CHARSET_LOADER*, char const*, unsigned int, int) (charset.cc:652) ==56082== by 0x49D210E: get_charset_by_csname(char const*, unsigned int, int) (charset.cc:670) ==56082== by 0x498021B: mysql_set_character_set_with_default_collation (client.cc:3688) ==56082== by 0x498021B: mysql_init_character_set(MYSQL*) (client.cc:3719) ==56082== by 0x498041A: csm_parse_handshake(mysql_async_connect*) (client.cc:6287) ==56082== James Read On Fri, Jun 5, 2020 at 3:38 PM Alexander Brock <ale...@lu...> wrote: > On 6/5/20 3:28 PM, James Read wrote: > > I'm guessing I'm going to have to compile MySQL with -g flag in order to > > decipher this stuff? > > Some distributions have extra packages with debug symbols, if you > install them you should get decent messages. > > Best Regards, > Alexander > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: James R. <jam...@gm...> - 2020-06-07 15:52:57
|
On Sun, Jun 7, 2020 at 4:16 PM Derrick McKee <der...@gm...> wrote: > It looks like you're using a pointer that has been freed some time earlier. > Yeah. Thanks. > > On Sun, Jun 7, 2020, 10:52 James Read <jam...@gm...> wrote: > >> I'm getting a series of Invalid read of size 1 errors. These seem to be >> related to strlen() calls. How is it possible for strlen() to make an >> invalid read? >> >> Here is my valgrind output: >> >> ==21737== Invalid read of size 1 >> ==21737== at 0x483EF46: strlen (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10D7E6: crawler_init (crawler.c:1165) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd >> ==21737== at 0x483CA3F: free (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10CC43: new_head_conn (crawler.c:911) >> ==21737== by 0x10D751: crawler_init (crawler.c:1148) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Block was alloc'd at >> ==21737== at 0x483B7F3: malloc (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x50DD50E: strdup (strdup.c:42) >> ==21737== by 0x10D70C: crawler_init (crawler.c:1145) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== >> ==21737== Invalid read of size 1 >> ==21737== at 0x483EF54: strlen (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10D7E6: crawler_init (crawler.c:1165) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Address 0x7adf2c1 is 1 bytes inside a block of size 52 free'd >> ==21737== at 0x483CA3F: free (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10CC43: new_head_conn (crawler.c:911) >> ==21737== by 0x10D751: crawler_init (crawler.c:1148) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Block was alloc'd at >> ==21737== at 0x483B7F3: malloc (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x50DD50E: strdup (strdup.c:42) >> ==21737== by 0x10D70C: crawler_init (crawler.c:1145) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== >> ==21737== Invalid read of size 1 >> ==21737== at 0x483EF46: strlen (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10D89B: crawler_init (crawler.c:1166) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd >> ==21737== at 0x483CA3F: free (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10CC43: new_head_conn (crawler.c:911) >> ==21737== by 0x10D751: crawler_init (crawler.c:1148) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Block was alloc'd at >> ==21737== at 0x483B7F3: malloc (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x50DD50E: strdup (strdup.c:42) >> ==21737== by 0x10D70C: crawler_init (crawler.c:1145) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== >> ==21737== Invalid read of size 1 >> ==21737== at 0x483EF54: strlen (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10D89B: crawler_init (crawler.c:1166) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Address 0x7adf2c1 is 1 bytes inside a block of size 52 free'd >> ==21737== at 0x483CA3F: free (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10CC43: new_head_conn (crawler.c:911) >> ==21737== by 0x10D751: crawler_init (crawler.c:1148) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Block was alloc'd at >> ==21737== at 0x483B7F3: malloc (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x50DD50E: strdup (strdup.c:42) >> ==21737== by 0x10D70C: crawler_init (crawler.c:1145) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== >> ==21737== Invalid read of size 1 >> ==21737== at 0x4993BFD: ??? (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x49D0D82: ??? (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x49759AF: mysql_real_escape_string_quote (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x49759DB: mysql_real_escape_string (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x10D8BB: crawler_init (crawler.c:1166) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd >> ==21737== at 0x483CA3F: free (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10CC43: new_head_conn (crawler.c:911) >> ==21737== by 0x10D751: crawler_init (crawler.c:1148) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Block was alloc'd at >> ==21737== at 0x483B7F3: malloc (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x50DD50E: strdup (strdup.c:42) >> ==21737== by 0x10D70C: crawler_init (crawler.c:1145) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== >> ==21737== Invalid read of size 1 >> ==21737== at 0x499D751: ??? (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x49D0D98: ??? (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x49759AF: mysql_real_escape_string_quote (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x49759DB: mysql_real_escape_string (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x10D8BB: crawler_init (crawler.c:1166) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd >> ==21737== at 0x483CA3F: free (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10CC43: new_head_conn (crawler.c:911) >> ==21737== by 0x10D751: crawler_init (crawler.c:1148) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Block was alloc'd at >> ==21737== at 0x483B7F3: malloc (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x50DD50E: strdup (strdup.c:42) >> ==21737== by 0x10D70C: crawler_init (crawler.c:1145) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== >> ==21737== Invalid read of size 1 >> ==21737== at 0x49D0DCB: ??? (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x49759AF: mysql_real_escape_string_quote (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x49759DB: mysql_real_escape_string (in >> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) >> ==21737== by 0x10D8BB: crawler_init (crawler.c:1166) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd >> ==21737== at 0x483CA3F: free (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x10CC43: new_head_conn (crawler.c:911) >> ==21737== by 0x10D751: crawler_init (crawler.c:1148) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== Block was alloc'd at >> ==21737== at 0x483B7F3: malloc (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==21737== by 0x50DD50E: strdup (strdup.c:42) >> ==21737== by 0x10D70C: crawler_init (crawler.c:1145) >> ==21737== by 0x10E417: main (crawler.c:1383) >> ==21737== >> >> Source code for my app is available at >> https://github.com/JamesRead5737/webcrawler >> >> Thanks, >> James Read >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > |
|
From: Derrick M. <der...@gm...> - 2020-06-07 15:17:04
|
It looks like you're using a pointer that has been freed some time earlier. On Sun, Jun 7, 2020, 10:52 James Read <jam...@gm...> wrote: > I'm getting a series of Invalid read of size 1 errors. These seem to be > related to strlen() calls. How is it possible for strlen() to make an > invalid read? > > Here is my valgrind output: > > ==21737== Invalid read of size 1 > ==21737== at 0x483EF46: strlen (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10D7E6: crawler_init (crawler.c:1165) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd > ==21737== at 0x483CA3F: free (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10CC43: new_head_conn (crawler.c:911) > ==21737== by 0x10D751: crawler_init (crawler.c:1148) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Block was alloc'd at > ==21737== at 0x483B7F3: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x50DD50E: strdup (strdup.c:42) > ==21737== by 0x10D70C: crawler_init (crawler.c:1145) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== > ==21737== Invalid read of size 1 > ==21737== at 0x483EF54: strlen (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10D7E6: crawler_init (crawler.c:1165) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Address 0x7adf2c1 is 1 bytes inside a block of size 52 free'd > ==21737== at 0x483CA3F: free (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10CC43: new_head_conn (crawler.c:911) > ==21737== by 0x10D751: crawler_init (crawler.c:1148) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Block was alloc'd at > ==21737== at 0x483B7F3: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x50DD50E: strdup (strdup.c:42) > ==21737== by 0x10D70C: crawler_init (crawler.c:1145) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== > ==21737== Invalid read of size 1 > ==21737== at 0x483EF46: strlen (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10D89B: crawler_init (crawler.c:1166) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd > ==21737== at 0x483CA3F: free (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10CC43: new_head_conn (crawler.c:911) > ==21737== by 0x10D751: crawler_init (crawler.c:1148) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Block was alloc'd at > ==21737== at 0x483B7F3: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x50DD50E: strdup (strdup.c:42) > ==21737== by 0x10D70C: crawler_init (crawler.c:1145) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== > ==21737== Invalid read of size 1 > ==21737== at 0x483EF54: strlen (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10D89B: crawler_init (crawler.c:1166) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Address 0x7adf2c1 is 1 bytes inside a block of size 52 free'd > ==21737== at 0x483CA3F: free (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10CC43: new_head_conn (crawler.c:911) > ==21737== by 0x10D751: crawler_init (crawler.c:1148) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Block was alloc'd at > ==21737== at 0x483B7F3: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x50DD50E: strdup (strdup.c:42) > ==21737== by 0x10D70C: crawler_init (crawler.c:1145) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== > ==21737== Invalid read of size 1 > ==21737== at 0x4993BFD: ??? (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x49D0D82: ??? (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x49759AF: mysql_real_escape_string_quote (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x49759DB: mysql_real_escape_string (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x10D8BB: crawler_init (crawler.c:1166) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd > ==21737== at 0x483CA3F: free (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10CC43: new_head_conn (crawler.c:911) > ==21737== by 0x10D751: crawler_init (crawler.c:1148) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Block was alloc'd at > ==21737== at 0x483B7F3: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x50DD50E: strdup (strdup.c:42) > ==21737== by 0x10D70C: crawler_init (crawler.c:1145) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== > ==21737== Invalid read of size 1 > ==21737== at 0x499D751: ??? (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x49D0D98: ??? (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x49759AF: mysql_real_escape_string_quote (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x49759DB: mysql_real_escape_string (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x10D8BB: crawler_init (crawler.c:1166) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd > ==21737== at 0x483CA3F: free (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10CC43: new_head_conn (crawler.c:911) > ==21737== by 0x10D751: crawler_init (crawler.c:1148) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Block was alloc'd at > ==21737== at 0x483B7F3: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x50DD50E: strdup (strdup.c:42) > ==21737== by 0x10D70C: crawler_init (crawler.c:1145) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== > ==21737== Invalid read of size 1 > ==21737== at 0x49D0DCB: ??? (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x49759AF: mysql_real_escape_string_quote (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x49759DB: mysql_real_escape_string (in > /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) > ==21737== by 0x10D8BB: crawler_init (crawler.c:1166) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd > ==21737== at 0x483CA3F: free (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x10CC43: new_head_conn (crawler.c:911) > ==21737== by 0x10D751: crawler_init (crawler.c:1148) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== Block was alloc'd at > ==21737== at 0x483B7F3: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==21737== by 0x50DD50E: strdup (strdup.c:42) > ==21737== by 0x10D70C: crawler_init (crawler.c:1145) > ==21737== by 0x10E417: main (crawler.c:1383) > ==21737== > > Source code for my app is available at > https://github.com/JamesRead5737/webcrawler > > Thanks, > James Read > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: James R. <jam...@gm...> - 2020-06-07 14:50:55
|
I'm getting a series of Invalid read of size 1 errors. These seem to be related to strlen() calls. How is it possible for strlen() to make an invalid read? Here is my valgrind output: ==21737== Invalid read of size 1 ==21737== at 0x483EF46: strlen (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10D7E6: crawler_init (crawler.c:1165) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd ==21737== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10CC43: new_head_conn (crawler.c:911) ==21737== by 0x10D751: crawler_init (crawler.c:1148) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Block was alloc'd at ==21737== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x50DD50E: strdup (strdup.c:42) ==21737== by 0x10D70C: crawler_init (crawler.c:1145) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== ==21737== Invalid read of size 1 ==21737== at 0x483EF54: strlen (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10D7E6: crawler_init (crawler.c:1165) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Address 0x7adf2c1 is 1 bytes inside a block of size 52 free'd ==21737== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10CC43: new_head_conn (crawler.c:911) ==21737== by 0x10D751: crawler_init (crawler.c:1148) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Block was alloc'd at ==21737== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x50DD50E: strdup (strdup.c:42) ==21737== by 0x10D70C: crawler_init (crawler.c:1145) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== ==21737== Invalid read of size 1 ==21737== at 0x483EF46: strlen (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10D89B: crawler_init (crawler.c:1166) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd ==21737== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10CC43: new_head_conn (crawler.c:911) ==21737== by 0x10D751: crawler_init (crawler.c:1148) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Block was alloc'd at ==21737== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x50DD50E: strdup (strdup.c:42) ==21737== by 0x10D70C: crawler_init (crawler.c:1145) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== ==21737== Invalid read of size 1 ==21737== at 0x483EF54: strlen (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10D89B: crawler_init (crawler.c:1166) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Address 0x7adf2c1 is 1 bytes inside a block of size 52 free'd ==21737== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10CC43: new_head_conn (crawler.c:911) ==21737== by 0x10D751: crawler_init (crawler.c:1148) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Block was alloc'd at ==21737== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x50DD50E: strdup (strdup.c:42) ==21737== by 0x10D70C: crawler_init (crawler.c:1145) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== ==21737== Invalid read of size 1 ==21737== at 0x4993BFD: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x49D0D82: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x49759AF: mysql_real_escape_string_quote (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x49759DB: mysql_real_escape_string (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x10D8BB: crawler_init (crawler.c:1166) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd ==21737== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10CC43: new_head_conn (crawler.c:911) ==21737== by 0x10D751: crawler_init (crawler.c:1148) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Block was alloc'd at ==21737== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x50DD50E: strdup (strdup.c:42) ==21737== by 0x10D70C: crawler_init (crawler.c:1145) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== ==21737== Invalid read of size 1 ==21737== at 0x499D751: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x49D0D98: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x49759AF: mysql_real_escape_string_quote (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x49759DB: mysql_real_escape_string (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x10D8BB: crawler_init (crawler.c:1166) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd ==21737== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10CC43: new_head_conn (crawler.c:911) ==21737== by 0x10D751: crawler_init (crawler.c:1148) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Block was alloc'd at ==21737== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x50DD50E: strdup (strdup.c:42) ==21737== by 0x10D70C: crawler_init (crawler.c:1145) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== ==21737== Invalid read of size 1 ==21737== at 0x49D0DCB: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x49759AF: mysql_real_escape_string_quote (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x49759DB: mysql_real_escape_string (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==21737== by 0x10D8BB: crawler_init (crawler.c:1166) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Address 0x7adf2c0 is 0 bytes inside a block of size 52 free'd ==21737== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x10CC43: new_head_conn (crawler.c:911) ==21737== by 0x10D751: crawler_init (crawler.c:1148) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Block was alloc'd at ==21737== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==21737== by 0x50DD50E: strdup (strdup.c:42) ==21737== by 0x10D70C: crawler_init (crawler.c:1145) ==21737== by 0x10E417: main (crawler.c:1383) ==21737== Source code for my app is available at https://github.com/JamesRead5737/webcrawler Thanks, James Read |
|
From: Alexander B. <ale...@lu...> - 2020-06-05 14:37:09
|
On 6/5/20 3:28 PM, James Read wrote: > I'm guessing I'm going to have to compile MySQL with -g flag in order to > decipher this stuff? Some distributions have extra packages with debug symbols, if you install them you should get decent messages. Best Regards, Alexander |
|
From: Paul F. <pj...@wa...> - 2020-06-05 14:31:58
|
Hi If you want to be certain then you will need to run with debug information. There may be something like a "mysql-debuginfo" package that you could install. That said, "still reachable" memory is often harmless, caused by libraries caching information. Similar questions have been asked on Stack Overflow you might want to check that you are shutting everythng down. Lastly, someone might already have a 'mysql' suppression file. I had a quick look and saw a few e.g., on github, but I don't know enough about mysql to be able to comment further. A+ Paul |
|
From: James R. <jam...@gm...> - 2020-06-05 13:29:05
|
I have a bunch of what seem to be MySQL related messages for my crawler at https://github.com/JamesRead5737/webcrawler ==371932== 3,416 bytes in 61 blocks are still reachable in loss record 406 of 408 ==371932== at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==371932== by 0x49CF339: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CF5FD: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49D02B8: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49D0CEE: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CE5AE: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x55C347E: __pthread_once_slow (pthread_once.c:116) ==371932== by 0x49CE07D: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CF022: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CF10E: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x497D21B: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x497D41A: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== ==371932== 4,328 bytes in 1 blocks are still reachable in loss record 407 of 408 ==371932== at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==371932== by 0x49CD678: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CF1BB: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CF3C1: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CF5FD: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49D02B8: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49D0CEE: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CE5AE: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x55C347E: __pthread_once_slow (pthread_once.c:116) ==371932== by 0x49CE07D: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CF022: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CF10E: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== ==371932== 16,528 bytes in 1 blocks are possibly lost in loss record 408 of 408 ==371932== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==371932== by 0x49D46F7: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49E3199: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49D4CBB: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CD954: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CE5E1: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x55C347E: __pthread_once_slow (pthread_once.c:116) ==371932== by 0x49CE07D: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CF022: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x49CF10E: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x497D21B: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) ==371932== by 0x497D41A: ??? (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.21.1.20) I'm guessing I'm going to have to compile MySQL with -g flag in order to decipher this stuff? James Read |
|
From: David C. <dcc...@ac...> - 2020-06-05 03:01:31
|
On 6/4/2020 7:26 PM, James Read wrote: > Here is my valgrind output that I don't understand: > > ==319842== Invalid write of size 1 > ==319842== at 0x48436E4: mempcpy (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==319842== by 0x50CD1D8: _IO_default_xsputn (genops.c:386) > ==319842== by 0x50CD1D8: _IO_default_xsputn (genops.c:370) > ==319842== by 0x50B227B: __vfprintf_internal (vfprintf-internal.c:1688) > ==319842== by 0x50C0278: __vsprintf_internal (iovsprintf.c:95) > ==319842== by 0x509D047: sprintf (sprintf.c:30) > ==319842== by 0x10B88F: html_link_find (crawler.c:452) > ==319842== by 0x10BD6F: html_parse (crawler.c:536) > ==319842== by 0x10C2CB: check_multi_info (crawler.c:678) > ==319842== by 0x10C3DA: event_cb (crawler.c:706) > ==319842== by 0x10D828: crawler_init (crawler.c:1154) > ==319842== by 0x10DAE8: main (crawler.c:1207) > ==319842== Address 0xf107d18 is 0 bytes after a block of size 8,200 > alloc'd > ==319842== at 0x483B7F3: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==319842== by 0x10B736: html_link_find (crawler.c:440) > ==319842== by 0x10BD6F: html_parse (crawler.c:536) > ==319842== by 0x10C2CB: check_multi_info (crawler.c:678) > ==319842== by 0x10C3DA: event_cb (crawler.c:706) > ==319842== by 0x10D828: crawler_init (crawler.c:1154) > ==319842== by 0x10DAE8: main (crawler.c:1207) > ==319842== > > valgrind: m_mallocfree.c:305 (get_bszB_as_is): Assertion 'bszB_lo == > bszB_hi' failed. > valgrind: Heap block lo/hi size mismatch: lo = 8272, hi = > 3625731377157460067. > This is probably caused by your program erroneously writing past the > end of a heap block and corrupting heap metadata. If you fix any > invalid writes reported by Memcheck, this assertion failure will > probably go away. Please try that before reporting this as a bug. > > The code this pertains to can be found at > https://github.com/JamesRead5737/webcrawler > > Any help in understanding what this error means would be greatly > appreciated. > > James Read > Line 452 of crawler.c (routine html_link_find()) is calling sprintf(), which is then writing past the end of an allocated buffer of 8200 bytes. My first guess is that you are not resizing the buffer enough to fit the text being written by sprintf(). Find out why this is occurring in html_link_find() (it should happen even when your code is not running under valgrind), fix it, then rerun valgrind. If your program is writing outside of buffers, it is possible that valgrind won't catch it and thus the assertion failure later. -- David Chapman dcc...@ac... Chapman Consulting -- San Jose, CA EDA Software Developer, Expert Witness www.chapman-consulting-sj.com 2018-2019 Chair, IEEE Consultants' Network of Silicon Valley |
|
From: Derrick M. <der...@gm...> - 2020-06-05 02:38:40
|
Oh sorry, you're trying to write 8201 bytes into an 8200 byte buffer. On Thu, Jun 4, 2020, 22:36 Derrick McKee <der...@gm...> wrote: > It looks like html_link_find is allocating a buffer of size 0, and then > you are trying to write 1 byte to it. > > On Thu, Jun 4, 2020, 22:28 James Read <jam...@gm...> wrote: > >> Here is my valgrind output that I don't understand: >> >> ==319842== Invalid write of size 1 >> ==319842== at 0x48436E4: mempcpy (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==319842== by 0x50CD1D8: _IO_default_xsputn (genops.c:386) >> ==319842== by 0x50CD1D8: _IO_default_xsputn (genops.c:370) >> ==319842== by 0x50B227B: __vfprintf_internal (vfprintf-internal.c:1688) >> ==319842== by 0x50C0278: __vsprintf_internal (iovsprintf.c:95) >> ==319842== by 0x509D047: sprintf (sprintf.c:30) >> ==319842== by 0x10B88F: html_link_find (crawler.c:452) >> ==319842== by 0x10BD6F: html_parse (crawler.c:536) >> ==319842== by 0x10C2CB: check_multi_info (crawler.c:678) >> ==319842== by 0x10C3DA: event_cb (crawler.c:706) >> ==319842== by 0x10D828: crawler_init (crawler.c:1154) >> ==319842== by 0x10DAE8: main (crawler.c:1207) >> ==319842== Address 0xf107d18 is 0 bytes after a block of size 8,200 >> alloc'd >> ==319842== at 0x483B7F3: malloc (in >> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==319842== by 0x10B736: html_link_find (crawler.c:440) >> ==319842== by 0x10BD6F: html_parse (crawler.c:536) >> ==319842== by 0x10C2CB: check_multi_info (crawler.c:678) >> ==319842== by 0x10C3DA: event_cb (crawler.c:706) >> ==319842== by 0x10D828: crawler_init (crawler.c:1154) >> ==319842== by 0x10DAE8: main (crawler.c:1207) >> ==319842== >> >> valgrind: m_mallocfree.c:305 (get_bszB_as_is): Assertion 'bszB_lo == >> bszB_hi' failed. >> valgrind: Heap block lo/hi size mismatch: lo = 8272, hi = >> 3625731377157460067. >> This is probably caused by your program erroneously writing past the >> end of a heap block and corrupting heap metadata. If you fix any >> invalid writes reported by Memcheck, this assertion failure will >> probably go away. Please try that before reporting this as a bug. >> >> The code this pertains to can be found at >> https://github.com/JamesRead5737/webcrawler >> >> Any help in understanding what this error means would be greatly >> appreciated. >> >> James Read >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > |
|
From: Derrick M. <der...@gm...> - 2020-06-05 02:37:06
|
It looks like html_link_find is allocating a buffer of size 0, and then you are trying to write 1 byte to it. On Thu, Jun 4, 2020, 22:28 James Read <jam...@gm...> wrote: > Here is my valgrind output that I don't understand: > > ==319842== Invalid write of size 1 > ==319842== at 0x48436E4: mempcpy (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==319842== by 0x50CD1D8: _IO_default_xsputn (genops.c:386) > ==319842== by 0x50CD1D8: _IO_default_xsputn (genops.c:370) > ==319842== by 0x50B227B: __vfprintf_internal (vfprintf-internal.c:1688) > ==319842== by 0x50C0278: __vsprintf_internal (iovsprintf.c:95) > ==319842== by 0x509D047: sprintf (sprintf.c:30) > ==319842== by 0x10B88F: html_link_find (crawler.c:452) > ==319842== by 0x10BD6F: html_parse (crawler.c:536) > ==319842== by 0x10C2CB: check_multi_info (crawler.c:678) > ==319842== by 0x10C3DA: event_cb (crawler.c:706) > ==319842== by 0x10D828: crawler_init (crawler.c:1154) > ==319842== by 0x10DAE8: main (crawler.c:1207) > ==319842== Address 0xf107d18 is 0 bytes after a block of size 8,200 > alloc'd > ==319842== at 0x483B7F3: malloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==319842== by 0x10B736: html_link_find (crawler.c:440) > ==319842== by 0x10BD6F: html_parse (crawler.c:536) > ==319842== by 0x10C2CB: check_multi_info (crawler.c:678) > ==319842== by 0x10C3DA: event_cb (crawler.c:706) > ==319842== by 0x10D828: crawler_init (crawler.c:1154) > ==319842== by 0x10DAE8: main (crawler.c:1207) > ==319842== > > valgrind: m_mallocfree.c:305 (get_bszB_as_is): Assertion 'bszB_lo == > bszB_hi' failed. > valgrind: Heap block lo/hi size mismatch: lo = 8272, hi = > 3625731377157460067. > This is probably caused by your program erroneously writing past the > end of a heap block and corrupting heap metadata. If you fix any > invalid writes reported by Memcheck, this assertion failure will > probably go away. Please try that before reporting this as a bug. > > The code this pertains to can be found at > https://github.com/JamesRead5737/webcrawler > > Any help in understanding what this error means would be greatly > appreciated. > > James Read > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: James R. <jam...@gm...> - 2020-06-05 02:26:52
|
Here is my valgrind output that I don't understand: ==319842== Invalid write of size 1 ==319842== at 0x48436E4: mempcpy (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==319842== by 0x50CD1D8: _IO_default_xsputn (genops.c:386) ==319842== by 0x50CD1D8: _IO_default_xsputn (genops.c:370) ==319842== by 0x50B227B: __vfprintf_internal (vfprintf-internal.c:1688) ==319842== by 0x50C0278: __vsprintf_internal (iovsprintf.c:95) ==319842== by 0x509D047: sprintf (sprintf.c:30) ==319842== by 0x10B88F: html_link_find (crawler.c:452) ==319842== by 0x10BD6F: html_parse (crawler.c:536) ==319842== by 0x10C2CB: check_multi_info (crawler.c:678) ==319842== by 0x10C3DA: event_cb (crawler.c:706) ==319842== by 0x10D828: crawler_init (crawler.c:1154) ==319842== by 0x10DAE8: main (crawler.c:1207) ==319842== Address 0xf107d18 is 0 bytes after a block of size 8,200 alloc'd ==319842== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==319842== by 0x10B736: html_link_find (crawler.c:440) ==319842== by 0x10BD6F: html_parse (crawler.c:536) ==319842== by 0x10C2CB: check_multi_info (crawler.c:678) ==319842== by 0x10C3DA: event_cb (crawler.c:706) ==319842== by 0x10D828: crawler_init (crawler.c:1154) ==319842== by 0x10DAE8: main (crawler.c:1207) ==319842== valgrind: m_mallocfree.c:305 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. valgrind: Heap block lo/hi size mismatch: lo = 8272, hi = 3625731377157460067. This is probably caused by your program erroneously writing past the end of a heap block and corrupting heap metadata. If you fix any invalid writes reported by Memcheck, this assertion failure will probably go away. Please try that before reporting this as a bug. The code this pertains to can be found at https://github.com/JamesRead5737/webcrawler Any help in understanding what this error means would be greatly appreciated. James Read |
|
From: John R. <jr...@bi...> - 2020-05-27 21:26:56
|
On 5/27/20 Paul FLOYD wrote: > Well, no real surprises. This is with a testcase that runs standalone in about 5 seconds and under DHAT in about 200 seconds (so a reasonable slowdown of 40x). > > # Overhead Command Shared Object > Symbol > # ........ ............... .................. ................................................................................................................................................................................................................ > # > 29.11% dhat-amd64-linu dhat-amd64-linux [.] interval_tree_Cmp > 21.13% dhat-amd64-linu perf-26905.map [.] 0x00000010057a25f8 > 13.32% dhat-amd64-linu dhat-amd64-linux [.] vgPlain_lookupFM > 9.56% dhat-amd64-linu dhat-amd64-linux [.] dh_handle_read > 8.83% dhat-amd64-linu dhat-amd64-linux [.] vgPlain_nextIterFM > 4.66% dhat-amd64-linu dhat-amd64-linux [.] check_for_peak > 1.85% dhat-amd64-linu dhat-amd64-linux [.] vgPlain_disp_cp_xindir > 1.32% dhat-amd64-linu [kernel.kallsyms] [k] 0xffffffff8103ec0a > 1.00% dhat-amd64-linu dhat-amd64-linux [.] dh_handle_write To me this suggests two things: 1) investigate the coding of the 4 or 5 highest-use subroutines (interval_tree_Cmp, vgPlain_lookupFM, dh_handle_read, vgPlain_nextIterFM) 2) see whether DHAT might recognize and use higher-level abstractions than MemoryRead and MemoryWrite of individual addresses. Similar to memcheck intercepting and analyzing strlen (etc.) as a complete concept instead of as its individual Reads and Writes, perhaps DHAT could intercept (and/or recognize) vector linear search, vector addition, vector partial sum, other BLAS routines, etc., and then analyze the algorithm as a whole. |
|
From: Paul F. <pj...@wa...> - 2020-05-27 20:33:30
|
[snip - perf]
Well, no real surprises. This is with a testcase that runs standalone in about 5 seconds and under DHAT in about 200 seconds (so a reasonable slowdown of 40x).
# Overhead Command Shared Object
Symbol
# ........ ............... .................. ................................................................................................................................................................................................................
#
29.11% dhat-amd64-linu dhat-amd64-linux [.] interval_tree_Cmp
21.13% dhat-amd64-linu perf-26905.map [.] 0x00000010057a25f8
13.32% dhat-amd64-linu dhat-amd64-linux [.] vgPlain_lookupFM
9.56% dhat-amd64-linu dhat-amd64-linux [.] dh_handle_read
8.83% dhat-amd64-linu dhat-amd64-linux [.] vgPlain_nextIterFM
4.66% dhat-amd64-linu dhat-amd64-linux [.] check_for_peak
1.85% dhat-amd64-linu dhat-amd64-linux [.] vgPlain_disp_cp_xindir
1.32% dhat-amd64-linu [kernel.kallsyms] [k] 0xffffffff8103ec0a
1.00% dhat-amd64-linu dhat-amd64-linux [.] dh_handle_write
A+
Paul
|
|
From: John R. <jr...@bi...> - 2020-05-26 16:29:11
|
> > So (4 * 5 * 10 * 3) is a slowdown of 600X, which turns 10 minutes into 100 hours.
>
> What I'm seeing is a DHAT-only slowdown that is much more than that.
Running 'perf' is likely to give data and strong hints about what is going on.
The overhead of 'perf' is only a few percent.
perf record valgrind --tool=DHAT <<valgrind_args>> ./my_app <<my_app_args>>
perf report > perf_output.txt
The "perf record ..." will stop shortly after the valgrind sub-process terminates.
You don't have to wait for DHAT to finish; just 'kill' it after a while.
|
188 messages has been excluded from this view by a project administrator.
