Menu
▾
▴
Re: [Valgrind-users] valgind with LD_PRELOAD
|
From: Tom H. <to...@co...> - 2018-03-08 07:35:45
|
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 <phi...@sk...> > *To:* Hari <har...@ya...>; val...@li...; > John Reiser <jr...@bi...> > *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 > <jr...@bi... <mailto:jr...@bi...>> 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 > > Val...@li... > <mailto:Val...@li...> > > 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 > > Val...@li... > <mailto:Val...@li...> > > 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Tom Hughes (to...@co...) http://compton.nu/ |
