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
(9) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: André O. <off...@gm...> - 2019-03-11 21:57:30
|
Hi all,
I'm struggling with a helgrind error that I don't understand. I've
stripped the code to a minimal example that shows the issue and pasted
the code below. As far as I can tell, the code should be thread safe,
and I've looked at the gcc assembly output, and I can't see anything
wrong with it so, so far I don't suspect it is a gcc error (but I'm not
certain).
The helgrind error only appears when I compile with -O0, -O1 or -O2, not
with -O3. Also, when I call "get_int_no_warning" instead of "get_int",
no helgrind errors are reported.
Would anybody be able to tell me if this is a helgrind false positive?
I compile with gcc (Debian 8.3.0-2) 8.3.0 and am using valgrind-3.14.0
from Debian testing.
(the weird method is used in a codebase to create an instance of an
object that is never destructed but isn't reported as leaked memory
either -- it's a hack around some static initialization order problems).
Source code:
#include <new>
#include <iostream>
#include <vector>
#include <thread>
#include <memory>
int* get_int()
{
static std::aligned_storage_t<sizeof(int), alignof(int)> storage;
// The following line is pointed out in a helgrind warning:
// "Possible data race during read of size 8..."
// When using -O2, this conflicts with a previous write of size 8,
also at this line...
static int* ptr = new (reinterpret_cast<int*>(&storage)) int();
return ptr; // But with -O0, the previous line conflicts with this
return statement.
}
int* get_int_no_warning()
{
static int x = 0;
return &x;
}
void test()
{
volatile int* a = get_int();
}
int main()
{
std::thread a(test), b(test);
a.join();
b.join();
}
Thanks,
André
|
|
From: Austin E. <aus...@gm...> - 2019-03-11 15:27:37
|
On Mon, Mar 11, 2019 at 4:03 PM Julian Seward <js...@ac...> wrote: > n-i-bz Improve PDB reading ? I thought I saw some patches for this .. > is it 253657 ? Who can help test this? > I saw the patch, but haven't had a good opportunity to test (currently traveling). If me testing it will help it get in, I can probably make time this week or next (I normally valgrind win32, not win64, so may need some time to test win64 first). -- -Austin GPG: 267B CC1F 053F 0749 (expires 2021/02/18) |
|
From: Ivo R. <iv...@iv...> - 2019-03-11 15:26:38
|
> One thing that I'd like to ask at this point is: what level of support for > Solaris should we say there is, in the release announcement? Now that we > unfortunately no longer have a Solaris maintainer, I am concerned that could > wind up shipping a non-working Solaris port. A similar question goes for the > Mac OSX port, although there at least we have a maintainer. Hi Julian, I am no longer in a position to do any serious Solaris maintenance. I don't have resources and access to Solaris source code which is necessary to get a deep understanding of the underlying problems. One manifestation is a message received yesterday: it seems that new Solaris 11.4 does things differently than 11.3 did, at least in debug info area. Another manifestation is a lack of bugs opened against Solaris support in Valgrind in the past year ;-) So it would be fair to say that Solaris port is supported on a voluntary effort basis in general and Valgrind on Solaris 11.4 has not been tested. Anyway, future of Solaris is quite murky [1] (search for "11.4"). I'd like to hear of any (prospective) maintainers from illumos community as well [2]. Kind regards, Ivosh [1] https://en.wikipedia.org/wiki/Solaris_(operating_system) [2] https://illumos.topicbox.com/groups/discuss/T5f2d86b0b56e6f31-Mcede5f51be0764230a7f7310/illumos-valgrind-maintainer-needed |
|
From: Julian S. <js...@ac...> - 2019-03-11 15:03:22
|
> I'll shortly send a second message listing the bugs I think are a priority.
Please feel free to disagree and/or add other bugs. This is only my personal
prioritisation.
J
Higher prio (really should fix for 3.15.0)
404843 s390x: backtrace sometimes ends prematurely
405182 Valgrind fails to build with Clang
398183 (amd64) Vex errors with _mm256_shuffle_epi8/vpshufb
Potentially serious?
399287 (amd64) Illegal Instruction vcmptrueps
404272 vex amd64->IR: 0x66 0xF 0x38 0x23 0xC0 0xF3 (PMOVSXWD)
Should fix
400099 Memcheck produces truncated backtrace when len(argv + env) = 4096
Possible stack overrun problem; should investigate
n-i-bz (amd64) Support RDRAND/RDSEED ? We really should.
Medium prio (would be nice to fix for 3.15.0)
399355 Add callgrind_diff
400793 pthread_rwlock_timedwrlock false positive
Probably would be easy to fix, but requires testing
401284 False positive "Source and destination overlap in strncat"
possibly valid; possible off-by-one error in overlap checking?
405201 Incorrect size of struct vki_siginfo on 64-bit Linux architectures
400162 Patch: Guard against __GLIBC_PREREQ for musl libc
Looks like simple fix; should take
398870 (amd64) Please add support for instruction vcvtps2ph
400538 vex amd64->IR: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55
Should fix (Wine/Windows)
401719 (x86) sterrror_r on i686 causes a GPF
32-bit segreg problem; maybe we should fix?
n-i-bz (amd64) Support RDPMC ?
n-i-bz Improve PDB reading ? I thought I saw some patches for this ..
is it 253657 ? Who can help test this?
|
|
From: Julian S. <js...@ac...> - 2019-03-11 14:53:31
|
Greetings all. I'd like to propose a 3.15.0 release in just under a month from now, on 5 April. The last release, 3.14.0, was on 9 Oct 2018. In the past few years we've released pretty much once a year. That has the undesirable effect of making fixes and new features available only after a long wait. By contrast, making a release in early April means only a six-month interval, and would get useful changes to users and distro packagers sooner rather than later. Primarily these: * Support for Gcc 9. * Overhaul of the DHAT heap-usage profiler, including addition of a GUI. * Reduced Memcheck false-positive rates on amd64 (x86_64) and ppc64 targets. * Much improved s390x z13 support. * Reduced overhead for handling indirect branches in very large applications. * The usual stack of bug fixes. I've made a first pass through all bugs reported since 3.14.0. The results are in docs/internals/3_14_BUGSTATUS.txt. If there are any bugs in there (or even, not in there) that you think are important to fix for the release, please do mention them. I'll shortly send a second message listing the bugs I think are a priority. One thing that I'd like to ask at this point is: what level of support for Solaris should we say there is, in the release announcement? Now that we unfortunately no longer have a Solaris maintainer, I am concerned that could wind up shipping a non-working Solaris port. A similar question goes for the Mac OSX port, although there at least we have a maintainer. J |
|
From: Ivo R. <iv...@iv...> - 2019-03-11 13:25:14
|
You should not need to build 32-bit Valgrind explicitly. By default Valgrind on newer Solaris should handle both 32-bit and 64-bit programs; but see README.solaris for caveats. You did not specify Solaris version (pkg info entire) so it is hard to say where you are. Note that Solaris 11.1 and 11.2 are quite old now. You need to compile Valgrind from sources (http://valgrind.org/downloads/repository.html) and see if the problem still persists. If it does, try to do something along these lines and analyze+report the output: $ dwarfdump -i /lib/ld.so.1 -or- $ readelf --debug-dump=info /lib/ld.so.1 Also try to invoke Valgrind with "--read-var-info=yes" to see if this triggers the problem. As per "how do I fix this": 1. Analyze and understand the problem. 2. Decide cons and pros of possible solutions. 3. Implement the fix. I. Il giorno dom 10 mar 2019 alle ore 08:48 sandeep bhardwaj <san...@gm...> ha scritto: > > I built 32 bit valgrind on Solaris x86 machine. > > Valgrind version : 3.14. > gcc version : 7.3.0 > > I ran configure script as below > > ./configure CC='cc -m32' CXX='CC -m32' > > I removed xpg symbols from vgpreload-solaris.mapfile as i was getting errors while building. > > I am getting the below error while running valgrind. How do i fix this?? > > root@*******:/tmp# valgrind ./test > ==7869== Memcheck, a memory error detector > ==7869== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==7869== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info > ==7869== Command: ./test > ==7869== > --7869-- WARNING: Serious error when reading debug info > --7869-- When reading debug info from /lib/ld.so.1: > --7869-- Can't make sense of .data section mapping > ==7869== Conditional jump or move depends on uninitialised value(s) > ==7869== at 0x4FFD94C5: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBFCF7: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB0A6B: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFC031D: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBDB95: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBEA19: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) > ==7869== by 0x57FEFD6E: ??? > ==7869== > ==7869== Conditional jump or move depends on uninitialised value(s) > ==7869== at 0x4FFD9469: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB3B54: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB474F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBDD4D: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBF1D6: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) > ==7869== by 0x57FEFD6E: ??? > ==7869== > ==7869== Conditional jump or move depends on uninitialised value(s) > ==7869== at 0x4FFD9497: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB3B54: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB474F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBDD4D: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBF1D6: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) > ==7869== by 0x57FEFD6E: ??? > ==7869== > ==7869== Conditional jump or move depends on uninitialised value(s) > ==7869== at 0x4FFD94C5: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB3C87: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB3E3B: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB48E2: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB7462: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB21D8: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBF22A: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) > ==7869== > ==7869== Conditional jump or move depends on uninitialised value(s) > ==7869== at 0x4FFD940D: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBFCF7: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB0A6B: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFC031D: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBD27E: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBD86B: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB781B: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB81BB: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB88BC: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB5C36: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB5FD9: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB62C5: ??? (in /lib/ld.so.1) > ==7869== > ==7869== > ==7869== HEAP SUMMARY: > ==7869== in use at exit: 0 bytes in 0 blocks > ==7869== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > > > Thanks & Regards, > Sandeep > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: sandeep b. <san...@gm...> - 2019-03-10 08:10:38
|
I built 32 bit valgrind on Solaris x86 machine. Valgrind version : 3.14. gcc version : 7.3.0 OS version: 5.11 11.4.0.15.0 I ran configure script as below ./configure CC='gcc -m32' CXX='gcc -m32' I removed xpg symbols from vgpreload-solaris.mapfile as i was getting errors while building. I am getting the below error while running valgrind. How do i fix this?? root@*******:/tmp# valgrind ./test ==7869== Memcheck, a memory error detector ==7869== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7869== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==7869== Command: ./test ==7869== *--7869-- WARNING: Serious error when reading debug info--7869-- When reading debug info from /lib/ld.so.1:--7869-- Can't make sense of .data section mapping* ==7869== Conditional jump or move depends on uninitialised value(s) ==7869== at 0x4FFD94C5: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBFCF7: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB0A6B: ??? (in /lib/ld.so.1) ==7869== by 0x4FFC031D: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBDB95: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBEA19: ??? (in /lib/ld.so.1) ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) ==7869== by 0x57FEFD6E: ??? ==7869== ==7869== Conditional jump or move depends on uninitialised value(s) ==7869== at 0x4FFD9469: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB3B54: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB474F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBDD4D: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBF1D6: ??? (in /lib/ld.so.1) ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) ==7869== by 0x57FEFD6E: ??? ==7869== ==7869== Conditional jump or move depends on uninitialised value(s) ==7869== at 0x4FFD9497: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB3B54: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB474F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBDD4D: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBF1D6: ??? (in /lib/ld.so.1) ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) ==7869== by 0x57FEFD6E: ??? ==7869== ==7869== Conditional jump or move depends on uninitialised value(s) ==7869== at 0x4FFD94C5: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB3C87: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB3E3B: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB48E2: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB7462: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB21D8: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBF22A: ??? (in /lib/ld.so.1) ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) ==7869== ==7869== Conditional jump or move depends on uninitialised value(s) ==7869== at 0x4FFD940D: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBFCF7: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB0A6B: ??? (in /lib/ld.so.1) ==7869== by 0x4FFC031D: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBD27E: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBD86B: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB781B: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB81BB: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB88BC: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB5C36: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB5FD9: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB62C5: ??? (in /lib/ld.so.1) ==7869== ==7869== ==7869== HEAP SUMMARY: ==7869== in use at exit: 0 bytes in 0 blocks ==7869== total heap usage: 0 allocs, 0 frees, 0 bytes allocated Thanks & Regards, Sandeep |
|
From: sandeep b. <san...@gm...> - 2019-03-10 08:08:53
|
Correction from my previous mail.. I ran the configure script like below. ./configure CC='gcc -m32' CXX='g++ -m32' On Sun, Mar 10, 2019 at 1:17 PM sandeep bhardwaj <san...@gm...> wrote: > I built 32 bit valgrind on Solaris x86 machine. > > Valgrind version : 3.14. > gcc version : 7.3.0 > > I ran configure script as below > > ./configure CC='cc -m32' CXX='CC -m32' > > I removed xpg symbols from vgpreload-solaris.mapfile as i was getting > errors while building. > > I am getting the below error while running valgrind. How do i fix this?? > > root@*******:/tmp# valgrind ./test > ==7869== Memcheck, a memory error detector > ==7869== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==7869== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info > ==7869== Command: ./test > ==7869== > > > *--7869-- WARNING: Serious error when reading debug info--7869-- When > reading debug info from /lib/ld.so.1:--7869-- Can't make sense of .data > section mapping* > ==7869== Conditional jump or move depends on uninitialised value(s) > ==7869== at 0x4FFD94C5: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBFCF7: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB0A6B: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFC031D: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBDB95: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBEA19: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) > ==7869== by 0x57FEFD6E: ??? > ==7869== > ==7869== Conditional jump or move depends on uninitialised value(s) > ==7869== at 0x4FFD9469: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB3B54: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB474F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBDD4D: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBF1D6: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) > ==7869== by 0x57FEFD6E: ??? > ==7869== > ==7869== Conditional jump or move depends on uninitialised value(s) > ==7869== at 0x4FFD9497: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB3B54: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB474F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBDD4D: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBF1D6: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) > ==7869== by 0x57FEFD6E: ??? > ==7869== > ==7869== Conditional jump or move depends on uninitialised value(s) > ==7869== at 0x4FFD94C5: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB3C87: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB3E3B: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB48E2: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB7462: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB21D8: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBF22A: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) > ==7869== > ==7869== Conditional jump or move depends on uninitialised value(s) > ==7869== at 0x4FFD940D: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBFCF7: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB0A6B: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFC031D: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBD27E: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFBD86B: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB781B: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB81BB: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB88BC: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB5C36: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB5FD9: ??? (in /lib/ld.so.1) > ==7869== by 0x4FFB62C5: ??? (in /lib/ld.so.1) > ==7869== > ==7869== > ==7869== HEAP SUMMARY: > ==7869== in use at exit: 0 bytes in 0 blocks > ==7869== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > > > Thanks & Regards, > Sandeep > |
|
From: sandeep b. <san...@gm...> - 2019-03-10 07:47:30
|
I built 32 bit valgrind on Solaris x86 machine. Valgrind version : 3.14. gcc version : 7.3.0 I ran configure script as below ./configure CC='cc -m32' CXX='CC -m32' I removed xpg symbols from vgpreload-solaris.mapfile as i was getting errors while building. I am getting the below error while running valgrind. How do i fix this?? root@*******:/tmp# valgrind ./test ==7869== Memcheck, a memory error detector ==7869== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7869== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==7869== Command: ./test ==7869== *--7869-- WARNING: Serious error when reading debug info--7869-- When reading debug info from /lib/ld.so.1:--7869-- Can't make sense of .data section mapping* ==7869== Conditional jump or move depends on uninitialised value(s) ==7869== at 0x4FFD94C5: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBFCF7: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB0A6B: ??? (in /lib/ld.so.1) ==7869== by 0x4FFC031D: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBDB95: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBEA19: ??? (in /lib/ld.so.1) ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) ==7869== by 0x57FEFD6E: ??? ==7869== ==7869== Conditional jump or move depends on uninitialised value(s) ==7869== at 0x4FFD9469: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB3B54: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB474F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBDD4D: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBF1D6: ??? (in /lib/ld.so.1) ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) ==7869== by 0x57FEFD6E: ??? ==7869== ==7869== Conditional jump or move depends on uninitialised value(s) ==7869== at 0x4FFD9497: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB3B54: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB474F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBDD4D: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBF1D6: ??? (in /lib/ld.so.1) ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) ==7869== by 0x57FEFD6E: ??? ==7869== ==7869== Conditional jump or move depends on uninitialised value(s) ==7869== at 0x4FFD94C5: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB36BD: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB3C87: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB3E3B: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB48E2: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB5185: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB54ED: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB7462: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB21D8: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBF22A: ??? (in /lib/ld.so.1) ==7869== by 0x4FFD1C3F: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB1E5E: ??? (in /lib/ld.so.1) ==7869== ==7869== Conditional jump or move depends on uninitialised value(s) ==7869== at 0x4FFD940D: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBFCF7: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB0A6B: ??? (in /lib/ld.so.1) ==7869== by 0x4FFC031D: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBD27E: ??? (in /lib/ld.so.1) ==7869== by 0x4FFBD86B: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB781B: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB81BB: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB88BC: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB5C36: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB5FD9: ??? (in /lib/ld.so.1) ==7869== by 0x4FFB62C5: ??? (in /lib/ld.so.1) ==7869== ==7869== ==7869== HEAP SUMMARY: ==7869== in use at exit: 0 bytes in 0 blocks ==7869== total heap usage: 0 allocs, 0 frees, 0 bytes allocated Thanks & Regards, Sandeep |
|
From: John R. <jr...@bi...> - 2019-03-07 04:44:40
|
> Where is the location of Bzip2 nowadays? In practice: download the source to the .rpm package (Fedora, Red Hat, SuSE) or the .deb package (Debian, etc.). Within that is the original source used by maintainers of the .rpm or .deb. For instance on Fedora: $ dnf download --source bzip2 bzip2-1.0.6-26.fc28.src.rpm 548 kB/s | 785 kB 00:01 $ rpm -ql -p bzip2-1.0.6-26.fc28.src.rpm bzip2-1.0.4-bzip2recover.patch bzip2-1.0.4-cflags.patch bzip2-1.0.4-saneso.patch bzip2-1.0.6.tar.gz <<<<< the original source bzip2-ldflags.patch bzip2.pc bzip2.spec set-out-file-to-null.patch $ rpm --install bzip2-1.0.6-26.fc28.src.rpm $ ls -l rpmbuild/SOURCES/bzip2-1.0.6.tar.gz -rw-rw-r--. 1 user group 782025 Sep 22 2010 rpmbuild/SOURCES/bzip2-1.0.6.tar.gz $ |
|
From: Jeffrey W. <nol...@gm...> - 2019-03-07 00:50:06
|
Hi Everyone, Forgive my ignorance... There's a Wordpress blog on bzip2 at http://www.bzip.org/ . The page says to download from Sourceforge at https://sourceforge.net/projects/bzip2/ . Sourceforge is a mess and all of this looks very fishy. I doubt anyone would put a project there now. Sourceforge has tampered with projects in the past, and they force people to accept their spam when trying to signup for a mailing list (you cannot opt-out of "I agree to receive these communications from SourceForge.net"). Has Seward done anything since losing the bzip2 domain? Where is the location of Bzip2 nowadays? Sorry to ask here. I understand Seward is part of Valgrind, and hope he may field a message instead of leaving everyone in the dark. Jeff |
|
From: Martin B. <mar...@tu...> - 2019-03-06 13:55:04
|
Hi Mohsen, If by 'main memory' you mean RAM usage in total as opposed to heap or stack), then this valgrind plugin might help: https://github.com/mbeckersys/valgrind-ws It can separate between instruction and data, gives you the number number of accessed pages, both over time and in total. Otherwise, for heap and stack you can use valgrind's massif. Regards, Martin On 06.03.19 14:13, Mohsen Pahlevanzadeh wrote: > Dear all, > > > > I need to find out size of my program main memory. How can I do it with > valgrind? > > > --regards > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Mohsen P. <mo...@pa...> - 2019-03-06 13:29:05
|
Dear all, I need to find out size of my program main memory. How can I do it with valgrind? --regards |
|
From: Vikram G. <vik...@gm...> - 2019-03-01 17:19:02
|
Hello,
I am trying to profile Petsc memory usage with massif, but
have been getting absurdly low values.
I have valgrind-devel installed, and compiled PETSc with both valgrind
and debugging options set to 1. I then compiled my executable which
has PETSc as a dependent library.
I ran valgrind with the following command: valgrind
--trace-children=yes --tool=massif --massif-out-file=<outfile>
<executable>
However, the output from valgrind in terms of total memory usage is
absurdly low (612 kb) and remains the same whether I compiled PetSc with or
without valgrind.
KB
612.0^ :
| #############::::::::::::::::::::::::::
| # : : ::
| # : : ::
| # : : ::
| # : : ::
| # : : ::
| # : : ::
| # : : ::
| # : : ::
| # : : ::
| # : : ::
| # : : ::
| # : : ::
| # : : ::
| # : : :::
| # : : :::
| @# : : :::
| @@# : : :::
| @@:::@:@::@@@@# : : :::
0 +----------------------------------------------------------------------->Mi
0 1.474
I suspect that valgrind is not actually able to get PETSc's memory
usage. Any ideas on how to get valgrind to give me the actual memory
consumed by PETSc would be helpful.
Thanks.
Vikram Garg
vikramvgarg.github.io/
|
|
From: Wuweijia <wuw...@hu...> - 2019-02-23 00:58:47
|
Hi:
Is there any plan for the implementation of AArch64 8.2A new instruction?
BR
Owen
发件人: Wuweijia
发送时间: 2019年2月14日 11:50
收件人: 'val...@li...' <val...@li...>
抄送: Fanbohao <fan...@hu...>
主题: [HELP] there is some unknown aarch64 fp16 instruction for valgrind 3.13 3.14
The source as below:
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <arm_neon.h>
int process(){
__fp16* zcb_hal16 = (__fp16*)malloc(100);
zcb_hal16[0] = 0;
float16x8_t vblkA0, vblkB0, vblkC0;
vblkC0 = vfmaq_n_f16(vblkC0, vblkB0, vblkA0[0]);
__asm __volatile("fmla %[c0].8h, %[b0].8h, %[a0].h[0]" : [c0] "+w"(vblkC0) : [b0] "w"(vblkB0), [a0] "w"(vblkA0));
return 0;
}
int main()
{
printf("start...\n");
process();
printf("ok...\n");
return 0;
}
The compile tool: clang 6
The compile args: clang ./test.cpp
The output as below:
localhost:~/workspace/neonfp16_test/jni # valgrind ./a.out
==9762== Memcheck, a memory error detector
==9762== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9762== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==9762== Command: ./a.out
==9762==
start...
disInstr(arm64): unhandled instruction 0x1EE703E0
disInstr(arm64): 0001'1110 1110'0111 0000'0011 1110'0000
==9762== valgrind: Unrecognised instruction at address 0x4005f8.
==9762== at 0x4005F8: process() (in /root/workspace/neonfp16_test/jni/a.out)
==9762== by 0x4006C7: main (in /root/workspace/neonfp16_test/jni/a.out)
|
|
From: aotto <aot...@t-...> - 2019-02-21 17:23:41
|
Hi, this is my first post to "val...@li..."… Hello!! I have a suggestion for improvement of the "--suppressions" feature… background: 1. I write a C-library to extend programming-languages like java, tcl, csharp etc… 2. for "memory debugging" and "leakcheck" I use "valgrind" 3. I'm only interested in information about MY library and NOT about everything related to the "programming-language-interpreter" and now my suggestion: it is possible to generate "--negative-suppressions" ? 1. A "negative-suppression" is a suppression pattern which should be NOT ignored 2. by DEFAULT everything should be IGNORED accept the "negative-suppressions" 3. I would define a "searchable" pattern for my "function" and "file-names" so that "valgrind" is able to identify MY information of interest. thanks. |
|
From: John R. <jr...@bi...> - 2019-02-19 02:54:07
|
>> The execution recipe works for me on Fedora 28 using valgrind-3.14.0-7.fc28.x86_64. > Also, the default on Mac is to use addresses greater than (1ul<<32). Because the program works when _not_ run under valgrind, then the conclusion is that valgrind-3.14.0-7 has a bug where it stores an address in 32 bits. To find the bug in valgrind: invoke a debug version of valgrind-3.14 under lldb on Mac, and then invoke main.l.exe under that valgrind. The SIGSEGV should happen inside valgrind itself, so use lldb to find the bug. |
|
From: John R. <jr...@bi...> - 2019-02-19 02:18:31
|
> The execution recipe works for me on Fedora 28 using valgrind-3.14.0-7.fc28.x86_64. > I omitted dsymutil. Why is it essential for you? > > > It is not essential. Therefore omitting dsymutil will narrow the search for the problem(s). > $ rpm -q clang > clang-6.0.1-2.fc28.x86_64 > Why there is no segmentation fault in your run? What version of clang? I showed that I used clang-6.0.1-2.fc28.x86_64. Also, the default on Mac is to use addresses greater than (1ul<<32). This catches some errors of storing an address in a 32-bit variable. The default on Fedora is to start using addresses at 4MiB, which saves 4 bytes of space in several important places, but in many cases avoids noticing the problem of storing an address in 32 bits. |
|
From: Peng Yu <pen...@gm...> - 2019-02-19 01:29:21
|
On Mon, Feb 18, 2019 at 7:07 PM John Reiser <jr...@bi...> wrote: > On 2/17/19, Peng Yu wrote: > > $ flex -o main.l.c main.l > > $ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c # > > rapidstring.h is in . > > $ clang main.l.o -lgc -lfl -o main.l.exe > > $ dsymutil main.l.exe > > What is 'dsymutil', where did you get it, what version? > What is the hardware architecture? That is just the command on Mac to generate the debug symbols. > > > The execution recipe works for me on Fedora 28 using > valgrind-3.14.0-7.fc28.x86_64. > I omitted dsymutil. Why is it essential for you? It is not essential. > > > $ ldd main.l.exe > linux-vdso.so.1 (0x00007fffa7d9f000) > libgc.so.1 => /lib64/libgc.so.1 (0x00007f255ef81000) > libc.so.6 => /lib64/libc.so.6 (0x00007f255ebc2000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f255e9a3000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f255e79f000) > libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 > (0x00007f255e59c000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f255e384000) > /lib64/ld-linux-x86-64.so.2 (0x00007f255f2de000) > > $ rpm -qf /lib64/libgc.so.1 > gc-7.6.4-3.fc28.x86_64 > $ rpm -qf /usr/bin/flex > flex-2.6.1-7.fc28.x86_64 > $ rpm -q clang > clang-6.0.1-2.fc28.x86_64 Why there is no segmentation fault in your run? > > > $ valgrind ./main.l.exe <input.txt > ==23299== Memcheck, a memory error detector > ==23299== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==23299== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright > info > ==23299== Command: ./main.l.exe > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299== at 0x4E4D166: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299== at 0x4E4D16B: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299== at 0x4E4CF57: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299== at 0x4E4CF66: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299== at 0x4E4CF9A: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299== at 0x4E491AA: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299== at 0x4E491B9: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299== at 0x4E491E7: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299== at 0x4E44733: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299== at 0x4E4D166: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299== at 0x4E4D16B: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299== at 0x4E4CF57: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299== at 0x4E4CF66: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299== at 0x4E4CF9A: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299== at 0x4E491AA: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299== at 0x4E491B9: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299== at 0x4E491E7: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299== at 0x4E44733: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299== by 0x403203: main (main.l:34) > ==23299== > tok = 1000, yylval= 1 > tok = 1001, yylval= a > tok = 1000, yylval= 23 > tok = 1001, yylval= b > tok = 1000, yylval= 456 > tok = 1001, yylval= c > ==23299== > ==23299== HEAP SUMMARY: > ==23299== in use at exit: 864 bytes in 3 blocks > ==23299== total heap usage: 14 allocs, 11 frees, 24,562 bytes allocated > ==23299== > ==23299== LEAK SUMMARY: > ==23299== definitely lost: 0 bytes in 0 blocks > ==23299== indirectly lost: 0 bytes in 0 blocks > ==23299== possibly lost: 864 bytes in 3 blocks > ==23299== still reachable: 0 bytes in 0 blocks > ==23299== suppressed: 0 bytes in 0 blocks > ==23299== Rerun with --leak-check=full to see details of leaked memory > ==23299== > ==23299== For counts of detected and suppressed errors, rerun with: -v > ==23299== Use --track-origins=yes to see where uninitialised values come > from > ==23299== ERROR SUMMARY: 390 errors from 18 contexts (suppressed: 0 from 0) > $ > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Regards, Peng |
|
From: John R. <jr...@bi...> - 2019-02-19 01:19:34
|
> ==23299== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==23299== Command: ./main.l.exe
> ==23299==
> ==23299== Conditional jump or move depends on uninitialised value(s)
> ==23299== at 0x4E4D166: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2)
> ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2)
> ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2)
> ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2)
> ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2)
> ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2)
> ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2)
> ==23299== by 0x403203: main (main.l:34)
After
$ sudo dnf debuginfo-install /usr/lib64/libgc.so.1.3.2
then the messages look like:
==23530== Command: ./main.l.exe
==23530==
==23530== Conditional jump or move depends on uninitialised value(s)
==23530== at 0x4E4D166: GC_push_all_eager (mark.c:1583)
==23530== by 0x4E49D21: GC_with_callee_saves_pushed (mach_dep.c:322)
==23530== by 0x4E4E786: GC_push_regs_and_stack (mark_rts.c:772)
==23530== by 0x4E4E786: GC_push_roots (mark_rts.c:845)
==23530== by 0x4E4D896: GC_mark_some (mark.c:415)
==23530== by 0x4E42C44: GC_stopped_mark (alloc.c:702)
==23530== by 0x4E43348: GC_try_to_collect_inner (alloc.c:488)
==23530== by 0x4E5043B: GC_init (misc.c:1292)
==23530== by 0x403203: main (main.l:34)
|
|
From: John R. <jr...@bi...> - 2019-02-19 01:06:15
|
On 2/17/19, Peng Yu wrote: > $ flex -o main.l.c main.l > $ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c # > rapidstring.h is in . > $ clang main.l.o -lgc -lfl -o main.l.exe > $ dsymutil main.l.exe What is 'dsymutil', where did you get it, what version? What is the hardware architecture? The execution recipe works for me on Fedora 28 using valgrind-3.14.0-7.fc28.x86_64. I omitted dsymutil. Why is it essential for you? $ ldd main.l.exe linux-vdso.so.1 (0x00007fffa7d9f000) libgc.so.1 => /lib64/libgc.so.1 (0x00007f255ef81000) libc.so.6 => /lib64/libc.so.6 (0x00007f255ebc2000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f255e9a3000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f255e79f000) libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 (0x00007f255e59c000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f255e384000) /lib64/ld-linux-x86-64.so.2 (0x00007f255f2de000) $ rpm -qf /lib64/libgc.so.1 gc-7.6.4-3.fc28.x86_64 $ rpm -qf /usr/bin/flex flex-2.6.1-7.fc28.x86_64 $ rpm -q clang clang-6.0.1-2.fc28.x86_64 $ valgrind ./main.l.exe <input.txt ==23299== Memcheck, a memory error detector ==23299== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==23299== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==23299== Command: ./main.l.exe ==23299== ==23299== Conditional jump or move depends on uninitialised value(s) ==23299== at 0x4E4D166: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Conditional jump or move depends on uninitialised value(s) ==23299== at 0x4E4D16B: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Use of uninitialised value of size 8 ==23299== at 0x4E4CF57: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Conditional jump or move depends on uninitialised value(s) ==23299== at 0x4E4CF66: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Use of uninitialised value of size 8 ==23299== at 0x4E4CF9A: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Use of uninitialised value of size 8 ==23299== at 0x4E491AA: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Conditional jump or move depends on uninitialised value(s) ==23299== at 0x4E491B9: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Use of uninitialised value of size 8 ==23299== at 0x4E491E7: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Use of uninitialised value of size 8 ==23299== at 0x4E44733: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Conditional jump or move depends on uninitialised value(s) ==23299== at 0x4E4D166: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Conditional jump or move depends on uninitialised value(s) ==23299== at 0x4E4D16B: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Use of uninitialised value of size 8 ==23299== at 0x4E4CF57: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Conditional jump or move depends on uninitialised value(s) ==23299== at 0x4E4CF66: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Use of uninitialised value of size 8 ==23299== at 0x4E4CF9A: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Use of uninitialised value of size 8 ==23299== at 0x4E491AA: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Conditional jump or move depends on uninitialised value(s) ==23299== at 0x4E491B9: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Use of uninitialised value of size 8 ==23299== at 0x4E491E7: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== ==23299== Use of uninitialised value of size 8 ==23299== at 0x4E44733: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E57F2C: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) ==23299== tok = 1000, yylval= 1 tok = 1001, yylval= a tok = 1000, yylval= 23 tok = 1001, yylval= b tok = 1000, yylval= 456 tok = 1001, yylval= c ==23299== ==23299== HEAP SUMMARY: ==23299== in use at exit: 864 bytes in 3 blocks ==23299== total heap usage: 14 allocs, 11 frees, 24,562 bytes allocated ==23299== ==23299== LEAK SUMMARY: ==23299== definitely lost: 0 bytes in 0 blocks ==23299== indirectly lost: 0 bytes in 0 blocks ==23299== possibly lost: 864 bytes in 3 blocks ==23299== still reachable: 0 bytes in 0 blocks ==23299== suppressed: 0 bytes in 0 blocks ==23299== Rerun with --leak-check=full to see details of leaked memory ==23299== ==23299== For counts of detected and suppressed errors, rerun with: -v ==23299== Use --track-origins=yes to see where uninitialised values come from ==23299== ERROR SUMMARY: 390 errors from 18 contexts (suppressed: 0 from 0) $ |
|
From: Peng Yu <pen...@gm...> - 2019-02-18 23:06:06
|
Here is the output. It still fails. So I am not supposed to use valgrind when I use boehm gc? $ valgrind --tool=none ./main.l.exe <<EOF 1a23b 10.8 456c EOF ==47141== Nulgrind, the minimal Valgrind tool ==47141== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. ==47141== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==47141== Command: ./main.l.exe ==47141== ==47141== ==47141== Process terminating with default action of signal 11 (SIGSEGV) ==47141== Access not within mapped region at address 0x18 ==47141== at 0x1006B55BA: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib) ==47141== by 0x1006B550C: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib) ==47141== by 0x1006B4BF8: thread_start (in /usr/lib/system/libsystem_pthread.dylib) ==47141== If you believe this happened as a result of a stack ==47141== overflow in your program's main thread (unlikely but ==47141== possible), you can try to increase the size of the ==47141== main thread stack using the --main-stacksize= flag. ==47141== The main thread stack size used in this run was 8388608. ==47141== Segmentation fault: 11 > You might first try with --tool=none to see if the basis of valgrind+boehm > gc works. -- Regards, Peng |
|
From: Philippe W. <phi...@sk...> - 2019-02-18 22:42:45
|
On Sun, 2019-02-17 at 20:51 -0600, Peng Yu wrote: > Hi, > > I have the follow flex code using Boehm garbage collector. > http://www.hboehm.info/gc/gcinterface.html > > The program is compiled with the following commands. > > $ flex -o main.l.c main.l > $ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c # > rapidstring.h is in . > $ clang main.l.o -lgc -lfl -o main.l.exe > $ dsymutil main.l.exe > > rapidstring.h can be downloaded here. > > https://raw.githubusercontent.com/boyerjohn/rapidstring/master/include/rapidstring.h > > The following commands show that without using valgrind, the program > runs OK. But if valgrind is used, the program will cause a > segmentation fault. > > Is it because valgrind does not work with a garbage collector? It would not be very amasing that memcheck (that replaces malloc) would conflict with something like Boehm gc, that for sure does strange things with malloc replacement itself. You might first try with --tool=none to see if the basis of valgrind+boehm gc works. Philippe |
|
From: Peng Yu <pen...@gm...> - 2019-02-18 02:51:49
|
Hi, I have the follow flex code using Boehm garbage collector. http://www.hboehm.info/gc/gcinterface.html The program is compiled with the following commands. $ flex -o main.l.c main.l $ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c # rapidstring.h is in . $ clang main.l.o -lgc -lfl -o main.l.exe $ dsymutil main.l.exe rapidstring.h can be downloaded here. https://raw.githubusercontent.com/boyerjohn/rapidstring/master/include/rapidstring.h The following commands show that without using valgrind, the program runs OK. But if valgrind is used, the program will cause a segmentation fault. Is it because valgrind does not work with a garbage collector? $ ./main.l.exe <<EOF 1a23b 456c EOF tok = 1000, yylval= 1 tok = 1001, yylval= a tok = 1000, yylval= 23 tok = 1001, yylval= b tok = 1000, yylval= 456 tok = 1001, yylval= c $ valgrind ./main.l.exe <<EOF 1a23b 456c EOF ==44938== Memcheck, a memory error detector ==44938== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==44938== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==44938== Command: ./main.l.exe ==44938== ==44938== Syscall param __pthread_sigmask(set) points to uninitialised byte(s) ==44938== at 0x10068CB96: __pthread_sigmask (in /usr/lib/system/libsystem_kernel.dylib) ==44938== by 0x1006C3674: pthread_sigmask (in /usr/lib/system/libsystem_pthread.dylib) ==44938== by 0x1000D0225: GC_start_mark_threads_inner (in /usr/local/Cellar/bdw-gc/8.0.2/lib/libgc.1.dylib) ==44938== by 0x1000C0060: GC_init (in /usr/local/Cellar/bdw-gc/8.0.2/lib/libgc.1.dylib) ==44938== by 0x100003133: main (main.l:33) ==44938== Address 0x1048a42e4 is on thread 1's stack ==44938== in frame #2, created by GC_start_mark_threads_inner (???:) ==44938== ==44938== Thread 2: ==44938== Invalid read of size 4 ==44938== at 0x1006C35BA: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib) ==44938== by 0x1006C350C: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib) ==44938== by 0x1006C2BF8: thread_start (in /usr/lib/system/libsystem_pthread.dylib) ==44938== Address 0x18 is not stack'd, malloc'd or (recently) free'd ==44938== ==44938== ==44938== Process terminating with default action of signal 11 (SIGSEGV) ==44938== Access not within mapped region at address 0x18 ==44938== at 0x1006C35BA: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib) ==44938== by 0x1006C350C: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib) ==44938== by 0x1006C2BF8: thread_start (in /usr/lib/system/libsystem_pthread.dylib) ==44938== If you believe this happened as a result of a stack ==44938== overflow in your program's main thread (unlikely but ==44938== possible), you can try to increase the size of the ==44938== main thread stack using the --main-stacksize= flag. ==44938== The main thread stack size used in this run was 8388608. ==44938== ==44938== HEAP SUMMARY: ==44938== in use at exit: 19,932 bytes in 162 blocks ==44938== total heap usage: 183 allocs, 21 frees, 28,380 bytes allocated ==44938== ==44938== LEAK SUMMARY: ==44938== definitely lost: 0 bytes in 0 blocks ==44938== indirectly lost: 2,064 bytes in 1 blocks ==44938== possibly lost: 0 bytes in 0 blocks ==44938== still reachable: 200 bytes in 6 blocks ==44938== suppressed: 17,668 bytes in 155 blocks ==44938== Rerun with --leak-check=full to see details of leaked memory ==44938== ==44938== For counts of detected and suppressed errors, rerun with: -v ==44938== Use --track-origins=yes to see where uninitialised values come from ==44938== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4) Segmentation fault: 11 $ cat main.l // clang-format off %{ // clang-format on #define TOK_NUMBER 1000 #define TOK_STRING 1001 #include <gc.h> #define RS_MALLOC GC_MALLOC #define RS_REALLOC GC_REALLOC #define RS_FREE GC_FREE #include <rapidstring.h> typedef struct { int num; rapidstring str; } YYSTYPE; // clang-format off %} %option nodefault noinput nounput %option reentrant bison-bridge %% [[:digit:]]+ yylval->num=atoi(yytext); return TOK_NUMBER; [[:alpha:]]+ { // clang-format on rs_cpy(&yylval->str, yytext); return TOK_STRING; // clang-format off } .|\n %% int main() { // clang-format on GC_INIT(); yyscan_t scanner; yylex_init(&scanner); int tok; YYSTYPE lval; rs_init(&lval.str); while ((tok = yylex(&lval, scanner))) { if (tok == TOK_NUMBER) { printf("tok = %d, yylval= %d\n", tok, yyget_lval(scanner)->num); } else if (tok == TOK_STRING) { printf("tok = %d, yylval= %s\n", tok, rs_data(&yyget_lval(scanner)->str)); } } yylex_destroy(scanner); return 0; } -- Regards, Peng |
|
From: / <is...@ya...> - 2019-02-16 17:14:55
|
great sorted! On 16/02/19 19:12, Philippe Waroquiers wrote: > On Sat, 2019-02-16 at 18:08 +0200, / wrote: >> My mistake, you are right, I had aliased valgrind to use >> --undef-value-errors=no >> >> thanks for your help and sorry for wasting your time. > No problem. > > BTW, the 'tool prefix' for arguments (e.g. --memcheck:undef-value-errors=no) > was designed so that you can do such alias, but in a way that will work > with whatever tool. > > Philippe > |
188 messages has been excluded from this view by a project administrator.
