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-03 22:04:53
|
On Tue, 3 Aug 2004, Jeff Dike wrote: >> + pushl %eax >> + movl VG_(m_state_static)+60, %eax >> + movl %eax, save_ip >> + popl %eax m_state_static doesn't exist anymore. You could try getting the simulated %eip out of the 'baseBlock' -- it starts at VG_(baseBlock), and %eip is VGOFF_(m_eip) *words* into it, ie. 4*VGOFF_(m_eax) bytes into it. I'm not certain that the simulated %eip is up-to-date exactly as necessary, but it could be. The rest of the patch would work the same way. > Also, I saw this: > >> valgrind: the `impossible' happened: >> Unhandled REPE case > > If you see this, check that you have > http://www.goop.org/~jeremy/valgrind/76-repe-scas.patch > and apply if not. That should be fixed in all recent versions of Valgrind. HTH N |
|
From: D. B. <db...@en...> - 2004-08-03 20:13:56
|
trying to find a way to wedge the old patch into the new code... i don't think it applies anymore. 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' does this need some kind of tie-in code in vg_syscalls.c? .globl VG_(clone) VG_(clone): #define FSZ (4+4+4) /* frame size = retaddr+ebx+edi */ push %ebx push %edi /* set up child stack with function and arg */ movl 4+FSZ(%esp), %ecx /* child stack */ movl 12+FSZ(%esp), %ebx /* fn arg */ movl 0+FSZ(%esp), %eax /* fn */ lea -8(%ecx), %ecx /* make space on stack */ movl %ebx, 4(%ecx) /* fn arg */ movl %eax, 0(%ecx) /* fn */ /* get other args to clone */ movl 8+FSZ(%esp), %ebx /* flags */ movl 20+FSZ(%esp), %edx /* parent tid * */ movl 16+FSZ(%esp), %edi /* child tid * */ movl $__NR_clone, %eax int $0x80 testl %eax, %eax jnz 1f /* CHILD - call thread function */ popl %eax call *%eax /* exit with result */ movl %eax, %ebx movl $__NR_exit, %eax int $0x80 /* Hm, exit returned */ ud2 1: /* PARENT or ERROR */ pop %edi pop %ebx ret Jeff Dike 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: > > >>@@ -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 > > > It handles the clone by calling clone itself, creating a new valgrind thread > which will go on grinding the new UML thread. > > Also, I saw this: > > >> valgrind: the `impossible' happened: >> Unhandled REPE case > > > If you see this, check that you have > http://www.goop.org/~jeremy/valgrind/76-repe-scas.patch > and apply if not. > > Jeff > -- 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: Jeff D. <jd...@ad...> - 2004-08-03 18:41:32
|
If you get past the clone and repe problems in valgrind, there was another
where V was confused by UML's stack switching. I didn't see a patch for that
in my email, but someone special-cased longjmp in the stack overflow detection
to get around that.
IIRC, that got UML booting. Now, it produced almost no useful information
because V doesn't understand the kernel memory allocators. So, below are
my attempts to make it do so. These apply to UML, and describe the kernel
to V.
I don't guarantee that they are correct, but they should at least give you
an idea what needs to happen.
Jeff
V doesn't see that PTRACE_FAULTINFO initializes the fault struct given to it:
diff -Naur um/arch/um/kernel/skas/process.c v/arch/um/kernel/skas/process.c
--- um/arch/um/kernel/skas/process.c Tue Jan 14 21:09:16 2003
+++ v/arch/um/kernel/skas/process.c Mon Dec 23 11:42:39 2002
@@ -25,6 +25,8 @@
#include "proc_mm.h"
#include "skas_ptrace.h"
+#include "memcheck.h"
+
unsigned long exec_regs[FRAME_SIZE];
unsigned long exec_fp_regs[HOST_FP_SIZE];
unsigned long exec_fpx_regs[HOST_XFP_SIZE];
@@ -40,6 +42,7 @@
panic("handle_segv - PTRACE_FAULTINFO failed, errno = %d\n",
errno);
+ VALGRIND_MAKE_READABLE(&fault, sizeof(fault));
segv(fault.addr, 0, FAULT_WRITE(fault.is_write), 1, NULL);
}
This makes buffers writeable according to V when they are handed out by
the slab allocator, and no-access when they are freed:
diff -Naur um/mm/slab.c v/mm/slab.c
--- um/mm/slab.c Fri Dec 20 18:42:53 2002
+++ v/mm/slab.c Mon Dec 23 11:15:31 2002
@@ -76,6 +76,8 @@
#include <linux/seq_file.h>
#include <asm/uaccess.h>
+#include "memcheck.h"
+
/*
* DEBUG - 1 for kmem_cache_create() to honour; SLAB_DEBUG_INITIAL,
* SLAB_RED_ZONE & SLAB_POISON.
@@ -500,6 +502,11 @@
* it is a named-page or buffer-page. The members it tests are
* of no interest here.....
*/
+
+ if(addr != NULL)
+ VALGRIND_MAKE_WRITABLE(addr,
+ (1 << cachep->gfporder) * PAGE_SIZE);
+
return addr;
}
@@ -1076,8 +1083,11 @@
* the same cache which they are a constructor for.
* Otherwise, deadlock. They must also be threaded.
*/
- if (cachep->ctor)
+ if (cachep->ctor){
+ VALGRIND_MAKE_WRITABLE(objp, cachep->objsize);
cachep->ctor(objp, cachep, ctor_flags);
+ VALGRIND_MAKE_NOACCESS(objp, cachep->objsize);
+ }
#if DEBUG
if (cachep->flags & SLAB_RED_ZONE)
objp -= BYTES_PER_WORD;
@@ -1528,7 +1538,11 @@
*/
void * kmem_cache_alloc (kmem_cache_t *cachep, int flags)
{
- return __kmem_cache_alloc(cachep, flags);
+ void *ptr = __kmem_cache_alloc(cachep, flags);
+
+ if(ptr != NULL)
+ VALGRIND_MAKE_READABLE(ptr, cachep->objsize);
+ return ptr;
}
/**
@@ -1557,10 +1571,16 @@
cache_sizes_t *csizep = cache_sizes;
for (; csizep->cs_size; csizep++) {
+ void *ptr;
if (size > csizep->cs_size)
continue;
- return __kmem_cache_alloc(flags & GFP_DMA ?
- csizep->cs_dmacachep : csizep->cs_cachep, flags);
+ ptr = __kmem_cache_alloc(flags & GFP_DMA ?
+ csizep->cs_dmacachep :
+ csizep->cs_cachep, flags);
+ if(ptr != NULL)
+ VALGRIND_MAKE_WRITABLE(ptr, size);
+
+ return ptr;
}
return NULL;
}
Ditto for vmalloc/vfree:
diff -Naur um/mm/vmalloc.c v/mm/vmalloc.c
--- um/mm/vmalloc.c Mon Feb 25 12:50:45 2002
+++ v/mm/vmalloc.c Mon Dec 23 11:30:26 2002
@@ -16,6 +16,8 @@
#include <asm/uaccess.h>
#include <asm/pgalloc.h>
+#include "memcheck.h"
+
rwlock_t vmlist_lock = RW_LOCK_UNLOCKED;
struct vm_struct * vmlist;
@@ -212,11 +214,14 @@
printk(KERN_ERR "Trying to vfree() bad address (%p)\n", addr);
return;
}
+
write_lock(&vmlist_lock);
for (p = &vmlist ; (tmp = *p) ; p = &tmp->next) {
if (tmp->addr == addr) {
*p = tmp->next;
vmfree_area_pages(VMALLOC_VMADDR(tmp->addr), tmp->size);
+ VALGRIND_MAKE_NOACCESS(VMALLOC_VMADDR(tmp->addr),
+ tmp->size);
write_unlock(&vmlist_lock);
kfree(tmp);
return;
@@ -244,6 +249,8 @@
vfree(addr);
return NULL;
}
+
+ VALGRIND_MAKE_WRITABLE(addr, size);
return addr;
}
|
|
From: Jeff D. <jd...@ad...> - 2004-08-03 18:33:39
|
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: > @@ -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 It handles the clone by calling clone itself, creating a new valgrind thread which will go on grinding the new UML thread. Also, I saw this: > valgrind: the `impossible' happened: > Unhandled REPE case If you see this, check that you have http://www.goop.org/~jeremy/valgrind/76-repe-scas.patch and apply if not. Jeff |
|
From: Nicholas N. <nj...@ca...> - 2004-08-03 18:17:01
|
On Tue, 3 Aug 2004, Lucas Brasilino wrote: > 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? > 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. N |
|
From: D. B. <db...@en...> - 2004-08-03 17:34:00
|
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() !?!!?? :
[u2](dbahi)276$ ~/valgrind-2.1.2/bin/valgrind -v --tool=memcheck
./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
==2951== Memcheck, a memory error detector for x86-linux.
==2951== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==2951== Using valgrind-2.1.2, a program supervision framework for
x86-linux.
==2951== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==2951== Valgrind library directory:
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind
==2951== Command line
==2951== ./linux
==2951== umid=kickme
==2951== ubd0=/local/cow/kickmoo,/local/dbahi/root_fs.rh-9-full
==2951== ubd1=/local/cow/kickmoo2,/local/dbahi/swap_fs.256
==2951== hostfs=/local/hostfs
==2951== Startup, with flags:
==2951== -v
==2951== --tool=memcheck
==2951== Contents of /proc/version:
==2951== 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
==2951== Reading syms from
/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux (0x8048000)
==2951== Reading syms from /lib/ld-2.3.2.so (0x1B8E4000)
==2951== object doesn't have any debug info
==2951== Reading syms from
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/stage2 (0xB0000000)
==2951== Reading syms from /lib/ld-2.3.2.so (0xB1000000)
==2951== object doesn't have any debug info
==2951== Reading syms from /lib/libdl-2.3.2.so (0xB1031000)
==2951== object doesn't have any debug info
==2951== Reading syms from /lib/i686/libc-2.3.2.so (0xB1036000)
==2951== object doesn't have any debug info
==2951== Reading syms from
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vgskin_memcheck.so
(0xB126F000)
==2951== Reading suppressions file:
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/default.supp
==2951== REDIRECT soname:libc.so.6(__GI___errno_location) to
soname:libpthread.so.0(__errno_location)
==2951== REDIRECT soname:libc.so.6(__errno_location) to
soname:libpthread.so.0(__errno_location)
==2951== REDIRECT soname:libc.so.6(__GI___h_errno_location) to
soname:libpthread.so.0(__h_errno_location)
==2951== REDIRECT soname:libc.so.6(__h_errno_location) to
soname:libpthread.so.0(__h_errno_location)
==2951== REDIRECT soname:libc.so.6(__GI___res_state) to
soname:libpthread.so.0(__res_state)
==2951== REDIRECT soname:libc.so.6(__res_state) to
soname:libpthread.so.0(__res_state)
==2951== REDIRECT soname:libc.so.6(stpcpy) to
*vgpreload_memcheck.so*(stpcpy)
==2951== REDIRECT soname:libc.so.6(strnlen) to
*vgpreload_memcheck.so*(strnlen)
==2951== REDIRECT soname:ld-linux.so.2(stpcpy) to
*vgpreload_memcheck.so*(stpcpy)
==2951== REDIRECT soname:ld-linux.so.2(strchr) to
*vgpreload_memcheck.so*(strchr)
==2951==
==2951== Reading syms from
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vg_inject.so (0x1B8FB000)
==2951== Reading syms from
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vgpreload_memcheck.so
(0x1B900000)
==2951== TRANSLATE: 0x1B8F5BB0 redirected to 0x1B903498
==2951== Reading syms from /lib/libutil-2.3.2.so (0x1B907000)
==2951== object doesn't have any debug info
==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.
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.
==2951== This may be because the functionality is hard to implement,
==2951== or because no reasonable program would behave this way,
==2951== or because nobody has yet needed it. In any case, let us know at
==2951== valgrind.kde.org and/or try to work around the problem, if you can.
==2951==
==2951== Valgrind has to exit now. Sorry. Bye!
==2951==
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==2951== at 0x420DF139: clone (in /lib/tls/libc-2.3.2.so)
==2951== by 0x80DA3A4: can_do_skas (process.c:239)
==2951== by 0x80DE595: linux_main (um_arch.c:332)
==2951== by 0x80532AF: main (main.c:148)
Jeff Dike wrote:
> nj...@ca... said:
>
>>What address was UML trying to load something at? Is that adjustable?
>
>
> It is now. Get the load-low patch from
> http://user-mode-linux.sourceforge.net/patches.html
>
> It will make UML load where every normal process loads when CONFIG_MODE_SKAS
> is on and CONFIG_MODE_TT is off. This should get you past valgrind's address
> space assumptions.
>
> As a side-benefit, this will allow UML to have much greater physical memory
> without needing to go to highmem. If you take advantage of this, either enable
> CONFIG_STATIC_LINK or keep the physical memory size below about 750M. The
> reason is you don't want to push UML physical memory into the 0x40000000 area
> occupied by shared libraries. With CONFIG_STATIC_LINK, this problem goes away
> and you can have physical memory up to about 2.75G.
>
> Let me know if there are any problems. It's not well tested - I ran it enough
> to see it panic because it had no root filesystem. My current work box doesn't
> have skas on it yet, so I can't boot this one up totally.
>
> Jeff
>
--
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: Nicholas N. <nj...@ca...> - 2004-08-03 17:30:09
|
On Mon, 2 Aug 2004, James Ahlborn wrote: > i was testing out the 2.1.2 version of valgrind on my redhat 7.3 box, and it was > virtually unuseable. i ran 2.0.0 fine with our application (slow, but > reasonable). with 2.1.2, the screen takes forever for each repaint, such that > it's almost impossible to use. any ideas on what changes might have caused > this? any ideas how i could diagnose the slowdown? That sounds unusual... I'd guess it's caused by the changes in the way system calls are handled, esp. block system calls. The output of --trace-syscalls=yes might help identify the problem if it's a particular system call that's the problem. You could also try the little-used --lowlat-signals=yes and --lowlat-syscalls=yes options? If they don't work, it would be great if you could file a bug report (see valgrind.kde.org/bugs.html). Thanks. HTH N |
|
From: Jeff D. <jd...@ad...> - 2004-08-03 16:54:14
|
nj...@ca... said: > What address was UML trying to load something at? Is that adjustable? It is now. Get the load-low patch from http://user-mode-linux.sourceforge.net/patches.html It will make UML load where every normal process loads when CONFIG_MODE_SKAS is on and CONFIG_MODE_TT is off. This should get you past valgrind's address space assumptions. As a side-benefit, this will allow UML to have much greater physical memory without needing to go to highmem. If you take advantage of this, either enable CONFIG_STATIC_LINK or keep the physical memory size below about 750M. The reason is you don't want to push UML physical memory into the 0x40000000 area occupied by shared libraries. With CONFIG_STATIC_LINK, this problem goes away and you can have physical memory up to about 2.75G. Let me know if there are any problems. It's not well tested - I ran it enough to see it panic because it had no root filesystem. My current work box doesn't have skas on it yet, so I can't boot this one up totally. Jeff |
|
From: Lucas B. <bra...@re...> - 2004-08-03 16:14:18
|
Hi! 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 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? thanks a lot in advance. -- []'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: Nicholas N. <nj...@ca...> - 2004-08-03 14:31:56
|
On Tue, 3 Aug 2004, Jeff Dike wrote: >> What address was UML trying to load something at? > > 0xa0000000 Currently Valgrind uses 0xb0000000--0xbfffffff for itself, always. Below that depends which tool you are using, if it uses "shadow memory" (ie. shadowing every memory value with a metavalue), and how big the shadow metavalues are. For example, Memcheck uses 9 bits of shadow memory for every byte of real memory, so it reserves down to 0x52c00000 or so for its own use. If you try Addrcheck, which only uses 1 shadow bit per real byte, it will reserve down to only about 0x9c000000. If you use --tool=none, no shadow memory is needed so you should be able to use up to about 0xaf000000. HTH N |
|
From: Jeff D. <jd...@ad...> - 2004-08-03 13:51:18
|
nj...@ca... said: > What address was UML trying to load something at? 0xa0000000 > Is that adjustable? Yup, just something I haven't got around to doing yet. Jeff |
|
From: Nicholas N. <nj...@ca...> - 2004-08-03 12:56:21
|
On Tue, 3 Aug 2004, pkr wrote: >> That looks like a header bug, which you're likely to get no matter which >> gcc version you use. I'm no expert on header bugs, unfortunately. > > The same gcc compiles 2.0.0 which is what I was trying to use in the > first place and landed into reloc error. That's because 2.1.2 uses the header which is broken on FC1, whereas 2.0.0 doesn't. The gcc version is irrelevant. 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: pkr <pan...@ya...> - 2004-08-03 12:15:06
|
Nicholas Nethercote wrote: > On Tue, 3 Aug 2004, Pankaj Rathore wrote: > > I've reworded it: "For one thing, 2.1.2 can be compiled with gcc-3.4.X, > whereas 2.0.0 cannot." Is that clearer? > Gotcha, I was staring a bit too hard I guess. > > That looks like a header bug, which you're likely to get no matter which > gcc version you use. I'm no expert on header bugs, unfortunately. The same gcc compiles 2.0.0 which is what I was trying to use in the first place and landed into reloc error. Pankaj |
|
From: James B. <ja...@ha...> - 2004-08-03 12:00:40
|
On Tue, 2004-08-03 at 11:33, Nicholas Nethercote wrote: > > I did see a compile issue with gcc 3.3.2. (attached > > below). I can tell u for sure that /usr/include/ files > > were never touched. > > That looks like a header bug, which you're likely to get no matter which > gcc version you use. I'm no expert on header bugs, unfortunately. Its a fedora core 1 bug, thats been discussed on this list before: http://article.gmane.org/gmane.comp.debugging.valgrind/1583 Cheers, James. -- James Begley |
|
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: Nicholas N. <nj...@ca...> - 2004-08-03 11:33:38
|
On Tue, 3 Aug 2004, Pankaj Rathore wrote: > <from valgrind homepage START> > Relative to 2.1.1, a large number of minor problems > have been fixed, and so if you use 2.1.1 you should > try 2.1.2. Users of the last stable release, 2.0.0, > might also want to try this release. For one thing, > 2.1.2 compiles with gcc-3.4.X, whereas 2.0.0 doesn't. > <from valgrind homepage END> I've reworded it: "For one thing, 2.1.2 can be compiled with gcc-3.4.X, whereas 2.0.0 cannot." Is that clearer? > I did see a compile issue with gcc 3.3.2. (attached > below). I can tell u for sure that /usr/include/ files > were never touched. That looks like a header bug, which you're likely to get no matter which gcc version you use. I'm no expert on header bugs, unfortunately. N |
|
From: Pankaj R. <pan...@ya...> - 2004-08-03 11:21:06
|
--- Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 3 Aug 2004, pkr wrote:
>
> > Unfortunately I cant do this as I dont have gcc
> 3.4 to compile
> > the latest one.
>
> Why do you need gcc 3.4? I use gcc 3.2.2 without
> any problems, and
> earlier ones should work too, AFAIK.
>
<from valgrind homepage START>
Relative to 2.1.1, a large number of minor problems
have been fixed, and so if you use 2.1.1 you should
try 2.1.2. Users of the last stable release, 2.0.0,
might also want to try this release. For one thing,
2.1.2 compiles with gcc-3.4.X, whereas 2.0.0 doesn't.
<from valgrind homepage END>
I did see a compile issue with gcc 3.3.2. (attached
below). I can tell u for sure that /usr/include/ files
were never touched.
Thanks
Pankaj
==============================================
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:
/usr/include/asm/timex.h:33: error: syntax error
before "cacheflush_time"
/usr/include/asm/timex.h:35: error: syntax error
before "get_cycles"
gmake[4]: *** [vg_syscalls.o] Error 1
gmake[4]: Leaving directory
`/disk1/pankajkr/valgrind-2.1.2/coregrind'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/disk1/pankajkr/valgrind-2.1.2/coregrind'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/disk1/pankajkr/valgrind-2.1.2/coregrind'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/disk1/pankajkr/valgrind-2.1.2'
gmake: *** [all] Error 2
[root@andlx-pankajkr valgrind-2.1.2]# gcc --version
gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE.
2
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-03 11:01:18
|
On Tue, 3 Aug 2004, pkr wrote: > Unfortunately I cant do this as I dont have gcc 3.4 to compile > the latest one. Why do you need gcc 3.4? I use gcc 3.2.2 without any problems, and earlier ones should work too, AFAIK. > So I am wondering if there is a binary version of valigrind 2.1.2 available > for download ? Not from valgrind.kde.org. > Is there a particular reason that binary versions are not made available > for download ? Not really, but it's extra work for developers and nobody's ever complained about it before. N |
|
From: pkr <pan...@ya...> - 2004-08-03 10:47:23
|
Unfortunately I cant do this as I dont have gcc 3.4 to compile the latest one. So I am wondering if there is a binary version of valigrind 2.1.2 available for download ? Is there a particular reason that binary versions are not made available for download ? Thanks, Pankaj Tom Hughes wrote: > In message <cenct6$oua$1...@se...> > pan...@ya... wrote: > > >>Can somebody tell what could be the problem ? >>I have a target host scenario. Valgrind is compiled on the host >>and taken to the target. >>Any workarounds ? > > > Yes. Use a more recent version of valgrind that fixes this problem. > > Tom > |
|
From: Nicholas N. <nj...@ca...> - 2004-08-03 09:31:38
|
On Tue, 3 Aug 2004, Jeff Dike wrote: > db...@en... said: >> Executable is mapped outside of range (nil)-0x52c00000 valgrind: >> do_exec(/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux) >> failed: Cannot allocate memory >> >> How does one get around this sudden valgrind exit? > > If I remember right, there is a hard-coded address in valgrind. If the process > loads above that you get that error. Changing it and rebuilding doesn't seem > to hurt anything. It's not quite hard-coded, but close -- that address depends on another address that is hard-coded, unfortunately. Programs that have to load pieces at high addresses don't interact well with Valgrind, which partitions the address space, the low part for the client program, the high part for Valgrind. What address was UML trying to load something at? Is that adjustable? N |
|
From: Tom H. <th...@cy...> - 2004-08-03 07:16:16
|
In message <cenct6$oua$1...@se...>
pan...@ya... wrote:
> Can somebody tell what could be the problem ?
> I have a target host scenario. Valgrind is compiled on the host
> and taken to the target.
> Any workarounds ?
Yes. Use a more recent version of valgrind that fixes this problem.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: pkr <pan...@ya...> - 2004-08-03 07:01:00
|
Hi,
Can somebody tell what could be the problem ?
I have a target host scenario. Valgrind is compiled on the host
and taken to the target.
Any workarounds ?
Thanks,
Pankaj
Linux(debug)# valgrind --version
valgrind-2.0.0
Linux(debug)# valgrind -v --logfile=/var/dpvm_mem_log /isan/bin/dpvm
<tons of symobls output...>
and finally
7113: symbol=__libc_waitpid; lookup in file=/lib/libc.so.6
7113: /usr/lib/valgrind/valgrind.so: error: relocation error:
symbol __libc_waitpid, version GLIBC_PRIVATE not defined in file
libc.so.6 with link time reference (fatal)
/isan/bin/dpvm: relocation error: /usr/lib/valgrind/valgrind.so: symbol
__libc_waitpid, version GLIBC_PRIVATE not defined in file libc.so.6 with
link time reference
|
|
From: Tom H. <th...@cy...> - 2004-08-03 06:16:23
|
In message <loo...@po...>
David Fernandez <df...@qu...> wrote:
> I agree the number is quite large but I started with 100, 1000,10000 and so
> on and I still get the same error. The application starts to come up but
> then valgrind aborts right after printing the VG_N_RWLOCKS error.
>
> My application should not require more than 200 RW locks and maybe that's
> still high but is a good estimate.
Sounds like there is a bug in valgrind then, if what you say about your
application is right. If you only need about 200 then setting VG_N_RWLOCKS
to 1000 should obviously be plenty.
> Any suggestions on how to keep valgrind happy?
Well clearly there must be a bug in valgrind. I suggest you try and
create a simple test case and then file a bug report.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeff D. <jd...@ad...> - 2004-08-03 04:18:53
|
db...@en... said: > Executable is mapped outside of range (nil)-0x52c00000 valgrind: > do_exec(/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux) > failed: Cannot allocate memory > > How does one get around this sudden valgrind exit? If I remember right, there is a hard-coded address in valgrind. If the process loads above that you get that error. Changing it and rebuilding doesn't seem to hurt anything. Jeff |
|
From: D. B. <db...@en...> - 2004-08-03 02:47:59
|
cc'ing valgrind users to solicit support! as of valgrind 2.1.2 is happy as can be within a User Mode Linux hosted session. This was tested with 2.4.24-1um and 2.4.26-2um + incrementals on a RedHat 9 (non-nptl, skas) host - and using RH9 UML filesystems. still trouble with launching a UML itself under valgrind (even with MODE_SKAS, ! MODE_TT, and KERNEL_STACK_ORDER=3) for starters we have: [u2](dbahi)443$ ~/valgrind-2.1.2/bin/valgrind --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/kickdir/ Executable is mapped outside of range (nil)-0x52c00000 valgrind: do_exec(/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux) failed: Cannot allocate memory How does one get around this sudden valgrind exit? Bahi, David wrote: > back some time ago it seems like someone had more than a clue as to what > was requried to get valgrind working under UML... well as of 2.1.1 it > still ain't working. > > http://marc.theaimsgroup.com/?l=user-mode-linux-devel&m=107066894230633& > w=2 > > I was wondering if a patch was available for our 'community' to make use > of this tool... for both running the UML as an application and for > running > applications within the UML. > > It seems that for running valgrind within the UML there is a signal > handling > problem where 'restorer' is NULL and causes a panic in > setup_signal_stack_si > > signal_kernel.c > handle_signal() > > if (ka->sa.sa_flags & SA_RESTORER) restorer = > ka->sa.sa_restorer; > else restorer = NULL; > > if(ka->sa.sa_flags & SA_SIGINFO) > err = setup_signal_stack_si(sp, signr, (unsigned long) > handler, > restorer, regs, info, > &save); > > thanks for any insight. > > db > > "The kernel is the only UNIX code that cannot be substituted by a user > to his own liking. For this reason, the kernel should make as few real > decisions as possible." -- K. Thompson -- 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). |