Re: [Valgrind-users] Assertion 'eltSzB <= ddpa->poolSzB' failed

[David H. <da...@da...>]

Hi Philippe,

thanks a lot for the quick reply!

I have rerun the test with -v -v -v -d -d -d options and attached the log.
I have also tested compiling the binary with gcc-5.2.1 and there I also see
the problem, so it doesn't look to be compiler specific.

If you have some specific patches you want tested, I can pull the valgrind
sources and do a local build?

Thanks for your help

/David

On Wed, Feb 3, 2016 at 9:50 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Wed, 2016-02-03 at 21:33 +0100, Philippe Waroquiers wrote:
> > On Wed, 2016-02-03 at 20:45 +0100, David Hallas wrote:
> >
> > > valgrind: m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion
> > > 'eltSzB <= ddpa->poolSzB' failed.
> > > I am running on a 64bit Linux system, and the binary is compiled using
> > > clang-3.7.
> > > Can anyone give some pointers as to what might be wrong?
> > This assert probably indicates there is a bug in valgrind triggered
> > by unexpected (or incorrect?) data in the executable (e.g. debug info).
> >
> > Normally, for such asserts, a guest and host stack traces are produced.
> > Without these stacktraces, not much chance to guess what is wrong.
> >
> > Assuming this is caused by debuginfo, you could try to run
> > with more tracing, e.g.
> >    -v -v -v -d -d -d
> > and one or more of
> >
> >     --trace-symtab=no|yes     show symbol table details? [no]
> >     --trace-symtab-patt=<patt> limit debuginfo tracing to obj name <patt>
> >     --trace-cfi=no|yes        show call-frame-info details? [no]
> >     --debug-dump=syms         mimic /usr/bin/readelf --syms
> >     --debug-dump=line         mimic /usr/bin/readelf --debug-dump=line
> >     --debug-dump=frames       mimic /usr/bin/readelf --debug-dump=frames
>
> The assert might be caused by the debuginfo containing a string bigger
> than SEGINFO_STRPOOLSIZE (64Kb).
> If that is the case, we could make the allocEltDedupPA function allow
> for bigger strings, but would be nice to first verify this is
> effectively a big string, and also then understand why clang
> generates strings > 64Kb.
>
> So, more info is needed to confirm what is the problem
> (i.e. either tracing and/or the crash stack traces)
>
> Philippe
>
>
>