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: Yuri D'E. <wa...@th...> - 2019-03-20 22:21:06
|
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. 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) ... |
|
From: Philippe W. <phi...@sk...> - 2019-03-20 17:42:09
|
On Wed, 2019-03-20 at 00:01 +0100, Yuri D'Elia wrote: > On Tue, Mar 19 2019, Philippe Waroquiers wrote: > > > ==19253== by 0x580A524B: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux) > > > ==19253== by 0x580A71EF: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux) > > > ==19253== by 0x580F5D80: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux) > > > > A 'classically' installed valgrind will give file and linenr in the host backtrace/ > > I don't have valgrind debugging symbols currently installed. > > > The easiest is to increase the constants significantly (e.g. * 10) > > and recompile/retest. If after that it works, then it would be nice to > > understand why your application needs so much temporary space. > > (and maybe have an idea of really how much your app needs). > > Could this buffer be made tunable in the future? > I so far always used a pre-compiled version of valgrind. I do not think that this would be particularly difficult, but up to now, the preferred approach was always to just have a big enough fixed size, and increase it when an unexpected set of instructions implies a bigger size. Note that compiling valgrind from source is quite easy, in particular if you use a release: there is almost no dependencies. Starting from the git repository is only slightly more complex (you need auto tools etc). So, I recommend compiling from sources for a case like this. > > > If that does not solve the problem, then I guess a small reproducer will > > help to investigate ... > > This is not something I wrote, although there's a double-free I wanted > to investigate. It's also not a small program, linking with quite a few > large libraries. > > But it's all fully OSS. I could provide the binaries or a VM with the > executable pre-loaded if somebody is interested in having a look. Easiest thing to try initially is to recompile with a bigger size. Philippe |
|
From: Yuri D'E. <wa...@th...> - 2019-03-19 23:01:17
|
On Tue, Mar 19 2019, Philippe Waroquiers wrote: >> ==19253== by 0x580A524B: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux) >> ==19253== by 0x580A71EF: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux) >> ==19253== by 0x580F5D80: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux) > A 'classically' installed valgrind will give file and linenr in the host backtrace/ I don't have valgrind debugging symbols currently installed. > The easiest is to increase the constants significantly (e.g. * 10) > and recompile/retest. If after that it works, then it would be nice to > understand why your application needs so much temporary space. > (and maybe have an idea of really how much your app needs). Could this buffer be made tunable in the future? I so far always used a pre-compiled version of valgrind. > If that does not solve the problem, then I guess a small reproducer will > help to investigate ... This is not something I wrote, although there's a double-free I wanted to investigate. It's also not a small program, linking with quite a few large libraries. But it's all fully OSS. I could provide the binaries or a VM with the executable pre-loaded if somebody is interested in having a look. |
|
From: Philippe W. <phi...@sk...> - 2019-03-19 22:39:04
|
On Tue, 2019-03-19 at 19:05 +0100, Yuri D'Elia wrote:
> Hi everyone. It looks like the impossible happened. I was attempting to
> blindly run valgrind on debian unstable against slic3r-pe (mostly c++,
> which itself uses wxWidgets 3.1), both freshly compiled using gcc 8.3
> and got the following:
>
> $ valgrind ./src/slic3r-gui
> ==19253== Memcheck, a memory error detector
> ==19253== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==19253== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==19253== Command: ./src/slic3r-gui
> ==19253==
> VEX temporary storage exhausted.
> Pool = TEMP, start 0x59640548 curr 0x59b04c90 end 0x59b05087 (size 5000000)
>
> vex: the `impossible' happened:
> VEX temporary storage exhausted.
> Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
> vex storage: T total 5219676632 bytes allocated
> vex storage: P total 512 bytes allocated
>
> valgrind: the 'impossible' happened:
> LibVEX called failure_exit().
>
> host stacktrace:
> ==19253== at 0x580480A4: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x580481B7: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x5804840B: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x5804842A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x5805EEB4: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x5814153A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x581415BD: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x581E405C: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x581CE277: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x581CF618: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x5813EB58: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x58061976: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x580A524B: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x580A71EF: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253== by 0x580F5D80: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
A 'classically' installed valgrind will give file and linenr in the host backtrace/
>
> sched status:
> running_tid=1
>
> Thread 1: status = VgTs_Runnable (lwpid 19253)
> ==19253== at 0x541A124: (anonymous namespace)::wxPNGImageData::DoLoadPNGFile(wxImage*, (ab/libwx_gtk3u_core-3.1.so.2.0.0)
> ...
> ...
>
> Is that the kind of impossible that I should fix by increasing the
> buffer, or it's the kind of impossible you want to know more about? ;)
The easiest is to increase the constants significantly (e.g. * 10)
and recompile/retest. If after that it works, then it would be nice to
understand why your application needs so much temporary space.
(and maybe have an idea of really how much your app needs).
If that does not solve the problem, then I guess a small reproducer will
help to investigate ...
Philippe
|
|
From: Philippe W. <phi...@sk...> - 2019-03-19 21:38:03
|
Some more info is needed to guess what the problem could be. Debug your program when running under valgrind using gdb + vgdb. Compare the behaviour e.g. with gdb+vgdb between the non working system and a working system and/or compare the -v -v -v -d -d -d traces. Philippe On Tue, 2019-03-19 at 09:42 -0600, Matthew Bettencourt via Valgrind-users wrote: > When I run a real program valgrind hangs on my redhat desktop, however I > can run on other systems with the same executable. > > > I ran > > > valgrind -v -v -v -d -d -d myprog.exe > > > and it spits out a lot of output and then sits there for many minutes, > I've let it sit for overnight and no progress. > > > I'm guessing some system configuration, but I googled and looked around > and didn't see anything that could cause this.. > > > The last set of output is below, but it doesn't lend any clue to me.. > > --2921-- di_notify_mmap-4: noting details in DebugInfo* at 0x100920A7E0 > --2921-- di_notify_mmap-5: achieved accept state for > /projects/sems/install/rhel7-x86_64/sems/compiler/gcc/7.2.0/openmpi/1.10.1/lib/openmpi/mca_grpcomm_bad.so > --2921-- Reading syms from > /projects/sems/install/rhel7-x86_64/sems/compiler/gcc/7.2.0/openmpi/1.10.1/lib/openmpi/mca_grpcomm_bad.so > --2921-- svma 0x0000000e10, avma 0x002fe04e10 > --2921-- cfsi range rx-mappings coverage check: Covered > 0x0-0xffffffffffffffff > --2921-- di_notify_mmap-0: > --2921-- di_notify_mmap-1: 0x30007000-0x30807fff rw- > --2921:1: aspacem allocated valgrind thread stack at 0x100abec000 size > 1064960 > --2921:2: stacks register [start-end] [0x30008000-0x30806FFF] as stack 1 > --2921:1:syswrap- run_a_thread_NORETURN(tid=2): pre-thread_wrapper > --2921:1:syswrap- thread_wrapper(tid=2): entry > --2921-- di_notify_mmap-0: > --2921-- di_notify_mmap-1: 0x4022000-0x4026fff rw- > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Yuri D'E. <wa...@th...> - 2019-03-19 18:10:17
|
Hi everyone. It looks like the impossible happened. I was attempting to
blindly run valgrind on debian unstable against slic3r-pe (mostly c++,
which itself uses wxWidgets 3.1), both freshly compiled using gcc 8.3
and got the following:
$ valgrind ./src/slic3r-gui
==19253== Memcheck, a memory error detector
==19253== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==19253== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==19253== Command: ./src/slic3r-gui
==19253==
VEX temporary storage exhausted.
Pool = TEMP, start 0x59640548 curr 0x59b04c90 end 0x59b05087 (size 5000000)
vex: the `impossible' happened:
VEX temporary storage exhausted.
Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
vex storage: T total 5219676632 bytes allocated
vex storage: P total 512 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
host stacktrace:
==19253== at 0x580480A4: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x580481B7: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x5804840B: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x5804842A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x5805EEB4: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x5814153A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x581415BD: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x581E405C: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x581CE277: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x581CF618: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x5813EB58: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x58061976: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x580A524B: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x580A71EF: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==19253== by 0x580F5D80: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable (lwpid 19253)
==19253== at 0x541A124: (anonymous namespace)::wxPNGImageData::DoLoadPNGFile(wxImage*, (ab/libwx_gtk3u_core-3.1.so.2.0.0)
...
...
Is that the kind of impossible that I should fix by increasing the
buffer, or it's the kind of impossible you want to know more about? ;)
|
|
From: Matthew B. <mb...@sa...> - 2019-03-19 15:52:57
|
Also, FWIW, I tried the rh devtoolset version, 3.14 compiled by myself and the git version, all behave the same way. On 3/19/19 9:42 AM, Matthew Bettencourt via Valgrind-users wrote: > When I run a real program valgrind hangs on my redhat desktop, however > I can run on other systems with the same executable. > > > I ran > > > valgrind -v -v -v -d -d -d myprog.exe > > > and it spits out a lot of output and then sits there for many minutes, > I've let it sit for overnight and no progress. > > > I'm guessing some system configuration, but I googled and looked > around and didn't see anything that could cause this.. > > > The last set of output is below, but it doesn't lend any clue to me.. > > --2921-- di_notify_mmap-4: noting details in DebugInfo* at 0x100920A7E0 > --2921-- di_notify_mmap-5: achieved accept state for > /projects/sems/install/rhel7-x86_64/sems/compiler/gcc/7.2.0/openmpi/1.10.1/lib/openmpi/mca_grpcomm_bad.so > --2921-- Reading syms from > /projects/sems/install/rhel7-x86_64/sems/compiler/gcc/7.2.0/openmpi/1.10.1/lib/openmpi/mca_grpcomm_bad.so > --2921-- svma 0x0000000e10, avma 0x002fe04e10 > --2921-- cfsi range rx-mappings coverage check: Covered > 0x0-0xffffffffffffffff > --2921-- di_notify_mmap-0: > --2921-- di_notify_mmap-1: 0x30007000-0x30807fff rw- > --2921:1: aspacem allocated valgrind thread stack at 0x100abec000 size > 1064960 > --2921:2: stacks register [start-end] [0x30008000-0x30806FFF] as > stack 1 > --2921:1:syswrap- run_a_thread_NORETURN(tid=2): pre-thread_wrapper > --2921:1:syswrap- thread_wrapper(tid=2): entry > --2921-- di_notify_mmap-0: > --2921-- di_notify_mmap-1: 0x4022000-0x4026fff rw- > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Matthew B. <mb...@sa...> - 2019-03-19 15:42:22
|
When I run a real program valgrind hangs on my redhat desktop, however I can run on other systems with the same executable. I ran valgrind -v -v -v -d -d -d myprog.exe and it spits out a lot of output and then sits there for many minutes, I've let it sit for overnight and no progress. I'm guessing some system configuration, but I googled and looked around and didn't see anything that could cause this.. The last set of output is below, but it doesn't lend any clue to me.. --2921-- di_notify_mmap-4: noting details in DebugInfo* at 0x100920A7E0 --2921-- di_notify_mmap-5: achieved accept state for /projects/sems/install/rhel7-x86_64/sems/compiler/gcc/7.2.0/openmpi/1.10.1/lib/openmpi/mca_grpcomm_bad.so --2921-- Reading syms from /projects/sems/install/rhel7-x86_64/sems/compiler/gcc/7.2.0/openmpi/1.10.1/lib/openmpi/mca_grpcomm_bad.so --2921-- svma 0x0000000e10, avma 0x002fe04e10 --2921-- cfsi range rx-mappings coverage check: Covered 0x0-0xffffffffffffffff --2921-- di_notify_mmap-0: --2921-- di_notify_mmap-1: 0x30007000-0x30807fff rw- --2921:1: aspacem allocated valgrind thread stack at 0x100abec000 size 1064960 --2921:2: stacks register [start-end] [0x30008000-0x30806FFF] as stack 1 --2921:1:syswrap- run_a_thread_NORETURN(tid=2): pre-thread_wrapper --2921:1:syswrap- thread_wrapper(tid=2): entry --2921-- di_notify_mmap-0: --2921-- di_notify_mmap-1: 0x4022000-0x4026fff rw- |
|
From: Tom H. <to...@co...> - 2019-03-18 10:31:11
|
On 18/03/2019 09:25, Jeffrey Walton wrote: > I think the projects bug reporter is broken. I searched for the terms > and got 0 results. This has happened in the past for me, too. Searching for TTEntryC (for example) worked or me once I included closed bugs in the search - note that by default searches are limited to bugs that are still open. That's standard for bugzilla. > Do you think the project will ever fix the bug reporter, or will it > continue to waste my time and your time? Well it's not our bug reporter, it's the KDE one that we are just "borrowing" so management of it is outside our control for the most part. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Jeffrey W. <nol...@gm...> - 2019-03-18 09:26:30
|
On Sun, Mar 17, 2019 at 9:08 AM Philippe Waroquiers <phi...@sk...> wrote: > > You should upgrade to a recent valgrind version (e.g. compile > the last official release 3.14, or even the git version). > See bug https://bugs.kde.org/show_bug.cgi?id=362935 Thanks Phillipe. I think the projects bug reporter is broken. I searched for the terms and got 0 results. This has happened in the past for me, too. Do you think the project will ever fix the bug reporter, or will it continue to waste my time and your time? Jeff |
|
From: Tom H. <to...@co...> - 2019-03-17 15:24:19
|
On 17/03/2019 15:03, Jeffrey Walton wrote: > Working from Master I got the message about the missing ioctl: > > Debug: term_config > ==3366== Warning: noted but unhandled ioctl 0x540c with no size/direction hints. > ==3366== This could cause spurious value errors to appear. > ==3366== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper > wrapper. > > Following http://www.valgrind.org/docs/manual/dist.readme-missing.html > I found the source files don't really follow what is described. For > example, I only see PRE_unknown_ioctl and POST_unknown_ioctl, and I > don't see the big collection of existing ioctl's as described. I don't > think it is a good idea to go further (for me). You're looking for PRE(sys_ioctl) and POST(sys_ioctl) here: coregrind/m_syswrap/syswrap-linux.c > Both ioctl's take a NULL argument, so no parameters are passed. If there's no memory being read or written then the warning is harmless and you can ignore it. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Jeffrey W. <nol...@gm...> - 2019-03-17 15:03:47
|
Hi Everyone, Working from Master I got the message about the missing ioctl: Debug: term_config ==3366== Warning: noted but unhandled ioctl 0x540c with no size/direction hints. ==3366== This could cause spurious value errors to appear. ==3366== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. Following http://www.valgrind.org/docs/manual/dist.readme-missing.html I found the source files don't really follow what is described. For example, I only see PRE_unknown_ioctl and POST_unknown_ioctl, and I don't see the big collection of existing ioctl's as described. I don't think it is a good idea to go further (for me). If interested in closing the gap, then these ioctl's two need to be implemented (https://linux.die.net/man/4/tty_ioctl): * TIOCEXCL * TIOCNXCL /* Set fd to exclusive mode, TIOCEXCL=0x540c */ if (ioctl(fd, TIOCEXCL, NULL) != 0) { log_error("ioctl_tty: %s\n", strerror(errno)); return -1; } TIOCNXCL unsets exclusive mode. Both ioctl's take a NULL argument, so no parameters are passed. The ioctl is needed to open a serial device or modem with O_EXCL. Using O_EXCL open() will succeed, but the flag is silently ignored because of character devices. Later, Modem Manager or another program will open the device and muck with program state. To fix the missing O_EXCL, TIOCEXCL can be used. And yes, there is a race but it is the best we have. Jeff |
|
From: Julian S. <js...@ac...> - 2019-03-17 13:11:23
|
On 17/03/2019 13:59, Jeffrey Walton wrote:
> valgrind: m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion
> 'sizeof(TTEntryC) <= 88' failed.
> Segmentation fault
I'm sure it's been fixed since then. Here's what the current trunk
sources have:
/* The TTEntryH size is critical for keeping the LLC miss rate down
when doing a lot of discarding. Hence check it here. We also
have a lot of TTEntryCs so let's check that too. */
if (sizeof(HWord) == 8) {
vg_assert(sizeof(TTEntryH) <= 32);
vg_assert(sizeof(TTEntryC) <= 112);
}
else if (sizeof(HWord) == 4) {
vg_assert(sizeof(TTEntryH) <= 20);
# if defined(VGP_ppc32_linux) || defined(VGP_mips32_linux) \
|| (defined(VGP_mips64_linux) && defined(VGABI_N32)) \
|| defined(VGP_arm_linux)
/* On PPC32, MIPS32, ARM32 platforms, alignof(ULong) == 8, so the
structure is larger than on other 32 bit targets. */
vg_assert(sizeof(TTEntryC) <= 96); <------------------ HERE
# else
vg_assert(sizeof(TTEntryC) <= 88);
# endif
}
else {
vg_assert(0);
}
J
|
|
From: Philippe W. <phi...@sk...> - 2019-03-17 13:08:34
|
You should upgrade to a recent valgrind version (e.g. compile the last official release 3.14, or even the git version). See bug https://bugs.kde.org/show_bug.cgi?id=362935 Philippe commit 7a8129795c5c4e0465ac48989dc6cd755b5d0a66 Author: Julian Seward <js...@ac...> AuthorDate: Thu Jul 21 12:47:51 2016 +0000 Commit: Julian Seward <js...@ac...> CommitDate: Thu Jul 21 12:47:51 2016 +0000 Fix incorrect assertion re sizeof TTEntryC on arm-linux. Fixes #362935. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15912 On Sun, 2019-03-17 at 08:59 -0400, Jeffrey Walton wrote: > Hi Everyone, > > I'm working on a Tinker Board > (https://www.asus.com/us/Single-Board-Computer/Tinker-Board/). It is a > Cortex-A17 with Debian 9.8. Debian provides Valgrind 3.12. > > $ valgrind ./test.exe > ==8876== Memcheck, a memory error detector > ==8876== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. > ==8876== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info > ==8876== Command: ./test.exe > ==8876== > > valgrind: m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion > 'sizeof(TTEntryC) <= 88' failed. > Segmentation fault > > A quick pass in the bug tracker did not show hits for the error, so > I'm guessing it has not been reported. > > $ apt-cache show valgrind > Package: valgrind > Source: valgrind (1:3.12.0~svn20160714-1) > Version: 1:3.12.0~svn20160714-1+b1 > Installed-Size: 29965 > Maintainer: Alessandro Ghedini <gh...@de...> > Architecture: armhf > ... > > I can provide remote access to the board. I need authorized_keys. > > Jeff > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Jeffrey W. <nol...@gm...> - 2019-03-17 12:59:45
|
Hi Everyone, I'm working on a Tinker Board (https://www.asus.com/us/Single-Board-Computer/Tinker-Board/). It is a Cortex-A17 with Debian 9.8. Debian provides Valgrind 3.12. $ valgrind ./test.exe ==8876== Memcheck, a memory error detector ==8876== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==8876== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info ==8876== Command: ./test.exe ==8876== valgrind: m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion 'sizeof(TTEntryC) <= 88' failed. Segmentation fault A quick pass in the bug tracker did not show hits for the error, so I'm guessing it has not been reported. $ apt-cache show valgrind Package: valgrind Source: valgrind (1:3.12.0~svn20160714-1) Version: 1:3.12.0~svn20160714-1+b1 Installed-Size: 29965 Maintainer: Alessandro Ghedini <gh...@de...> Architecture: armhf ... I can provide remote access to the board. I need authorized_keys. Jeff |
|
From: Matthias A. <gu...@un...> - 2019-03-16 15:59:00
|
El día sábado, marzo 16, 2019 a las 11:50:48a. m. +0000, Tom Hughes escribió: > On 16/03/2019 11:42, Matthias Apitz wrote: > > El día sábado, marzo 16, 2019 a las 09:23:06a. m. +0100, Matthias Apitz escribió: > > > >>> What is the value of MAX_FSTAB_ROWS ? > >> > >> #define MAX_FSTAB_ROWS 3000 > > > > I set a gdb breakpoint at the entry of FstabInit(). The size of the > > array is: > > > > (gdb) p sizeof(t_sik_fstab) > > $4 = 950 > > (gdb) p sizeof(myFSTABrows) > > $5 = 2850000 > > > > and as well I can not see anything unusual while stepping through the > > init sequence of the function. > > That's nearly 3Mbytes that you are creating on the stack > which is quite a lot... > > More importantly it is more than the default value that > valgrind uses for --max-stackframe so it is likely to lead > to confusion - do you get a warning about a stack switch > being assumed before those other messages? > > Try using --max-stackframe=4000000 or something to specify > a larger maximum stack frame size and see if that helps. It says at the start when I set '--main-stacksize=640000000': ==5868== Memcheck, a memory error detector ==5868== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==5868== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==5868== Command: /opt/lib/sisis/opserver/bin/OPServer -p 4711 ==5868== 16.03.2019 09:17:15.772 OPServer <5868> : started at : 16.03.2019 09:17:15 ==5868== Warning: client switching stacks? SP change: 0xffefff3e8 --> 0xffed47690 ==5868== to suppress, use: --max-stackframe=2850136 or greater ==5868== Invalid write of size 4 ==5868== at 0x9DE90EF: FstabInit (BKFstab.c:2131) ==5868== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299) ==5868== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738) ==5868== by 0x413657: main (OPDaemon.c:272) ==5868== Address 0xffed476bc is on thread 1's stack ==5868== in frame #0, created by FstabInit (BKFstab.c:2131) Ahh, it's requesting to higher '--max-stackframe'. The '--main-stacksize' is per default 8M and big enough, but '--max-stackframe' is per default only 2000000. I set it to 8000000 and with this the warning above and the false positive about bad reads in FstabInit() disappeared. Thanks for the hint and I will think in rewrite this using malloc(3C). Lesson learned. matthias -- Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub |
|
From: Tom H. <to...@co...> - 2019-03-16 11:51:04
|
On 16/03/2019 11:42, Matthias Apitz wrote: > El día sábado, marzo 16, 2019 a las 09:23:06a. m. +0100, Matthias Apitz escribió: > >>> What is the value of MAX_FSTAB_ROWS ? >> >> #define MAX_FSTAB_ROWS 3000 > > I set a gdb breakpoint at the entry of FstabInit(). The size of the > array is: > > (gdb) p sizeof(t_sik_fstab) > $4 = 950 > (gdb) p sizeof(myFSTABrows) > $5 = 2850000 > > and as well I can not see anything unusual while stepping through the > init sequence of the function. That's nearly 3Mbytes that you are creating on the stack which is quite a lot... More importantly it is more than the default value that valgrind uses for --max-stackframe so it is likely to lead to confusion - do you get a warning about a stack switch being assumed before those other messages? Try using --max-stackframe=4000000 or something to specify a larger maximum stack frame size and see if that helps. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Matthias A. <gu...@un...> - 2019-03-16 11:42:35
|
El día sábado, marzo 16, 2019 a las 09:23:06a. m. +0100, Matthias Apitz escribió: > > What is the value of MAX_FSTAB_ROWS ? > > #define MAX_FSTAB_ROWS 3000 I set a gdb breakpoint at the entry of FstabInit(). The size of the array is: (gdb) p sizeof(t_sik_fstab) $4 = 950 (gdb) p sizeof(myFSTABrows) $5 = 2850000 and as well I can not see anything unusual while stepping through the init sequence of the function. 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-16 08:23:20
|
Hello John,
Thanks for follow-up.
El día viernes, marzo 15, 2019 a las 02:54:11p. m. -0700, John Reiser escribió:
> What is the version of valgrind? (run "valgrind --version")
# /usr/local/sisis-pap/bin/valgrind --version
valgrind-3.11.0
(compiled by myself)
> What is the hardware architecture?
# uname -a
Linux srap18dxr1 4.12.14-95.3-default #1 SMP Wed Dec 5 06:00:48 UTC 2018 (63a8d29) x86_64 x86_64 x86_64 GNU/Linux
The process in question is:
# file /opt/lib/sisis/opserver/bin/OPServer
/opt/lib/sisis/opserver/bin/OPServer: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.0.0, BuildID[sha1]=ec9556bbcae06e85560d496b1755342aae9391d6, not stripped
I'm attaching below the output of 'pmap -x PID'.
> What is the value of MAX_FSTAB_ROWS ?
#define MAX_FSTAB_ROWS 3000
> > ==9332== Address 0xffed476bc is on thread 1's stack
> Note that the address of the Invalid write is 0xffed476bc which is 0xf_fed4_76bc or around 63 GiB.
> That is very large, so large that it is very much more than the usual default maximum size
> of a thread stack, which typically is 8 MiB or 16 MiB.
> Try invoking valgrind with the parameter --main-stacksize=64000000000 which *might* work.
> Otherwise: use malloc() instead of on-stack allocation for the myFSTABrows array.
I do not know exactly the sizeof(t_sik_fstab) but this will not exceed
10k and 3000 x 10k does not go so far. With '--main-stacksize=64000000000'
valgrind does not start anymore, but with '--main-stacksize=640000000'
and it says now the same with other addr values, but as I said BKFstab.c:2131
is the line of the function:
PFSTAB FstabInit(
FSTAB_SetId id /* Set-Id fuer die jeweilige FSTAB */
)
{ <----- line 2131
/*-------------------------------------------------------------------------*/
char *funk = "FstabInit()";
/* t_sik_fstab lesePuffer=SIK_FSTAB_EMPTY; */
DB_ERR dbError;
PFSTAB fstab = NULL;
int anzFstabElemente = 0, anzIndikatorfelder = 0;
int anzRows = 0;
...
==5868== Invalid write of size 4
==5868== at 0x9DE90EF: FstabInit (BKFstab.c:2131)
==5868== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299)
==5868== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738)
==5868== by 0x413657: main (OPDaemon.c:272)
==5868== Address 0xffed476bc is on thread 1's stack
==5868== in frame #0, created by FstabInit (BKFstab.c:2131)
==5868==
==5868== Invalid read of size 4
==5868== at 0x9DE911D: FstabInit (BKFstab.c:2151)
==5868== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299)
==5868== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738)
==5868== by 0x413657: main (OPDaemon.c:272)
==5868== Address 0xffed476bc is on thread 1's stack
==5868== in frame #0, created by FstabInit (BKFstab.c:2131)
==5868==
How valgrind can come to this large addr 0xffed476bc?
# pmap -x 2149
2149: OPServer
START SIZE RSS PSS DIRTY PERM MAPPING
0000000000400000 168K 168K 16K 0K r-xp /opt/lib/sisis/opserver/bin/OPServer
000000000062a000 4K 4K 0K 4K r--p /opt/lib/sisis/opserver/bin/OPServer
000000000062b000 32K 32K 6K 24K rw-p /opt/lib/sisis/opserver/bin/OPServer
0000000000633000 28K 8K 4K 8K rw-p [anon]
00000000025fc000 3448K 3408K 809K 3408K rw-p [heap]
00007fdfb68f6000 1216K 0K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_COLLATE
00007fdfb6a26000 252K 248K 24K 248K rw-p [anon]
00007fdfb6a95000 272K 64K 1K 0K r--p /usr/lib/locale/de_DE.utf8/LC_CTYPE
00007fdfb6ad9000 128K 128K 12K 128K rw-p [anon]
00007fdfb6b36000 128K 128K 12K 128K rw-p [anon]
00007fdfb6b92000 356K 0K 0K 0K r-xp /opt/sybase157sp130/OCS-15_0/lib/libsybunic64.so
00007fdfb6beb000 2044K 0K 0K 0K ---p /opt/sybase157sp130/OCS-15_0/lib/libsybunic64.so
00007fdfb6dea000 332K 196K 17K 172K rw-p /opt/sybase157sp130/OCS-15_0/lib/libsybunic64.so
00007fdfb6e3d000 96K 84K 1K 0K r-xp /lib64/libpthread-2.22.so
00007fdfb6e55000 2044K 0K 0K 0K ---p /lib64/libpthread-2.22.so
00007fdfb7054000 4K 4K 0K 4K r--p /lib64/libpthread-2.22.so
00007fdfb7055000 4K 4K 4K 4K rw-p /lib64/libpthread-2.22.so
00007fdfb7056000 16K 4K 4K 4K rw-p [anon]
00007fdfb705a000 32K 32K 0K 0K r-xp /opt/sybase157sp130/OCS-15_0/lib/libsybintl64.so
00007fdfb7062000 2048K 0K 0K 0K ---p /opt/sybase157sp130/OCS-15_0/lib/libsybintl64.so
00007fdfb7262000 4K 4K 0K 4K rw-p /opt/sybase157sp130/OCS-15_0/lib/libsybintl64.so
00007fdfb7263000 684K 512K 12K 0K r-xp /opt/sybase157sp130/OCS-15_0/lib/libsybcomn64.so
00007fdfb730e000 2044K 0K 0K 0K ---p /opt/sybase157sp130/OCS-15_0/lib/libsybcomn64.so
00007fdfb750d000 56K 56K 8K 52K rw-p /opt/sybase157sp130/OCS-15_0/lib/libsybcomn64.so
00007fdfb751b000 12K 12K 1K 12K rw-p [anon]
00007fdfb751e000 152K 128K 3K 0K r-xp /opt/sybase157sp130/OCS-15_0/lib/libsybtcl64.so
00007fdfb7544000 2044K 0K 0K 0K ---p /opt/sybase157sp130/OCS-15_0/lib/libsybtcl64.so
00007fdfb7743000 4K 4K 0K 4K rw-p /opt/sybase157sp130/OCS-15_0/lib/libsybtcl64.so
00007fdfb7744000 8K 8K 4K 8K rw-p [anon]
00007fdfb7746000 76K 76K 1K 0K r-xp /opt/sybase157sp130/OCS-15_0/lib/libsybcs64.so
00007fdfb7759000 2044K 0K 0K 0K ---p /opt/sybase157sp130/OCS-15_0/lib/libsybcs64.so
00007fdfb7958000 4K 4K 0K 4K rw-p /opt/sybase157sp130/OCS-15_0/lib/libsybcs64.so
00007fdfb7959000 572K 512K 12K 0K r-xp /opt/sybase157sp130/OCS-15_0/lib/libsybct64.so
00007fdfb79e8000 2044K 0K 0K 0K ---p /opt/sybase157sp130/OCS-15_0/lib/libsybct64.so
00007fdfb7be7000 72K 72K 7K 72K rw-p /opt/sybase157sp130/OCS-15_0/lib/libsybct64.so
00007fdfb7bf9000 1644K 1344K 18K 0K r-xp /lib64/libc-2.22.so
00007fdfb7d94000 2048K 0K 0K 0K ---p /lib64/libc-2.22.so
00007fdfb7f94000 16K 16K 1K 16K r--p /lib64/libc-2.22.so
00007fdfb7f98000 8K 8K 8K 8K rw-p /lib64/libc-2.22.so
00007fdfb7f9a000 16K 16K 12K 16K rw-p [anon]
00007fdfb7f9e000 940K 64K 1K 0K r-xp /usr/local/sisis-pap/lib/libiconv.so.2.5.0
00007fdfb8089000 2044K 0K 0K 0K ---p /usr/local/sisis-pap/lib/libiconv.so.2.5.0
00007fdfb8288000 8K 8K 0K 8K r--p /usr/local/sisis-pap/lib/libiconv.so.2.5.0
00007fdfb828a000 4K 4K 0K 4K rw-p /usr/local/sisis-pap/lib/libiconv.so.2.5.0
00007fdfb828b000 2000K 1408K 115K 0K r-xp /usr/local/sisis-pap/lib/libcrypto.so.1.1
00007fdfb847f000 2044K 0K 0K 0K ---p /usr/local/sisis-pap/lib/libcrypto.so.1.1
00007fdfb867e000 116K 116K 11K 116K r--p /usr/local/sisis-pap/lib/libcrypto.so.1.1
00007fdfb869b000 40K 40K 14K 40K rw-p /usr/local/sisis-pap/lib/libcrypto.so.1.1
00007fdfb86a5000 12K 12K 12K 12K rw-p [anon]
00007fdfb86a8000 404K 372K 27K 0K r-xp /usr/local/sisis-pap/lib/libssl.so.1.1
00007fdfb870d000 2044K 0K 0K 0K ---p /usr/local/sisis-pap/lib/libssl.so.1.1
00007fdfb890c000 16K 16K 1K 16K r--p /usr/local/sisis-pap/lib/libssl.so.1.1
00007fdfb8910000 24K 24K 20K 24K rw-p /usr/local/sisis-pap/lib/libssl.so.1.1
00007fdfb8916000 1692K 64K 1K 0K r-xp /usr/local/sisis-pap/lib/libxml2.so.2.6.32
00007fdfb8abd000 2048K 0K 0K 0K ---p /usr/local/sisis-pap/lib/libxml2.so.2.6.32
00007fdfb8cbd000 28K 28K 2K 28K r--p /usr/local/sisis-pap/lib/libxml2.so.2.6.32
00007fdfb8cc4000 12K 12K 1K 12K rw-p /usr/local/sisis-pap/lib/libxml2.so.2.6.32
00007fdfb8cc7000 4K 0K 0K 0K rw-p [anon]
00007fdfb8cc8000 44K 44K 0K 0K r-xp /lib64/libcrypt-2.22.so
00007fdfb8cd3000 2048K 0K 0K 0K ---p /lib64/libcrypt-2.22.so
00007fdfb8ed3000 4K 4K 0K 4K r--p /lib64/libcrypt-2.22.so
00007fdfb8ed4000 4K 4K 0K 4K rw-p /lib64/libcrypt-2.22.so
00007fdfb8ed5000 184K 0K 0K 0K rw-p [anon]
00007fdfb8f03000 8K 8K 0K 0K r-xp /lib64/libdl-2.22.so
00007fdfb8f05000 2048K 0K 0K 0K ---p /lib64/libdl-2.22.so
00007fdfb9105000 4K 4K 0K 4K r--p /lib64/libdl-2.22.so
00007fdfb9106000 4K 4K 4K 4K rw-p /lib64/libdl-2.22.so
00007fdfb9107000 1008K 128K 3K 0K r-xp /usr/local/sisis-pap/lib/libglib-2.0.so.0.2000.0
00007fdfb9203000 2048K 0K 0K 0K ---p /usr/local/sisis-pap/lib/libglib-2.0.so.0.2000.0
00007fdfb9403000 4K 4K 0K 4K r--p /usr/local/sisis-pap/lib/libglib-2.0.so.0.2000.0
00007fdfb9404000 4K 4K 0K 4K rw-p /usr/local/sisis-pap/lib/libglib-2.0.so.0.2000.0
00007fdfb9405000 1004K 64K 1K 0K r-xp /lib64/libm-2.22.so
00007fdfb9500000 2048K 0K 0K 0K ---p /lib64/libm-2.22.so
00007fdfb9700000 4K 4K 0K 4K r--p /lib64/libm-2.22.so
00007fdfb9701000 4K 4K 0K 4K rw-p /lib64/libm-2.22.so
00007fdfb9702000 88K 64K 1K 0K r-xp /lib64/libnsl-2.22.so
00007fdfb9718000 2044K 0K 0K 0K ---p /lib64/libnsl-2.22.so
00007fdfb9917000 4K 4K 0K 4K r--p /lib64/libnsl-2.22.so
00007fdfb9918000 4K 4K 0K 4K rw-p /lib64/libnsl-2.22.so
00007fdfb9919000 8K 0K 0K 0K rw-p [anon]
00007fdfb991b000 108K 64K 1K 0K r-xp /usr/local/sisis-pap/lib/libz.so.1.2.8
00007fdfb9936000 2044K 0K 0K 0K ---p /usr/local/sisis-pap/lib/libz.so.1.2.8
00007fdfb9b35000 4K 4K 0K 4K r--p /usr/local/sisis-pap/lib/libz.so.1.2.8
00007fdfb9b36000 4K 4K 0K 4K rw-p /usr/local/sisis-pap/lib/libz.so.1.2.8
00007fdfb9b37000 24K 24K 1K 0K r-xp /opt/lib/sisis/lib/libIDServer.so
00007fdfb9b3d000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libIDServer.so
00007fdfb9d3c000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libIDServer.so
00007fdfb9d3d000 4K 4K 4K 4K rw-p /opt/lib/sisis/lib/libIDServer.so
00007fdfb9d3e000 12K 0K 0K 0K r-xp /opt/lib/sisis/opserver/lib/libpdservice.so
00007fdfb9d41000 2044K 0K 0K 0K ---p /opt/lib/sisis/opserver/lib/libpdservice.so
00007fdfb9f40000 4K 4K 0K 4K r--p /opt/lib/sisis/opserver/lib/libpdservice.so
00007fdfb9f41000 4K 4K 0K 4K rw-p /opt/lib/sisis/opserver/lib/libpdservice.so
00007fdfb9f42000 20832K 704K 28K 0K r-xp /opt/lib/sisis/lib/syb157/libdbcall.so
00007fdfbb39a000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/syb157/libdbcall.so
00007fdfbb599000 8K 8K 0K 8K r--p /opt/lib/sisis/lib/syb157/libdbcall.so
00007fdfbb59b000 52K 52K 9K 16K rw-p /opt/lib/sisis/lib/syb157/libdbcall.so
00007fdfbb5a8000 2884K 2068K 2064K 2068K rw-p [anon]
00007fdfbb879000 164K 128K 3K 0K r-xp /opt/lib/sisis/lib/libsbstring.so
00007fdfbb8a2000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libsbstring.so
00007fdfbbaa1000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libsbstring.so
00007fdfbbaa2000 360K 360K 36K 360K rw-p /opt/lib/sisis/lib/libsbstring.so
00007fdfbbafc000 8K 4K 0K 4K rw-p [anon]
00007fdfbbafe000 320K 0K 0K 0K r-xp /opt/lib/sisis/lib/librech.so
00007fdfbbb4e000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/librech.so
00007fdfbbd4d000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/librech.so
00007fdfbbd4e000 8K 8K 1K 8K rw-p /opt/lib/sisis/lib/librech.so
00007fdfbbd50000 4512K 4K 0K 4K rw-p [anon]
00007fdfbc1b8000 288K 0K 0K 0K r-xp /opt/lib/sisis/lib/libsikisserver.so
00007fdfbc200000 2048K 0K 0K 0K ---p /opt/lib/sisis/lib/libsikisserver.so
00007fdfbc400000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libsikisserver.so
00007fdfbc401000 8K 8K 0K 8K rw-p /opt/lib/sisis/lib/libsikisserver.so
00007fdfbc403000 164K 16K 1K 16K rw-p [anon]
00007fdfbc42c000 60K 0K 0K 0K r-xp /opt/lib/sisis/lib/libopacserver.so
00007fdfbc43b000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libopacserver.so
00007fdfbc63a000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libopacserver.so
00007fdfbc63b000 36K 36K 2K 16K rw-p /opt/lib/sisis/lib/libopacserver.so
00007fdfbc644000 8K 0K 0K 0K rw-p [anon]
00007fdfbc646000 4K 0K 0K 0K r-xp /opt/lib/sisis/lib/libBSA.so
00007fdfbc647000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libBSA.so
00007fdfbc846000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libBSA.so
00007fdfbc847000 4K 4K 0K 4K rw-p /opt/lib/sisis/lib/libBSA.so
00007fdfbc848000 556K 0K 0K 0K r-xp /opt/lib/sisis/lib/libsiasbase.so
00007fdfbc8d3000 2048K 0K 0K 0K ---p /opt/lib/sisis/lib/libsiasbase.so
00007fdfbcad3000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libsiasbase.so
00007fdfbcad4000 8K 8K 1K 8K rw-p /opt/lib/sisis/lib/libsiasbase.so
00007fdfbcad6000 176K 20K 2K 20K rw-p [anon]
00007fdfbcb02000 132K 0K 0K 0K r-xp /opt/lib/sisis/lib/libsicall.so
00007fdfbcb23000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libsicall.so
00007fdfbcd22000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libsicall.so
00007fdfbcd23000 4K 4K 0K 4K rw-p /opt/lib/sisis/lib/libsicall.so
00007fdfbcd24000 12K 0K 0K 0K rw-p [anon]
00007fdfbcd27000 860K 0K 0K 0K r-xp /opt/lib/sisis/lib/libsiasserver.so
00007fdfbcdfe000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libsiasserver.so
00007fdfbcffd000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libsiasserver.so
00007fdfbcffe000 8K 8K 1K 8K rw-p /opt/lib/sisis/lib/libsiasserver.so
00007fdfbd000000 180K 0K 0K 0K rw-p [anon]
00007fdfbd02d000 16K 0K 0K 0K r-xp /opt/lib/sisis/lib/libInfo2ZFL.so
00007fdfbd031000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libInfo2ZFL.so
00007fdfbd230000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libInfo2ZFL.so
00007fdfbd231000 4K 4K 0K 4K rw-p /opt/lib/sisis/lib/libInfo2ZFL.so
00007fdfbd232000 4K 0K 0K 0K rw-p [anon]
00007fdfbd233000 56K 0K 0K 0K r-xp /opt/lib/sisis/lib/libpfl.so
00007fdfbd241000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libpfl.so
00007fdfbd440000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libpfl.so
00007fdfbd441000 4K 4K 0K 4K rw-p /opt/lib/sisis/lib/libpfl.so
00007fdfbd442000 24K 0K 0K 0K rw-p [anon]
00007fdfbd448000 428K 0K 0K 0K r-xp /opt/lib/sisis/lib/libcopz39.so
00007fdfbd4b3000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libcopz39.so
00007fdfbd6b2000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libcopz39.so
00007fdfbd6b3000 24K 24K 2K 20K rw-p /opt/lib/sisis/lib/libcopz39.so
00007fdfbd6b9000 84K 0K 0K 0K rw-p [anon]
00007fdfbd6ce000 148K 0K 0K 0K r-xp /opt/lib/sisis/lib/libslnpz39.so
00007fdfbd6f3000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libslnpz39.so
00007fdfbd8f2000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libslnpz39.so
00007fdfbd8f3000 4K 4K 0K 4K rw-p /opt/lib/sisis/lib/libslnpz39.so
00007fdfbd8f4000 8K 0K 0K 0K rw-p [anon]
00007fdfbd8f6000 92K 0K 0K 0K r-xp /opt/lib/sisis/lib/libz39.so
00007fdfbd90d000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libz39.so
00007fdfbdb0c000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libz39.so
00007fdfbdb0d000 4K 4K 0K 4K rw-p /opt/lib/sisis/lib/libz39.so
00007fdfbdb0e000 156K 148K 4K 0K r-xp /opt/lib/sisis/lib/libslnp.so
00007fdfbdb35000 2048K 0K 0K 0K ---p /opt/lib/sisis/lib/libslnp.so
00007fdfbdd35000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libslnp.so
00007fdfbdd36000 8K 8K 8K 8K rw-p /opt/lib/sisis/lib/libslnp.so
00007fdfbdd38000 16408K 20K 20K 20K rw-p [anon]
00007fdfbed3e000 28K 0K 0K 0K r-xp /opt/lib/sisis/lib/libslnpstd.so
00007fdfbed45000 2048K 0K 0K 0K ---p /opt/lib/sisis/lib/libslnpstd.so
00007fdfbef45000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libslnpstd.so
00007fdfbef46000 4K 4K 0K 4K rw-p /opt/lib/sisis/lib/libslnpstd.so
00007fdfbef47000 72K 0K 0K 0K r-xp /opt/lib/sisis/opserver/lib/libcmdops.so
00007fdfbef59000 2044K 0K 0K 0K ---p /opt/lib/sisis/opserver/lib/libcmdops.so
00007fdfbf158000 4K 4K 0K 4K r--p /opt/lib/sisis/opserver/lib/libcmdops.so
00007fdfbf159000 24K 24K 2K 24K rw-p /opt/lib/sisis/opserver/lib/libcmdops.so
00007fdfbf15f000 220K 0K 0K 0K r-xp /opt/lib/sisis/opserver/lib/libslnpops.so
00007fdfbf196000 2044K 0K 0K 0K ---p /opt/lib/sisis/opserver/lib/libslnpops.so
00007fdfbf395000 4K 4K 0K 4K r--p /opt/lib/sisis/opserver/lib/libslnpops.so
00007fdfbf396000 4K 4K 0K 4K rw-p /opt/lib/sisis/opserver/lib/libslnpops.so
00007fdfbf397000 392K 128K 12K 0K r-xp /opt/lib/sisis/opserver/lib/libops.so
00007fdfbf3f9000 2044K 0K 0K 0K ---p /opt/lib/sisis/opserver/lib/libops.so
00007fdfbf5f8000 4K 4K 0K 4K r--p /opt/lib/sisis/opserver/lib/libops.so
00007fdfbf5f9000 112K 36K 4K 16K rw-p /opt/lib/sisis/opserver/lib/libops.so
00007fdfbf615000 148K 16K 5K 16K rw-p [anon]
00007fdfbf63a000 16K 16K 0K 0K r-xp /opt/lib/sisis/lib/libsrvtrace.so
00007fdfbf63e000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libsrvtrace.so
00007fdfbf83d000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libsrvtrace.so
00007fdfbf83e000 4K 4K 4K 4K rw-p /opt/lib/sisis/lib/libsrvtrace.so
00007fdfbf83f000 20480K 0K 0K 0K rw-p [anon]
00007fdfc0c3f000 688K 0K 0K 0K r-xp /opt/lib/sisis/lib/libslnpbts.so
00007fdfc0ceb000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libslnpbts.so
00007fdfc0eea000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libslnpbts.so
00007fdfc0eeb000 4K 4K 0K 4K rw-p /opt/lib/sisis/lib/libslnpbts.so
00007fdfc0eec000 32K 0K 0K 0K r-xp /opt/lib/sisis/lib/libnahrot.so
00007fdfc0ef4000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libnahrot.so
00007fdfc10f3000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libnahrot.so
00007fdfc10f4000 4K 4K 0K 4K rw-p /opt/lib/sisis/lib/libnahrot.so
00007fdfc10f5000 12K 0K 0K 0K rw-p [anon]
00007fdfc10f8000 480K 0K 0K 0K r-xp /opt/lib/sisis/lib/libbts.so
00007fdfc1170000 2044K 0K 0K 0K ---p /opt/lib/sisis/lib/libbts.so
00007fdfc136f000 4K 4K 0K 4K r--p /opt/lib/sisis/lib/libbts.so
00007fdfc1370000 8K 8K 0K 8K rw-p /opt/lib/sisis/lib/libbts.so
00007fdfc1372000 320K 0K 0K 0K rw-p [anon]
00007fdfc13c2000 132K 132K 1K 0K r-xp /lib64/ld-2.22.so
00007fdfc1426000 252K 248K 24K 248K rw-p [anon]
00007fdfc147d000 128K 128K 12K 128K rw-p [anon]
00007fdfc14b3000 152K 152K 12K 0K r--p /usr/share/locale/de/LC_MESSAGES/libc.mo
00007fdfc14d9000 212K 64K 1K 64K r--s /run/nscd/dbWCJN5T
00007fdfc150e000 444K 0K 0K 0K r--p /opt/lib/nls/msg/de_DE.UTF-8/ops.cat.utf8
00007fdfc157d000 212K 64K 2K 64K r--s /run/nscd/passwd
00007fdfc15b2000 44K 44K 11K 44K rw-p [anon]
00007fdfc15c8000 4K 4K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_NUMERIC
00007fdfc15c9000 4K 0K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_TIME
00007fdfc15ca000 4K 0K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_MONETARY
00007fdfc15cb000 4K 0K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_MESSAGES/SYS_LC_MESSAGES
00007fdfc15cc000 4K 0K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_PAPER
00007fdfc15cd000 4K 0K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_NAME
00007fdfc15ce000 4K 0K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_ADDRESS
00007fdfc15cf000 4K 0K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_TELEPHONE
00007fdfc15d0000 4K 0K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_MEASUREMENT
00007fdfc15d1000 28K 28K 1K 0K r--s /usr/lib64/gconv/gconv-modules.cache
00007fdfc15d8000 4K 0K 0K 0K r--p /usr/lib/locale/de_DE.utf8/LC_IDENTIFICATION
00007fdfc15d9000 40K 40K 11K 40K rw-p [anon]
00007fdfc15e3000 4K 4K 0K 4K r--p /lib64/ld-2.22.so
00007fdfc15e4000 4K 4K 4K 4K rw-p /lib64/ld-2.22.so
00007fdfc15e5000 4K 4K 4K 4K rw-p [anon]
00007ffccdbf5000 2860K 992K 122K 992K rw-p [stack]
00007ffccdf0e000 12K 0K 0K 0K r--p [vvar]
00007ffccdf11000 8K 4K 0K 0K r-xp [vdso]
ffffffffff600000 4K 0K 0K 0K r-xp [vsyscall]
Total: 182480K 15816K 3631K 9032K
54336K writable-private, 127692K readonly-private, 452K shared, and 9964K referenced
--
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
|
|
From: John R. <jr...@bi...> - 2019-03-15 21:54:29
|
What is the version of valgrind? (run "valgrind --version")
What is the hardware architecture?
What is the value of MAX_FSTAB_ROWS ?
> ==9332== Address 0xffed476bc is on thread 1's stack
Note that the address of the Invalid write is 0xffed476bc which is 0xf_fed4_76bc or around 63 GiB.
That is very large, so large that it is very much more than the usual default maximum size
of a thread stack, which typically is 8 MiB or 16 MiB.
Try invoking valgrind with the parameter --main-stacksize=64000000000 which *might* work.
Otherwise: use malloc() instead of on-stack allocation for the myFSTABrows array.
> 2128 PFSTAB FstabInit(
> 2129 FSTAB_SetId id /* Set-Id fuer die jeweilige FSTAB */
> 2130 )
> 2131 {
> 2132 /*-------------------------------------------------------------------------*/
> 2133 char *funk = "FstabInit()";
> 2134
> 2135 /* t_sik_fstab lesePuffer=SIK_FSTAB_EMPTY; */
> 2136 DB_ERR dbError;
> 2137 PFSTAB fstab = NULL;
> 2138
> 2139 int anzFstabElemente = 0, anzIndikatorfelder = 0;
> 2140 int anzRows = 0;
> 2141
> 2142 /* SRP-23121: we read the complete FSTAB into memory because we
> 2143 * have to pass twice through it for the logic of indicator fields
> 2144 *
> 2145 * maybe we should malloc() the space ...
> 2146 * the number MAX_FSTAB_ROWS is the limit for one set in FSTAB
> 2147 */
> 2148 t_sik_fstab myFSTABrows[MAX_FSTAB_ROWS];
> 2149
> 2150 /* check the SetId */
> 2151 if( id == FSTAB_Null || id >= FSTAB_Alle ) goto ABBRUCH;
> 2152
> 2153 /* init the buffer for read */
> 2154 memset( &myFSTABrows[anzRows], 0, sizeof( t_sik_fstab ));
> 2155
>
>
> ---------------------------
>
> ==9332== Invalid write of size 4
> ==9332== at 0x9DE90EF: FstabInit (BKFstab.c:2131)
> ==9332== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299)
> ==9332== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738)
> ==9332== by 0x413657: main (OPDaemon.c:272)
> ==9332== Address 0xffed476bc is on thread 1's stack
> ==9332== in frame #0, created by FstabInit (BKFstab.c:2131)
> ==9332==
> ==9332== Invalid read of size 4
> ==9332== at 0x9DE911D: FstabInit (BKFstab.c:2151)
> ==9332== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299)
> ==9332== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738)
> ==9332== by 0x413657: main (OPDaemon.c:272)
> ==9332== Address 0xffed476bc is on thread 1's stack
> ==9332== in frame #0, created by FstabInit (BKFstab.c:2131)
|
|
From: Matthias A. <gu...@un...> - 2019-03-15 19:02:59
|
Hello,
While I'm often identifying the issue in our C source (compiled as 64bit on
Linux) I have here a case, which I do not understand and I'd like to ask
for some help. I have below the valgrind warnings and the C-code with
line numbers (from vim). It starts already with the 1st complaint about
"Invalid write of size 4" on line 2131. There is no code, just the start
of the function with a '{'.
Thanks for some explanations.
matthias
2128 PFSTAB FstabInit(
2129 FSTAB_SetId id /* Set-Id fuer die jeweilige FSTAB */
2130 )
2131 {
2132 /*-------------------------------------------------------------------------*/
2133 char *funk = "FstabInit()";
2134
2135 /* t_sik_fstab lesePuffer=SIK_FSTAB_EMPTY; */
2136 DB_ERR dbError;
2137 PFSTAB fstab = NULL;
2138
2139 int anzFstabElemente = 0, anzIndikatorfelder = 0;
2140 int anzRows = 0;
2141
2142 /* SRP-23121: we read the complete FSTAB into memory because we
2143 * have to pass twice through it for the logic of indicator fields
2144 *
2145 * maybe we should malloc() the space ...
2146 * the number MAX_FSTAB_ROWS is the limit for one set in FSTAB
2147 */
2148 t_sik_fstab myFSTABrows[MAX_FSTAB_ROWS];
2149
2150 /* check the SetId */
2151 if( id == FSTAB_Null || id >= FSTAB_Alle ) goto ABBRUCH;
2152
2153 /* init the buffer for read */
2154 memset( &myFSTABrows[anzRows], 0, sizeof( t_sik_fstab ));
2155
---------------------------
==9332== Invalid write of size 4
==9332== at 0x9DE90EF: FstabInit (BKFstab.c:2131)
==9332== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299)
==9332== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738)
==9332== by 0x413657: main (OPDaemon.c:272)
==9332== Address 0xffed476bc is on thread 1's stack
==9332== in frame #0, created by FstabInit (BKFstab.c:2131)
==9332==
==9332== Invalid read of size 4
==9332== at 0x9DE911D: FstabInit (BKFstab.c:2151)
==9332== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299)
==9332== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738)
==9332== by 0x413657: main (OPDaemon.c:272)
==9332== Address 0xffed476bc is on thread 1's stack
==9332== in frame #0, created by FstabInit (BKFstab.c:2131)
==9332==
==9332== Invalid read of size 4
==9332== at 0x9DE912A: FstabInit (BKFstab.c:2151)
==9332== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299)
==9332== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738)
==9332== by 0x413657: main (OPDaemon.c:272)
==9332== Address 0xffed476bc is on thread 1's stack
==9332== in frame #0, created by FstabInit (BKFstab.c:2131)
==9332==
==9332== Invalid write of size 8
==9332== at 0x9DE915A: FstabInit (BKFstab.c:2154)
==9332== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299)
==9332== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738)
==9332== by 0x413657: main (OPDaemon.c:272)
==9332== Address 0xffed47688 is on thread 1's stack
==9332== in frame #0, created by FstabInit (BKFstab.c:2131)
==9332==
==9332== Invalid write of size 8
==9332== at 0x4C305C7: memset (vg_replace_strmem.c:1224)
==9332== by 0x9DE915E: FstabInit (BKFstab.c:2154)
==9332== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299)
==9332== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738)
==9332== by 0x413657: main (OPDaemon.c:272)
==9332== Address 0xffed476c0 is on thread 1's stack
==9332== in frame #1, created by FstabInit (BKFstab.c:2131)
==9332==
==9332== Invalid write of size 1
==9332== at 0x4C305E0: memset (vg_replace_strmem.c:1224)
==9332== by 0x9DE915E: FstabInit (BKFstab.c:2154)
==9332== by 0x6BFF1E8: OpsInitDatabase (SRVServerInit.c:1299)
==9332== by 0x413B48: SlnpInitDaemon (OPDaemon.c:738)
==9332== by 0x413657: main (OPDaemon.c:272)
==9332== Address 0xffed47a70 is on thread 1's stack
--
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
What is a good definition for Legacy Software? -- This is one which works.
|
|
From: Adam N. <an...@so...> - 2019-03-14 22:35:08
|
In HPC/cluster environments, users often don't have root and can't use traditional package managers; I generally need to build and install software with a --prefix sent to the configure script. It's not that I don't want to build valgrind; I do want to build it from source. But I want to have some assurance that the source I got is the source everyone else got, given that I trust the valgrind project. What I don't want to have to do is to audit the whole codebase myself after each download/clone. The recommended clone command on http://valgrind.org/downloads/repository.html should be `git clone https://sourceware.org/git/valgrind.git`, and the mirror clone command should be changed to `git clone https://repo.or.cz/valgrind.git`, both of which appear to be availabe. I shouldn't have to guess at the existence of a secure way to clone the repo and fix up an insecure default command; it should be documented and the default. If the only secure way to get valgrind's source is to clone the Git repo, then that should be the recommended installation process; the source tarballs should be offered as a backup solution only for people who can't clone the repo (myself excluded). The current releases page at http://valgrind.org/downloads/current.html should thus contain the Git commands to clone the repo and check out the latest tag, above the links to the tarballs. The way the site is laid out now, it looks like the insecure tarball downloads are the recommended way for people not using a package manager to get a copy of valgrind. Is there a repository for the web site where I can propose a patch? On 3/14/19, John Reiser <jr...@bi...> wrote: >> *And* I >> have to clone the whole git repo when really I just want to install >> the current release of the program > That is by design. If *you* want to get the bits that way, then *you* must > build valgrind. > Besides, the repo is not large, and building it is not long. > Someone whose email address ends in .ucsc.edu should have no resource > problems. > > If the goal is "install the current release" with the least hassle, > then you should consider installing the current release from a > Linux distribution such as Fedora or Debian. The .rpm or .deb > is "signed by someone reputable". It may even have some bugs fixed > already. > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: John R. <jr...@bi...> - 2019-03-14 21:48:45
|
> *And* I > have to clone the whole git repo when really I just want to install > the current release of the program That is by design. If *you* want to get the bits that way, then *you* must build valgrind. Besides, the repo is not large, and building it is not long. Someone whose email address ends in .ucsc.edu should have no resource problems. If the goal is "install the current release" with the least hassle, then you should consider installing the current release from a Linux distribution such as Fedora or Debian. The .rpm or .deb is "signed by someone reputable". It may even have some bugs fixed already. |
|
From: Adam N. <an...@so...> - 2019-03-14 21:07:59
|
Hello, I'm looking for a secure way to download the Valgrind source tarballs, or to verify their hashes. Right now it looks like the whole Valgrind web site, including the official downloads, is only available over HTTP (yet is also available over IPv6). So downloads could be tampered with in transit, and probably shouldn't be installed on any systems that need to be secure. (In my case, I'm trying to profile programs on a system that has access to controlled-access genomics data, which needs to be protected.) I've found that I can clone https://sourceware.org/git/valgrind.git over a secure connection, but I got that URL from the insecure page, so I'm relying on Sourceware's reputation as a place where malicious software is not hosted. And I'm not following any of the recommended install instructions; I had to manually add in the "s" there. *And* I have to clone the whole git repo when really I just want to install the current release of the program. Can the Valgrind website, or at least the tarball downloads, please be given HTTPS support? Or GPG-signed by someone reputable? Thanks, -Adam |
|
From: Patrick J. L. <lop...@gm...> - 2019-03-11 22:17:38
|
I believe Helgrind does not understand modern GCC implementations of the Meyers Singleton. You will see similar warnings for any non-trivial static object. See e.g. https://stackoverflow.com/q/44698412/ I vaguely recall this was discussed here before and deemed "hard to fix". But I cannot seem to find that discussion. - Pat On Mon, Mar 11, 2019 at 2:59 PM André Offringa <off...@gm...> wrote: > 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é > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
188 messages has been excluded from this view by a project administrator.
