|
From: Naveen K. <g_n...@ya...> - 2005-01-25 20:32:45
|
Hi all,
I have finally got to the stage where the following
commands
valgrind
valgrind --help
valgrind --tool=xxxxx
valgrind --tool=xxxxx --help
work. Some items of note. I am using the following
address space mapping
client_base 9000000 (498MB)
client_mapbase 28280000 (998MB)
client_end 66900000 (1MB)
shadow_base 66A00000 (1684MB)
shadow_end CFE20000 (1MB)
valgrind_base D0000000 (255MB)
valgrind_end DFFFFFFF
since the stack is positioned below the text
segment(for sol-x86) the whole space above text until
kernelbase can be used. kernelbase has been #defined
to 0xE0000000. CLIENT_BASE starts from 0x09000000
instead of 0x00000000 as in Linux-x86. In
layout_remaining_space
client_size should include VG_(valgrind_base) and
VG_(client_base) in the calculation.
client_size = ROUNDDN((VG_(valgrind_base)-
REDZONE_SIZE-VG_(client_base)) / (1.+ratio),
CLIENT_SIZE_MULTIPLE);
Am I correct is doing that ?
Another interesting note. When doing a fillgap from
0x08a00000(text seg end) to 0xD0000000(kickstart_base)
the mmap call failed with err ENOSPC. However if you
split the region into chunks and do an mmap it
works!!!. I dont know why. This is weird. Currently I
break it up into 0x40000000 size chunks.
This was one tough err to track down.
The problem I am currently having is that when
executing in stage2, the program crashes at fprintf(or
printf) in load_ELF(ume.c). A printf in vg_main.c
shows no problems but a printf at any point in
load_ELF gives a seg fault. Any ideas ???
Thanks
Naveen
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: Jeremy F. <je...@go...> - 2005-01-25 23:21:19
|
On Tue, 2005-01-25 at 12:32 -0800, Naveen Kumar wrote: > Hi all, > I have finally got to the stage where the following > commands > > valgrind > valgrind --help > valgrind --tool=xxxxx > valgrind --tool=xxxxx --help > > work. Some items of note. I am using the following > address space mapping > > client_base 9000000 (498MB) > client_mapbase 28280000 (998MB) > client_end 66900000 (1MB) > shadow_base 66A00000 (1684MB) > shadow_end CFE20000 (1MB) > valgrind_base D0000000 (255MB) > valgrind_end DFFFFFFF > > since the stack is positioned below the text > segment(for sol-x86) the whole space above text until > kernelbase can be used. kernelbase has been #defined > to 0xE0000000. CLIENT_BASE starts from 0x09000000 > instead of 0x00000000 as in Linux-x86. In > layout_remaining_space Why start at 0x9000000? client_base is the base of the client address space, so it has to include the client stack. Setting client_base to 0x9000000 implies that it is absolutely forbidden, under any circumstances, for the client to touch memory in the range 0x0-0x9000000. > client_size should include VG_(valgrind_base) and > VG_(client_base) in the calculation. > > client_size = ROUNDDN((VG_(valgrind_base)- > REDZONE_SIZE-VG_(client_base)) / (1.+ratio), > CLIENT_SIZE_MULTIPLE); > > Am I correct is doing that ? Well, if the range 0-client_base off limits for client use, then probably. > Another interesting note. When doing a fillgap from > 0x08a00000(text seg end) to 0xD0000000(kickstart_base) > the mmap call failed with err ENOSPC. However if you > split the region into chunks and do an mmap it > works!!!. I dont know why. This is weird. Currently I > break it up into 0x40000000 size chunks. > This was one tough err to track down. Yeah, some Linux kernels with some configurations do that too, though normally its OK because those mappings are mapped out of a file. The kernel is applying a heuristic to prevent your process from using "too much" memory, by trying to guess how much the process will end up using by looking at the address space it claims. Since we never intend to use that memory at all, its estimates are off. > The problem I am currently having is that when > executing in stage2, the program crashes at fprintf(or > printf) in load_ELF(ume.c). A printf in vg_main.c > shows no problems but a printf at any point in > load_ELF gives a seg fault. Any ideas ??? Is it just printf, or any libc function? Is memory padded at the time? Could it be something trying to allocate and failing? What's the fault address? J |
|
From: Naveen K. <g_n...@ya...> - 2005-01-26 01:28:52
|
--- Jeremy Fitzhardinge <je...@go...> wrote:
> On Tue, 2005-01-25 at 12:32 -0800, Naveen Kumar
> wrote:
> > Hi all,
> > I have finally got to the stage where the
> following
> > commands
> >
> > valgrind
> > valgrind --help
> > valgrind --tool=xxxxx
> > valgrind --tool=xxxxx --help
> >
> > work. Some items of note. I am using the following
> > address space mapping
> >
> > client_base 9000000 (498MB)
> > client_mapbase 28280000 (998MB)
> > client_end 66900000 (1MB)
> > shadow_base 66A00000 (1684MB)
> > shadow_end CFE20000 (1MB)
> > valgrind_base D0000000 (255MB)
> > valgrind_end DFFFFFFF
> >
> > since the stack is positioned below the text
> > segment(for sol-x86) the whole space above text
> until
> > kernelbase can be used. kernelbase has been
> #defined
> > to 0xE0000000. CLIENT_BASE starts from 0x09000000
> > instead of 0x00000000 as in Linux-x86. In
> > layout_remaining_space
>
> Why start at 0x9000000? client_base is the base of
> the client address
> space, so it has to include the client stack.
> Setting client_base to
> 0x9000000 implies that it is absolutely forbidden,
> under any
> circumstances, for the client to touch memory in the
> range
> 0x0-0x9000000.
I tried setting client_base to 0 but got a fault at
munmap((void*)VG_(client_base), client_size);
Incurred fault #6, FLTBOUNDS %pc = 0x00000000
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
*** process killed ***
Actually I just looked into it through the debugger
and this is what happens. Just after completion of the
munmap system call when I try to look at the stack
this is what I get
x/10w $esp
0x8047ab0: Cannot access memory at address 0x8047ab0
Is it because the stack is getting mapped out ?
This is the map of the process(first few entries)
08046000 8K read/write/exec [ stack ]
08048000 188K read/exec
/export/home/msat/my_local/bin/valgrind
08077000 16K read/write
/export/home/msat/my_local/bin/valgrind
0807B000 140K read/write [ heap ]
0809E000 8K read/write/exec [ heap ]
66900000 1024K - [ anon ]
D0000000 528K read/exec dev:102,7
ino:181652
D0084000 8K read/write dev:102,7
ino:181652
D0086000 1384K read/write [ anon ]
D1000000 576K read/exec /usr/lib/libc.so.1
D1090000 64K read/write/exec /usr/lib/libc.so.1
>
> > The problem I am currently having is that when
> > executing in stage2, the program crashes at
> fprintf(or
> > printf) in load_ELF(ume.c). A printf in vg_main.c
> > shows no problems but a printf at any point in
> > load_ELF gives a seg fault. Any ideas ???
>
> Is it just printf, or any libc function? Is memory
> padded at the time?
> Could it be something trying to allocate and
> failing? What's the fault
> address?
This happens only for printf/fprintf. malloc etc work
fine.
G
__________________________________
Do you Yahoo!?
All your favorites on one personal page Try My Yahoo!
http://my.yahoo.com
|
|
From: Jeremy F. <je...@go...> - 2005-01-26 05:22:16
|
On Tue, 2005-01-25 at 17:28 -0800, Naveen Kumar wrote: > --- Jeremy Fitzhardinge <je...@go...> wrote: > > > On Tue, 2005-01-25 at 12:32 -0800, Naveen Kumar > > wrote: > > > Hi all, > > > I have finally got to the stage where the > > following > > > commands > > > > > > valgrind > > > valgrind --help > > > valgrind --tool=xxxxx > > > valgrind --tool=xxxxx --help > > > > > > work. Some items of note. I am using the following > > > address space mapping > > > > > > client_base 9000000 (498MB) > > > client_mapbase 28280000 (998MB) > > > client_end 66900000 (1MB) > > > shadow_base 66A00000 (1684MB) > > > shadow_end CFE20000 (1MB) > > > valgrind_base D0000000 (255MB) > > > valgrind_end DFFFFFFF > > > > > > since the stack is positioned below the text > > > segment(for sol-x86) the whole space above text > > until > > > kernelbase can be used. kernelbase has been > > #defined > > > to 0xE0000000. CLIENT_BASE starts from 0x09000000 > > > instead of 0x00000000 as in Linux-x86. In > > > layout_remaining_space > > > > Why start at 0x9000000? client_base is the base of > > the client address > > space, so it has to include the client stack. > > Setting client_base to > > 0x9000000 implies that it is absolutely forbidden, > > under any > > circumstances, for the client to touch memory in the > > range > > 0x0-0x9000000. > > I tried setting client_base to 0 but got a fault at > munmap((void*)VG_(client_base), client_size); > > Incurred fault #6, FLTBOUNDS %pc = 0x00000000 > siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000 > Received signal #11, SIGSEGV [default] > siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000 > *** process killed *** > > Actually I just looked into it through the debugger > and this is what happens. Just after completion of the > munmap system call when I try to look at the stack > this is what I get > x/10w $esp > 0x8047ab0: Cannot access memory at address 0x8047ab0 > > Is it because the stack is getting mapped out ? > This is the map of the process(first few entries) > > 08046000 8K read/write/exec [ stack ] > 08048000 188K read/exec > /export/home/msat/my_local/bin/valgrind > 08077000 16K read/write > /export/home/msat/my_local/bin/valgrind > 0807B000 140K read/write [ heap ] > 0809E000 8K read/write/exec [ heap ] > 66900000 1024K - [ anon ] > D0000000 528K read/exec dev:102,7 > ino:181652 > D0084000 8K read/write dev:102,7 > ino:181652 > D0086000 1384K read/write [ anon ] > D1000000 576K read/exec /usr/lib/libc.so.1 > D1090000 64K read/write/exec /usr/lib/libc.so.1 You need to move the stack too. In Linux, the stack lives at the top of the address space, so stage2 uses it directly. In Solaris, when stage1 sets up the address space for stage2, it needs allocate memory for the stack in the top part of the address space, and make sure that stage2 starts of using it. This means you need to build the stack from scratch, rather than diddle with the kernel-generated one as in the Linux case. Once control has been passed to stage2, nothing should be using the original stack, so it should be OK to unmap (and then re-create for the client's use). J |