Re: [Valgrind-users] VEX temporary storage exhausted
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. ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] VEX temporary storage exhausted
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 500)
>
> 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
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind hangs on my RHEL-7 box
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 0x000e10, avma 0x002fe04e10 > --2921-- cfsi range rx-mappings coverage check: Covered > 0x0-0x > --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 > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] VEX temporary storage exhausted
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 500)
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? ;)
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [EXTERNAL] Valgrind hangs on my RHEL-7 box
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 0x000e10, avma 0x002fe04e10 --2921-- cfsi range rx-mappings coverage check: Covered 0x0-0x --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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Valgrind hangs on my RHEL-7 box
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 0x000e10, avma 0x002fe04e10 --2921-- cfsi range rx-mappings coverage check: Covered 0x0-0x --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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
