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: Mark W. <ma...@kl...> - 2019-04-10 12:11:32
|
On Tue, 2019-04-09 at 09:02 +0200, Mark Wielaard wrote: > Hi, > > On Mon, 2019-04-08 at 11:11 +0200, Julian Seward wrote: > > A first release candidate for 3.15.0 is available at > > https://sourceware.org/pub/valgrind/valgrind-3.15.0.RC1.tar.bz2 > > (md5 = 56d9f5e25615d48110da0aa5764d481e) > > > > Please give it a try on platforms that are important for you. If > > no serious > > issues are reported, the 3.15.0 final release will happen on 12 > > April, that > > is, this coming Friday. > > For users are binary rpms for fedora and centos in koji and on copr > if > people find that easier to use for testing: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1246875 > https://copr.fedorainfracloud.org/coprs/mjw/valgrind-3.15.0/ > > For developers the build.logs do contain the make regtest diffs for > any > failing tests. I did new builds with the one extra commit and a couple of bug fixes: https://koji.fedoraproject.org/koji/buildinfo?buildID=1247329 https://copr.fedorainfracloud.org/coprs/mjw/valgrind-3.15.0/build/881204/ This includes the following extra fixes: valgrind commit b2d2da64b0de1c4d657b63187967b68606e84711 GET_STARTREGS for s390: fix register constraint KDE#406352 RC1 fails cachegrind/callgrind ann tests because of missing a.c KDE#406360 memcheck/tests/libstdc++.supp needs more supression variants KDE#406354 dhat is broken on x86 (32bit) KDE#406355 mcsignopass and mcsigpass fails due to a difference in gdb output KDE#406357 RC1 fails gdbserver_tests because of gdb output change I hand tested them all (because I made the mistake of only running the nonexp-regtest (which doesn't include gdbserver_tests) and messed up the data on the a.c file, which generates a warning, but shows the fix itself is good. May I push these fixes to git? Should they go on the master branch, or is there a 3.15.0 branch already? Thanks, Mark |
|
From: Mark W. <ma...@kl...> - 2019-04-09 12:08:29
|
On Mon, 2019-04-08 at 10:25 -0700, Carl Love wrote: > I have run RC1 on Power 7, Power 8 LE, Power 8 BE and Power 9 and > noted each system the same four post errors that I did not see last > week when I tested patches to be committed. The errors are: > > cachegrind/tests/ann1 (post) > cachegrind/tests/ann2 (post) > callgrind/tests/ann1 (post) > callgrind/tests/ann2 (post) > > I looked a little into the errors. I am not familiar with the tests. > > The diff files appear to be consistent across systems. It is indeed failing on other systems too. I filed the following bug, with proposed fix: https://bugs.kde.org/show_bug.cgi?id=406352 > I can't say for sure but I am guessing these will be architecture > independent errors. Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2019-04-09 07:02:34
|
Hi, On Mon, 2019-04-08 at 11:11 +0200, Julian Seward wrote: > A first release candidate for 3.15.0 is available at > https://sourceware.org/pub/valgrind/valgrind-3.15.0.RC1.tar.bz2 > (md5 = 56d9f5e25615d48110da0aa5764d481e) > > Please give it a try on platforms that are important for you. If no serious > issues are reported, the 3.15.0 final release will happen on 12 April, that > is, this coming Friday. For users are binary rpms for fedora and centos in koji and on copr if people find that easier to use for testing: https://koji.fedoraproject.org/koji/buildinfo?buildID=1246875 https://copr.fedorainfracloud.org/coprs/mjw/valgrind-3.15.0/ For developers the build.logs do contain the make regtest diffs for any failing tests. Cheers, Mark |
|
From: John R. <jr...@bi...> - 2019-04-09 06:00:52
|
On 4/8/19 4:54 PM, Wuweijia wrote: > localhost:/system/bin # ./valgrind -v --undef-value-errors=no ./test > ==30806== Memcheck, a memory error detector > ==30806== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==30806== Using Valgrind-3.14.0-353a3587bb-20181007X and LibVEX; rerun with -h for copyright info > linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags) > WARNING: linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags) > linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags) > WARNING: linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags) Please visit https://bugs.kde.org/show_bug.cgi?id=406349 and enter the version of Android and/or /system_Q_EA3/bin/linker64 into an Additional Comment. Also please attach the source code of the test program ./test to the valgrind bug report. The Android run-time linker /system_Q_EA3/bin/linker64 does not understand important flags in the DF_FLAGS_1 data item of the PT_DYNAMIC "segment" of /lib64/valgrind/vgpreload_core-arm64-linux.so and other valgrind shared libraries. As a result, memcheck does not re-direct nor intercept calls to malloc() or free(). This cripples memcheck. |
|
From: Wuweijia <wuw...@hu...> - 2019-04-08 23:54:50
|
localhost:/system/bin # ./valgrind -v --undef-value-errors=no ./test
==30806== Memcheck, a memory error detector
==30806== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==30806== Using Valgrind-3.14.0-353a3587bb-20181007X and LibVEX; rerun with -h for copyright info
==30806== Command: ./test
==30806==
--30806-- Valgrind options:
--30806-- -v
--30806-- --undef-value-errors=no
--30806-- Contents of /proc/version:
--30806-- Linux version 4.4.7+ (root@baixin-HP-Compaq-8200-Elite-MT-PC) (gcc version 4.9.3 20151223 (prerelease) (SDK V100R005C00SPC030B080) ) #1 SMP PREEMPT Fri Sep 9 14:57:05 CST 2016
--30806--
--30806-- Arch and hwcaps: ARM64, LittleEndian, baseline
--30806-- Page sizes: currently 4096, max supported 65536
--30806-- Valgrind library directory: /system/lib64/valgrind
--30806-- Reading syms from /system_Q_EA3/bin/test
--30806-- Reading syms from /system_Q_EA3/bin/linker64
--30806-- Scheduler: using generic scheduler lock implementation.
--30806-- Reading suppressions file: /system/lib64/valgrind/default.supp
--30806-- Reading syms from /system_Q_EA3/lib64/libm.so
linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
new lld p=0x5613000
==30806==
==30806== HEAP SUMMARY:
==30806== in use at exit: 0 bytes in 0 blocks
==30806== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==30806==
==30806== All heap blocks were freed -- no leaks are possible
==30806==
==30806== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==30806== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
ocalhost:/system/bin # readelf -d ../lib64/libc.so
Dynamic section at offset 0x15ee20 contains 28 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [ld-android.so]
0x0000000000000001 (NEEDED) Shared library: [libdl.so]
0x000000000000000e (SONAME) Library soname: [libc.so]
0x000000000000001e (FLAGS) BIND_NOW
0x000000006ffffffb (FLAGS_1) Flags: NOW
0x0000000000000007 (RELA) 0xf188
0x0000000000000008 (RELASZ) 39288 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffff9 (RELACOUNT) 1575
0x0000000000000017 (JMPREL) 0x18b00
0x0000000000000002 (PLTRELSZ) 13776 (bytes)
0x0000000000000003 (PLTGOT) 0x15f390
0x0000000000000014 (PLTREL) RELA
0x0000000000000006 (SYMTAB) 0x270
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000005 (STRTAB) 0xb1c4
0x000000000000000a (STRSZ) 16323 (bytes)
0x000000006ffffef5 (GNU_HASH) 0x8f10
0x0000000000000019 (INIT_ARRAY) 0x15edf8
0x000000000000001b (INIT_ARRAYSZ) 40 (bytes)
0x000000000000001a (FINI_ARRAY) 0x15a000
0x000000000000001c (FINI_ARRAYSZ) 16 (bytes)
0x000000006ffffff0 (VERSYM) 0x8328
0x000000006ffffffc (VERDEF) 0x8de4
0x000000006ffffffd (VERDEFNUM) 9
0x000000006ffffffe (VERNEED) 0x8ee0
0x000000006fffffff (VERNEEDNUM) 1
0x0000000000000000 (NULL) 0x0
The text in blue as below:
> LOAD 0x000000 0x0000000000000000 0x0000000000000000
> 0x0469bc 0x0469bc R 0x1000
> LOAD 0x047000 0x0000000000047000 0x0000000000047000
> 0x10ee20 0x10ee20 E 0x1000
> LOAD 0x156000 0x0000000000156000 0x0000000000156000
> 0x00a598 0x221fa8 RW 0x1000
> DYNAMIC 0x15ee20 0x000000000015ee20 0x000000000015ee20
> 0x0001c0 0x0001c0 RW 0x8
-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...]
发送时间: 2019年4月8日 12:24
收件人: val...@li...
主题: Re: [Valgrind-users] [HELP] Android use LD to link the program but the valgrind can not report malloc leak;
> Elf file type is DYN (Shared object file) Entry point 0x47000 There
> are 9 program headers, starting at offset 64
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flg Align
> PHDR 0x000040 0x0000000000000040 0x0000000000000040
> 0x0001f8 0x0001f8 R 0x8
> LOAD 0x000000 0x0000000000000000 0x0000000000000000
> 0x0469bc 0x0469bc R 0x1000
> LOAD 0x047000 0x0000000000047000 0x0000000000047000
> 0x10ee20 0x10ee20 E 0x1000
> LOAD 0x156000 0x0000000000156000 0x0000000000156000
> 0x00a598 0x221fa8 RW 0x1000
> DYNAMIC 0x15ee20 0x000000000015ee20 0x000000000015ee20
> 0x0001c0 0x0001c0 RW 0x8
> GNU_RELRO 0x15a000 0x000000000015a000 0x000000000015a000
> 0x006598 0x007000 R 0x1
> GNU_EH_FRAME 0x02a2a4 0x000000000002a2a4 0x000000000002a2a4
> 0x005ddc 0x005ddc R 0x4
> GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000
> 0x000000 0x000000 RW 0
> NOTE 0x000238 0x0000000000000238 0x0000000000000238
> 0x000038 0x000038 R 0x4
> Valgrind can not find memory leak with malloc;
Which version of valgrind? (Run "valgrind --version".)
Please post the valgrind output just before and just after the place where the report of memory leaks should appear.
Please re-run using "valgrind -v ..." and show the output from the very beginning until the last REDIR message, such as:
--15470-- REDIR: 0x4ebf390 (libc.so.6:malloc) redirected to 0x4c2edc9 (malloc)
--15470-- REDIR: 0x4ebf9e0 (libc.so.6:free) redirected to 0x4c2ffca (free)
> I think maybe there is something different with GNU LD command;
> because there is two segment new；
> Please focus on the text in blue;
The text that was originally posted to [valgrind-users] was all in black. There was no blue.
Please post the output from:
readelf --dynamic <the_program>
ldd <the_program>
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Julian S. <js...@ac...> - 2019-04-08 09:11:16
|
Greetings. A first release candidate for 3.15.0 is available at https://sourceware.org/pub/valgrind/valgrind-3.15.0.RC1.tar.bz2 (md5 = 56d9f5e25615d48110da0aa5764d481e) Please give it a try on platforms that are important for you. If no serious issues are reported, the 3.15.0 final release will happen on 12 April, that is, this coming Friday. J |
|
From: Paulo M. <pm...@li...> - 2019-04-08 07:10:56
|
On 05/04/2019 23:27, Philippe Waroquiers wrote: > On Fri, 2019-04-05 at 20:53 +0200, Paulo Matos via Valgrind-users wrote: >> disInstr(arm64): unhandled instruction 0xD5380000 > ... >> Could this really be a problem with valgrind, or am I missing something? >> >> If I should raise a bug or add more info please let me know. > > Searching on 'disInstr(arm64): unhandled instruction 0xD5380000' > points e.g. at https://bugs.kde.org/show_bug.cgi?id=381556 > which is marked as fixed. > > So, first thing to try is to test with the latest release (3.14) > and/or the GIT version. > Thanks Philippe, you are correct. This is fixed in the last git commit. -- Paulo Matos |
|
From: Julian S. <js...@ac...> - 2019-04-08 05:39:38
|
The official Massif documentation is at http://valgrind.org/docs/manual/ms-manual.html. time is measured in instructions, not nanoseconds, so as to make runs repeatable. The various _B values are sizes of things in bytes. See the above URL for details. J On 08/04/2019 07:34, Yogi S wrote: > Hi, > i am a novice. when I capture the snapshots using massif tool following are > the attributes seen in the snapshot. > > time=5325473651 > mem_heap_B=232194935 > mem_heap_extra_B=1038185 > mem_stacks_B=0 > heap_tree=peak > > If I understand correctly time would refer to the time in nano seconds (*may > be some other units*) > But what are the mem_heap_B , mem_heap_extra_B and mem_stacks_B and > heap_tree. > > I tried searching for suitable article online on this could not get one. > can you help me with the same? > > Regards > Yogi > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Yogi S <inf...@gm...> - 2019-04-08 05:34:32
|
Hi, i am a novice. when I capture the snapshots using massif tool following are the attributes seen in the snapshot. time=5325473651 mem_heap_B=232194935 mem_heap_extra_B=1038185 mem_stacks_B=0 heap_tree=peak If I understand correctly time would refer to the time in nano seconds (*may be some other units*) But what are the mem_heap_B , mem_heap_extra_B and mem_stacks_B and heap_tree. I tried searching for suitable article online on this could not get one. can you help me with the same? Regards Yogi |
|
From: John R. <jr...@bi...> - 2019-04-08 04:24:15
|
> Elf file type is DYN (Shared object file)
> Entry point 0x47000
> There are 9 program headers, starting at offset 64
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x0001f8 0x0001f8 R 0x8
> LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0469bc 0x0469bc R 0x1000
> LOAD 0x047000 0x0000000000047000 0x0000000000047000 0x10ee20 0x10ee20 E 0x1000
> LOAD 0x156000 0x0000000000156000 0x0000000000156000 0x00a598 0x221fa8 RW 0x1000
> DYNAMIC 0x15ee20 0x000000000015ee20 0x000000000015ee20 0x0001c0 0x0001c0 RW 0x8
> GNU_RELRO 0x15a000 0x000000000015a000 0x000000000015a000 0x006598 0x007000 R 0x1
> GNU_EH_FRAME 0x02a2a4 0x000000000002a2a4 0x000000000002a2a4 0x005ddc 0x005ddc R 0x4
> GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0
> NOTE 0x000238 0x0000000000000238 0x0000000000000238 0x000038 0x000038 R 0x4
> Valgrind can not find memory leak with malloc;
Which version of valgrind? (Run "valgrind --version".)
Please post the valgrind output just before and just after
the place where the report of memory leaks should appear.
Please re-run using "valgrind -v ..." and show the output
from the very beginning until the last REDIR message, such as:
--15470-- REDIR: 0x4ebf390 (libc.so.6:malloc) redirected to 0x4c2edc9 (malloc)
--15470-- REDIR: 0x4ebf9e0 (libc.so.6:free) redirected to 0x4c2ffca (free)
> I think maybe there is something different with GNU LD command; because there is two segment new；
> Please focus on the text in blue;
The text that was originally posted to [valgrind-users] was all in black. There was no blue.
Please post the output from:
readelf --dynamic <the_program>
ldd <the_program>
|
|
From: Wuweijia <wuw...@hu...> - 2019-04-08 03:51:50
|
Elf file type is DYN (Shared object file) Entry point 0x47000 There are 9 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x0001f8 0x0001f8 R 0x8 LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0469bc 0x0469bc R 0x1000 LOAD 0x047000 0x0000000000047000 0x0000000000047000 0x10ee20 0x10ee20 E 0x1000 LOAD 0x156000 0x0000000000156000 0x0000000000156000 0x00a598 0x221fa8 RW 0x1000 DYNAMIC 0x15ee20 0x000000000015ee20 0x000000000015ee20 0x0001c0 0x0001c0 RW 0x8 GNU_RELRO 0x15a000 0x000000000015a000 0x000000000015a000 0x006598 0x007000 R 0x1 GNU_EH_FRAME 0x02a2a4 0x000000000002a2a4 0x000000000002a2a4 0x005ddc 0x005ddc R 0x4 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0 NOTE 0x000238 0x0000000000000238 0x0000000000000238 0x000038 0x000038 R 0x4 Valgrind can not find memory leak with malloc; I think maybe there is something different with GNU LD command; because there is two segment new； Please focus on the text in blue; |
|
From: Philippe W. <phi...@sk...> - 2019-04-05 21:27:49
|
On Fri, 2019-04-05 at 20:53 +0200, Paulo Matos via Valgrind-users wrote: > disInstr(arm64): unhandled instruction 0xD5380000 ... > Could this really be a problem with valgrind, or am I missing something? > > If I should raise a bug or add more info please let me know. Searching on 'disInstr(arm64): unhandled instruction 0xD5380000' points e.g. at https://bugs.kde.org/show_bug.cgi?id=381556 which is marked as fixed. So, first thing to try is to test with the latest release (3.14) and/or the GIT version. Philippe |
|
From: Paulo M. <pm...@li...> - 2019-04-05 19:10:59
|
Hi, In an attempt to investigate a bug in the racket compiler under aarch64, I got myself an amazon arm machine (a1.xlarge instance) running ubuntu cosmic. ubuntu@ip-172-31-16-13:~$ cat /proc/cpuinfo processor : 0 BogoMIPS : 166.66 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 1 BogoMIPS : 166.66 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 2 BogoMIPS : 166.66 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 3 BogoMIPS : 166.66 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 ubuntu@ip-172-31-16-13:~$ uname -a Linux ip-172-31-16-13 4.18.0-1008-aws #10-Ubuntu SMP Mon Jan 14 22:12:09 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux I have then build racket with gcc and ran valgrind on the command line I know to segfault and got this: $ valgrind ./racket3m -cqu ../../racket/mksystem.rkt system.rktd "gcc -E -I. -I../../racket/include -I../../racket/src -g -O2 -DUSE_SENORA_GC ../../racket/src/systype.c" "" machine "./racket3m" "./racket3m" ==18997== Memcheck, a memory error detector ==18997== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==18997== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==18997== Command: ./racket3m -cqu ../../racket/mksystem.rkt system.rktd gcc\ -E\ -I.\ -I../../racket/include\ -I../../racket/src\ -g\ -O2\ \ \ -DUSE_SENORA_GC\ \ \ \ ../../racket/src/systype.c machine ./racket3m ./racket3m ==18997== ARM64 front end: branch_etc disInstr(arm64): unhandled instruction 0xD5380000 disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000 ==18997== valgrind: Unrecognised instruction at address 0x40148e0. ==18997== at 0x40148E0: init_cpu_features (cpu-features.c:70) ==18997== by 0x40148E0: dl_platform_init (dl-machine.h:208) ==18997== by 0x40148E0: _dl_sysdep_start (dl-sysdep.c:231) ==18997== by 0x4001883: _dl_start_final (rtld.c:415) ==18997== by 0x4001AFF: _dl_start (rtld.c:524) ==18997== by 0x4001047: ??? (in /lib/aarch64-linux-gnu/ld-2.28.so) ==18997== Your program just tried to execute an instruction that Valgrind ==18997== did not recognise. There are two possible reasons for this. ==18997== 1. Your program has a bug and erroneously jumped to a non-code ==18997== location. If you are running Memcheck and you just saw a ==18997== warning about a bad jump, it's probably your program's fault. ==18997== 2. The instruction is legitimate but Valgrind doesn't handle it, ==18997== i.e. it's Valgrind's fault. If you think this is the case or ==18997== you are not sure, please let us know and we'll try to fix it. ==18997== Either way, Valgrind will now raise a SIGILL signal which will ==18997== probably kill your program. ==18997== ==18997== Process terminating with default action of signal 4 (SIGILL) ==18997== Illegal opcode at address 0x40148E0 ==18997== at 0x40148E0: init_cpu_features (cpu-features.c:70) ==18997== by 0x40148E0: dl_platform_init (dl-machine.h:208) ==18997== by 0x40148E0: _dl_sysdep_start (dl-sysdep.c:231) ==18997== by 0x4001883: _dl_start_final (rtld.c:415) ==18997== by 0x4001AFF: _dl_start (rtld.c:524) ==18997== by 0x4001047: ??? (in /lib/aarch64-linux-gnu/ld-2.28.so) ==18997== ==18997== HEAP SUMMARY: ==18997== in use at exit: 0 bytes in 0 blocks ==18997== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==18997== ==18997== All heap blocks were freed -- no leaks are possible ==18997== ==18997== For counts of detected and suppressed errors, rerun with: -v ==18997== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction (core dumped) Could this really be a problem with valgrind, or am I missing something? If I should raise a bug or add more info please let me know. -- Paulo Matos |
|
From: Дилян П. <Dil...@ae...> - 2019-03-30 22:25:04
|
Hello, I have cheap computer, which is slow and has small brain (RAM). Running big applications under valgrind is not smooth. Can valgrind be tweaked to load the debug informarion, only if it is needed, or only from specific libraries, or only at the evry end whein everyrhing woild be rendered, in order to save RAM? With gcc there are different options how much debug information to geberate, e.g. -g and -ggdb3 . Which debug informatiom generated by gcc/clang is interpreted by valgrind and which not? Do you have recommendation how to generate less debug informarion, in order ro occupy less RAM by valgrind, yet to have useful output? When valgrind crashes, e.g. due application misbehaviour, what shall I do? Regards Дилян |
|
From: John R. <jr...@bi...> - 2019-03-29 21:51:26
|
> There's a bunch of errors reported [by valgrind] from the dynamic linker on Android, that I think can be suppressed. For memory leaks, particularly if related to static initialization and/or are bounded in small total size, then probably they can be added to a list of errors to suppress by default on Android. Such as: a file ./Android-x.y.supp at the top level of the valgrind source. Enter a bug report (see http://valgrind.org/support/bug_reports.html) and attach the suppressions as a file to the bug report. For access errors, then start by submitting them to Android. There's a good chance that they are real errors that Android should fix. If Android declines, then file a _separate_ bug report to add the complaints to the valgrind suppressions. |
|
From: Taylor H. <tay...@gm...> - 2019-03-29 21:13:05
|
Hello! First off, thanks for creating such an awesome tool. I've been using valgrind on Termux (a terminal for Android.) There's a bunch of errors reported from the dynamic linker on Android, that I think can be suppressed. I've been using a generated suppression file that I include with .valgrindrc, but I'm wondering if this can be built into valgrind, as with the other suppression files that exist in the tarball distribution. Thanks in advance! |
|
From: Matthias A. <gu...@un...> - 2019-03-26 09:00:35
|
Hello,
This is with valgrind 3.14.0 compiled and used on SuSE Linux 12 and 15 x86_64.
I do start our servers with something like this to get the
suppression-hint into a file to sort them out if they belong to our
C-code or to shared libs we do not have under control, for example of
the DBS Sybase or SSL layer:
/usr/local/sisis-pap/bin/valgrind --version
valgrind-3.14.0
LOG=/home/sisis/guru/avs-sup.log
nohup /usr/local/sisis-pap/bin/valgrind \
--leak-check=full --show-reachable=yes \
--error-limit=no \
--max-stackframe=8000000 \
--trace-children=yes \
--leak-check=no \ <**************
--leak-resolution=low \
--track-origins=yes \
--gen-suppressions=all \
$AVSERVER_PATH/AVServer -p $PORT >>$LOG 2>&1 &
I recently updated from 3.12 to now 3.14 and while I got with 3.12 some
500 suppression-hints, esp. of forein shared libs, now I get less then
10 on the first run of the (same) server. Has something changed with
3.14? I found nothing about this in the NEWS file in the source tree.
It seems that '--leak-check=no' disables somehow the generation of the
suppression-hints.
Thanks
matthias
--
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
|
|
From: Matthias A. <gu...@un...> - 2019-03-25 08:35:01
|
I was lucky and catched the situation again and could attach a GDB to the
running process. It's a bit complicated because the software is a
running server with ~10 children which server altogether a web application via tomcat
and you do not know when you fire up a search in the browser, which
process will serve this. Anyway, here it is:
==17753== Conditional jump or move depends on uninitialised value(s)
==17753== at 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215)
==17753== by 0x8B8069C: SRVCatSearchMedia (SRVCatSearchMedia.c:579)
==17753== by 0x74D3683: SlnpRunModule (SLNPInterpreter.c:567)
==17753== by 0x74D31C7: SlnpInterpreter (SLNPInterpreter.c:287)
==17753== by 0x414543: SlnpMainLoop (OPServer.c:874)
==17753== by 0x413ED3: OPServer (OPServer.c:258)
==17753== by 0x413792: main (OPDaemon.c:407)
==17753== Uninitialised value was created by a stack allocation
==17753== at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so)
==17753==
srap22dxr1:/home/sisis/guru # gdb /opt/lib/sisis/opserver/bin/OPServer 17753
...
(gdb) info line *0x8B43AF0
No line number information available for address 0x8b43af0 <CatTmFilterExclude@plt>
I did an 'objdump -S /home/sisis/guru/libcopz39.so > libcopz39.so' of the shared lib and the first
function in this is CatAdmCatClass(); setting a bt there shows:
(gdb) br CatAdmCatClass
Breakpoint 8 at 0x8b44ea9: file CATAdmCat.c, line 133.
(gdb) list CatAdmCatClass
127 static int AdmCatSetBool(CatAdmCatValue, CatJaNein);
128 static int AdmCatSetString(CatAdmCatValue, char *);
129 static int AdmCatSetInt(CatAdmCatValue, int);
130
131 t_adm_cat *CatAdmCatClass()
132 {
133 return &s_adm_cat;
134 }
135
136 void CatAdmCatInitFlag(CatBool is_set)
(gdb) info line *0x8b44ea9
Line 133 of "CATAdmCat.c" starts at address 0x8b44ea9 <CatAdmCatClass+4> and ends at 0x8b44eb0 <CatAdmCatClass+11>.
i.e. the addr shown by valgrind 0x8B43AF0 has really no code in /home/sisis/guru/libcopz39.so.
Also a hex dump underpins this:
(gdb) x/2000x 0x8B43AF0
0x8b43af0 <CatTmFilterExclude@plt>: 0x6c7225ff 0xea680025 0xe9000000 0xfffff140
0x8b43b00 <g_utf8_find_prev_char@plt>: 0x6c6a25ff 0xeb680025 0xe9000000 0xfffff130
0x8b43b10 <CatClearSisError@plt>: 0x6c6225ff 0xec680025 0xe9000000 0xfffff120
0x8b43b20 <FensterZuString@plt>: 0x6c5a25ff 0xed680025 0xe9000000 0xfffff110
0x8b43b30 <FstabLoeschen@plt>: 0x6c5225ff 0xee680025 0xe9000000 0xfffff100
0x8b43b40 <Fstab_IsNormalFeld@plt>: 0x6c4a25ff 0xef680025 0xe9000000 0xfffff0f0
0x8b43b50 <RechScanFenster@plt>: 0x6c4225ff 0xf0680025 0xe9000000 0xfffff0e0
0x8b43b60 <CatZ39ExplainFree@plt>: 0x6c3a25ff 0xf1680025 0xe9000000 0xfffff0d0
0x8b43b70 <SlnpErrIsSet@plt>: 0x6c3225ff 0xf2680025 0xe9000000 0xfffff0c0
0x8b43b80 <CatAdmUserGetUsernumber@plt>: 0x6c2a25ff 0xf3680025 0xe9000000 0xfffff0b0
0x8b43b90 <CatSearchInterprete@plt>: 0x6c2225ff 0xf4680025 0xe9000000 0xfffff0a0
0x8b43ba0 <fprintf@plt>: 0x6c1a25ff 0xf5680025 0xe9000000 0xfffff090
0x8b43bb0 <BKAllgFeldNrToFstabFeldNr@plt>: 0x6c1225ff 0xf6680025 0xe9000000 0xfffff080
0x8b43bc0 <FstabHoleTabElementByOPACKurzname@plt>: 0x6c0a25ff 0xf7680025 0xe9000000 0xfffff070
0x8b43bd0 <DB_insr@plt>: 0x6c0225ff 0xf8680025 0xe9000000 0xfffff060
0x8b43be0 <RechDBEnde@plt>: 0x6bfa25ff 0xf9680025 0xe9000000 0xfffff050
0x8b43bf0 <basename@plt>: 0x6bf225ff 0xfa680025 0xe9000000 0xfffff040
0x8b43c00 <RechAnzahlNotaId@plt>: 0x6bea25ff 0xfb680025 0xe9000000 0xfffff030
0x8b43c10 <SlnpFreeRspStatus@plt>: 0x6be225ff 0xfc680025 0xe9000000 0xfffff020
0x8b43c20 <fopen64@plt>: 0x6bda25ff 0xfd680025 0xe9000000 0xfffff010
0x8b43c30 <BAZ820@plt>: 0x6bd225ff 0xfe680025 0xe9000000 0xfffff000
0x8b43c40 <CatGenListRegisterData@plt>: 0x6bca25ff 0xff680025 0xe9000000 0xffffeff0
0x8b43c50 <CatSearchCollMainTitles@plt>: 0x6bc225ff 0x00680025 0xe9000001 0xffffefe0
0x8b43c60 <RechInitAnfrageDesc@plt>: 0x6bba25ff 0x01680025 0xe9000001 0xffffefd0
0x8b43c70 <BAZ042@plt>: 0x6bb225ff 0x02680025 0xe9000001 0xffffefc0
...
0x8b44d60 <Optab_Bez@plt>: 0x633a25ff 0x11680025 0xe9000002 0xffffded0
0x8b44d70 <g_unichar_isspace@plt>: 0x633225ff 0x12680025 0xe9000002 0xffffdec0
0x8b44d80 <CatReallocList@plt>: 0x632a25ff 0x13680025 0xe9000002 0xffffdeb0
0x8b44d90 <CatSearchDuplicate@plt>: 0x632225ff 0x14680025 0xe9000002 0xffffdea0
0x8b44da0 <RSetzeFehlerText@plt>: 0x631a25ff 0x15680025 0xe9000002 0xffffde90
0x8b44db0 <__gmon_start__@plt>: 0x512225ff 0x90660025 0x521225ff 0x90660025
0x8b44dc0 <deregister_tm_clones>: 0x60058d48 0x480025a6 0xa6523d8d 0x48550025
0x8b44dd0 <deregister_tm_clones+16>: 0x8948f829 0xf88348e5 0x5d02770e 0x058b48c3
0x8b44de0 <deregister_tm_clones+32>: 0x0025503c 0x74c08548 0xe0ff5df2 0x00401f0f
0x8b44df0 <register_tm_clones>: 0x29058d48 0x480025a6 0xa6223d8d 0x48550025
0x8b44e00 <register_tm_clones+16>: 0x8948f829 0xf8c148e5 0xc2894803 0x3feac148
0x8b44e10 <register_tm_clones+32>: 0x48d00148 0x0275f8d1 0x8b48c35d 0x25517f15
0x8b44e20 <register_tm_clones+48>: 0xd2854800 0x485df274 0xe2ffc689 0x00401f0f
0x8b44e30 <__do_global_dtors_aux>: 0xa5e93d80 0x75000025 0x3d834827 0x0025518f
0x8b44e40 <__do_global_dtors_aux+16>: 0x89485500 0x480c74e5 0x62923d8b 0x65e80025
0x8b44e50 <__do_global_dtors_aux+32>: 0xe8ffffff 0xffffff68 0xc005c65d 0x010025a5
0x8b44e60 <__do_global_dtors_aux+48>: 0x1f0fc3f3 0x2e660040 0x00841f0f 0x00000000
0x8b44e70 <frame_dummy>: 0xc03d8348 0x0000254c 0x8b482674 0x2550ff05
0x8b44e80 <frame_dummy+16>: 0xc0854800 0x48551a74 0x4caa3d8d 0x89480025
0x8b44e90 <frame_dummy+32>: 0x5dd0ffe5 0xffff57e9 0x801f0fff 0x00000000
0x8b44ea0 <frame_dummy+48>: 0xffff4be9 0x894855ff 0x058d48e5 0x0025a590
0x8b44eb0 <CatAdmCatClass+11>: 0x4855c35d 0x7d89e589 0xfc458bfc 0xa9360589
0x8b44ec0 <CatAdmCatInitFlag+14>: 0x5d900025 0x894855c3 0xec8348e5 0xfc7d8910
0x8b44ed0 <CatAdmCatSetUserNumber+11>: 0x89fc458b 0x0000bfc6 0xf8e80000 0xc9000010
0x8b44ee0 <CatAdmCatSetUserNumber+27>: 0x894855c3 0xec8348e5 0xfc7d8910 0x89fc458b
0x8b44ef0 <CatAdmCatSetSortMax+15>: 0x0001bfc6 0xdce80000 0xc9000010 0x894855c3
0x8b44f00 <CatAdmCatSetDelListPath+3>: 0xec8348e5 0x7d894810 0x458b48f8 0xc68948f8
I'd say, valgrind gives a wrong address as hint about the stack allocation, or?
I don't have any clue how to nail this down further.
matthias
--
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
|
|
From: Philippe W. <phi...@sk...> - 2019-03-23 10:42:42
|
On Thu, 2019-03-21 at 23:30 +0100, Yuri D'Elia wrote: > On Thu, Mar 21 2019, Philippe Waroquiers wrote: > > Strange. > > The only thing I see that can cause this failure is VexTransOutputFull. > > > > So, the next trial is to bump x10 > > m_translate.c N_TMPBUF > > > > You have to edit similarly the 60000 in VG_(add_to_transtab) > > This seems to have worked. > > What now, though? Humph, so functionally, valgrind seems to work, but needs an unexpectedly big amount of memory to handle some piece of code. The best is to file a bug on bugzilla, attaching more information. My knowledge in this area is relatively limited, but I think that the below should give the needed info: Use the unpatched valgrind (so as to reproduce the problem/crash). run a first time: valgrind --trace-flags=11111111 <yourprogram> This will output a bunch of lines such as: ... ==== SB 1789 (evchecks 8650) [tid 1] 0x4f833a7 free_mem+231 UNKNOWN_OBJECT+0x0 ==== SB 1790 (evchecks 8651) [tid 1] 0x4f832ae free_slotinfo+110 UNKNOWN_OBJECT+0x0 ... Then rerun with valgrind --trace-flags=11111111 --trace-notbelow=XXXXX <yourprogram> where XXXXX is one or two numbers before the SB that causes the crash. File a bug on bugzilla, attaching the resulting trace, and add the relevant details, such as indicating that increasing the 2 constants bypasses the problem. thanks Philippe |
|
From: Philippe W. <phi...@sk...> - 2019-03-23 10:27:51
|
On Fri, 2019-03-22 at 10:21 +0100, Matthias Apitz wrote: > El día Thursday, March 21, 2019 a las 10:44:54PM +0100, Philippe Waroquiers escribió: > > > On Thu, 2019-03-21 at 20:00 +0100, Matthias Apitz wrote: > > > Hello, > > > > > > Why are only the '???' marks printed for the localtion of the stack > > > allocation? This is with 3.18.0 on Linux x64: > > > > 3.18.0 ? > > Last release is 3.14. > > Yep. Sorry, this was a typo. I have 3.14.0, compiled by my own on SuSE > Linux SLES 12. > > > > ==24390== Conditional jump or move depends on uninitialised value(s) > > > ==24390== at 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215) > > > ==24390== by 0x8B8069C: SRVCatSearchMedia (SRVCatSearchMedia.c:579) > > > ==24390== by 0x74D3683: SlnpRunModule (SLNPInterpreter.c:567) > > > ==24390== by 0x74D31C7: SlnpInterpreter (SLNPInterpreter.c:287) > > > ==24390== by 0x414543: SlnpMainLoop (OPServer.c:874) > > > ==24390== by 0x413ED3: OPServer (OPServer.c:258) > > > ==24390== by 0x413792: main (OPDaemon.c:407) > > > ==24390== Uninitialised value was created by a stack allocation > > > ==24390== at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so) > > > ==24390== > > > > > > /home/sisis/guru # file libcopz39.so > > > libcopz39.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=eb1d460ebb565dedfe48bf5f534d2c097d9ca59c, with debug_info, not stripped > > > > > > The *.o files in the shared lib have been compiled with 'gcc -m64 -g ...' > > > > Can you check what file/line nr corresponds to 0x8B43AF0, > > using another tool (gdb, or whatever) ? > > I have to check how to convert he addr 0x8B43AF0 into a line: What I am typically doing is the following: valgrind --vgdb-error=1 <your_program> (assuming that is the first reported error). Then valgrind will stop and wait for GDB to connect. Then do the following: gdb target remote | vgdb info line *0x8B43AF0 When you do that when attached to the running executable, that will guarantee that the shared lib address translation is done using the address at which it is currently loaded. If GDB equally tells that there is no source/line nr, then I guess that is the best valgrind can do. Philippe |
|
From: John R. <jr...@bi...> - 2019-03-22 13:21:27
|
>>> ==24390== Uninitialised value was created by a stack allocation
>>> ==24390== at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so)
>>> ==24390==
>> Can you check what file/line nr corresponds to 0x8B43AF0,
>> using another tool (gdb, or whatever) ?
> Looks like this is near to 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215), may be in
> the same source file.
0x8B43AF0 (identified by valgrind) is somewhat far from
0x8B5DC3A (identified by the poster)
=========
0x1a14a d9fference
Use:
(gdb) info shared
Example:
$ gdb /bin/date
(gdb) b main
(gdb) run
Breakpoint 1, main (argc=0x1, argv=0x7fffffffd4b8) at ../src/date.c:348
(gdb) info shared
From To Syms Read Shared Object Library
0x00007ffff7dd6f60 0x00007ffff7df5080 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7a383a0 0x00007ffff7b7f11f Yes /lib64/libc.so.6
(gdb) quit
|
|
From: Matthias A. <gu...@un...> - 2019-03-22 09:21:35
|
El día Thursday, March 21, 2019 a las 10:44:54PM +0100, Philippe Waroquiers escribió: > On Thu, 2019-03-21 at 20:00 +0100, Matthias Apitz wrote: > > Hello, > > > > Why are only the '???' marks printed for the localtion of the stack > > allocation? This is with 3.18.0 on Linux x64: > 3.18.0 ? > Last release is 3.14. Yep. Sorry, this was a typo. I have 3.14.0, compiled by my own on SuSE Linux SLES 12. > > ==24390== Conditional jump or move depends on uninitialised value(s) > > ==24390== at 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215) > > ==24390== by 0x8B8069C: SRVCatSearchMedia (SRVCatSearchMedia.c:579) > > ==24390== by 0x74D3683: SlnpRunModule (SLNPInterpreter.c:567) > > ==24390== by 0x74D31C7: SlnpInterpreter (SLNPInterpreter.c:287) > > ==24390== by 0x414543: SlnpMainLoop (OPServer.c:874) > > ==24390== by 0x413ED3: OPServer (OPServer.c:258) > > ==24390== by 0x413792: main (OPDaemon.c:407) > > ==24390== Uninitialised value was created by a stack allocation > > ==24390== at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so) > > ==24390== > > > > /home/sisis/guru # file libcopz39.so > > libcopz39.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=eb1d460ebb565dedfe48bf5f534d2c097d9ca59c, with debug_info, not stripped > > > > The *.o files in the shared lib have been compiled with 'gcc -m64 -g ...' > > Can you check what file/line nr corresponds to 0x8B43AF0, > using another tool (gdb, or whatever) ? I have to check how to convert he addr 0x8B43AF0 into a line: (gdb) info line *0x8B43AF0 No line number information available for address 0x8b43af0 <CatTmFilterExclude@plt> I will copy the sources over to the server. Looks like this is near to 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215), may be in the same source file. matthias -- Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. |
|
From: Philippe W. <phi...@sk...> - 2019-03-21 21:45:03
|
On Thu, 2019-03-21 at 20:00 +0100, Matthias Apitz wrote: > Hello, > > Why are only the '???' marks printed for the localtion of the stack > allocation? This is with 3.18.0 on Linux x64: 3.18.0 ? Last release is 3.14. > > ==24390== Conditional jump or move depends on uninitialised value(s) > ==24390== at 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215) > ==24390== by 0x8B8069C: SRVCatSearchMedia (SRVCatSearchMedia.c:579) > ==24390== by 0x74D3683: SlnpRunModule (SLNPInterpreter.c:567) > ==24390== by 0x74D31C7: SlnpInterpreter (SLNPInterpreter.c:287) > ==24390== by 0x414543: SlnpMainLoop (OPServer.c:874) > ==24390== by 0x413ED3: OPServer (OPServer.c:258) > ==24390== by 0x413792: main (OPDaemon.c:407) > ==24390== Uninitialised value was created by a stack allocation > ==24390== at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so) > ==24390== > > /home/sisis/guru # file libcopz39.so > libcopz39.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=eb1d460ebb565dedfe48bf5f534d2c097d9ca59c, with debug_info, not stripped > > The *.o files in the shared lib have been compiled with 'gcc -m64 -g ...' Can you check what file/line nr corresponds to 0x8B43AF0, using another tool (gdb, or whatever) ? Thanks Philippe |
|
From: Philippe W. <phi...@sk...> - 2019-03-21 21:42:36
|
On Wed, 2019-03-20 at 23:20 +0100, Yuri D'Elia wrote: > On Wed, Mar 20 2019, Philippe Waroquiers wrote: > > Easiest thing to try initially is to recompile with a bigger size. > > After bumping buffers 10x, I get this: > > ==14645== Memcheck, a memory error detector > ==14645== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==14645== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info > ==14645== Command: ./src/slic3r-gui > ==14645== > > valgrind: m_translate.c:1815 (vgPlain_translate): Assertion 'tres.status == VexTransOK' failed. Strange. The only thing I see that can cause this failure is VexTransOutputFull. So, the next trial is to bump x10 m_translate.c N_TMPBUF You have to edit similarly the 60000 in VG_(add_to_transtab) Philippe > > host stacktrace: > ==14645== at 0x58049D7C: show_sched_status_wrk (m_libcassert.c:369) > ==14645== by 0x58049E97: report_and_quit (m_libcassert.c:440) > ==14645== by 0x5804A034: vgPlain_assert_fail (m_libcassert.c:506) > ==14645== by 0x58064ECC: vgPlain_translate (m_translate.c:1815) > ==14645== by 0x580AAD4A: handle_chain_me (scheduler.c:1134) > ==14645== by 0x580ACDCF: vgPlain_scheduler (scheduler.c:1483) > ==14645== by 0x580FF770: thread_wrapper (syswrap-linux.c:103) > ==14645== by 0x580FF770: run_a_thread_NORETURN (syswrap-linux.c:156) > > sched status: > running_tid=1 > > Thread 1: status = VgTs_Runnable (lwpid 14645) > ==14645== at 0x541E124: (anonymous namespace)::wxPNGImageData::DoLoadPNGFile(wxImage*, (anonymous namespace)::wxPNGInfoStruct&) [clone .constprop.45] (in /usr/local/stow/wxWidgets-3.1.2/lib/libwx_gtk3u_core-3.1.so.2.0.0) > ==14645== by 0x541F1B2: wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool, int) (in /usr/local/stow/wxWidgets-3.1.2/lib/libwx_gtk3u_core-3.1.so.2.0.0) > ==14645== by 0x5400A93: wxImage::DoLoad(wxImageHandler&, wxInputStream&, int) (in /usr/local/stow/wxWidgets-3.1.2/lib/libwx_gtk3u_core-3.1.so.2.0.0) > ... > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Matthias A. <gu...@un...> - 2019-03-21 19:00:36
|
Hello, Why are only the '???' marks printed for the localtion of the stack allocation? This is with 3.18.0 on Linux x64: ==24390== Conditional jump or move depends on uninitialised value(s) ==24390== at 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215) ==24390== by 0x8B8069C: SRVCatSearchMedia (SRVCatSearchMedia.c:579) ==24390== by 0x74D3683: SlnpRunModule (SLNPInterpreter.c:567) ==24390== by 0x74D31C7: SlnpInterpreter (SLNPInterpreter.c:287) ==24390== by 0x414543: SlnpMainLoop (OPServer.c:874) ==24390== by 0x413ED3: OPServer (OPServer.c:258) ==24390== by 0x413792: main (OPDaemon.c:407) ==24390== Uninitialised value was created by a stack allocation ==24390== at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so) ==24390== /home/sisis/guru # file libcopz39.so libcopz39.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=eb1d460ebb565dedfe48bf5f534d2c097d9ca59c, with debug_info, not stripped The *.o files in the shared lib have been compiled with 'gcc -m64 -g ...' Thanks matthias -- Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub |
188 messages has been excluded from this view by a project administrator.
