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=xxxxx valgrind <any shell that works under 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 100000
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 +0000, 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/<pid>/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.)
 >
 >
> ------------------------------------------------------------------------------
 > 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 <mailto: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 <mailto: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



--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

Reply via email to