|
From: Oswald B. <os...@kd...> - 2004-08-09 14:29:47
|
On Mon, Aug 09, 2004 at 02:28:29PM +0100, Nicholas Nethercote wrote: > On Thu, 5 Aug 2004, Oswald Buddenhagen wrote: > >>Why is it bad for distributors? > >> > >multiple kernels (with different PAGE_OFFSETs), one valgrind (configured > >for a specific PAGE_OFFSET). hmmm ... > >sure, it's not different from the current situation, so i don't expect > >the stream of puzzled failure reports to widen ... > > I'm not sure I understand. If it's set up at configure-time, why is it a > problem for distributors? > > The only problem I can see with a configure-time setup is if a person has > more than one kernel on the same system, or changes their kernel's memory > layout. But Valgrind could check at startup that the memory layout > matches what it saw at configure-time, and abort/warn if it doesn't. > Or is there a problem here that I'm not seeing? > only the correlation. ;) distribs can either build a valgrind that runs on any kernel (well, with, say, PAGE_OFFSET >= 1gb) and heavily restrict the memory available to valgrind for all users, or they can build one for PAGE_OFFSET=3g (or even 3.5, fwiw), but exclude the users with a lower PAGE_OFFSET (like they do currently). the only (linux) distributor that would have no problem with this would be gentoo, as they ship only sources ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: pkr <pan...@ya...> - 2004-08-19 14:29:55
|
Hi, Sorry to come back again after a long time. 2 queries this time.. 1. Wanted to know if it is possible to make memcheck work too, as somebody mentioned using 0xa0000000. 2. Is it possible for valgrind to generate its report on some other event apart from program exit ? ie I have a daemon which is up 24x7 and would like to collect the valgrind report at specific time intervals. Thanks, Pankaj Nicholas Nethercote wrote: > On Thu, 5 Aug 2004, pkr wrote: > >> 2 pieces of info. >> 1. As Nick guessed earlier, the kernel is configured for 4GB and >> 2GBuser/2GB kernel . >> >> Let me know if there could be a fix from valgrind. > > > Try this: > > - in coregrind/stage1.c, change "info.mapbase" on line 181 from 0xb1000000 > to 0x71000000. > > - in coregrind/Makefile, change "kickstart_base" from 0xb0000000 to > 0x70000000. > > - re-make Valgrind > > I found that Memcheck and Helgrind do not work under this setup, because > they cannot load libraries at 0x40000000 as they want to -- the tools > reserve too much of the 2GB address space for themselves. > > However, Addrcheck, Cachegrind and Massif do work, as they need less > space for themselves, which is a start. Note that if you try running > big programs under Valgrind, you might run out of memory, as the system > doesn't have that much to play with. > > It really would be nice to improve on this situation. > > N > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com |
|
From: Tom H. <th...@cy...> - 2004-08-19 14:54:11
|
In message <412...@ya...>
pan...@ya... wrote:
> 2. Is it possible for valgrind to generate its report on some other
> event apart from program exit ? ie I have a daemon which is up 24x7 and
> would like to collect the valgrind report at specific time intervals.
Memory access problems are reported as they happen. Memory leaks are
reported on exit or when the VALGRIND_DO_LEAK_CHECK client request is
used by the target program.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: pkr <pan...@ya...> - 2004-08-20 05:32:35
|
Tom Hughes wrote: > In message <412...@ya...> > pan...@ya... wrote: > > >>2. Is it possible for valgrind to generate its report on some other >>event apart from program exit ? ie I have a daemon which is up 24x7 and >>would like to collect the valgrind report at specific time intervals. > > > Memory access problems are reported as they happen. Memory leaks are > reported on exit or when the VALGRIND_DO_LEAK_CHECK client request is > used by the target program. > My intention was about leak report only. It would be good to have some way of notifying (signal) valgrind to generate the report. As there could be situations when the above api cant be inserted in the code... Thanks, Pankaj > Tom > |
|
From: Tom H. <th...@cy...> - 2004-08-20 06:19:25
|
In message <412...@ya...>
pkr <pan...@ya...> wrote:
> My intention was about leak report only. It would be good to have
> some way of notifying (signal) valgrind to generate the report.
> As there could be situations when the above api cant be inserted in
> the code...
The problem is that if valgrind starting acting on signals it
would break programs which used that signal themselves - there
is no separate valgrind process to send the signal to.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-19 15:15:32
|
On Thu, 19 Aug 2004, pkr wrote: > 1. Wanted to know if it is possible to make memcheck work too, > as somebody mentioned using 0xa0000000. Not as it stands with your machine's 2G/2G user/kernel memory layout, sorry. N |
|
From: Oswald B. <os...@kd...> - 2004-08-09 16:04:54
|
On Thu, Aug 05, 2004 at 04:11:53PM +0200, Oswald Buddenhagen wrote: > > what's the slow-down for PIC usually like? > > > supposedly about 1-2%. it depends on how many global symbols you > reference. > if you're concerned about it, make this a configure option, so one could compile either with dynamic offset, or an autodetected or specified fixed offset. ok, that does not help pre-built packages as well, but who cares. :) btw, ever thought about valgrinding valgrind (which valgrinds another valgrind :)? with a dynamic load address this shouldn't be a major problem any more. ok, for me, even the most trivial "valgrind valgrind" just segfaults, but i suppose this is easily fixable. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Tom H. <th...@cy...> - 2004-08-09 16:18:10
|
In message <20040809160451.GC28119@ugly.local>
Oswald Buddenhagen <os...@kd...> wrote:
> btw, ever thought about valgrinding valgrind (which valgrinds another
> valgrind :)? with a dynamic load address this shouldn't be a major
> problem any more. ok, for me, even the most trivial "valgrind valgrind"
> just segfaults, but i suppose this is easily fixable.
Oh we've though about it. We'd dearly love to be able to do it and
one day we might get there. It certainly isn't trivial however.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-20 08:40:23
|
On Mon, 9 Aug 2004, Oswald Buddenhagen wrote: > btw, ever thought about valgrinding valgrind (which valgrinds another > valgrind :)? Sure, it's the first thing everyone tries :) > with a dynamic load address this shouldn't be a major problem any more. > ok, for me, even the most trivial "valgrind valgrind" just segfaults, > but i suppose this is easily fixable. I don't think it's that easy. Then again, I'd be happy to be proven wrong, patches are welcome :) I once had self-hosting briefly working in the LD_PRELOAD days, by statically linking V with a program, and then running that combination under another V. There were difficulties with the inner V doing clever things that fooled the outer V and gave spurious errors. I didn't do much with it, and then we switched to FV and that stopped working. N |
|
From: pkr <pan...@ya...> - 2004-08-05 10:43:18
|
Tom Hughes wrote:
> In message <411...@ya...>
> pan...@ya... wrote:
>
>
>>Linux(debug)# /usr/local/bin/valgrind -v --logfile=/var/dpvm_mem
>>/isan/bin/dpvm
>>Executable is mapped outside of range 0x80cd000-0x7ffff000
>>failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory
>
>
> Have you linked your program with an unusual load address?
>
Not that I know of. My system runs some standard linux processes
(httpd/xinetd) as well as some proprietary process.
What I see in /proc/<pid>/maps is that for all processes the maps start
from 08048000
ie.
Linux(debug)# cat /proc/1583/maps
08048000-0810b000 r-xp 00000000 00:000007 1451 /usr/sbin/httpd
0810b000-0810e000 rw-p 000c3000 00:000007 1451 /usr/sbin/httpd
Is it possible to make changes in valgrind or do the inevitable ?
ie change the load address in libc/ld-linux.so. (I remember this
discussed on some other mailing list...)
Some info that could be of help:
Linux(debug)# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 1053306880 528330752 524976128 0 4698112 402055168
Swap: 0 0 0
MemTotal: 1028620 kB
MemFree: 512672 kB
MemShared: 0 kB
Buffers: 4588 kB
Cached: 392632 kB
SwapCached: 0 kB
Active: 12272 kB
Inactive: 446656 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 1028620 kB
LowFree: 512672 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Committed_AS: 412744 kB
VmallocTotal: 1007608 kB
VmallocUsed: 88144 kB
VmallocChunk: 919404 kB
Thanks,
Pankaj
> Unfortunately in order to use valgrind your program will need to have
> a load address in the range that valgrind reported. Normally linked
> programs should fit that criteria though.
>
> Tom
>
|
|
From: Tom H. <th...@cy...> - 2004-08-03 11:58:48
|
In message <200...@we...>
Pankaj Rathore <pan...@ya...> wrote:
> gmake[4]: Entering directory
> `/disk1/pankajkr/valgrind-2.1.2/coregrind'
> if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle
> -I../include -I../include -I./x86
> -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -Winline
> -Wall -Wshadow -O -fno-omit-frame-pointer
> -mpreferred-stack-boundary=2 -g -DELFSZ=32 -MT
> vg_syscalls.o -MD -MP -MF ".deps/vg_syscalls.Tpo" -c
> -o vg_syscalls.o vg_syscalls.c; \
> then mv -f ".deps/vg_syscalls.Tpo"
> ".deps/vg_syscalls.Po"; else rm -f
> ".deps/vg_syscalls.Tpo"; exit 1; fi
> In file included from vg_unsafe.h:65,
> from vg_syscalls.c:35:
> /usr/include/linux/timex.h:56: error: syntax error
> before "and"
> In file included from /usr/include/linux/timex.h:126,
> from vg_unsafe.h:65,
> from vg_syscalls.c:35:
It's a bug in the kernel headers which has been discussed here
several times before. If you edit /usr/include/linux/timex.h you
will see that there is a "/*" missing from that start of a comment
near the top of the file. Fix that and valgrind will compile.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Andy B. <ab...@th...> - 2004-08-05 18:30:21
|
On Thu, 2004-08-05 at 07:26, Nicholas Nethercote wrote: > I found that Memcheck and Helgrind do not work under this setup, because > they cannot load libraries at 0x40000000 as they want to -- the tools > reserve too much of the 2GB address space for themselves. > > However, Addrcheck, Cachegrind and Massif do work, as they need less space > for themselves, which is a start. Note that if you try running big > programs under Valgrind, you might run out of memory, as the system > doesn't have that much to play with. Just throwing out an idea here -- but how possible would it be to run a tool in a different process and have valgrind communicate with the tool's process over IPC? Then the working set of valgrinding something is the normal size of the process + overhead of valgrind itself, rather than process + valgrind + tool. The tool would have a full address space at its disposal. There is speed to consider, this would most likely be slower than the suggested 1-2% slowdown from using -fPIC, but you'd at least be able to valgrind larger processes then. If you used sockets between valgrind and the tool, you could even run the tool on a different machine, perhaps one with more RAM. You might even be able to run multiple tools at the same time this way. This is not necessarily a good idea though, most likely a lot of work to further abstract the memory accesses through the tool to allow non-direct access (I have not examined the code at this level of detail). |
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 21:44:00
|
On Thu, 5 Aug 2004, Andy Bakun wrote: > Just throwing out an idea here -- but how possible would it be to run a > tool in a different process and have valgrind communicate with the > tool's process over IPC? Then the working set of valgrinding something > is the normal size of the process + overhead of valgrind itself, rather > than process + valgrind + tool. The tool would have a full address > space at its disposal. There is speed to consider, this would most > likely be slower than the suggested 1-2% slowdown from using -fPIC, but > you'd at least be able to valgrind larger processes then. If you used > sockets between valgrind and the tool, you could even run the tool on a > different machine, perhaps one with more RAM. You might even be able to > run multiple tools at the same time this way. This is not necessarily a > good idea though, most likely a lot of work to further abstract the > memory accesses through the tool to allow non-direct access (I have not > examined the code at this level of detail). Every memory access would have to pass through a socket. And maybe every register access, depends how you structure it. I don't know much about IPC and sockets, but I imagine this would fatally reduce speed. I think the current approach can be tweaked so that things aren't so problematic, eg. by having an option that makes memory layout less rigid. N |
|
From: Robert W. <rj...@du...> - 2004-08-20 06:26:12
|
> > My intention was about leak report only. It would be good to have > > some way of notifying (signal) valgrind to generate the report. > > As there could be situations when the above api cant be inserted in > > the code... >=20 > The problem is that if valgrind starting acting on signals it > would break programs which used that signal themselves - there > is no separate valgrind process to send the signal to. One way of doing this is to have Valgrind open a socket and check it for requests generated by a companion client program every so often. Sounds like it might slow things down, though. Should be simple to code up and measure, though. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@ca...> - 2004-08-20 08:04:15
|
On Thu, 19 Aug 2004, Robert Walsh wrote: > One way of doing this is to have Valgrind open a socket and check it for > requests generated by a companion client program every so often. Sounds > like it might slow things down, though. Should be simple to code up and > measure, though. Another recent discussion was based around using signals, but letting the user specify which signal on the command line. So you could, for example, using SIGINT for leak checking on Ctrl-C in interactive programs (maybe using a prompt which asks, when you get a SIGINT, whether to do a leak-check or just treat the signal normally). N |
|
From: pkr <pan...@ya...> - 2004-08-20 12:12:31
|
Not sure whether this is possible in valgrind.... 1. But can we not trap signal(), sigaction() calls (similar to trapping malloc etc) to register the user function ptr in a internal data structure and then on the actual signal we do our job and then call user function ? 2. And then the signal number can always be cmdline parameter so that user is free to select a appropriate signal (some of them are unused ie SIGUSR1 etc) and then user is also warned that this signal wont be passed to the program.. Thanks, Pankaj Tom Hughes wrote: > In message <412...@ya...> > pkr <pan...@ya...> wrote: > > >>My intention was about leak report only. It would be good to have >>some way of notifying (signal) valgrind to generate the report. >>As there could be situations when the above api cant be inserted in >>the code... > > > The problem is that if valgrind starting acting on signals it > would break programs which used that signal themselves - there > is no separate valgrind process to send the signal to. > > Tom > |
|
From: Tom H. <th...@cy...> - 2004-08-20 12:50:35
|
In message <412...@ya...>
pan...@ya... wrote:
> 1. But can we not trap signal(), sigaction() calls (similar to
> trapping malloc etc) to register the user function ptr
> in a internal data structure and then on the actual signal
> we do our job and then call user function ?
We already virtualise the signal handling anyway. The problem with
your suggestion is that the signal winds up having two effects, one
on valgrind and one on the target program, and that's pretty nasty.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|