valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Many false positives "Mismatched free() / delete / delete []"

[David F. <fa...@kd...>]

I found it.

Using "step" in gdb showed that the new calls that valgrind complains about
go into.... qtwebengine/src/3rdparty/chromium/base/allocator/allocator_shim.cc

146├>void* ShimCppNew(size_t size) {
147│   const allocator::AllocatorDispatch* const chain_head = GetChainHead();
148│   void* ptr;
149│   do {
150│     ptr = chain_head->alloc_function(chain_head, size);
151│   } while (!ptr && CallNewHandler());
152│   return ptr;
153│ }

Indeed chromium's allocator_shim_override_cpp_symbols.h says
SHIM_ALWAYS_EXPORT void* operator new(size_t size)
    SHIM_ALIAS_SYMBOL(ShimCppNew);

This is why it didn't happen in smaller testcases, it only happens when 
including some qtwebengine headers.

=> No valgrind bug, sorry for the noise. I am now going to yell at the 
qtwebengine/chromium people for polluting applications with their custom 
operator new...

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] Many false positives "Mismatched free() / delete / delete []"

[David F. <fa...@kd...>]

On jeudi 22 décembre 2016 21:06:04 CET Philippe Waroquiers wrote:
> To be sure: if you just replace in the above setup valgrind 3.13 SVN
> by valgrind 3.12 release, then you do not have the problem anymore ?

Good point. I just tried with /usr/bin/valgrind, which is 3.11, and the same 
thing happens!

On jeudi 22 décembre 2016 21:28:32 CET pa...@fr... wrote:
> It doesn't much look like it, but there could be calls to new [] in the
> QBoxLayoutPrivate ctor, or its parent classes.

I don't think so, and again: this is a -O0 -g build, no inlining is happening,
so these frames would show in the stack.

> Do you know if global new/delete are replaced

I wonder how to find out.

To make matters more complex, a simple QVBoxLayout testcase doesn't show the 
issue. Neither do small size autotests with dialogs and layouts. Only the 
bigger test program with lots of memory allocations hits this.

I've seen it before in other programs though so it's not specific to that test 
either.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] Many false positives "Mismatched free() / delete / delete []"

[<pa...@fr...>]

----- Original Message -----
> On jeudi 22 décembre 2016 06:46:44 CET David Chapman wrote:
> > If this is new valgrind behavior, I wouldn't discount a bug in its
> > code
> 
> It certainly looks like one :)
> 
> > but the developers (not me) would need to know what the QVBoxLayout
> > constructor is doing.  If it's inlined, the call stack might point
> > fingers at the calling function rather than the true offender.
> 
> It is not inline, and my call stack is from a non-optimized debug
> build
> anyway.
> 
> > Does the QVBoxLayout constructor allocate any memory inside?
> 
> Yes but not with new[].
> 
> QVBoxLayout::QVBoxLayout(QWidget *parent)
>     : QBoxLayout(TopToBottom, parent)
> {
> }
> 
> QBoxLayout::QBoxLayout(Direction dir, QWidget *parent)
>     : QLayout(*new QBoxLayoutPrivate, 0, parent)
> {
>     d->dir = dir;
> }

It doesn't much look like it, but there could be calls to new [] in the QBoxLayoutPrivate ctor, or its parent classes.

Do you know if global new/delete are replaced, or if there are any class overloads?

A+
Paul

Re: [Valgrind-users] Many false positives "Mismatched free() / delete / delete []"

[Philippe W. <phi...@sk...>]

On Thu, 2016-12-22 at 12:22 +0100, David Faure wrote:

> Any idea why this is happening?
> 
> gcc (SUSE Linux) 4.8.5
> valgrind-3.13.0.SVN
> glibc-2.22-3.7.x86_64
> `uname -a` = Linux 4.4.36-8-default #1 SMP Fri Dec 9 16:18:38 UTC 2016 (3ec5648) x86_64 x86_64 x86_64 GNU/Linux
> OpenSuSE Leap 42.2
> 
To be sure: if you just replace in the above setup valgrind 3.13 SVN
by valgrind 3.12 release, then you do not have the problem anymore ?

Philippe

Re: [Valgrind-users] Many false positives "Mismatched free() / delete / delete []"

[David F. <fa...@kd...>]

On jeudi 22 décembre 2016 06:46:44 CET David Chapman wrote:
> If this is new valgrind behavior, I wouldn't discount a bug in its code

It certainly looks like one :)

> but the developers (not me) would need to know what the QVBoxLayout
> constructor is doing.  If it's inlined, the call stack might point
> fingers at the calling function rather than the true offender.

It is not inline, and my call stack is from a non-optimized debug build 
anyway.

> Does the QVBoxLayout constructor allocate any memory inside?

Yes but not with new[].

QVBoxLayout::QVBoxLayout(QWidget *parent)
    : QBoxLayout(TopToBottom, parent)
{
}

QBoxLayout::QBoxLayout(Direction dir, QWidget *parent)
    : QLayout(*new QBoxLayoutPrivate, 0, parent)
{
    d->dir = dir;
}



-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] Many false positives "Mismatched free() / delete / delete []"

[David C. <dcc...@ac...>]

On 12/22/2016 3:22 AM, David Faure wrote:
> There seems to be a regression in valgrind SVN, where it thinks new[] was used, while in fact a simple new was used.
> I see this all over the place when running valgrind on Qt code.
>
> ==4799== Mismatched free() / delete / delete []
> ==4799==    at 0x4C2A65D: operator delete(void*) (vg_replace_malloc.c:576)
> ==4799==    by 0x6CF853D: QVBoxLayout::~QVBoxLayout() (qboxlayout.cpp:1354)
> ==4799==    by 0x6D1CE90: QWidget::~QWidget() (qwidget.cpp:1594)
> ==4799==    by 0x6F631A1: QDialog::~QDialog() (qdialog.cpp:352)
> ==4799==    by 0x5152C85: Akonadi::EmailAddressSelectionDialog::~EmailAddressSelectionDialog() (emailaddressselectiondialog.cpp:92)
> ==4799==    by 0x401876: main (emailaddressselectiondialogtest.cpp:35)
> ==4799==  Address 0x279546e0 is 0 bytes inside a block of size 32 alloc'd
> ==4799==    at 0x4C29D78: operator new[](unsigned long) (vg_replace_malloc.c:423)
> ==4799==    by 0x5152DB7: Akonadi::EmailAddressSelectionDialog::Private::Private(Akonadi::EmailAddressSelectionDialog*, QAbstractItemModel*) (emailaddressselectiondialog.cpp:40)
> ==4799==    by 0x5152B22: Akonadi::EmailAddressSelectionDialog::EmailAddressSelectionDialog(QWidget*) (emailaddressselectiondialog.cpp:82)
> ==4799==    by 0x401681: main (emailaddressselectiondialogtest.cpp:35)
>
> emailaddressselectiondialog.cpp:40 says
>   QVBoxLayout *mainLayout = new QVBoxLayout(q);
>
> And this is just one example, it happens in many many places, it's nothing special about this particular file.
>
> Any idea why this is happening?
>
> gcc (SUSE Linux) 4.8.5
> valgrind-3.13.0.SVN
> glibc-2.22-3.7.x86_64
> `uname -a` = Linux 4.4.36-8-default #1 SMP Fri Dec 9 16:18:38 UTC 2016 (3ec5648) x86_64 x86_64 x86_64 GNU/Linux
> OpenSuSE Leap 42.2
>
If this is new valgrind behavior, I wouldn't discount a bug in its code, 
but the developers (not me) would need to know what the QVBoxLayout 
constructor is doing.  If it's inlined, the call stack might point 
fingers at the calling function rather than the true offender.  Does the 
QVBoxLayout constructor allocate any memory inside?

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com

[Valgrind-users] Many false positives "Mismatched free() / delete / delete []"

[David F. <fa...@kd...>]

There seems to be a regression in valgrind SVN, where it thinks new[] was used, while in fact a simple new was used.
I see this all over the place when running valgrind on Qt code.

==4799== Mismatched free() / delete / delete []
==4799==    at 0x4C2A65D: operator delete(void*) (vg_replace_malloc.c:576)
==4799==    by 0x6CF853D: QVBoxLayout::~QVBoxLayout() (qboxlayout.cpp:1354)
==4799==    by 0x6D1CE90: QWidget::~QWidget() (qwidget.cpp:1594)
==4799==    by 0x6F631A1: QDialog::~QDialog() (qdialog.cpp:352)
==4799==    by 0x5152C85: Akonadi::EmailAddressSelectionDialog::~EmailAddressSelectionDialog() (emailaddressselectiondialog.cpp:92)
==4799==    by 0x401876: main (emailaddressselectiondialogtest.cpp:35)
==4799==  Address 0x279546e0 is 0 bytes inside a block of size 32 alloc'd
==4799==    at 0x4C29D78: operator new[](unsigned long) (vg_replace_malloc.c:423)
==4799==    by 0x5152DB7: Akonadi::EmailAddressSelectionDialog::Private::Private(Akonadi::EmailAddressSelectionDialog*, QAbstractItemModel*) (emailaddressselectiondialog.cpp:40)
==4799==    by 0x5152B22: Akonadi::EmailAddressSelectionDialog::EmailAddressSelectionDialog(QWidget*) (emailaddressselectiondialog.cpp:82)
==4799==    by 0x401681: main (emailaddressselectiondialogtest.cpp:35)

emailaddressselectiondialog.cpp:40 says
 QVBoxLayout *mainLayout = new QVBoxLayout(q);

And this is just one example, it happens in many many places, it's nothing special about this particular file.

Any idea why this is happening?

gcc (SUSE Linux) 4.8.5
valgrind-3.13.0.SVN
glibc-2.22-3.7.x86_64
`uname -a` = Linux 4.4.36-8-default #1 SMP Fri Dec 9 16:18:38 UTC 2016 (3ec5648) x86_64 x86_64 x86_64 GNU/Linux
OpenSuSE Leap 42.2

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] SfMayBlock with fuse-compatible

[Radoslaw K. <ku...@9l...>]

W dniu 08.12.2016 o 17:24, Ivo Raisr pisze:
>
>
> 2016-12-08 11:28 GMT+01:00 Radoslaw Kujawa <ku...@9l... 
> <mailto:ku...@9l...>>:
>
>
>     W dniu 08.12.2016 o 11:12, Ivo Raisr pisze:
>>
>>
>>     2016-12-07 13:54 GMT+01:00 Radoslaw Kujawa <ku...@9l...
>>     <mailto:ku...@9l...>>:
>>
>>         Hi Ivo,
>>
>>         here is the log that appeared when we switched on trace-syscalls:
>>
>>         SYSCALL[28094,1](89) sys_readlink (
>>         0x374581b667(/proc/self/exe), 0xffeffec10, 4096 ) -->
>>         [pre-success] Success(0x52)
>>         valgrind: m_syswrap/syswrap-main.c:1938
>>         (vgPlain_client_syscall): Assertion '0 == (sci->flags &
>>         ~(SfPollAfter | SfYieldAfter | SfNoWriteResult))' failed.
>>
>>
>>     Hi Radek,
>>
>>     Thanks to the log you provided, I was able to quickly analyse the
>>     situation and get to the root cause.
>>     Pre-syscall wrapper for sys_readlink in syswrap-generic.c sets
>>     SfMayBlock unconditionally (via FUSE_COMPATIBLE_MAY_BLOCK)
>>     in the anticipation that the subsequent real syscall may block.
>>     However in some cases, such as when operating on /proc/self/exe,
>>     the wrapper calls the real syscall
>>     itself and therefore SfMayBlock should not have been set.
>>
>>     If you are able to compile Valgrind from sources, I can prepare a
>>     small patch for you to test.
>>     Unfortunately I don't have an environment to test with FUSE for you.
>>     I.
>
>     Yes, we can recompile Valgrind. We will be grateful if you prepare
>     a patch for us.
>     If it occurs that this patch resolves the problem, do you think we
>     should report it as a bug via bugzilla?
>
>
>
> Please find attached a patch. File a bug anyway and report your findings.
> I.

Thanks for patch, it helped. I've reported this issue via bugzilla.
Radek

[Valgrind-users] Fosdem devroom and Valgrind Hackaton

[Mark W. <mj...@re...>]

Hi Valgrind users, hackers and enthusiasts,

We have program from the valgrind devroom that will take place during
Fosdem in Brussels on Saturday 5 February 2017:
https://fosdem.org/2017/schedule/track/valgrind/

The last session will be the Valgrind BoF and Hackaton!

We need your help for that session! The simplest way to help is to just
show up and discuss anything you like and then start hacking! But it is
also fun to have a little structure to the session by letting us know
beforehand what you think we should discuss and/or hack on.

Here is the current desciption, please help improve it:

Valgrind BoF and Hackaton
Open discussion of ideas for Valgrind - and then we hack!
https://fosdem.org/2017/schedule/event/valgrind_hackaton/

Come and hack on Valgrind together. Open discussion about small (or big)
ideas to improve or change Valgrind.

Valgrind developers and users are encouraged to participate either by
submitting ideas/suggestions or by joining the discussion. And of course
by kindly (or bitterly) complain about bugs you find important that are
still Not YET solved for that many years!?@!!!

Afterwards we will sit together and try to fix or implement some of the
things discussed.


Discuss any kind of possible improvement (technical or functional) to
Valgrind.

If you want to put something on the agenda please send a small
description (one or two paragraphs) to the the moderator Mark Wielaard
mj...@re... with in the subject: "FOSDEM devroom discuss: ..." If you
want to discuss a somewhat larger topic please do feel free to send two
or three slides in advance.

Mark will collect ideas/suggestions/... and present these and coordinate
the discussion (and keep track of the time, so every idea will be
discussed).

Some discussion topic ideas:

      * Release/bugfixing strategy/policy.
      * Can we move to git yet?
      * Valgrind and transactional memory.
      * Making Valgrind really multi-threaded, parallelising Memcheck,
        parallelising the rest of the framework, and tools.
      * Instant leak detector. Modify memcheck to report the last leaked
        pointer to a block. Integrate "omega" as a memcheck option or
        omega as a separate tool.
        http://www.brainmurders.eclipse.co.uk/omega.html
      * Make Callgrind work sanely on ARM (and PPC). The Callgrind
        algorithm to track call and return is to be improved to work
        properly on these platforms. Is there a way to make this better?
        E.g. by having a fast way working in most cases, and rely on
        unwind info in the difficult cases. Can we detect at
        instrumentation time that an instruction is a difficult case?
      * Packaging valgrind for distros, handling patches, suppressions,
        etc.
      * 32-bit x86 vs modern instruction sets (avx, etc.)
      * VEX is in theory cross-architecture. What would it take to make
        valgrind cross-arch? How about starting with i686 on x86_64?
      * Which CPUID is it anyway? Valgrind isn't completely consistent
        in handling host CPU capabilities vs VEX emulation capabilities.
        What can we do to improve that? Make it user tunable?
      * <YOUR SUGGESTION HERE!>

And now is the time on Sprockets when we hack!

Re: [Valgrind-users] .gcda files are not generated when run on valgrind

[Ravi K. <rav...@gm...>]

Hi,


>>>>What is the smallest program which fails?  Post it here (the source and the build recipe).
If you cannot do that, then tell us its characteristics.
Such as: CPU architecture, compiler and version, C runtime library and version,
size of executable ("/usr/bin/size my_app"), number and size of shared libraries
("/usr/bin/ldd my_app", then 'size' of each library), duration of execution
("time ./my_app arg1..."; telling us "a lot of time", without
quantifying it, is useless).

   Below are the required details:

CPU Architecture : x86_64
Compiler and version : gcc version 4.6.2 (GCC)
C runtime library and version : libc.so 2.11.1
Number and size of shared libraries : 24 & 8 M.B
Valgrind version : valgrind-3.9.0
Execution time : 10 - 12 hours
Gcov version : gcov (GCC) 4.6.2

CFLAGS += "--coverage -fno-inline -fprofile-arcs -ftest-coverage"
LDFLAGS += "-lgcov"


I'm working on the small test case with this issue . I will be back with
example at the earliest

Thanks,
Ravi

On Thu, Dec 1, 2016 at 9:26 AM, Ravi Kaipu <rav...@gm...> wrote:

> Hi,
>
> Could you please respond for the below problem as it is very important.
>
> We will appreciate your efforts.
>
> Thanks in advance,
>
> Regards,
> Ravi
>
> On Wed, Nov 23, 2016 at 1:05 PM, Ravi Kaipu <rav...@gm...>
> wrote:
>
>> Hi,
>>
>> We have a huge code base which requires a lot of time to check the
>> runtime errors and code coverage (using lcov tool) separately
>>
>> We have built  the components with coverage flags and are now trying to
>> run on valgrind for .gcda files to find coverage. but, .gcda files are not
>> generated sometimes when run on valgrind. But the same components when run
>> with coverage flags without valgrind generate .gcda files
>>
>> We are doing this to reduce the execution time of the test case . Can we
>> rely on this method or shall we avoid running on valgrind with coverage
>> flags to get coverage
>>
>> Has anyone tried like this before ? appreciate any help on this .
>>
>> Thanks in advance,
>>
>> Regards,
>> Ravi
>>
>>
>

Re: [Valgrind-users] SfMayBlock with fuse-compatible

[Ivo R. <iv...@iv...>]

2016-12-08 11:28 GMT+01:00 Radoslaw Kujawa <ku...@9l...>:

>
> W dniu 08.12.2016 o 11:12, Ivo Raisr pisze:
>
>
>
> 2016-12-07 13:54 GMT+01:00 Radoslaw Kujawa <ku...@9l...>:
>
>> Hi Ivo,
>>
>> here is the log that appeared when we switched on trace-syscalls:
>>
>> SYSCALL[28094,1](89) sys_readlink ( 0x374581b667(/proc/self/exe),
>> 0xffeffec10, 4096 ) --> [pre-success] Success(0x52)
>> valgrind: m_syswrap/syswrap-main.c:1938 (vgPlain_client_syscall):
>> Assertion '0 == (sci->flags & ~(SfPollAfter | SfYieldAfter |
>> SfNoWriteResult))' failed.
>>
>
> Hi Radek,
>
> Thanks to the log you provided, I was able to quickly analyse the
> situation and get to the root cause.
> Pre-syscall wrapper for sys_readlink in syswrap-generic.c sets SfMayBlock
> unconditionally (via FUSE_COMPATIBLE_MAY_BLOCK)
> in the anticipation that the subsequent real syscall may block.
> However in some cases, such as when operating on /proc/self/exe, the
> wrapper calls the real syscall
> itself and therefore SfMayBlock should not have been set.
>
> If you are able to compile Valgrind from sources, I can prepare a small
> patch for you to test.
> Unfortunately I don't have an environment to test with FUSE for you.
> I.
>
>
> Yes, we can recompile Valgrind. We will be grateful if you prepare a patch
> for us.
> If it occurs that this patch resolves the problem, do you think we should
> report it as a bug via bugzilla?
>


Please find attached a patch. File a bug anyway and report your findings.
I.

Re: [Valgrind-users] Valgrind crash on armv7l

[John R. <jr...@bi...>]

> Most of the time, when I start valgrind like this:
>   # valgrind --tool=memcheck <path to my program>
> it exits with a segmentation fault. I tried different programs, small and big, but this does not really seem to make a difference. ...

Most of the time?  Then run valgrind under gdb, get the traceback
at the time of the SIGSEGV, and file a bug report against valgrind.
	$ gdb valgrind
	(gdb) run --tool=memcheck /path/to/the/smallest/program/which/fails
	SIGSEGV
	(gdb) bt


> But sometimes I have crashes like this:

> --443-- warning: DiCfSI 0x38012f58 .. 0x38952f73 is huge; length = 9699356 (NONE)
> --443-- DWARF2 CFI reader: unhandled CFI instruction 0:36
> --443-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
> --443-- si_code=1;  Faulting address: 0x4200D858;  sp: 0x624b4da0

This indicates a problem with reading the debug symbols.
Find the smallest program that ever fails this way, run
	$ readelf --debug-dump /path/to/my/program
Look for "CFI instruction 0:36", and file a bug report
against valgrind with relevant information.
(For example: paste the whole output onto a pastebin somewhere on the net,
and include the URL in the bug report.)

[You will get more sympathy (and help) if you run the current version
of valgrind, which is 3.12.]

[Valgrind-users] Valgrind crash on armv7l

[<Fra...@we...>]

Hi,
 
I have an embedded linux system similar to the BeagleBone. It runs buildroot on it.

  # uname -a
  Linux xenon 4.4.21 #1 PREEMPT Thu Dec 8 12:19:53 CET 2016 armv7l GNU/Linux
 
Within the last days, I enabled valgrind in buildroot (version 3.11.0) to examine memory issues in some programs.
Most of the time, when I start valgrind like this:
  # valgrind --tool=memcheck <path to my program> 
it exits with a segmentation fault. I tried different programs, small and big, but this does not really seem to make a difference. Most of the time, the output isn't really verbose:
 # valgrind --tool=memcheck /path/to/program
==470== Memcheck, a memory error detector
==470== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==470== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==470== Command: /path/to/program
==470==
Segmentation fault (core dumped)


But sometimes I have crashes like this:

 # valgrind /path/to/otherprogram
==443== Memcheck, a memory error detector
==443== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==443== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==443== Command: /path/to/otherprogram
==443==
--443-- warning: DiCfSI 0x38012f58 .. 0x38952f73 is huge; length = 9699356 (NONE)
--443-- DWARF2 CFI reader: unhandled CFI instruction 0:36
--443-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--443-- si_code=1;  Faulting address: 0x4200D858;  sp: 0x624b4da0

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==443==    at 0x38061360: vgPlain_allocEltPA (m_poolalloc.c:126)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 443)
==443==    at 0x4019AA4: mmap (mmap.c:36)


For me, it looks like an internal error. But perhaps I just missed some important setting to let valgrind run successfully? Any ideas?

best regards,
Frank

Re: [Valgrind-users] SfMayBlock with fuse-compatible

[Radoslaw K. <ku...@9l...>]

W dniu 08.12.2016 o 11:12, Ivo Raisr pisze:
>
>
> 2016-12-07 13:54 GMT+01:00 Radoslaw Kujawa <ku...@9l... 
> <mailto:ku...@9l...>>:
>
>     Hi Ivo,
>
>     here is the log that appeared when we switched on trace-syscalls:
>
>     SYSCALL[28094,1](89) sys_readlink ( 0x374581b667(/proc/self/exe),
>     0xffeffec10, 4096 ) --> [pre-success] Success(0x52)
>     valgrind: m_syswrap/syswrap-main.c:1938 (vgPlain_client_syscall):
>     Assertion '0 == (sci->flags & ~(SfPollAfter | SfYieldAfter |
>     SfNoWriteResult))' failed.
>
>
> Hi Radek,
>
> Thanks to the log you provided, I was able to quickly analyse the 
> situation and get to the root cause.
> Pre-syscall wrapper for sys_readlink in syswrap-generic.c sets 
> SfMayBlock unconditionally (via FUSE_COMPATIBLE_MAY_BLOCK)
> in the anticipation that the subsequent real syscall may block.
> However in some cases, such as when operating on /proc/self/exe, the 
> wrapper calls the real syscall
> itself and therefore SfMayBlock should not have been set.
>
> If you are able to compile Valgrind from sources, I can prepare a 
> small patch for you to test.
> Unfortunately I don't have an environment to test with FUSE for you.
> I.

Yes, we can recompile Valgrind. We will be grateful if you prepare a 
patch for us.
If it occurs that this patch resolves the problem, do you think we 
should report it as a bug via bugzilla?

Radek

Re: [Valgrind-users] How to Valgrind processes near 256GB?

[Ivo R. <iv...@iv...>]

2016-12-07 18:39 GMT+01:00 Gregory Czajkowski <gcf...@gm...>:

> I have processes near 256GB, need to run valgrind to determine why, but it
> runs out of memory ~60GB
>
>
> ==15336==     Valgrind's memory management: out of memory:
>
> ==15336==        newSuperblock's request for 4194304 bytes failed.
>
> ==15336==        62,289,825,792 bytes have already been mmap-ed ANONYMOUS.
>
> ==15336==     Valgrind cannot continue.  Sorry.
>
> ==15336==     more, depending on the tool.  On a 64-bit machine, Valgrind
> ==15336==     should be able to make use of up 32GB memory.
>
> How can it's limits be increased?
>

If you google around then you'll hit:
http://stackoverflow.com/questions/8644234/why-is-valgrind-limited-to-32-gb-on-64-bit-architectures
http://valgrind.10908.n7.nabble.com/increase-32G-limit-td43507.html

This topic was also recently discussed on Valgrind user's list.

Kind regards,
I.

Re: [Valgrind-users] SfMayBlock with fuse-compatible

[Ivo R. <iv...@iv...>]

2016-12-07 13:54 GMT+01:00 Radoslaw Kujawa <ku...@9l...>:

> Hi Ivo,
>
> here is the log that appeared when we switched on trace-syscalls:
>
> SYSCALL[28094,1](89) sys_readlink ( 0x374581b667(/proc/self/exe),
> 0xffeffec10, 4096 ) --> [pre-success] Success(0x52)
> valgrind: m_syswrap/syswrap-main.c:1938 (vgPlain_client_syscall):
> Assertion '0 == (sci->flags & ~(SfPollAfter | SfYieldAfter |
> SfNoWriteResult))' failed.
>

Hi Radek,

Thanks to the log you provided, I was able to quickly analyse the situation
and get to the root cause.
Pre-syscall wrapper for sys_readlink in syswrap-generic.c sets SfMayBlock
unconditionally (via FUSE_COMPATIBLE_MAY_BLOCK)
in the anticipation that the subsequent real syscall may block.
However in some cases, such as when operating on /proc/self/exe, the
wrapper calls the real syscall
itself and therefore SfMayBlock should not have been set.

If you are able to compile Valgrind from sources, I can prepare a small
patch for you to test.
Unfortunately I don't have an environment to test with FUSE for you.
I.

Re: [Valgrind-users] Does anyone use valgrind work on a dpdk code with huge page?

[Philippe W. <phi...@sk...>]

On Wed, 2016-12-07 at 15:17 +0800, Datong Li wrote:


> So I guess this error maybe cause by hugepage when use valgrind.
>  Does anybody know something about this?

Which version of valgrind are you using ?
Which platform (OS, distro, ...) ?

Support of huge page is supposed to work since valgrind 3.11.
See a.o. bugs 333051, 339163, 338995, 348269, which were all fixed.

Thanks

Philippe

[Valgrind-users] How to Valgrind processes near 256GB?

[Gregory C. <gcf...@gm...>]

I have processes near 256GB, need to run valgrind to determine why, but it
runs out of memory ~60GB


==15336==     Valgrind's memory management: out of memory:

==15336==        newSuperblock's request for 4194304 bytes failed.

==15336==        62,289,825,792 bytes have already been mmap-ed ANONYMOUS.

==15336==     Valgrind cannot continue.  Sorry.

==15336==     more, depending on the tool.  On a 64-bit machine, Valgrind
==15336==     should be able to make use of up 32GB memory.

How can it's limits be increased?

Thanks
++G

Re: [Valgrind-users] SfMayBlock with fuse-compatible

[Radoslaw K. <ku...@9l...>]

Hi Ivo,

here is the log that appeared when we switched on trace-syscalls:

SYSCALL[28094,1](12) sys_brk ( 0x0 ) --> [pre-success] Success(0x4000000)
--28094-- REDIR: 0x37458176d0 (ld-linux-x86-64.so.2:strlen) redirected 
to 0x380550c1 (vgPlain_amd64_linux_REDIR_FOR_strlen)
SYSCALL[28094,1](63) sys_newuname ( 0xffefffb10 )[sync] --> Success(0x0)
--28094-- REDIR: 0x37458174e0 (ld-linux-x86-64.so.2:index) redirected to 
0x380550db (vgPlain_amd64_linux_REDIR_FOR_index)
SYSCALL[28094,1](89) sys_readlink ( 0x374581b667(/proc/self/exe), 
0xffeffec10, 4096 ) --> [pre-success] Success(0x52)
valgrind: m_syswrap/syswrap-main.c:1938 (vgPlain_client_syscall): 
Assertion '0 == (sci->flags & ~(SfPollAfter | SfYieldAfter | 
SfNoWriteResult))' failed.


We also managed to create simple file exposing the problem (see attachment).

Exact command used by us to reproduce the problem:
valgrind --tool=memcheck -v --trace-syscalls=yes 
--sim-hints=fuse-compatible ./a.out

Radek


W dniu 06.12.2016 o 17:23, Ivo Raisr pisze:
>
>
> 2016-12-06 15:39 GMT+00:00 Radoslaw Kujawa <ku...@9l... 
> <mailto:ku...@9l...>>:
>
>     Hi everyone,
>
>     we're trying to run valgrind on a multi-threaded binary that uses fuse to emulate a filesystem. We've found|--sim-hints=|fuse-compatible flag, which is great (resolves some problems with deadlocks), but then valgrind fails on an assert:
>
>     vg_assert(0 == (sci->flags & ~(SfPollAfter | SfYieldAfter | SfNoWriteResult))); (in syswrap_main.c)
>
>     In our case (sci->flags & SfMayBlock) is true. When we added SfMayBlock to acceptable flags, and recompiled valgrind, everything worked fine.
>
>     Do you have and idea what we can do to run our binary in a simple way (without any hacks in assertions...)? Is it some configuration issue to allow blocking operations or maybe it is a bug in valgrind itself?
>
>
> Can you isolate this problem in a very simple program so there is a 
> reproducible test case?
> Alternatively, please provide output of running Valgrind with 
> '--trace-syscalls=yes'.
> I.

[Valgrind-users] Does anyone use valgrind work on a dpdk code with huge page?

[Datong Li <osd...@gm...>]

When I use valgrind in my program, which use dpdk (a intel library) and
open a hugepage to allocate memory, it arises a error when I run it like
below:

PANIC in rte_eal_init():
Cannot init memory
7: [./output/bdsec_ids() [0x41ebe1]]
6: [/lib64/libc.so.6(__libc_start_main+0xfd) [0x318ae1ecdd]]
5: [./output/bdsec_ids(main_run+0x182) [0x41ee22]]
4: [./output/bdsec_ids(pal_init+0x1e6) [0x428626]]
3: [./output/bdsec_ids(rte_eal_init+0x1410) [0x493bc0]]
2: [./output/bdsec_ids(__rte_panic+0xc4) [0x41eb24]]
1: [./output/bdsec_ids(rte_dump_stack+0x1e) [0x498aee]]


What I found in system 's log :

Detected 12 lcore(s)
EAL: Setting up memory...
EAL: map_all_hugepages(): mmap failed: Invalid argument
EAL: Failed to mmap 1024 MB hugepages


So I guess this error maybe cause by hugepage when use valgrind. Does
anybody know something about this?

With Best wishes,
Datong Li

Re: [Valgrind-users] SfMayBlock with fuse-compatible

[Ivo R. <iv...@iv...>]

2016-12-06 15:39 GMT+00:00 Radoslaw Kujawa <ku...@9l...>:

> Hi everyone,
>
> we're trying to run valgrind on a multi-threaded binary that uses fuse to emulate a filesystem. We've found --sim-hints=fuse-compatible flag, which is great (resolves some problems with deadlocks), but then valgrind fails on an assert:
>
> vg_assert(0 == (sci->flags & ~(SfPollAfter | SfYieldAfter | SfNoWriteResult))); (in syswrap_main.c)
>
> In our case (sci->flags & SfMayBlock) is true. When we added SfMayBlock to acceptable flags, and recompiled valgrind, everything worked fine.
>
> Do you have and idea what we can do to run our binary in a simple way (without any hacks in assertions...)? Is it some configuration issue to allow blocking operations or maybe it is a bug in valgrind itself?
>
>
Can you isolate this problem in a very simple program so there is a
reproducible test case?
Alternatively, please provide output of running Valgrind with
'--trace-syscalls=yes'.
I.

[Valgrind-users] SfMayBlock with fuse-compatible

[Radoslaw K. <ku...@9l...>]

Hi everyone,

we're trying to run valgrind on a multi-threaded binary that uses fuse to emulate a filesystem. We've found|--sim-hints=|fuse-compatible flag, which is great (resolves some problems with deadlocks), but then valgrind fails on an assert:

vg_assert(0 == (sci->flags & ~(SfPollAfter | SfYieldAfter | SfNoWriteResult))); (in syswrap_main.c)

In our case (sci->flags & SfMayBlock) is true. When we added SfMayBlock to acceptable flags, and recompiled valgrind, everything worked fine.

Do you have and idea what we can do to run our binary in a simple way (without any hacks in assertions...)? Is it some configuration issue to allow blocking operations or maybe it is a bug in valgrind itself?

Cheers,
Radek


I attach valgrind log:

--12525-- Valgrind options:
--12525--    --tool=memcheck
--12525--    -v
--12525--    --sim-hints=fuse-compatible
--12525--    --run-libc-freeres=no
--12525-- Contents of /proc/version:
--12525--   Linux version 2.6.32-504.el6.x86_64 (moc...@c6... 
<mailto:moc...@c6...>) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Oct 15 04:27:16 UTC 2014
--12525--
--12525-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-sse3
--12525-- Page sizes: currently 4096, max supported 4096
--12525-- Valgrind library directory: /home2/me/tmp/valgrindXXX/lib/valgrind
--12525-- Reading syms from /home2/me/binary.exe
--12525-- Reading syms from /home2/me/tmp/valgrindXXX/lib/valgrind/memcheck-amd64-linux
--12525--    object doesn't have a dynamic symbol table
--12525-- Reading syms from /lib64/ld-2.12.so
--12525-- Scheduler: using generic scheduler lock implementation.
--12525-- Reading suppressions file: /home2/me/tmp/valgrindXXX/lib/valgrind/default.supp
==12525== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-12525-by-kot-on-beta35
==12525== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-12525-by-kot-on-beta35
==12525== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-12525-by-kot-on-beta35
==12525==
==12525== TO CONTROL THIS PROCESS USING vgdb (which you probably
==12525== don't want to do, unless you know exactly what you're doing,
==12525== or are doing some strange experiment):
==12525==   /home2/me/tmp/valgrindXXX/lib/valgrind/../../bin/vgdb --pid=12525 ...command...
==12525==
==12525== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==12525==   /path/to/gdb /home2/me/binary.exe
==12525== and then give GDB the following command
==12525==   target remote | /home2/me/tmp/valgrindXXX/lib/valgrind/../../bin/vgdb --pid=12525
==12525== --pid is optional if only one valgrind process is running
==12525==
--12525-- REDIR: 0x37458176d0 (ld-linux-x86-64.so.2:strlen) redirected to 0x380550c1 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--12525-- REDIR: 0x37458174e0 (ld-linux-x86-64.so.2:index) redirected to 0x380550db (vgPlain_amd64_linux_REDIR_FOR_index)

valgrind: m_syswrap/syswrap-main.c:1938 (vgPlain_client_syscall): Assertion '0 == (sci->flags & ~(SfPollAfter | SfYieldAfter | SfNoWriteResult))' failed.

host stacktrace:
==12525==    at 0x38039548: show_sched_status_wrk (m_libcassert.c:343)
==12525==    by 0x38039824: report_and_quit (m_libcassert.c:419)
==12525==    by 0x38039A40: vgPlain_assert_fail (m_libcassert.c:485)
==12525==    by 0x380933E0: vgPlain_client_syscall (syswrap-main.c:1938)
==12525==    by 0x38090EB4: handle_syscall (scheduler.c:1118)
==12525==    by 0x38090EB4: vgPlain_scheduler (scheduler.c:1435)
==12525==    by 0x380C6F6F: thread_wrapper (syswrap-linux.c:103)
==12525==    by 0x380C6F6F: run_a_thread_NORETURN (syswrap-linux.c:156)

sched status:
   running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 12525)
==12525==    at 0x3745811BD1: _dl_get_origin (in /lib64/ld-2.12.so)
==12525==    by 0x3745806385: expand_dynamic_string_token (in /lib64/ld-2.12.so)
==12525==    by 0x37458063EE: decompose_rpath (in /lib64/ld-2.12.so)
==12525==    by 0x37458068BC: _dl_init_paths (in /lib64/ld-2.12.so)
==12525==    by 0x3745803169: dl_main (in /lib64/ld-2.12.so)
==12525==    by 0x3745815B4D: _dl_sysdep_start (in /lib64/ld-2.12.so)
==12525==    by 0x37458014A3: _dl_start (in /lib64/ld-2.12.so)
==12525==    by 0x3745800B07: ??? (in /lib64/ld-2.12.so)

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

[Danny W. <da...@to...>]

Hi Jeff,

I've downloaded and compiled gcc 4.4.7 (same as stock Centos version).

Unfortunately, the program no longer compiles, giving an error "This platform does not support exception propagation".  (I don't know what that means).

Any suggestion on how to get around this?
Thanks,
Danny

/home/dvmon/bin/gcc-4.4.7/bin/g++ -c -g -O0  -DDEBUG -DCHECK_ALL -DDVMONDEBUG  -DDV_BUILD_DATE=\"2016.12.06-17:58:21\"  -Wall -Wextra -Wno-sign-compare -Wcast-align -DDV_MAJOR_VERSION=6 -DDV_MINOR_VERSION=0 -DDV_BETA_INDICATOR= -DDV_BUILD_NUMBER=27 -DDV_INSTALL_DIR=\"/usr/local/dvstation\" -ftemplate-depth-32 -march=native -ggdb -fPIC -DACE_HAS_NO_THROW_SPEC -D_GNU_SOURCE -D__ACE_INLINE__ -I../../include -I../../src -I/mnt/swdevel/DVMon/source_build/ext/ACE -I/mnt/swdevel/DVMon/source_build/ext/ACE/TAO -I/mnt/swdevel/DVMon/source_build/ext/ACE/TAO/orbsvcs -I/usr/include/libxml2 -Iinclude -DAGENTPP_NAMESPACE -I/usr/lib/qt-3.3/include -I/usr/include/pcap -o DvMain.o DvMain.cpp

In file included from ../../include/com/DvComDefaultExceptionHandler.h:76,
                 from DvMain.cpp:26:

/home/dvmon/bin/gcc-4.4.7/lib/gcc/i686-pc-linux-gnu/4.4.7/../../../../include/c++/4.4.7/exception_ptr.h:40:4: error: #error This platform does not support exception propagation.
make[1]: *** [DvMain.o] Error 1



On 29/11/2016, at 12:35 PM, Jeff Hammond wrote:

> Based upon your prior report showing the illegal instruction associated with std:tr1 code (re-included below), I recommend you build GCC from source so that your C++ standard library is compiled with generic instructions.  Building GCC sounds daunting but I do it all the time.  My poorly curated notes are https://github.com/jeffhammond/HPCInfo/wiki/GCC if you like to copy+paste from the internet :-)

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

[Danny W. <da...@to...>]

Hi Tom,

I omitted -march (didn't have -mcpu), but unfortunately exactly same error.

Now recompiling g++ 4.4.7 from source as per suggestion from Jeff Hammond.

Danny

On 29/11/2016, at 8:19 PM, Tom Hughes wrote:

>> For -march I've tried 'native', 'pentiumpro' and 'core2'.
>> When compiling for valgrind, also -O0.
> 
> Well native is definitely not going to work, and core2 might be pushing it, but pentiumpro should be fine. To be honest just leaving out -march and -mcpu should be ok as it will default to something relatively basic.

Re: [Valgrind-users] .gcda files are not generated when run on valgrind

[John R. <jr...@bi...>]

What is the smallest program which fails?  Post it here (the source and the build recipe).
If you cannot do that, then tell us its characteristics.
Such as: CPU architecture, compiler and version, C runtime library and version,
size of executable ("/usr/bin/size my_app"), number and size of shared libraries
("/usr/bin/ldd my_app", then 'size' of each library), duration of execution
("time ./my_app arg1..."; telling us "a lot of time", without quantifying it, is useless).

Then, show the system calls of a failing run:
	strace -f -o strace-bad.out -e trace=file valgrind ./my_app arg1...
and pay particular attention to the pathname and directory of what should be
the .gcda files.  Contrast with the system calls of a non-failing run:
	strace -f -o strace-good.out -e trace=file ./my_app arg1...

Yes, this is work for you; but it is the minimal price that you must pay for good answers.


On 11/30/2016 07:56 PM, Ravi Kaipu wrote:
> Hi,
>
> Could you please respond for the below problem as it is very important.
>
> We will appreciate your efforts.
>
> Thanks in advance,
>
> Regards,
> Ravi
>
> On Wed, Nov 23, 2016 at 1:05 PM, Ravi Kaipu <rav...@gm... <mailto:rav...@gm...>> wrote:
>
>     Hi,
>
>     We have a huge code base which requires a lot of time to check the runtime errors and code coverage (using lcov tool) separately
>
>     We have built  the components with coverage flags and are now trying to run on valgrind for .gcda files to find coverage. but, .gcda files are not generated sometimes when run on valgrind. But the same components when run with coverage flags without valgrind generate .gcda files
>
>     We are doing this to reduce the execution time of the test case . Can we rely on this method or shall we avoid running on valgrind with coverage flags to get coverage
>
>     Has anyone tried like this before ? appreciate any help on this .
>
>     Thanks in advance,
>
>     Regards,
>     Ravi
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>