Re: [Valgrind-users] VEX temporary storage exhausted

2019-03-23 Thread Philippe Waroquiers 
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 6 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= 

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= --trace-notbelow=X 
where X 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



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] VEX temporary storage exhausted

2019-03-21 Thread Philippe Waroquiers 
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 6 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
> 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

Re: [Valgrind-users] VEX temporary storage exhausted

2019-03-20 Thread Yuri D'Elia 
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)
...



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] VEX temporary storage exhausted

2019-03-20 Thread Philippe Waroquiers 
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



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] VEX temporary storage exhausted

2019-03-19 Thread Yuri D'Elia 
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

2019-03-19 Thread Philippe Waroquiers 
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

[Valgrind-users] VEX temporary storage exhausted

2019-03-19 Thread Yuri D'Elia 
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