You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(1) |
2
(8) |
3
(26) |
4
(14) |
5
(23) |
6
(8) |
7
(6) |
|
8
(1) |
9
(5) |
10
|
11
(7) |
12
|
13
(4) |
14
(2) |
|
15
|
16
(6) |
17
(4) |
18
(18) |
19
(10) |
20
(13) |
21
(2) |
|
22
|
23
(1) |
24
(7) |
25
(13) |
26
(35) |
27
(5) |
28
(2) |
|
29
(3) |
30
(5) |
31
(7) |
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 12:26:43
|
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 |
|
From: pkr <pan...@ya...> - 2004-08-05 12:10:45
|
Ok, 2 pieces of info. 1. As Nick guessed earlier, the kernel is configured for 4GB and 2GBuser/2GB kernel . from make menuconfig of our kernel. ======================================== <*> /dev/cpu/*/cpuid - CPU information support (4GB) High Memory Support [ ] HIGHMEM I/O support (NEW) (2GB) User address space size [ ] Math emulation [*] MTRR (Memory Type Range Register) support ======================================= 2. output of cat /proc/self/maps Linux(debug)# cat /proc/self/ cmdline environ fd mem root statcpu statpages cwd exe maps mounts stat statm status Linux(debug)# cat /proc/self/maps 08048000-0804b000 r-xp 00000000 00:000007 30 /bin/cat 0804b000-0804c000 rw-p 00002000 00:000007 30 /bin/cat 0804c000-0804d000 rwxp 00000000 00:000000 0 2aaab000-2aac0000 r-xp 00000000 00:000007 828 /lib/ld-2.3.2.so 2aac0000-2aac1000 rw-p 00014000 00:000007 828 /lib/ld-2.3.2.so 2aac1000-2aac2000 rw-p 00000000 00:000000 0 2aac4000-2abfb000 r-xp 00000000 00:000007 835 /lib/libc-2.3.2.so 2abfb000-2abff000 rw-p 00136000 00:000007 835 /lib/libc-2.3.2.so 2abff000-2ac02000 rw-p 00000000 00:000000 0 7fffe000-80000000 rwxp fffff000 00:000000 0 Let me know if there could be a fix from valgrind. Thanks, Pankaj Nicholas Nethercote wrote: > On Thu, 5 Aug 2004, Tom Hughes wrote: > >>> My system only has 1 GB. But something similar to what you suggest is >>> not ruled out. (As we have a memory mapped IPC system (proprietory) >>> which reserves some huge amout of memory during kernel init) >> >> >> It isn't a question of how much physical memory you have, it's how the >> address space is split between the user space and the kernel space. >> >> The normal split is 3Gb to user space and 1Gb to kernel although some >> systems now give the whole 4Gb to user space. You can also build the >> kernel to give 1Gb to the user and 3Gb to the kernel or 2Gb to each >> which is what it looks like your system is doing. >> >> Like you say, this is probably related to your IPC system needing >> extra kernel address space. > > > Yes, sounds like it. > > I'd be interested to see what /proc/self/maps looks like for a typical > process. Pankaj, can you run "vim /proc/self/maps" or something > similar, and post the results? Thanks. > > ---- > > Ultimately, I think the full virtualisation of the address space > introduced in 2.1.1 has enough problems in tricky cases like this that > we should be prepared to consider a fall-back scheme that operates more > like 2.0.0, whereby valgrind's memory and the client's memory are mixed > up much more. Eg. if you specified --pointer-check=no. This does have > disadvantages -- eg. a buggy client can trash Valgrind's memory -- but > it seems like there's a small fraction of programs for which the current > approach is just too rigid. This could be difficult, though. > > (Nb: "full virtualisation" is not an accurate name, we haven't > virtualised the address space, just partioned it.) > > 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: Nicholas N. <nj...@ca...> - 2004-08-05 11:17:37
|
On Thu, 5 Aug 2004, Tom Hughes wrote: >> My system only has 1 GB. But something similar to what you suggest is >> not ruled out. (As we have a memory mapped IPC system (proprietory) >> which reserves some huge amout of memory during kernel init) > > It isn't a question of how much physical memory you have, it's how the > address space is split between the user space and the kernel space. > > The normal split is 3Gb to user space and 1Gb to kernel although some > systems now give the whole 4Gb to user space. You can also build the > kernel to give 1Gb to the user and 3Gb to the kernel or 2Gb to each > which is what it looks like your system is doing. > > Like you say, this is probably related to your IPC system needing > extra kernel address space. Yes, sounds like it. I'd be interested to see what /proc/self/maps looks like for a typical process. Pankaj, can you run "vim /proc/self/maps" or something similar, and post the results? Thanks. ---- Ultimately, I think the full virtualisation of the address space introduced in 2.1.1 has enough problems in tricky cases like this that we should be prepared to consider a fall-back scheme that operates more like 2.0.0, whereby valgrind's memory and the client's memory are mixed up much more. Eg. if you specified --pointer-check=no. This does have disadvantages -- eg. a buggy client can trash Valgrind's memory -- but it seems like there's a small fraction of programs for which the current approach is just too rigid. This could be difficult, though. (Nb: "full virtualisation" is not an accurate name, we haven't virtualised the address space, just partioned it.) N |
|
From: Tom H. <th...@cy...> - 2004-08-05 11:03:20
|
In message <411...@ya...>
pan...@ya... wrote:
> Nicholas Nethercote wrote:
>
> > Pankaj, do you know why this would be? Is your system setup so user
> > programs get 2GB of address space, and the kernel gets 2GB? (The
> > most common setup is 3GB user, 1GB kernel.)
>
> My system only has 1 GB. But something similar to what you suggest is
> not ruled out. (As we have a memory mapped IPC system (proprietory)
> which reserves some huge amout of memory during kernel init)
It isn't a question of how much physical memory you have, it's how the
address space is split between the user space and the kernel space.
The normal split is 3Gb to user space and 1Gb to kernel although some
systems now give the whole 4Gb to user space. You can also build the
kernel to give 1Gb to the user and 3Gb to the kernel or 2Gb to each
which is what it looks like your system is doing.
Like you say, this is probably related to your IPC system needing
extra kernel address space.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: pkr <pan...@ya...> - 2004-08-05 10:54:16
|
Nicholas Nethercote wrote: > On Thu, 5 Aug 2004, Tom Hughes wrote: > > Pankaj, do you know why this would be? Is your system setup so user > programs get 2GB of address space, and the kernel gets 2GB? (The most > common setup is 3GB user, 1GB kernel.) My system only has 1 GB. But something similar to what you suggest is not ruled out. (As we have a memory mapped IPC system (proprietory) which reserves some huge amout of memory during kernel init) > > I'm sorry that you're having so many difficulties, It is ok. Not a problem. I hope we can work out the problem. > Let me know what info should I provide to go ahead. Thanks, Pankaj |
|
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: Nicholas N. <nj...@ca...> - 2004-08-05 10:31:35
|
On Thu, 5 Aug 2004, Tom Hughes 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? > > 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. I don't think that's the problem. The problem is that the stack ends at 0x7fffffff, instead of the normal place 0xbfffffff. So Valgrind thinks that everything above 0x7fffffff is untouchable. Thus, it refuses to load stage2 at 0xb0000000, where it wants to. So the question is: why is the stack at 0x7fffffff? And can Valgrind safely use the memory above there or not? Pankaj, do you know why this would be? Is your system setup so user programs get 2GB of address space, and the kernel gets 2GB? (The most common setup is 3GB user, 1GB kernel.) I'm sorry that you're having so many difficulties, I hope we can work out the problem. N |
|
From: Tom H. <th...@cy...> - 2004-08-05 10:10:32
|
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?
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
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: pkr <pan...@ya...> - 2004-08-05 09:55:31
|
Hi,
I was able to compile 2.1.2 successfully.
However I now get different problem (attached below)
Any idea what could be causing this ?
TIA,
Pankaj
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
Linux(debug)# strace -o /var/vg.strace /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
Linux(debug)# cat /var/vg.strace
execve("/usr/local/bin/valgrind", ["/usr/local/bin/valgrind", "-v",
"--logfile=/var/dpvm_mem", "/isan/bin/dpvm"], [/* 23 vars */]) = 0
uname({sys="Linux", node="rbadri-vegas13", ...}) = 0
brk(0) = 0x80cc5f8
brk(0x80ed5f8) = 0x80ed5f8
brk(0x80ee000) = 0x80ee000
getrlimit(0x9, 0x7ffff794) = 0
setrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
open("/usr/local/lib/valgrind/stage2", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=1674776, ...}) = 0
geteuid32() = 0
getegid32() = 0
getgroups32(0x20, 0x80c7f44) = 1
pread(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0008\310"...,
4096, 0) = 4096
pread(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0008\310"...,
52, 0) = 52
pread(3, "\6\0\0\0004\0\0\0004\0\0\2604\0\0\260\0\1\0\0\0\1\0\0\5"...,
256, 52) = 256
pread(3, "/lib/ld-linux.so.2\0", 19, 308) = 19
open("/lib/ld-linux.so.2", O_RDONLY|O_LARGEFILE) = 4
pread(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\n\0"...,
52, 0) = 52
pread(4, "\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\217C\1\0\217C\1\0\5\0"...,
96, 52) = 96
write(2, "Executable is mapped outside of "..., 59) = 59
close(3) = 0
write(2, "failed to load /usr/local/lib/va"..., 70) = 70
semget(1, 0, 0) = -1 ENOSYS (Function not
implemented)
_exit(1) = ?
Linux(debug)# ulimit -a
core file size (blocks, -c) 48828
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 32000
cpu time (seconds, -t) unlimited
max user processes (-u) 8151
virtual memory (kbytes, -v) unlimited
Nicholas Nethercote wrote:
> On Tue, 3 Aug 2004, pkr wrote:
> To summarise:
> - it shouldn't matter which gcc you use
> - using 2.1.2 should fix the bug you encountered with 2.0.0
> - but you'll have to fix your broken header as Tom suggested to compile
> 2.1.2
>
> HTH
>
> N
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 09:41:36
|
On Wed, 4 Aug 2004, Lucas Brasilino wrote: > At first view, I thought it was a valgrind bug. But > going deeper in my code, the problem was a variable that was > declared without value, which is used to allocate its number > of an given structure. So, it was my mistake. Thanks a lot > for you time and patience :) Good! I'm glad you've solved your problem. But it's identified a chink in Memcheck's checking -- if you pass an uninitialised value to malloc(), no warning is given. The problem is that Memcheck implements malloc() via a "client request". The details of client requests aren't important here, other than the validity of arguments to client requests is not checked. Similar to how arguments to system calls are not checked. (Memory pointed to by system call args is checked, but not the args themselves.) This means that a lot of the args to pthread functions are also not checked, because they are also mostly implemented using client requests. I think it shouldn't be too hard to fix this situation. I'll take a look. N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 09:28:14
|
On Wed, 4 Aug 2004, Jeff Dike wrote: > It feels to me more like the valgrind thread runs a system call with no > perceptible effect, and there's this new thread all of a sudden which runs > happily in this address space because it can't tell that valgrind is there. To summarise: you seem to be confident there won't be any problems, and Tom's not so sure. I'm not sure either, but the threads/signals/syscalls stuff is the part of Valgrind I understand the least. I would say, just don't be shocked if you do this and weird things start happening :) N |
|
From: Jeff D. <jd...@ad...> - 2004-08-04 20:03:20
|
th...@cy... said: > The problem is that the virtual environment seen by a program running > under valgrind may not be the same as the real environment - things > like signal handlers, signal masks, resource limits and son. That > might be confusing for the thread that isn't running under valgrind > and might even lead to that thread damaging the process state. I'm not > saying it will happen, just that it's something to beware of. Yeah, that's why I was concerned about the process data existing in its native state. As for the rest, in the absense of CLONE_SIGHAND, it is all private to the thread, so it and valgrind won't trip over each other, assuming that the child is sufficiently careful not to inherit stuff that it doesn't expect. > It's still switch from the simulated CPU to the real CPU though - the > thread of control arrives at the clone and then branches with one > branch continuing on the real CPU and one on the simulated CPU. That > sounds to me just the same (for the new thread) as the existing thread > of control continuing on the real CPU. It feels to me more like the valgrind thread runs a system call with no perceptible effect, and there's this new thread all of a sudden which runs happily in this address space because it can't tell that valgrind is there. > You probably really need Jeremy's thoughts on the matter - he's more > up on this stuff and I think he was involved in dropping the support > for switching back to the real CPU. Yeah, he was responsible for that fragment I posted as well. Jeff |
|
From: Tom H. <th...@cy...> - 2004-08-04 17:57:32
|
In message <200...@cc...>
Jeff Dike <jd...@ad...> wrote:
> th...@cy... said:
> > Even doing that (if it's still possible) is quite dangerous as that
> > thread could accidentally damage valgrind's environment.
>
> So? It's also quite dangerous as that thread could damage another thread's
> environment. That's the nature of multithreaded apps.
The problem is that the virtual environment seen by a program running
under valgrind may not be the same as the real environment - things like
signal handlers, signal masks, resource limits and son. That might be
confusing for the thread that isn't running under valgrind and might
even lead to that thread damaging the process state. I'm not saying
it will happen, just that it's something to beware of.
> > That would imply that the newly created thread was left to run on the
> > real CPU rather than the simulated CPU. If that's the case then I'm
> > not that it is possible anymore - I know we had to take out the stuff
> > that allowed valgrind to switch back to the real CPU after running a
> > specified number of basic blocks because it could no longer be made to
> > work.
>
> We're not talking about a thread switching back and forth between the real
> CPU and the simulated one. We're talking about a thread being created on
> the real CPU and staying there.
It's still switch from the simulated CPU to the real CPU though - the
thread of control arrives at the clone and then branches with one
branch continuing on the real CPU and one on the simulated CPU. That
sounds to me just the same (for the new thread) as the existing thread
of control continuing on the real CPU.
You probably really need Jeremy's thoughts on the matter - he's more
up on this stuff and I think he was involved in dropping the support
for switching back to the real CPU.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeff D. <jd...@ad...> - 2004-08-04 17:01:49
|
th...@cy... said: > Even doing that (if it's still possible) is quite dangerous as that > thread could accidentally damage valgrind's environment. So? It's also quite dangerous as that thread could damage another thread's environment. That's the nature of multithreaded apps. > That would imply that the newly created thread was left to run on the > real CPU rather than the simulated CPU. If that's the case then I'm > not that it is possible anymore - I know we had to take out the stuff > that allowed valgrind to switch back to the real CPU after running a > specified number of basic blocks because it could no longer be made to > work. We're not talking about a thread switching back and forth between the real CPU and the simulated one. We're talking about a thread being created on the real CPU and staying there. Jeff |
|
From: Lucas B. <bra...@re...> - 2004-08-04 15:47:03
|
Hi Nicholas: >> May be a library I'm using... I gonna check it out. I'm using >> libxml2 2.6.6, gdbm 1.8.0 and libpam 0.7.5 (among glibc, libz and >> libpthread). > > > It's potentially a valgrind bug. It would be great if you could isolate > a test case and send us it. At first view, I thought it was a valgrind bug. But going deeper in my code, the problem was a variable that was declared without value, which is used to allocate its number of an given structure. So, it was my mistake. Thanks a lot for you time and patience :) bests regards -- []'s Lucas Brasilino bra...@re... http://www.recife.pe.gov.br Emprel - Empresa Municipal de Informatica (pt_BR) Municipal Computing Enterprise (en_US) Recife - Pernambuco - Brasil Fone: +55-81-34167078 |
|
From: Tom H. <th...@cy...> - 2004-08-04 14:58:24
|
In message <200...@cc...>
Jeff Dike <jd...@ad...> wrote:
>> But how did you cope with the fact that valgrind doesn't protect it's
>> internal data structures in any way? You would have all sorts of
>> problems with two threads trying to access the same data.
>
> I think I was mistaken about this firing off another valgrind thread, for
> two reasons.
>
> I remember being concerned about whether the process data was still
> present in its normal, not running under valgrind, form. This would
> only be a problem if you were planning on running a non-valgrind
> thread in the same address space.
Even doing that (if it's still possible) is quite dangerous as
that thread could accidentally damage valgrind's environment.
> Second, the patch above looks like it extracts the client IP from
> valigrind's state and branches to it. This would make the new
> thread a non-valgrind one.
That would imply that the newly created thread was left to run on
the real CPU rather than the simulated CPU. If that's the case then
I'm not that it is possible anymore - I know we had to take out the
stuff that allowed valgrind to switch back to the real CPU after
running a specified number of basic blocks because it could no longer
be made to work.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeff D. <jd...@ad...> - 2004-08-04 14:36:38
|
On Wed, Aug 04, 2004 at 08:52:19AM +0100, Tom Hughes wrote: > >> @@ -39,6 +40,10 @@ > >> # code which copies from baseBlock before the call, into > >> # m_state_static, and back afterwards. > >> > >> +.section .data > >> +save_ip: > >> + .long 0 > >> + > >> VG_(do_syscall): > >> # Save all the int registers of the real machines state on the > >> # simulators stack. > >> @@ -80,10 +85,27 @@ > >> movl VG_(m_state_static)+48, %esi > >> movl VG_(m_state_static)+52, %edi > >> > >> + cmpl $__NR_clone, %eax > >> + jne not_clone > >> + > >> + pushl %eax > >> + movl VG_(m_state_static)+60, %eax > >> + movl %eax, save_ip > >> + popl %eax > >> + > >> + int $0x80 > >> + > >> + cmpl $0, %eax > >> + jne parent_finish > >> + > >> + jmp *save_ip > >> + > >> +not_clone: > >> # esp now refers to the simulatees stack > >> # Do the actual system call > >> int $0x80 > > But how did you cope with the fact that valgrind doesn't protect it's > internal data structures in any way? You would have all sorts of > problems with two threads trying to access the same data. I think I was mistaken about this firing off another valgrind thread, for two reasons. I remember being concerned about whether the process data was still present in its normal, not running under valgrind, form. This would only be a problem if you were planning on running a non-valgrind thread in the same address space. Second, the patch above looks like it extracts the client IP from valigrind's state and branches to it. This would make the new thread a non-valgrind one. So, this being the case, there are no concerns about multi-threading V, just UML, which isn't your problem. Jeff |
|
From: Nicholas N. <nj...@ca...> - 2004-08-04 14:35:46
|
On Wed, 4 Aug 2004, Lucas Brasilino wrote: >> That happens when Valgrind sees a big allocation or deallocation via >> malloc(), free, brk(), mmap(), munmap(), etc. It's not necessarily a >> problem, but it is a bit suspicious -- is your program likely to be >> allocating or deallocating 530+ MB in one hit, either directly or via a >> library? > No, it is not allocating that big. When I run my application > without valgrind, every thing works fine, ie, VM not kills it. Well, Memcheck more than doubles memory usage, so not running out of memory normally doesn't indicate much. > May be a library I'm using... I gonna check it out. I'm using > libxml2 2.6.6, gdbm 1.8.0 and libpam 0.7.5 (among glibc, libz and > libpthread). It's potentially a valgrind bug. It would be great if you could isolate a test case and send us it. >> You could try using --tool=addrcheck, which uses less memory than >> --tool=memcheck (but also does less thorough checking) You could also try >> valgrind 2.1.2, to see if that acts any different. > I've tried with --tool=memcheck and I've got the same > results, so I downgrade back to 2.0.0. Did --tool=addrcheck help? N |
|
From: Jeff D. <jd...@ad...> - 2004-08-04 14:12:00
|
On Wed, Aug 04, 2004 at 08:52:19AM +0100, Tom Hughes wrote: > I don't see how a patch that small can have made clone work for you in > any version - at the very least you would need a change to vg_syscall.c > to stop it trapping the clone and complaining about it or you would > never actually reach VG_(do_syscall). There may have been more - this was the only bit that I spotted in my old email. In any case, that patch was the guts of the clone support. > But how did you cope with the fact that valgrind doesn't protect it's > internal data structures in any way? You would have all sorts of > problems with two threads trying to access the same data. Despite its use of clone, UML is essentially single-threaded. The child thread goes and does something, and the parent waits for it. There is a window between the clone and wait where both could be executing at the same time, and trashing valgrind data, but I never saw that happen. Jeff |
|
From: Lucas B. <bra...@re...> - 2004-08-04 11:26:03
|
Hi Nicholas: >> I'm trying to debug some memory leaks using valgrind 2.0.0 >> and options "-v --leak-check=yes" but it is ending with: >> >> ==<PID>== Warning: set address range perms: large range 538090744, a >> 0, v 0 > > > That happens when Valgrind sees a big allocation or deallocation via > malloc(), free, brk(), mmap(), munmap(), etc. It's not necessarily a > problem, but it is a bit suspicious -- is your program likely to be > allocating or deallocating 530+ MB in one hit, either directly or via a > library? No, it is not allocating that big. When I run my application without valgrind, every thing works fine, ie, VM not kills it. May be a library I'm using... I gonna check it out. I'm using libxml2 2.6.6, gdbm 1.8.0 and libpam 0.7.5 (among glibc, libz and libpthread). >> And kernel VM (2.4.20-31.9) ends valgrind with "out of memory". >> When I run the application without valgrind, it works just fine. >> Anybody knows something about is annoying issue? > > > You could try using --tool=addrcheck, which uses less memory than > --tool=memcheck (but also does less thorough checking) You could also > try valgrind 2.1.2, to see if that acts any different. I've tried with --tool=memcheck and I've got the same results, so I downgrade back to 2.0.0. thanks a lot for you answer. bests regards -- []'s Lucas Brasilino bra...@re... http://www.recife.pe.gov.br Emprel - Empresa Municipal de Informatica (pt_BR) Municipal Computing Enterprise (en_US) Recife - Pernambuco - Brasil Fone: +55-81-34167078 |
|
From: Tom H. <th...@cy...> - 2004-08-04 07:52:32
|
In message <200...@cc...>
Jeff Dike <jd...@ad...> wrote:
> db...@en... said:
>> ugh, so close - it bails - stopped by clone() !?!!?? :
>
> OK, there were a bunch of problems that were fixed when me, Jeremy,
> and Julian were working on this. The clone one seems to have not
> made it. I've lost the patches I had, but I dug this out of a piece
> of email. It applies to coregrind/vg_syscalls.c:
Clone is not (at least in general) supportable in valgrind without
a reasonably large amount of work.
>> @@ -39,6 +40,10 @@
>> # code which copies from baseBlock before the call, into
>> # m_state_static, and back afterwards.
>>
>> +.section .data
>> +save_ip:
>> + .long 0
>> +
>> VG_(do_syscall):
>> # Save all the int registers of the real machines state on the
>> # simulators stack.
>> @@ -80,10 +85,27 @@
>> movl VG_(m_state_static)+48, %esi
>> movl VG_(m_state_static)+52, %edi
>>
>> + cmpl $__NR_clone, %eax
>> + jne not_clone
>> +
>> + pushl %eax
>> + movl VG_(m_state_static)+60, %eax
>> + movl %eax, save_ip
>> + popl %eax
>> +
>> + int $0x80
>> +
>> + cmpl $0, %eax
>> + jne parent_finish
>> +
>> + jmp *save_ip
>> +
>> +not_clone:
>> # esp now refers to the simulatees stack
>> # Do the actual system call
>> int $0x80
I don't see how a patch that small can have made clone work for you in
any version - at the very least you would need a change to vg_syscall.c
to stop it trapping the clone and complaining about it or you would
never actually reach VG_(do_syscall).
> It handles the clone by calling clone itself, creating a new
> valgrind thread which will go on grinding the new UML thread.
But how did you cope with the fact that valgrind doesn't protect it's
internal data structures in any way? You would have all sorts of
problems with two threads trying to access the same data.
Or are you not specifying CLONE_VM among the flags? it is it more like
a fork than a thread creation? That valgrind may be able to handle
quite easily.
In fact, what is the exact set of flags you're using to clone?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-08-04 07:47:52
|
In message <410...@en...>
D. Bahi <db...@en...> wrote:
> alright, i don't read assembly (head hung low) but
> valgrind 2.1.2/coregrind/vg_syscall.S has something
> that makes me ask why i'm getting the 'clone() not
> supported message'
You're not getting as far as any code in vg_syscall.S though. Don't
get confused by VG_(clone) as that has nothing to do with implementing
clone in the client program - it's used by valgrind to start the
background threads that it uses for handling blocking system calls.
> does this need some kind of tie-in code in vg_syscalls.c?
Not exactly. The message you are getting comes from vg_syscalls.c
but the point is that clone is not like other system calls where
you can trivially implement it - it would require a substantial
amount of work throughout valgrind.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-08-04 07:44:27
|
In message <411...@vg...>
Nuno Silva <nun...@vg...> wrote:
> | ==2951== Valgrind detected that your program requires
> | ==2951== the following unimplemented functionality:
> | ==2951== clone(): not supported by Valgrind.
>
> [..]
>
> You have a NPTL/TLS system. Maybe that's the problem. You could try to:
>
> # mv /lib/tls /lib/tls.off
>
> ...and rerun that. Maybe it works better. :-)
> Remember to move tls.off again to revert to tls-enabled glibc ;)
Modern valgrind's work fine with TLS so that is not the problem.
The problem is, as valgrind clearly explained, that clone is not
supported by valgrind.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: D. B. <db...@en...> - 2004-08-04 02:48:10
|
thanks for the idea, but, nope. i'm sorry to report same results.
to clarify, the toolchain supports NTPL but the kernel is not built
with this feature as the UML 2.4 series didn't have an skas patch
that supported this...
oh well. here's the log so you can see the invocation/results:
[u2](dbahi)307$ ~/valgrind-2.1.2/bin/valgrind -v --tool=memcheck
/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux umid=kickme
ubd0=/local/cow/kickmoo,/local/dbahi/root_fs.rh-9-full
ubd1=/local/cow/kickmoo2,/local/dbahi/swap_fs.256 hostfs=/local/hostfs&
[2] 18281
[u2](dbahi)308$ ==18281== Memcheck, a memory error detector for x86-linux.
==18281== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==18281== Using valgrind-2.1.2, a program supervision framework for
x86-linux.
==18281== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==18281== Valgrind library directory:
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind
==18281== Command line
==18281== /local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux
==18281== umid=kickme
==18281==
ubd0=/local/target0/s1/cow/kickmoo,/local/dbahi/root_fs.rh-9-full
==18281== ubd1=/local/target0/s1/cow/kickmoo2,/local/dbahi/swap_fs.256
==18281== hostfs=/local/target0/s1/hostfs/chassis[box].cm[cm1]/
==18281== Startup, with flags:
==18281== -v
==18281== --tool=memcheck
==18281== Contents of /proc/version:
==18281== Linux version 2.4.20-28.9.ets.1.autofs41.skas3
(dbahi@etrs-pc02) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5))
#1 Thu Feb 12 21:32:45 EST 2004
==18281== Reading syms from
/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux (0x8048000)
==18281== Reading syms from /lib/ld-2.3.2.so (0x1B8E4000)
==18281== object doesn't have any debug info
==18281== Reading syms from
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/stage2 (0xB0000000)
==18281== Reading syms from /lib/ld-2.3.2.so (0xB1000000)
==18281== object doesn't have any debug info
==18281== Reading syms from /lib/libdl-2.3.2.so (0xB1031000)
==18281== object doesn't have any debug info
==18281== Reading syms from /lib/i686/libc-2.3.2.so (0xB1036000)
==18281== object doesn't have any debug info
==18281== Reading syms from
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vgskin_memcheck.so
(0xB126F000)
==18281== Reading suppressions file:
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/default.supp
==18281== REDIRECT soname:libc.so.6(__GI___errno_location) to
soname:libpthread.so.0(__errno_location)
==18281== REDIRECT soname:libc.so.6(__errno_location) to
soname:libpthread.so.0(__errno_location)
==18281== REDIRECT soname:libc.so.6(__GI___h_errno_location) to
soname:libpthread.so.0(__h_errno_location)
==18281== REDIRECT soname:libc.so.6(__h_errno_location) to
soname:libpthread.so.0(__h_errno_location)
==18281== REDIRECT soname:libc.so.6(__GI___res_state) to
soname:libpthread.so.0(__res_state)
==18281== REDIRECT soname:libc.so.6(__res_state) to
soname:libpthread.so.0(__res_state)
==18281== REDIRECT soname:libc.so.6(stpcpy) to
*vgpreload_memcheck.so*(stpcpy)
==18281== REDIRECT soname:libc.so.6(strnlen) to
*vgpreload_memcheck.so*(strnlen)
==18281== REDIRECT soname:ld-linux.so.2(stpcpy) to
*vgpreload_memcheck.so*(stpcpy)
==18281== REDIRECT soname:ld-linux.so.2(strchr) to
*vgpreload_memcheck.so*(strchr)
==18281==
==18281== Reading syms from
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vg_inject.so (0x1B8FB000)
==18281== Reading syms from
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vgpreload_memcheck.so
(0x1B900000)
==18281== TRANSLATE: 0x1B8F5BB0 redirected to 0x1B903498
==18281== Reading syms from /lib/libutil-2.3.2.so (0x1B907000)
==18281== object doesn't have any debug info
==18281== Reading syms from /lib/libc-2.3.2.so (0x1B90B000)
==18281== object doesn't have any debug info
==18281== TRANSLATE: 0x1B97E1C0 redirected to 0x1B903C90
==18281==
==18281== Valgrind detected that your program requires
==18281== the following unimplemented functionality:
==18281== clone(): not supported by Valgrind.
We do now support programs linked against
libpthread.so, though. Re-run with -v and ensure that
you are picking up Valgrind's implementation of libpthread.so.
==18281== This may be because the functionality is hard to implement,
==18281== or because no reasonable program would behave this way,
==18281== or because nobody has yet needed it. In any case, let us know at
==18281== valgrind.kde.org and/or try to work around the problem, if you
can.
==18281==
==18281== Valgrind has to exit now. Sorry. Bye!
==18281==
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==18281== at 0x1B9EE4C9: clone (in /lib/libc-2.3.2.so)
==18281== by 0x80DA3A4: can_do_skas (process.c:239)
==18281== by 0x80DE595: linux_main (um_arch.c:332)
==18281== by 0x80532AF: main (main.c:148)
Nuno Silva wrote:
> Hi!
>
> D. Bahi wrote:
> | fantastic! patch applied. results below.
> |
> | note that valgrind almost _requires_ dynamic
> | linking - so I'll keep mem= below 750M, right?
> |
> | ugh, so close - it bails - stopped by clone() !?!!?? :
>
> [..]
>
> |
> | ==2951== Reading syms from /lib/tls/libc-2.3.2.so (0x42000000)
> | ==2951== object doesn't have any debug info
> | ==2951== TRANSLATE: 0x1B8E4C00 redirected to 0x52BFF040
> | ==2951== TRANSLATE: 0x42073700 redirected to 0x1B903C90
> | ==2951==
> | ==2951== Valgrind detected that your program requires
> | ==2951== the following unimplemented functionality:
> | ==2951== clone(): not supported by Valgrind.
>
> [..]
>
> You have a NPTL/TLS system. Maybe that's the problem. You could try to:
>
> # mv /lib/tls /lib/tls.off
>
> ...and rerun that. Maybe it works better. :-)
> Remember to move tls.off again to revert to tls-enabled glibc ;)
>
> HTH,
> Nuno Silva
--
There are two kinds of people in this world: Those that enter a room and
turn the television set on, and those that enter a room and turn the
television set off. -- Raymond Shaw, The Manchurian Candidate (1962).
|
|
From: Nuno S. <nun...@vg...> - 2004-08-04 01:09:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! D. Bahi wrote: | fantastic! patch applied. results below. | | note that valgrind almost _requires_ dynamic | linking - so I'll keep mem= below 750M, right? | | ugh, so close - it bails - stopped by clone() !?!!?? : [..] | | ==2951== Reading syms from /lib/tls/libc-2.3.2.so (0x42000000) | ==2951== object doesn't have any debug info | ==2951== TRANSLATE: 0x1B8E4C00 redirected to 0x52BFF040 | ==2951== TRANSLATE: 0x42073700 redirected to 0x1B903C90 | ==2951== | ==2951== Valgrind detected that your program requires | ==2951== the following unimplemented functionality: | ==2951== clone(): not supported by Valgrind. [..] You have a NPTL/TLS system. Maybe that's the problem. You could try to: # mv /lib/tls /lib/tls.off ...and rerun that. Maybe it works better. :-) Remember to move tls.off again to revert to tls-enabled glibc ;) HTH, Nuno Silva -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBEDc9OPig54MP17wRAvMQAKCfBLEKk4jMnDrZtFvfLMYQ9tJvHACfVKlF fNIUgR/H6gDkE0/VsvUmQNc= =HEXR -----END PGP SIGNATURE----- |