Re: [Valgrind-users] valgind with LD_PRELOAD

[Tom Hughes]

I don't think that "blocking stdout" is the problem.

More likely is just that malloc_stats doesn't work under
valgrind because malloc is diverted to be handled by valgrind
so nothing is ever allocated from the C library heap.

Maybe if there have been no allocations malloc_stats doesn't
bother to print anything?

Tom

On 08/03/18 06:58, Hari via Valgrind-users wrote:

Hi Phillippe,

Thanks for your inputs. I got to the rootcause of the problem. The 
signal handler written in the library which is LD_PRELOADED to my 
process has a call to malloc_stats() which typically sends the output 
memory statistics to stderr. I see when the process is run with 
valgrind, the output is not written into the stdout and hence i was 
assuming that the signal is not reaching my process.


To test this i have opened a file in the signal handler, write something 
to it and close. When i send the signal to my process (and there by 
valgrind), i see the file getting created. So this confirms the signal 
is reaching the process.


However i am not sure if valgrind would block stdouts of the process it 
is running on, since the same works properly without valgrind and all 
the stdouts are visible.

Thanks
Hari



*From:* Philippe Waroquiers <philippe.waroqui...@skynet.be>
*To:* Hari <hari_10...@yahoo.com>; valgrind-users@lists.sourceforge.net; 
John Reiser <jrei...@bitwagon.com>

*Sent:* Wednesday, March 7, 2018 9:55 AM
*Subject:* Re: [Valgrind-users] valgind with LD_PRELOAD

To further investigate, some more info might be useful, and some
actions below might help.

General info:
Which version of valgrind are you using ? On which platform ?

The function setup_client_env in initimg-linux.c is responsible
to modify LD_PRELOAD (as valgrind needs to add some values there).
To check this is working properly, you can do the below:
   * change Bool   debug   = False; to True
and/or
   * do:
     LD_PRELOAD=x valgrind 
         echo $LD_PRELOAD # this should show the modified by valgrind 
LD_PRELOAD

   (bash fails under valgrind, I tried with dash)

Please run with -v -v -v -d -d -d your program and examine the trace.
At least at the end of execution, you should find a trace
of the address space manager showing which files are mapped,
and that should contain your preloaded library.

If LD_PRELOAD is correct, but the lib is not mapped, then
you might trace ld.so using LD_DEBUG
(see man ld.so)

If the lib is loaded, but no signals seems to arrive,
you might try:
     valgrind --trace-signals=yes sleep 10
and in another shell, send the signal to the valgrind pid
and observe the trace (which should show the signal arriving)
Then do the same but when valgrind runs your program.

Philippe



On Mon, 2018-03-05 at 11:12 +, Hari via Valgrind-users wrote:
 > Hi John,
 >
 > Thanks for your inputs. I tried both --trace-signals=yes and strace 
options indicated but i could not see any traces of signal sent reaching 
my_process.

 >
 > I suspect if LD_PRELOAD itself did not happen with the following 
command to my_process

 >
 > LD_PRELOAD=./libfake.so valgrind ./my_process
 >
 > Is there a different way to make sure that LD_PRELOAD done above is 
indeed successful? I checked few online portals and i see 
/proc//maps (pid of my_process) and i see references to the 
libfake.so. Does this confirm that LD_PRELOAD is indeed successful? Is 
there any other way to trace where the signal is reaching?

 >
 > Thanks
 > Hari
 >
 >
 > On Wednesday, February 28, 2018, 9:43:29 AM GMT+5:30, John Reiser 
<jrei...@bitwagon.com <mailto:jrei...@bitwagon.com>> wrote:

 >
 >
 > > 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.)
 >
 >
 > 

Re: [Valgrind-users] valgind with LD_PRELOAD

[Hari via Valgrind-users]

Hi Phillippe,
Thanks for your inputs. I got to the rootcause of the problem. The signal 
handler written in the library which is LD_PRELOADED to my process has a call 
to malloc_stats() which typically sends the output memory statistics to stderr. 
I see when the process is run with valgrind, the output is not written into the 
stdout and hence i was assuming that the signal is not reaching my process.
To test this i have opened a file in the signal handler, write something to it 
and close. When i send the signal to my process (and there by valgrind), i see 
the file getting created. So this confirms the signal is reaching the process.
However i am not sure if valgrind would block stdouts of the process it is 
running on, since the same works properly without valgrind and all the stdouts 
are visible. ThanksHari

  From: Philippe Waroquiers <philippe.waroqui...@skynet.be>
 To: Hari <hari_10...@yahoo.com>; valgrind-users@lists.sourceforge.net; John 
Reiser <jrei...@bitwagon.com> 
 Sent: Wednesday, March 7, 2018 9:55 AM
 Subject: Re: [Valgrind-users] valgind with LD_PRELOAD
   
To further investigate, some more info might be useful, and some
actions below might help.

General info:
Which version of valgrind are you using ? On which platform ?

The function setup_client_env in initimg-linux.c is responsible
to modify LD_PRELOAD (as valgrind needs to add some values there).
To check this is working properly, you can do the below:
  * change Bool   debug   = False; to True
and/or
  * do:
    LD_PRELOAD=x valgrind 
        echo $LD_PRELOAD # this should show the modified by valgrind LD_PRELOAD
  (bash fails under valgrind, I tried with dash)

Please run with -v -v -v -d -d -d your program and examine the trace.
At least at the end of execution, you should find a trace
of the address space manager showing which files are mapped,
and that should contain your preloaded library.

If LD_PRELOAD is correct, but the lib is not mapped, then
you might trace ld.so using LD_DEBUG
(see man ld.so)

If the lib is loaded, but no signals seems to arrive,
you might try:
    valgrind --trace-signals=yes sleep 10
and in another shell, send the signal to the valgrind pid
and observe the trace (which should show the signal arriving)
Then do the same but when valgrind runs your program.

Philippe



On Mon, 2018-03-05 at 11:12 +, Hari via Valgrind-users wrote:
> Hi John,
> 
> Thanks for your inputs. I tried both --trace-signals=yes and strace options 
> indicated but i could not see any traces of signal sent reaching my_process. 
> 
> I suspect if LD_PRELOAD itself did not happen with the following command to 
> my_process
> 
> LD_PRELOAD=./libfake.so valgrind ./my_process
> 
> Is there a different way to make sure that LD_PRELOAD done above is indeed 
> successful? I checked few online portals and i see /proc//maps (pid of 
> my_process) and i see references to the libfake.so. Does this confirm that 
> LD_PRELOAD is indeed successful? Is there any other way to trace where the 
> signal is reaching?
> 
> Thanks
> Hari
> 
> 
> On Wednesday, February 28, 2018, 9:43:29 AM GMT+5:30, John Reiser 
> <jrei...@bitwagon.com> wrote:
> 
> 
> > 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.)
> 
> 
> --
> 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
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> -

Re: [Valgrind-users] valgind with LD_PRELOAD

[Philippe Waroquiers]

To further investigate, some more info might be useful, and some
actions below might help.

General info:
Which version of valgrind are you using ? On which platform ?

The function setup_client_env in initimg-linux.c is responsible
to modify LD_PRELOAD (as valgrind needs to add some values there).
To check this is working properly, you can do the below:
  * change Bool   debug   = False; to True
and/or
  * do:
LD_PRELOAD=x valgrind 
echo $LD_PRELOAD # this should show the modified by valgrind LD_PRELOAD
   (bash fails under valgrind, I tried with dash)

Please run with -v -v -v -d -d -d your program and examine the trace.
At least at the end of execution, you should find a trace
of the address space manager showing which files are mapped,
and that should contain your preloaded library.

If LD_PRELOAD is correct, but the lib is not mapped, then
you might trace ld.so using LD_DEBUG
(see man ld.so)

If the lib is loaded, but no signals seems to arrive,
you might try:
valgrind --trace-signals=yes sleep 10
and in another shell, send the signal to the valgrind pid
and observe the trace (which should show the signal arriving)
Then do the same but when valgrind runs your program.

Philippe



On Mon, 2018-03-05 at 11:12 +, Hari via Valgrind-users wrote:
> Hi John,
> 
> Thanks for your inputs. I tried both --trace-signals=yes and strace options 
> indicated but i could not see any traces of signal sent reaching my_process. 
> 
> I suspect if LD_PRELOAD itself did not happen with the following command to 
> my_process
> 
> LD_PRELOAD=./libfake.so valgrind ./my_process
> 
> Is there a different way to make sure that LD_PRELOAD done above is indeed 
> successful? I checked few online portals and i see /proc//maps (pid of 
> my_process) and i see references to the libfake.so. Does this confirm that 
> LD_PRELOAD is indeed successful? Is there any other way to trace where the 
> signal is reaching?
> 
> Thanks
> Hari
> 
> 
> On Wednesday, February 28, 2018, 9:43:29 AM GMT+5:30, John Reiser 
>  wrote:
> 
> 
> > 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.)
> 
> 
> --
> 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
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> --
> 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
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

--
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgind with LD_PRELOAD

[Hari via Valgrind-users]

Hi John,
Thanks for your inputs. I tried both --trace-signals=yes and strace options 
indicated but i could not see any traces of signal sent reaching my_process. 
I suspect if LD_PRELOAD itself did not happen with the following command to 
my_process
LD_PRELOAD=./libfake.so valgrind ./my_process

Is there a different way to make sure that LD_PRELOAD done above is indeed 
successful? I checked few online portals and i see /proc//maps (pid of 
my_process) and i see references to the libfake.so. Does this confirm that 
LD_PRELOAD is indeed successful? Is there any other way to trace where the 
signal is reaching?
ThanksHari 

On Wednesday, February 28, 2018, 9:43:29 AM GMT+5:30, John Reiser 
 wrote:  
 
 > 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.)

--
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
  --
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgind with LD_PRELOAD

[John Reiser]

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.)

--
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users