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

[David Hallas]

Hi Philippe,

sorry to be poking about this again. Is there any news on the issue? Can I
help to provide a fix for it? Would increasing the pool size really be a
good fix? Or should the code be re-written to dynamically allocate the
needed memory? I guess another solution could be to just truncate the
string, if it is just debug information then that would at least be better
that crashing?

Let me know how I can help

Thanks

/David

On Mon, Feb 8, 2016 at 2:19 PM, David Hallas  wrote:

> Hi Philippe,
>
> thanks a lot for your help. I have created this ticket
> https://bugs.kde.org/show_bug.cgi?id=359133 to track the issue.
>
> I was wondering, is there some kind out of out buffering when using printf
> in valgrind? I guess that could explain why I do not see the debug print?
>
> Thanks
>
> /David
>
> On Fri, Feb 5, 2016 at 9:05 PM, Philippe Waroquiers <
> philippe.waroqui...@skynet.be> wrote:
>
>> On Fri, 2016-02-05 at 11:20 +0100, David Hallas wrote:
>>
>>
>> > thanks for the reply. I tried increasing the SEGINFO_STRPOOLSIZE as
>> > you requested, and for me the magic number is 268*1024 then the assert
>> > goes away :) I also tried to add the print to the ML_(addStr) function
>> > in storage.c but for some reason I never see the print?
>> Strange. VG_(printf) prints unconditionally.
>> >
>> > I tried to play with objdump and nm to find some large symbols, but I
>> > think I do not have enough objdump/nm skills to do that. But I also
>> > tried to play with strings and I found one string (a symbol name) that
>> > is 274154 bytes long (this fits perfectly with that I see the problem
>> > if the SEGINFO_STRPOOLSIZE is 267*1024 but not with 268*1024). The
>> > code that I am debugging is using a lot of templates, so go figure ;)
>> > So I think it sounds very plausible that it is this string that is
>> > causing the problem?
>> A symbol name of 268 Kb is quite impressive,
>> I hope you never have to print this variable in gdb :).
>> >
>> > Please let me know if there is any other information that you need? Or
>> > if you have some other things to test.
>> The information is clear, I think the problem is identified now.
>> The best is to file a bug entry in bugzilla, I hope to fix
>> this problem in the coming weeks or so.
>>
>> Thanks
>>
>> Philippe
>>
>>
>>
>>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[David Hallas]

Hi Philippe,

thanks a lot for your help. I have created this ticket
https://bugs.kde.org/show_bug.cgi?id=359133 to track the issue.

I was wondering, is there some kind out of out buffering when using printf
in valgrind? I guess that could explain why I do not see the debug print?

Thanks

/David

On Fri, Feb 5, 2016 at 9:05 PM, Philippe Waroquiers <
philippe.waroqui...@skynet.be> wrote:

> On Fri, 2016-02-05 at 11:20 +0100, David Hallas wrote:
>
>
> > thanks for the reply. I tried increasing the SEGINFO_STRPOOLSIZE as
> > you requested, and for me the magic number is 268*1024 then the assert
> > goes away :) I also tried to add the print to the ML_(addStr) function
> > in storage.c but for some reason I never see the print?
> Strange. VG_(printf) prints unconditionally.
> >
> > I tried to play with objdump and nm to find some large symbols, but I
> > think I do not have enough objdump/nm skills to do that. But I also
> > tried to play with strings and I found one string (a symbol name) that
> > is 274154 bytes long (this fits perfectly with that I see the problem
> > if the SEGINFO_STRPOOLSIZE is 267*1024 but not with 268*1024). The
> > code that I am debugging is using a lot of templates, so go figure ;)
> > So I think it sounds very plausible that it is this string that is
> > causing the problem?
> A symbol name of 268 Kb is quite impressive,
> I hope you never have to print this variable in gdb :).
> >
> > Please let me know if there is any other information that you need? Or
> > if you have some other things to test.
> The information is clear, I think the problem is identified now.
> The best is to file a bug entry in bugzilla, I hope to fix
> this problem in the coming weeks or so.
>
> Thanks
>
> Philippe
>
>
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[Philippe Waroquiers]

On Fri, 2016-02-05 at 11:20 +0100, David Hallas wrote:


> thanks for the reply. I tried increasing the SEGINFO_STRPOOLSIZE as
> you requested, and for me the magic number is 268*1024 then the assert
> goes away :) I also tried to add the print to the ML_(addStr) function
> in storage.c but for some reason I never see the print?
Strange. VG_(printf) prints unconditionally.
> 
> I tried to play with objdump and nm to find some large symbols, but I
> think I do not have enough objdump/nm skills to do that. But I also
> tried to play with strings and I found one string (a symbol name) that
> is 274154 bytes long (this fits perfectly with that I see the problem
> if the SEGINFO_STRPOOLSIZE is 267*1024 but not with 268*1024). The
> code that I am debugging is using a lot of templates, so go figure ;)
> So I think it sounds very plausible that it is this string that is
> causing the problem?
A symbol name of 268 Kb is quite impressive,
I hope you never have to print this variable in gdb :).
> 
> Please let me know if there is any other information that you need? Or
> if you have some other things to test.
The information is clear, I think the problem is identified now.
The best is to file a bug entry in bugzilla, I hope to fix
this problem in the coming weeks or so.

Thanks

Philippe




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[David Hallas]

Hi Philippe,

thanks for the reply. I tried increasing the SEGINFO_STRPOOLSIZE as you
requested, and for me the magic number is 268*1024 then the assert goes
away :) I also tried to add the print to the ML_(addStr) function in
storage.c but for some reason I never see the print?

I tried to play with objdump and nm to find some large symbols, but I think
I do not have enough objdump/nm skills to do that. But I also tried to play
with strings and I found one string (a symbol name) that is 274154 bytes
long (this fits perfectly with that I see the problem if the
SEGINFO_STRPOOLSIZE is 267*1024 but not with 268*1024). The code that I am
debugging is using a lot of templates, so go figure ;) So I think it sounds
very plausible that it is this string that is causing the problem?

Please let me know if there is any other information that you need? Or if
you have some other things to test.

Thanks

/David


On Fri, Feb 5, 2016 at 12:53 AM, Philippe Waroquiers <
philippe.waroqui...@skynet.be> wrote:

> On Thu, 2016-02-04 at 08:28 +0100, David Hallas wrote:
> > 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.
>
> Strange thing is that there is no host stacktrace.
> (so maybe the error is encountered before the debug info needed for
> the stack trace is loaded).
>
> From the trace, if this is a (too) big string, then that string
> is in gtest.
> Maybe you could use objdump and/or other tools (strings?)
> to find what could be this string of > 64Kb (if that is really the
> problem).
>
> >
> >
> > If you have some specific patches you want tested, I can pull the
> > valgrind sources and do a local build?
> Yes, what you could try is to increase
> #define SEGINFO_STRPOOLSIZE (64*1024)
> in coregrind/m_debuginfo/priv_storage.h
> (e.g. to (640*1024))
> and see if it works.
>
> I would be nice also to add a
>if (len > 64 * 1024)
>  VG_(printf("huge string <%s>\n", str);
> in the ML_(addStr) function in storage.c
> to understand what is this big string.
>
> If the patch above and/or the printf do not give a clue; then
> more debugging/tracing of valgrind will be needed.
>
> Philippe
>
>
>
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[Philippe Waroquiers]

On Thu, 2016-02-04 at 08:54 +0100, Florian Krohm wrote:
> On 03.02.2016 21:50, Philippe Waroquiers wrote:
> > 
> > The assert might be caused by the debuginfo containing a string bigger
> > than SEGINFO_STRPOOLSIZE (64Kb).
> 
> Why exactly are we having yet another fixed size buffer here?
> I've spent a lot of time crawling through the code and getting rid of
> those. To read this is a bit of a disappointment.
Yes, the work on removing or auditing the maxima was a nice thing.
For this particular fixed size:
This is not a (very) new fixed size buffer.
It was already there at least in 3.9.0 (did not check before).
In fact, I suspect that in 3.9.0, exceeding the maxima was
causing a buffer overflow (i.e. was not checked).

I think it should not be that difficult to allow to exceed the
pool size (but still keeping the pool size reasonable, and allocate
a bigger one only when needed).

Still, finding a 64kb string in the debug info is strange.


Philippe



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[Philippe Waroquiers]

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= limit debuginfo tracing to obj name 
--trace-cfi=no|yesshow 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

Philippe



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[David Hallas]

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 <
philippe.waroqui...@skynet.be> 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= limit debuginfo tracing to obj name 
> > --trace-cfi=no|yesshow 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
>
>
>
--15128:1:debuglog DebugLog system started by Stage 1, level 3 logging requested
--15128:1:launcher no tool requested, defaulting to 'memcheck'
--15128:2:launcher   selecting platform for './gtest'
--15128:2:launcher   selecting platform for './gtest'
--15128:2:launcher   opened './gtest'
--15128:2:launcher   read 4096 bytes from './gtest'
--15128:2:launcher   selected platform 'amd64-linux'
--15128:1:launcher selected platform 'amd64-linux'
--15128:1:launcher launching /usr/lib64/valgrind/memcheck-amd64-linux
--15128:1:debuglog DebugLog system started by Stage 2 (main), level 3 logging requested
--15128:1:main Welcome to Valgrind version 3.11.0 debug logging
--15128:1:main Checking current stack is plausible
--15128:1:main Checking initial stack was noted
--15128:1:main Starting the address space manager
--15128:2: aspacem   sp_at_startup = 0x7fff0a48cfc0 (supplied)
--15128:2: aspacem minAddr = 0x000400 (computed)
--15128:2: aspacem maxAddr = 0x0f (computed)
--15128:2: aspacem  cStart = 0x000400 (computed)
--15128:2: aspacem  vStart = 0x080200 (computed)
--15128:2: aspacem   suggested_clstack_end = 0x0fff000fff (computed)
--15128:2: aspacem   <<< SHOW_SEGMENTS: Initial layout (5 segments)
--15128:2: aspacem   0 segment names in 0 slots
--15128:2: aspacem   freelist is empty
--15128:2: aspacem 0: RSVN 00-0003ff 64m - SmFixed
--15128:2: aspacem 1:  000400-0801ff  32736m
--15128:2: aspacem 2: RSVN 080200-0802000fff4096 - SmFixed
--15128:2: aspacem 3:  0802001000-0f  32735m
--15128:2: aspacem 4: RSVN 10-  16383e - SmFixed
--15128:2: aspacem   >>>
--15128:2: aspacem   Reading /proc/self/maps
--15128:2: aspacem   <<< SHOW_SEGMENTS: With contents of /proc/self/maps (17 segments)
--15128:2: aspacem   1 segment names in 1 slots
--15128:2: aspacem   freelist is empty
--15128:2: aspacem   (0,4,2) /usr/lib64/valgrind/memcheck-amd64-linux
--15128:2: aspacem 0: RSVN 00-0003ff 64m - SmFixed
--15128:2: aspacem 1:  000400-0037ff832m
--15128:2: aspacem 2: FILE 003800-0038224fff 2248704 r-x-- d=0x802 i=2282207 o=0   (0,4)
--15128:2: aspacem 3:  0038225000-0038424fff 2097152
--15128:2: aspacem 4: FILE 0038425000-0038427fff   12288 rw--- d=0x802 i=2282207 o=2248704 (0,4)
--15128:2: aspacem 5: ANON 0038428000-00395ddfff 17m rw---
--15128:2: aspacem 6:  00395de000-0801ff  31882m
--15128:2: aspacem 7: RSVN 080200-0802000fff4096 - SmFixed
--15128:2: aspacem 8:  0802001000-0f  32735m
--15128:2: aspacem 9: RSVN 

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

[Florian Krohm]

On 03.02.2016 21:50, Philippe Waroquiers wrote:
> 
> The assert might be caused by the debuginfo containing a string bigger
> than SEGINFO_STRPOOLSIZE (64Kb).

Why exactly are we having yet another fixed size buffer here?
I've spent a lot of time crawling through the code and getting rid of
those. To read this is a bit of a disappointment.

  Florian


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[David Hallas]

Hi All,

I have run into a problem with valgrind when analyzing a binary, I receive
the following error:

==19823== Memcheck, a memory error detector
==19823== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==19823== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==19823== Command: ./gtest
==19823==

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?

Thanks!

/David
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users