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
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
