valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Is it possible to use callgrind to view the call graphs of a Java program

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

> I use callgrind a lot when I am trying to view the execution path of C++ programs (call it an alternate use case of the execution profiler). I was wondering if it is possible to do the same thing for a Java program running in a JVM. Also, is it possible to do the same thing for a Perl script?

Callgrind tracks only call+return at the level of machine instructions,
or perhaps also when a compiler annotates the generated machine language
to mark the call+return.  In general callgrind does not track call+return
which are handled entirely within a higher-level interpreter such as JVM
or Perl.  Callgrind does track the call+return of the internal
implementation of the interpreter, and sometimes this may give clues
to what is happening at the level of the input language.

[Valgrind-users] Is it possible to use callgrind to view the call graphs of a Java program

[Nick O. <nic...@gm...>]

Hi,

I use callgrind a lot when I am trying to view the execution path of C++
programs (call it an alternate use case of the execution profiler). I was
wondering if it is possible to do the same thing for a Java program running
in a JVM. Also, is it possible to do the same thing for a Perl script?

Thanks,
Nick

Re: [Valgrind-users] how to generate core file on invalid reads/writes?

[Tomas V. <tv...@fu...>]

On 02/20/2018 02:08 PM, Nicolas Sauvaget wrote:
> Tomas,
> 
> Timers, threads ,"real time behaviour" of your application and GDB
> may jostle each other, so you may not be able to use it.
> 

Understood. Luckily, Postgres is single-threaded, and it does not use 
timers or realtime stuff, so that should not be a problem.

> What you can do is getting a valgrind report as usual and, from this
> report, understand where the issues are. Then you instrument your
> code using VALGRIND_PRINTF_BACKTRACE(). Of course nothing is
> automatic.
> 

Yeah, that's where I started but it's not very practical approach. The 
regression tests are executing many SQL queries on many pieces of data, 
and it's nearly impossible to pinpoint which of the queries/rows 
triggers the issue based on just the report.

But it seems the gdbserver with --vgdb-error=1 is very helpful, because 
then I can inspect the full server state and identify the exact queries 
/ rows triggering the issue.

> Hope it helps you in your investigations.
> 

Yep, is sure did. Thanks to everyone on this thread for the help so far! 
And to all the devs working on valgrind - it's such a useful tool.

regards
Tomas

Re: [Valgrind-users] rodata warning

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

2018-02-16 17:27 GMT+01:00 John Reiser <jr...@bi...>:
>> What would you like to do instead? REOPENED?
>
>
> The presenting symptom is the same, so REOPENED is an obvious candidate.
> My post was to draw attention to the re-appearance because I
> could not change the Status away from "no need to look at this anymore."
> Another way would be to create a new bug report.

I'd prefer another bug report in this case.
Although the symptoms are equivalent, the underlying reasoning is different.
And the new bug will have different story, uncluttered by the past.


>> https://bugs.kde.org/show_bug.cgi?id=360749
>> explains why the "fix" was reverted back then.
>> It was rather a kludge around Solaris linker limitation.
>>
>> The underlying problem with Solaris linker is different this time.
>> Back in 2015, there was some linker development hiccup which got
>> eventually fixed.
>> As described in 360749, it occurred only for some period during
>> Solaris 12 development.
>>
>> Recent occurrence is found in Solaris 11.3 and we do not see it with
>> libstdc++.so.6.0.20 and gcc 5.
>> It is only seen with gcc 8 and libstdc++.so.6.0.25.
>
>
> The resolution of 360749 says
>    Solaris linker now combines SHF_STRINGS SHF_MERGE sections with differing
>    alignment and thus creates only one .rodata section.
>
> The Sample in 353802 shows a different kind of "multiple .rodata":
> one .rodata with SHF_MERGE|SHF_STRINGS, one without, and many
> .rodata.<subr_name> with SHF_MERGE|SHF_STRINGS.  All are contiguous
> after considering alignment.
>
> It seems to me that the re-appearance of the symptom is caused by
> the same old problem.  Solaris linker (and/or its input linker script)
> is prone to not merging Sections that coregrind's debuginfo reader
> would rather consider as one instead of many.
> So coregrind should be extended to handle multiple .rodata*, or the reader
> should work-around the problem by looking for and doing the merge itself.
>
> There is also the question "Why does coregrind care?" In this case
> it seems that the refinement of the read-only data intervals carries
> no information that matters to coregrind, so the complaint is at most
> about the time wasted in processing the descriptors.

Indeed.
Although one .rodata is arguable the preferred outcome, it should not matter.
As long as the ELF file is properly formatted, and all the .rodata
sections actually
end up in the text segment, the specific sections within that segment
that they're assigned
to is of little consequence.
Unfortunately the Valgrind debug info reader assumes one .rodata
(going from section name to symbols). This is a wrong approach.
The right approach is to follow the shndx from the symbol to the
correct section.

I.

Re: [Valgrind-users] valgind with LD_PRELOAD

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

> LD_PRELOAD=./libfake.so ./my_process --> runs fine and prints memory stats
> 
> But,
> 
> LD_PRELOAD=./libfake.so valgrind ./my_process --> doesnt print the memory stats
> 
>  From few online blogs, i understand that valgrind does forward any signals to the child process that it is running on but it doesnt seem to work here.

There is no parent-child relationship between valgrind and ./my_process.
Both valgrind and ./my_process run in the same address space as just one process.
The inter-process communication would be extremely expensive if valgrind
and ./my_process did not share the same address space, and memcheck tracking
of each memory access would be difficult if there were 2 threads of control.

The command-line parameter "--trace-signals=yes" causes valgrind to report on signals.
The Linux utility /usr/bin/strace also reports on signals.  (Probably use
something like "strace -e trace=file" to reduce the syscalls that strace reports;
in particular 'read' and 'write' are usually heavily used and ignorable.)

[Valgrind-users] valgind with LD_PRELOAD

[Hari <har...@ya...>]

Hi,
I have a query on using LD_PRELOAD with valgrind. I have a process which is LD_PRELOADED with a libraray libfake.so (name changed) which registers a signal handler and when the signal to the process is received, prints the memory statistics of this process into the log file. The same is monitored by the test framework to see if the memory is increasing on executing a test multiple times.
Apart from monitoring the memory, we also need valgrind to give backtraces of all memory allocations while the tests run just in case the test framework detects memory increase. LD_PRELOAD with my process just runs fine printing the memory statistics, however when the process is run from valgrind, the signal doesnt seem to reach my process at all.
For ex:
LD_PRELOAD=./libfake.so ./my_process --> runs fine and prints memory stats

But,
LD_PRELOAD=./libfake.so valgrind ./my_process --> doesnt print the memory stats
>From few online blogs, i understand that valgrind does forward any signals to the child process that it is running on but it doesnt seem to work here. Any inputs here will be of great help. I am using valgrind 3.11 for my use.
ThanksHari

Re: [Valgrind-users] Mempool chunk migration

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

On 02/27/2018 09:30 UTC, Marc Marí wrote:

> In our memory allocator, memory chunks can be allocated in one pool and
> freed in another (different) pool. This is no problem, because chunks
> have a specific size, and they are pushed to a queue of free chunks.

Well, yes it is a problem ... because memcheck does not understand.
Such an implementation violates the property that a block belongs
to one specific and unchanging pool.

It is likely that the soonest-to-implement solution is for the custom
allocator to free() a block back into the same pool from which it was
allocated.  On a 32-bit architecture this should be easy: the entire
address space is only 1M pages of 4KB, and 1M of bits is only 128KB.
Give each pool such a bitmap which implements the characteristic function
"do I manage this page?"
For a 64-bit architecture, in practice a small handful of 4GiB regions
will cover all the pools.  So divide-and-conquer.

[Valgrind-users] Mempool chunk migration

[Marc M. <5.m...@gm...>]

Hi

I am working on a custom memory allocator, and I'm currently trying to
integrate Valgrind with it, so that we can use memcheck with it. I
think I have understood properly the documentation, and I have a
correct implementation. But there is still one issue remaining.

In our memory allocator, memory chunks can be allocated in one pool and
freed in another (different) pool. This is no problem, because chunks
have a specific size, and they are pushed to a queue of free chunks.

This, when integrated with Valgrind, causes that the pools specified
when calling VALGRIND_MEMPOOL_ALLOC and VALGRIND_MEMPOOL_FREE are not
the same. This does not give any error nor warning (maybe it should?).
Later, the chunk is reused in the new pool, and when Valgrind checks
for overlaps, it outputs this:

Block 0x6f17a00..0x6f17bff overlaps with block 0x6f17a00..0x6f17bff

Which makes complete sense: the same chunk has been used in two pools
(although never "at the same time").

The chunks come with no information to the allocator, so there is no
easy way of checking which was the original pool. If this was the case,
I could just do a FREE from the original pool.

Is there any other way to tell Valgrind that one chunk has swapped
pools?

(If something seems wrong with my logic, tell me, because I may have
misundertood the documentation. I'm writing this because the output of
Valgrind fits with what I think it's happening).

Thanks
Marc

Re: [Valgrind-users] failed in UME with error 22

[SILVA J. <joa...@al...>]

Hi again,

Our program now seems to have enlarged and now occupies:

valgrind: mmap(0xa2d000, 2154274816) failed in UME with error 22 (Invalid argument).
valgrind: this can be caused by executables with very large text, data or bss segments.

However, I cannot relocate it anymore:

$ grep 0x7f000000 configure.ac 
        valt_load_address_pri_norml="0x7f000000"
           valt_load_address_pri_norml="0x7f000000"
           valt_load_address_pri_norml="0x7f000000"
           valt_load_address_pri_norml="0x7f000000"
           valt_load_address_sec_norml="0x7f000000"

This value, 0x7f000000, is too much:

../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_mallocfree.o): In function `sanity_check_malloc_arena':
/home/AltranUK/jsilva.fs/src/valgrind/coregrind/m_mallocfree.c:1321:(.text+0xe19): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[3]: *** [memcheck-amd64-linux] Error 1

Is there an alternative to create more space for the program?

Thanks.

João M. S. Silva

> -----Original Message-----
> From: Silva João
> Sent: 10 de dezembro de 2017 21:10
> To: Philippe Waroquiers <phi...@sk...>; Ivo Raisr
> <iv...@iv...>
> Cc: Valgrind Users <val...@li...>
> Subject: RE: [Valgrind-users] failed in UME with error 22
> 
> Then you have to understand what this task is doing.
> Isn't the backtrace pointing at what the code is doing and what this
> read could be ?
> Look at the file descriptor on which it is reading and see what this fd
> is ?
> Is it a real file ? (unlikely to be blocking then)
> Is it a pipe ? A tcp/ip connection ?
> Use lsof if you cannot determine in gdb what this fd is for.
> 
> [JMSS] It's a file. After I added some prints for debugging, the main
> thread seem to get unblocked (?)
> 
> This can be false positive of course, and of course, this can be a true
> positive :).
> With only an address, no access to the code, no backtrace, no
> reproducer,
> there is not much feedback we can give.
> 
> Let me just tell that at my work, we have added for helgrind a few
> suppression
> entries related to the 'low level implementation of the gnat runtime',
> to
> suppress false positive created by the low level inner working of the
> runtime.
> 
> To see what you case is, the minimum needed would be the stack traces of
> the error msg.
> 
> In summary, at this point, it looks like you have to debug your
> application
> when running under valgrind, and then you might determine if what you
> see
> is a real application bug, or a valgrind bug/limitation e.g. in the
> valgrind
> scheduler/signal handling/syscall handling or whatever.
> 
> At this state, without further info, let's assume you have
> an application bug :)
> 
> [JMSS] Yes, I think that we are now able to debug the application. It
> seems to run under nulgrind, helgrind and memcheck, so it should be
> "good" to go.
> 
> [JMSS] I'll try to provide the patch for the configuration now.
> 
> João M. S. Silva

Re: [Valgrind-users] failed in UME with error 22

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

2018-02-23 19:54 GMT+01:00 SILVA João <joa...@al...>:
> The reason we allocate everything statically is safety.
>
> What about you, Ivo, any other hints on creating space for this executable?

Unfortunately I have run out of ideas, I am sorry.

>
> This seems a limitation of Valgrind, should I create a bug report? It's a software limit, while the limit should be the hardware, right?

Valgrind does many things to your application.
Different virtual address memory organization is one of them. In
short, V. has to squeeze application and Valgrind into one process'
address space.
I don't think the current design of aspacemgr could allow for the
flexibility you need.
Feel free to have a look, perhaps you will be able to come up with another idea.

I.

Re: [Valgrind-users] failed in UME with error 22

[SILVA J. <joa...@al...>]

The reason we allocate everything statically is safety.

What about you, Ivo, any other hints on creating space for this executable?

This seems a limitation of Valgrind, should I create a bug report? It's a software limit, while the limit should be the hardware, right?

João M. S. Silva

> -----Original Message-----
> From: Philippe Waroquiers [mailto:phi...@sk...]
> Sent: 22 de fevereiro de 2018 06:34
> To: SILVA João <joa...@al...>; Ivo Raisr <iv...@iv...>
> Cc: Valgrind Users <val...@li...>
> Subject: Re: [Valgrind-users] failed in UME with error 22
> 
> I would suggest to stop doing such huge static allocations,
> and replace these huge static allocations by dynamic allocation
> done at elaboration time.
> This should give you several benefits:
>   * you should be able to run under Valgrind without the below problems
>   * you will get additional verifications/safety net when running under
>     valgrind, as valgrind does not check static data as well as
>     dynamic data.
>   * you can at startup decide on how much memory you use, without the
> need
>     to recompile.
> 
> If your coding standard strictly forbids dynamic allocation even at
> elaboration
> time, then use e.g. gnatprep to have 2 modes:
>   * a static data version
>   * a dynamic version
> (the changes to switch between the 2 versions should be limited to the
> variable declarations, thanks to the compiler using implicit .all
> 
> 
> Apart of the above, I have no idea what the below linker error means,
> and how to fix it.
> 
> Philippe
> 
> 
> On Wed, 2018-02-21 at 12:11 +0000, SILVA João wrote:
> > Hi again,
> >
> > Our program now seems to have enlarged and now occupies:
> >
> > valgrind: mmap(0xa2d000, 2154274816) failed in UME with error 22
> (Invalid argument).
> > valgrind: this can be caused by executables with very large text, data
> or bss segments.
> >
> > However, I cannot relocate it anymore:
> >
> > $ grep 0x7f000000 configure.ac
> >         valt_load_address_pri_norml="0x7f000000"
> >            valt_load_address_pri_norml="0x7f000000"
> >            valt_load_address_pri_norml="0x7f000000"
> >            valt_load_address_pri_norml="0x7f000000"
> >            valt_load_address_sec_norml="0x7f000000"
> >
> > This value, 0x7f000000, is too much:
> >
> > ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-
> m_mallocfree.o): In function `sanity_check_malloc_arena':
> >
> /home/AltranUK/jsilva.fs/src/valgrind/coregrind/m_mallocfree.c:1321:(.te
> xt+0xe19): additional relocation overflows omitted from the output
> > collect2: error: ld returned 1 exit status
> > make[3]: *** [memcheck-amd64-linux] Error 1
> >
> > Is there an alternative to create more space for the program?
> >
> > Thanks.
> >
> > João M. S. Silva
> >
> > > -----Original Message-----
> > > From: Silva João
> > > Sent: 10 de dezembro de 2017 21:10
> > > To: Philippe Waroquiers <phi...@sk...>; Ivo Raisr
> > > <iv...@iv...>
> > > Cc: Valgrind Users <val...@li...>
> > > Subject: RE: [Valgrind-users] failed in UME with error 22
> > >
> > > Then you have to understand what this task is doing.
> > > Isn't the backtrace pointing at what the code is doing and what this
> > > read could be ?
> > > Look at the file descriptor on which it is reading and see what this
> fd
> > > is ?
> > > Is it a real file ? (unlikely to be blocking then)
> > > Is it a pipe ? A tcp/ip connection ?
> > > Use lsof if you cannot determine in gdb what this fd is for.
> > >
> > > [JMSS] It's a file. After I added some prints for debugging, the
> main
> > > thread seem to get unblocked (?)
> > >
> > > This can be false positive of course, and of course, this can be a
> true
> > > positive :).
> > > With only an address, no access to the code, no backtrace, no
> > > reproducer,
> > > there is not much feedback we can give.
> > >
> > > Let me just tell that at my work, we have added for helgrind a few
> > > suppression
> > > entries related to the 'low level implementation of the gnat
> runtime',
> > > to
> > > suppress false positive created by the low level inner working of
> the
> > > runtime.
> > >
> > > To see what you case is, the minimum needed would be the stack
> traces of
> > > the error msg.
> > >
> > > In summary, at this point, it looks like you have to debug your
> > > application
> > > when running under valgrind, and then you might determine if what
> you
> > > see
> > > is a real application bug, or a valgrind bug/limitation e.g. in the
> > > valgrind
> > > scheduler/signal handling/syscall handling or whatever.
> > >
> > > At this state, without further info, let's assume you have
> > > an application bug :)
> > >
> > > [JMSS] Yes, I think that we are now able to debug the application.
> It
> > > seems to run under nulgrind, helgrind and memcheck, so it should be
> > > "good" to go.
> > >
> > > [JMSS] I'll try to provide the patch for the configuration now.
> > >
> > > João M. S. Silva

[Valgrind-users] Valgrind with and without stack provide different result

[Bastien M. <bas...@gm...>]

Hi,

I am prety new to valgrind. I mainly use memcheck, sgcheck and massif.

As I want to check stack and heap memory usage of a binary I use massif and
found something weird to me :

I used `valgrind --tool=massif --time-unit=B --peak-inaccuracy=0.1
--threshold=0.1 --detailed-freq=1 --max-snapshots=1000
--massif-out-file="my/math/massif.out" my_binary to get a heap profile. The
last snapshot was the following :
--------------------------------------------------------------------------------
  n        time(B)         total(B)   useful-heap(B) extra-heap(B)
stacks(B)
--------------------------------------------------------------------------------
747      1,828,928                0                0
0            0

So all was fine. Then I tryed with --stacks=yes and got this :
--------------------------------------------------------------------------------
  n        time(B)         total(B)   useful-heap(B) extra-heap(B)
stacks(B)
--------------------------------------------------------------------------------
856     78,076,000            2,256            1,040             8
1,208

I don't understand why this time the useful and extra heap does not fall to
0 even if it is the same binary.

Some explanation would be very helpful and welcome :)

Regars.

Re: [Valgrind-users] rodata warning

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

2018-02-21 22:55 GMT+01:00 John Reiser <jr...@bi...>:
> On 02/19/2018 09:35 UTC, Ivo Raisr wrote:
>
>> I'd prefer another bug report in this case.
>> Although the symptoms are equivalent, the underlying reasoning is
>> different.
>> And the new bug will have different story, uncluttered by the past.
>
>
> https://bugs.kde.org/show_bug.cgi?id=390871

Thank you,
I.

Re: [Valgrind-users] failed in UME with error 22

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

I would suggest to stop doing such huge static allocations,
and replace these huge static allocations by dynamic allocation
done at elaboration time.
This should give you several benefits:
  * you should be able to run under Valgrind without the below problems
  * you will get additional verifications/safety net when running under
    valgrind, as valgrind does not check static data as well as
    dynamic data.
  * you can at startup decide on how much memory you use, without the need
    to recompile.

If your coding standard strictly forbids dynamic allocation even at elaboration
time, then use e.g. gnatprep to have 2 modes:
  * a static data version
  * a dynamic version
(the changes to switch between the 2 versions should be limited to the
variable declarations, thanks to the compiler using implicit .all


Apart of the above, I have no idea what the below linker error means,
and how to fix it.

Philippe


On Wed, 2018-02-21 at 12:11 +0000, SILVA João wrote:
> Hi again,
> 
> Our program now seems to have enlarged and now occupies:
> 
> valgrind: mmap(0xa2d000, 2154274816) failed in UME with error 22 (Invalid argument).
> valgrind: this can be caused by executables with very large text, data or bss segments.
> 
> However, I cannot relocate it anymore:
> 
> $ grep 0x7f000000 configure.ac 
>         valt_load_address_pri_norml="0x7f000000"
>            valt_load_address_pri_norml="0x7f000000"
>            valt_load_address_pri_norml="0x7f000000"
>            valt_load_address_pri_norml="0x7f000000"
>            valt_load_address_sec_norml="0x7f000000"
> 
> This value, 0x7f000000, is too much:
> 
> ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_mallocfree.o): In function `sanity_check_malloc_arena':
> /home/AltranUK/jsilva.fs/src/valgrind/coregrind/m_mallocfree.c:1321:(.text+0xe19): additional relocation overflows omitted from the output
> collect2: error: ld returned 1 exit status
> make[3]: *** [memcheck-amd64-linux] Error 1
> 
> Is there an alternative to create more space for the program?
> 
> Thanks.
> 
> João M. S. Silva
> 
> > -----Original Message-----
> > From: Silva João
> > Sent: 10 de dezembro de 2017 21:10
> > To: Philippe Waroquiers <phi...@sk...>; Ivo Raisr
> > <iv...@iv...>
> > Cc: Valgrind Users <val...@li...>
> > Subject: RE: [Valgrind-users] failed in UME with error 22
> > 
> > Then you have to understand what this task is doing.
> > Isn't the backtrace pointing at what the code is doing and what this
> > read could be ?
> > Look at the file descriptor on which it is reading and see what this fd
> > is ?
> > Is it a real file ? (unlikely to be blocking then)
> > Is it a pipe ? A tcp/ip connection ?
> > Use lsof if you cannot determine in gdb what this fd is for.
> > 
> > [JMSS] It's a file. After I added some prints for debugging, the main
> > thread seem to get unblocked (?)
> > 
> > This can be false positive of course, and of course, this can be a true
> > positive :).
> > With only an address, no access to the code, no backtrace, no
> > reproducer,
> > there is not much feedback we can give.
> > 
> > Let me just tell that at my work, we have added for helgrind a few
> > suppression
> > entries related to the 'low level implementation of the gnat runtime',
> > to
> > suppress false positive created by the low level inner working of the
> > runtime.
> > 
> > To see what you case is, the minimum needed would be the stack traces of
> > the error msg.
> > 
> > In summary, at this point, it looks like you have to debug your
> > application
> > when running under valgrind, and then you might determine if what you
> > see
> > is a real application bug, or a valgrind bug/limitation e.g. in the
> > valgrind
> > scheduler/signal handling/syscall handling or whatever.
> > 
> > At this state, without further info, let's assume you have
> > an application bug :)
> > 
> > [JMSS] Yes, I think that we are now able to debug the application. It
> > seems to run under nulgrind, helgrind and memcheck, so it should be
> > "good" to go.
> > 
> > [JMSS] I'll try to provide the patch for the configuration now.
> > 
> > João M. S. Silva

Re: [Valgrind-users] rodata warning

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

On 02/19/2018 09:35 UTC, Ivo Raisr wrote:

> I'd prefer another bug report in this case.
> Although the symptoms are equivalent, the underlying reasoning is different.
> And the new bug will have different story, uncluttered by the past.

https://bugs.kde.org/show_bug.cgi?id=390871

Re: [Valgrind-users] how to generate core file on invalid reads/writes?

[Nicolas S. <nic...@ya...>]

Tomas,

Timers, threads ,"real time behaviour" of your application and GDB may jostle each other, so you may not be able to use it. 
What you can do is getting a valgrind report as usual and, from this report, understand where the issues are. Then you instrument your code using VALGRIND_PRINTF_BACKTRACE(). Of course nothing is automatic.

Hope it helps you in your investigations.

Nicolas.

--------------------------------------------
En date de : Mar 20.2.18, Tomas Vondra <tv...@fu...> a écrit :

 Objet: Re: [Valgrind-users] how to generate core file on invalid reads/writes?
 À: "John Reiser" <jr...@bi...>, val...@li...
 Date: Mardi 20 février 2018, 1h50
 
 
 
 On 02/19/2018 11:14 PM, John Reiser wrote:
 >> Is there a way to get core when
 valgrind on invalid access? Am I 
 >>
 missing something?
 > 
 > If you are running valgrind interactively
 and valgrind reports an error,
 > then one
 of the error options is to invoke gdb.  Gdb has a
 command:
 >     generate-core-file
 <filename>
 > See the gdb manual
 which is available online in html.
 > 
 
 Interesting. Shame on me for
 not knowing about the gdbserver thing!
 
 I wonder what exactly does
 "interactively" mean here. I'm running it as
 
 part of an automated regression test suite
 that starts postgres, and 
 executes a bunch
 of SQL scripts on it.
 
 If I
 understand the docs correctly, this qualifies as
 interactive. I'll 
 try tweaking the
 scripts tomorrow to use the --vgdb options.
 
 > If you start valgrind
 with the option  --vgdb-error=<number>
 > then you have a gdbserver process which
 provides *much better*
 > service than
 attaching gdb only at the point of error.
 > See the valgrind manual, or "valgrind
 --help" for a synopsis.
 > 
 > In either case the core file will include
 the pieces of valgrind
 > which are
 running in the same process [and address space]
 > as "your" program.  So you
 might become confused while separating
 >
 what is "your" program from what is valgrind.
 > 
 > For practical
 purposes (shortest time to finding and fixing
 > the "first" error) it often is
 best to use the --vgdb-error=<number>
 > invocation, perhaps with
 --track-origins=yes.  And yes, this
 >
 means you are allowed to [you must] watch and help.
 > 
 
 I
 don't follow. Watch and help with what?
 
 
 regards
 Tomas
 
 ------------------------------------------------------------------------------
 Check out the vibrant tech community on one of
 the world's most
 engaging tech sites,
 Slashdot.org! http://sdm.link/slashdot
 _______________________________________________
 Valgrind-users mailing list
 Val...@li...
 https://lists.sourceforge.net/lists/listinfo/valgrind-users
 

Re: [Valgrind-users] how to generate core file on invalid reads/writes?

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

>> And yes, this
>> means you are allowed to [you must] watch and help.

> I don't follow. Watch and help with what?

It means that scripting the interaction can be quirky, tedious,
and frustrating.  Especially the first time, you are likely
to get better results by first invoking everything "by hand",
then sit at the terminal, watching and waiting for the error
to appear, and helping by looking at output, understanding
what it means, and typing input on the keyboard.

Re: [Valgrind-users] how to generate core file on invalid reads/writes?

[Tomas V. <tv...@fu...>]

On 02/19/2018 11:14 PM, John Reiser wrote:
>> Is there a way to get core when valgrind on invalid access? Am I 
>> missing something?
> 
> If you are running valgrind interactively and valgrind reports an error,
> then one of the error options is to invoke gdb.  Gdb has a command:
>     generate-core-file <filename>
> See the gdb manual which is available online in html.
> 

Interesting. Shame on me for not knowing about the gdbserver thing!

I wonder what exactly does "interactively" mean here. I'm running it as 
part of an automated regression test suite that starts postgres, and 
executes a bunch of SQL scripts on it.

If I understand the docs correctly, this qualifies as interactive. I'll 
try tweaking the scripts tomorrow to use the --vgdb options.

> If you start valgrind with the option  --vgdb-error=<number>
> then you have a gdbserver process which provides *much better*
> service than attaching gdb only at the point of error.
> See the valgrind manual, or "valgrind --help" for a synopsis.
> 
> In either case the core file will include the pieces of valgrind
> which are running in the same process [and address space]
> as "your" program.  So you might become confused while separating
> what is "your" program from what is valgrind.
> 
> For practical purposes (shortest time to finding and fixing
> the "first" error) it often is best to use the --vgdb-error=<number>
> invocation, perhaps with --track-origins=yes.  And yes, this
> means you are allowed to [you must] watch and help.
> 

I don't follow. Watch and help with what?


regards
Tomas

Re: [Valgrind-users] how to generate core file on invalid reads/writes?

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

> Is there a way to get core when valgrind on invalid access? Am I missing something?

If you are running valgrind interactively and valgrind reports an error,
then one of the error options is to invoke gdb.  Gdb has a command:
    generate-core-file <filename>
See the gdb manual which is available online in html.

If you start valgrind with the option  --vgdb-error=<number>
then you have a gdbserver process which provides *much better*
service than attaching gdb only at the point of error.
See the valgrind manual, or "valgrind --help" for a synopsis.

In either case the core file will include the pieces of valgrind
which are running in the same process [and address space]
as "your" program.  So you might become confused while separating
what is "your" program from what is valgrind.

For practical purposes (shortest time to finding and fixing
the "first" error) it often is best to use the --vgdb-error=<number>
invocation, perhaps with --track-origins=yes.  And yes, this
means you are allowed to [you must] watch and help.

[Valgrind-users] how to generate core file on invalid reads/writes?

[Tomas V. <tv...@fu...>]

Hi,

I wonder if it's possible to generate cores (or rather vgcores) when 
valgrind detects invalid reads or writes. We do occasionally see such 
reports by valgrind, and it would be really helpful to be able to 
investigate the internal state using gdb. But I don't see any such 
option in valgrind :-(

I was thinking about triggering a segfault somehow, but the trouble is I 
don't really know how to identify that the read actually was invalid 
(which is a very rare event).

Adding more detailed logging is another possibility, but it's going to 
be very tedious to identify traces matching the invalid access.

Is there a way to get core when valgrind on invalid access? Am I missing 
something?

regards
Tomas

Re: [Valgrind-users] rodata warning

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

On 02/16/2018 07:02 UTC, Ivo Raisr wrote:
> 2018-02-15 15:54 GMT+01:00 John Reiser <jr...@bi...>:
>>> --18142-- WARNING: Serious error when reading debug info
>>> --18142-- When reading debug info from
>>> /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25:
>>> --18142-- Can't make sense of .rodata section mapping
>>>
>>> (GCC SVN head, Solaris 11.3, Valgrind git head).
>>
>>
>> This is in the "do not forget about this situation" list as:
>> https://bugs.kde.org/show_bug.cgi?id=353802
>>    "ELF debug info reader confused with multiple .rodata sections"
>>
>> The bug Status currently is incorrect.  It says "RESOLVED FIXED".
>> However the original patch to fix it was reverted without changing the
>> status:
>>     https://bugs.kde.org/show_bug.cgi?id=353802#c9
>> That was almost 2 years ago, and anyway does not include this week's
>> re-appearance.
>>
>> I could find no way to remove the "RESOLVED FIXED" label.

> What would you like to do instead? REOPENED?

The presenting symptom is the same, so REOPENED is an obvious candidate.
My post was to draw attention to the re-appearance because I
could not change the Status away from "no need to look at this anymore."
Another way would be to create a new bug report.

> 
> https://bugs.kde.org/show_bug.cgi?id=360749
> explains why the "fix" was reverted back then.
> It was rather a kludge around Solaris linker limitation.
> 
> The underlying problem with Solaris linker is different this time.
> Back in 2015, there was some linker development hiccup which got
> eventually fixed.
> As described in 360749, it occurred only for some period during
> Solaris 12 development.
> 
> Recent occurrence is found in Solaris 11.3 and we do not see it with
> libstdc++.so.6.0.20 and gcc 5.
> It is only seen with gcc 8 and libstdc++.so.6.0.25.

The resolution of 360749 says
    Solaris linker now combines SHF_STRINGS SHF_MERGE sections with differing
    alignment and thus creates only one .rodata section.

The Sample in 353802 shows a different kind of "multiple .rodata":
one .rodata with SHF_MERGE|SHF_STRINGS, one without, and many
.rodata.<subr_name> with SHF_MERGE|SHF_STRINGS.  All are contiguous
after considering alignment.

It seems to me that the re-appearance of the symptom is caused by
the same old problem.  Solaris linker (and/or its input linker script)
is prone to not merging Sections that coregrind's debuginfo reader
would rather consider as one instead of many.
So coregrind should be extended to handle multiple .rodata*, or the reader
should work-around the problem by looking for and doing the merge itself.

There is also the question "Why does coregrind care?" In this case
it seems that the refinement of the read-only data intervals carries
no information that matters to coregrind, so the complaint is at most
about the time wasted in processing the descriptors.

Re: [Valgrind-users] rodata warning

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

2018-02-15 15:54 GMT+01:00 John Reiser <jr...@bi...>:
>> --18142-- WARNING: Serious error when reading debug info
>> --18142-- When reading debug info from
>> /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25:
>> --18142-- Can't make sense of .rodata section mapping
>>
>> (GCC SVN head, Solaris 11.3, Valgrind git head).
>
>
> This is in the "do not forget about this situation" list as:
> https://bugs.kde.org/show_bug.cgi?id=353802
>   "ELF debug info reader confused with multiple .rodata sections"
>
> The bug Status currently is incorrect.  It says "RESOLVED FIXED".
> However the original patch to fix it was reverted without changing the
> status:
>    https://bugs.kde.org/show_bug.cgi?id=353802#c9
> That was almost 2 years ago, and anyway does not include this week's
> re-appearance.
>
> I could find no way to remove the "RESOLVED FIXED" label.

What would you like to do instead? REOPENED?

https://bugs.kde.org/show_bug.cgi?id=360749
explains why the "fix" was reverted back then.
It was rather a kludge around Solaris linker limitation.

The underlying problem with Solaris linker is different this time.
Back in 2015, there was some linker development hiccup which got
eventually fixed.
As described in 360749, it occurred only for some period during
Solaris 12 development.

Recent occurrence is found in Solaris 11.3 and we do not see it with
libstdc++.so.6.0.20 and gcc 5.
It is only seen with gcc 8 and libstdc++.so.6.0.25.

I.

Re: [Valgrind-users] rodata warning

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

> --18142-- WARNING: Serious error when reading debug info
> --18142-- When reading debug info from /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25:
> --18142-- Can't make sense of .rodata section mapping
> 
> (GCC SVN head, Solaris 11.3, Valgrind git head).

This is in the "do not forget about this situation" list as:
https://bugs.kde.org/show_bug.cgi?id=353802
   "ELF debug info reader confused with multiple .rodata sections"

The bug Status currently is incorrect.  It says "RESOLVED FIXED".
However the original patch to fix it was reverted without changing the status:
    https://bugs.kde.org/show_bug.cgi?id=353802#c9
That was almost 2 years ago, and anyway does not include this week's re-appearance.

I could find no way to remove the "RESOLVED FIXED" label.

Re: [Valgrind-users] rodata warning

[Paul F. <pj...@wa...>]

> On 13 Feb 2018, at 01:03, John Reiser <jr...@bi...> wrote:
> 
>> https://zerobin.net/?0bf6ea80afca0924#PT/yP+KTPOXYx/+IKUC+wwhm/UCF+S2fccpHQB9Cf7Q=
> 
> [That "paste" site says that the page expires in 6 days.]


It’s the first time I’ve used such a site. I don’t know if there are ones that have free persistent storage for large files.

...

> It might be possible to confirm this diagnosis by turning on TRACE_SYMTAB
> (which is controlled by command-line argument --trace-symtab=yes
> and perhaps by --trace-symtab-patt=<patt> ) and looking through
> what valgrind reports.
> 
> [Of course I also see the many hundreds of Sections ".rodata.<subr_name>"
> and ".text.<subr_name>" and ".text.unlikely.<subr_name>" which at first
> glance seem to be overkill and/or extravagant waste of space.  There
> should be a more-compact way to convey the information.]

I did try —trace-symtab=yes, but the output was exceedingly long. I’ll give the pattern a try tonight.

On the other front, I’ll try to find out why libstc++ has so many sections.

A+
Paul

Re: [Valgrind-users] rodata warning

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

It appears that all the .rodata* sections are contiguous, after considering
alignment.  Thus a workaround would be for valgrind's debuginfo reader
to aggregate them all into one internal .rodata which is the convex hull.

Example:

   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
round_up(Off + Size, Al.next) = Off.next

   [15] .rodata._ZNKSt10l PROGBITS        00093a88 093a88 000010 01 AMS  0   0  1
round_up(093a88 + 000010, 1) = 093a98

   [16] .rodata._ZNKSt12_ PROGBITS        00093a98 093a98 000008 01 AMS  0   0  1
round_up(093a98 + 000008, 1) = 093aa0

   [17] .rodata._ZNKSt12_ PROGBITS        00093aa0 093aa0 000007 01 AMS  0   0  1
round_up(093aa0 + 000007, 32) = 093ac0  <<< note Al.next

   [18] .rodata           PROGBITS        00093ac0 093ac0 003504 00   A  0   0 32
round_up(093ac0 + 003504, 32) = 096fe0

   [19] .rodata._ZTSNSt12 PROGBITS        00096fe0 096fe0 00002c 00   A  0   0 32
round_up(096fe0 + 00002c, 32) = 097020

   [20] .rodata._ZTSNSt12 PROGBITS        00097020 097020 00002b 00   A  0   0 32
round_up(097020 + 00002b, 1) = 09704b  <<< note Al.next

   [21] .rodata._ZNSt6chr PROGBITS        0009704b 09704b 000001 00   A  0   0  1