|
From: Jason K. <kra...@ca...> - 2011-03-29 14:33:34
|
Can anyone offer any suggestions about how to use valgrind in an environment which doesn't support shared libraries? I could staticly link the valgrind components into my program but it isn't clear how to handle initialization, startup, etc. The first problem will be the multiple main routines. thanks, - jason kraftcheck |
|
From: Tom H. <to...@co...> - 2011-03-29 15:13:55
|
On 29/03/11 15:33, Jason Kraftcheck wrote: > Can anyone offer any suggestions about how to use valgrind in an environment > which doesn't support shared libraries? I could staticly link the valgrind > components into my program but it isn't clear how to handle initialization, > startup, etc. The first problem will be the multiple main routines. Well valgrind is mostly static - the only place it uses shared libraries is to inject it's malloc etc replacements into your programs. If you really want to do this, it is only the code from the various vgpreload*.so libraries that you need to link into your program. You should then still be able to use valgrind in the normal way. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Jason K. <kra...@ca...> - 2011-03-29 15:25:59
|
On 03/29/2011 10:13 AM, Tom Hughes wrote: > On 29/03/11 15:33, Jason Kraftcheck wrote: > >> Can anyone offer any suggestions about how to use valgrind in an environment >> which doesn't support shared libraries? I could staticly link the valgrind >> components into my program but it isn't clear how to handle initialization, >> startup, etc. The first problem will be the multiple main routines. > > Well valgrind is mostly static - the only place it uses shared libraries > is to inject it's malloc etc replacements into your programs. > > If you really want to do this, it is only the code from the various > vgpreload*.so libraries that you need to link into your program. You > should then still be able to use valgrind in the normal way. > I tried that but I get errors like: valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux': Function not implemented Is there something I can specify for --tool= to tell valgrind not to try to load anything (because I've already statically linked coregrind and memcheck)? thanks, - jason |
|
From: Tom H. <to...@co...> - 2011-03-29 15:50:22
|
On 29/03/11 16:25, Jason Kraftcheck wrote:
> On 03/29/2011 10:13 AM, Tom Hughes wrote:
>> On 29/03/11 15:33, Jason Kraftcheck wrote:
>>
>>> Can anyone offer any suggestions about how to use valgrind in an environment
>>> which doesn't support shared libraries? I could staticly link the valgrind
>>> components into my program but it isn't clear how to handle initialization,
>>> startup, etc. The first problem will be the multiple main routines.
>>
>> Well valgrind is mostly static - the only place it uses shared libraries
>> is to inject it's malloc etc replacements into your programs.
>>
>> If you really want to do this, it is only the code from the various
>> vgpreload*.so libraries that you need to link into your program. You
>> should then still be able to use valgrind in the normal way.
>>
>
> I tried that but I get errors like:
>
> valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux':
> Function not implemented
>
> Is there something I can specify for --tool= to tell valgrind not to try to
> load anything (because I've already statically linked coregrind and memcheck)?
Messages about starting the tool refer to the point at which the
valgrind launcher execs the tool binary in the valgrind library directory.
Specifically that error means that the call to execve that the launcher
makes to switch to the tool binary has failed with ENOSYS. I rather
suspect that a system that doesn't implement execve is going to be
sufficiently odd that running valgrind on it will be a major challenge...
To understand how things work, this is how valgrind starts up:
- The valgrind launcher (/usr/bin/valgrind) is run.
- The launcher decides which tool you want execs it to
replace the launcher.
- The tool binary loads at a high address then acts as
an ELF loader and loads the target program into the
same process, using LD_PRELOAD to try and inject a
small amount of code into it.
The launcher is normally dynamically linked, but is just a normal
program and can probably be statically linked if you wish.
The tool binary is already statically linked and should not need
changing. Only the preload code needs to be added into your program somehow.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: Jason K. <kra...@ca...> - 2011-03-29 16:04:58
|
On 03/29/2011 10:50 AM, Tom Hughes wrote: > > Messages about starting the tool refer to the point at which the > valgrind launcher execs the tool binary in the valgrind library directory. > > Specifically that error means that the call to execve that the launcher > makes to switch to the tool binary has failed with ENOSYS. I rather > suspect that a system that doesn't implement execve is going to be > sufficiently odd that running valgrind on it will be a major challenge... > > To understand how things work, this is how valgrind starts up: > > - The valgrind launcher (/usr/bin/valgrind) is run. > - The launcher decides which tool you want execs it to > replace the launcher. > - The tool binary loads at a high address then acts as > an ELF loader and loads the target program into the > same process, using LD_PRELOAD to try and inject a > small amount of code into it. > > The launcher is normally dynamically linked, but is just a normal > program and can probably be statically linked if you wish. > > The tool binary is already statically linked and should not need > changing. Only the preload code needs to be added into your program > somehow. > Running like this (leaving out unnecessary details) seems to work around that issue: VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux a.out Now I see the following error: ==102== ==102== Valgrind's memory management: out of memory: ==102== newSuperblock's request for 4194304 bytes failed. ==102== 25448448 bytes have already been allocated. ==102== Valgrind cannot continue. Sorry. ==102== ==102== There are several possible reasons for this. ==102== - You have some kind of memory limit in place. Look at the ==102== output of 'ulimit -a'. Is there a limit on the size of ==102== virtual memory or address space? ==102== - You have run out of swap space. ==102== - Valgrind has a bug. If you think this is the case or you are ==102== not sure, please let us know and we'll try to fix it. ==102== Please note that programs can take substantially more memory than ==102== normal when running under Valgrind tools, eg. up to twice or ==102== more, depending on the tool. On a 64-bit machine, Valgrind ==102== should be able to make use of up 32GB memory. On a 32-bit ==102== machine, Valgrind should be able to use all the memory available ==102== to a single process, up to 4GB if that's how you have your ==102== kernel configured. Most 32-bit Linux setups allow a maximum of ==102== 3GB per process. ==102== ==102== Whatever the reason, Valgrind cannot continue. Sorry. There should be at least 2GB of memory available. Is there something odd in the way valgrind allocates this memory? thanks, - jason |
|
From: Julian S. <js...@ac...> - 2011-03-29 16:27:38
|
> VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux a.out
>
> Now I see the following error:
Try again with
VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux \
-d -d -v -v a.out
so at least we can see what's going on at startup. There may
be a lot of output.
J
|
|
From: Jason K. <kra...@ca...> - 2011-03-29 16:37:21
|
On 03/29/2011 11:21 AM, Julian Seward wrote: > >> VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux a.out >> >> Now I see the following error: > > Try again with > > VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux \ > -d -d -v -v a.out > > so at least we can see what's going on at startup. There may > be a lot of output. > --100:1:debuglog DebugLog system started by Stage 2 (main), level 2 logging requested --100:1:main Welcome to Valgrind version 3.6.1 debug logging --100:1:main Checking current stack is plausible --100:1:main Checking initial stack was noted --100:1:main Starting the address space manager --100:2:aspacem sp_at_startup = 0x00bfff6780 (supplied) --100:2:aspacem minAddr = 0x0004000000 (computed) --100:2:aspacem maxAddr = 0x00bfff5fff (computed) --100:2:aspacem cStart = 0x0004000000 (computed) --100:2:aspacem vStart = 0x0061ffb000 (computed) --100:2:aspacem suggested_clstack_top = 0x00beff6fff (computed) --100:2:aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments, 0 segnames) --100:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --100:2:aspacem 1: 0004000000-0061ffafff 1503m --100:2:aspacem 2: RSVN 0061ffb000-0061ffbfff 4096 ----- SmFixed --100:2:aspacem 3: 0061ffc000-00bfff5fff 1503m --100:2:aspacem 4: RSVN 00bfff6000-00ffffffff 1024m ----- SmFixed --100:2:aspacem >>> --100:2:aspacem Reading /proc/self/maps --100:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps (59 segments, 12 segnames) --100:2:aspacem ( 0) /lib/libc-2.4.so --100:2:aspacem ( 1) /lib/libpthread-2.4.so --100:2:aspacem ( 2) /lib/libgcc_s.so.1 --100:2:aspacem ( 3) /lib/libm-2.4.so --100:2:aspacem ( 4) /lib/libstdc++.so.6.0.8 --100:2:aspacem ( 5) /sbin.rd/ioproxy --100:2:aspacem ( 6) /lib/ld-2.4.so --100:2:aspacem ( 7) /dev/tree1 --100:2:aspacem ( 8) /ciod.rd/ciod-message-buffer-24063 --100:2:aspacem ( 9) /ciod.rd/ciod-message-buffer-24127 --100:2:aspacem (10) /ciod.rd/ciod-message-buffer-24191 --100:2:aspacem (11) /ciod.rd/ciod-message-buffer-24255 --100:2:aspacem 0: RSVN 0000000000-0000991fff 9m ----- SmFixed --100:2:aspacem 1: FILE 0000992000-0000ad4fff 1323008 r-x-- d=0x001 i=207 o=0 (0) --100:2:aspacem 2: FILE 0000ad5000-0000b91fff 774144 ----- d=0x001 i=207 o=1323008 (0) --100:2:aspacem 3: FILE 0000b92000-0000b96fff 20480 r---- d=0x001 i=207 o=1376256 (0) --100:2:aspacem 4: FILE 0000b97000-0000b97fff 4096 rw--- d=0x001 i=207 o=1396736 (0) --100:2:aspacem 5: ANON 0000b98000-0000b9afff 12288 rw--- --100:2:aspacem 6: RSVN 0000b9b000-0000baafff 65536 ----- SmFixed --100:2:aspacem 7: FILE 0000bab000-0000bbdfff 77824 r-x-- d=0x001 i=249 o=0 (1) --100:2:aspacem 8: FILE 0000bbe000-0000caafff 970752 ----- d=0x001 i=249 o=77824 (1) --100:2:aspacem 9: FILE 0000cab000-0000cabfff 4096 r---- d=0x001 i=249 o=131072 (1) --100:2:aspacem 10: FILE 0000cac000-0000cacfff 4096 rw--- d=0x001 i=249 o=135168 (1) --100:2:aspacem 11: ANON 0000cad000-0000caefff 8192 rw--- --100:2:aspacem 12: RSVN 0000caf000-0000cbefff 65536 ----- SmFixed --100:2:aspacem 13: FILE 0000cbf000-0000cd0fff 73728 r-x-- d=0x001 i=219 o=0 (2) --100:2:aspacem 14: FILE 0000cd1000-0000dbefff 974848 ----- d=0x001 i=219 o=73728 (2) --100:2:aspacem 15: FILE 0000dbf000-0000dbffff 4096 rw--- d=0x001 i=219 o=131072 (2) --100:2:aspacem 16: RSVN 0000dc0000-0000dcffff 65536 ----- SmFixed --100:2:aspacem 17: FILE 0000dd0000-0000e70fff 659456 r-x-- d=0x001 i=223 o=0 (3) --100:2:aspacem 18: FILE 0000e71000-0000ecffff 389120 ----- d=0x001 i=223 o=659456 (3) --100:2:aspacem 19: FILE 0000ed0000-0000ed3fff 16384 r---- d=0x001 i=223 o=720896 (3) --100:2:aspacem 20: FILE 0000ed4000-0000ed4fff 4096 rw--- d=0x001 i=223 o=737280 (3) --100:2:aspacem 21: RSVN 0000ed5000-0000ee4fff 65536 ----- SmFixed --100:2:aspacem 22: FILE 0000ee5000-0000fd4fff 983040 r-x-- d=0x001 i=264 o=0 (4) --100:2:aspacem 23: FILE 0000fd5000-0000fe4fff 65536 ----- d=0x001 i=264 o=983040 (4) --100:2:aspacem 24: FILE 0000fe5000-0000fe8fff 16384 r---- d=0x001 i=264 o=983040 (4) --100:2:aspacem 25: FILE 0000fe9000-0000fe9fff 4096 rw--- d=0x001 i=264 o=999424 (4) --100:2:aspacem 26: ANON 0000fea000-0000feffff 24576 rw--- --100:2:aspacem 27: RSVN 0000ff0000-0000ffffff 65536 ----- SmFixed --100:2:aspacem 28: FILE 0001000000-000101dfff 122880 r-x-- d=0x001 i=297 o=0 (5) --100:2:aspacem 29: RSVN 000101e000-00010fffff 925696 ----- SmFixed --100:2:aspacem 30: FILE 0001100000-0001100fff 4096 rw--- d=0x001 i=297 o=131072 (5) --100:2:aspacem 31: ANON 0001101000-0001122fff 139264 rwx-- --100:2:aspacem 32: RSVN 0001123000-0003ffffff 46m ----- SmFixed --100:2:aspacem 33: 0004000000-002fffffff 704m --100:2:aspacem 34: FILE 0030000000-003001ffff 131072 r-x-- d=0x001 i=196 o=0 (6) --100:2:aspacem 35: ANON 0030020000-0030022fff 12288 rw--- --100:2:aspacem 36: FILE 0030023000-0030023fff 4096 rw--- d=0x001 i=100 o=0 (7) --100:2:aspacem 37: FILE 0030024000-0030024fff 4096 rw--- d=0x001 i=100 o=0 (7) --100:2:aspacem 38: FILE 0030025000-0030025fff 4096 rw--- d=0x001 i=100 o=0 (7) --100:2:aspacem 39: FILE 0030026000-0030026fff 4096 rw--- d=0x001 i=100 o=0 (7) --100:2:aspacem 40: 0030027000-00300fffff 888832 --100:2:aspacem 41: FILE 0030100000-0030100fff 4096 r---- d=0x001 i=196 o=131072 (6) --100:2:aspacem 42: FILE 0030101000-0030101fff 4096 rw--- d=0x001 i=196 o=135168 (6) --100:2:aspacem 43: FILE 0030102000-0030502fff 4198400 rw--- d=0x001 i=5414 o=0 (8) --100:2:aspacem 44: FILE 0030503000-0030903fff 4198400 rw--- d=0x001 i=5478 o=0 (9) --100:2:aspacem 45: FILE 0030904000-0030d04fff 4198400 rw--- d=0x001 i=5542 o=0 (10) --100:2:aspacem 46: FILE 0030d05000-0031105fff 4198400 rw--- d=0x001 i=5606 o=0 (11) --100:2:aspacem 47: ANON 0031106000-0031106fff 4096 ----- --100:2:aspacem 48: ANON 0031107000-0031905fff 8384512 rw--- --100:2:aspacem 49: ANON 0031906000-0031906fff 4096 ----- --100:2:aspacem 50: ANON 0031907000-0032105fff 8384512 rw--- --100:2:aspacem 51: ANON 0032106000-0032106fff 4096 ----- --100:2:aspacem 52: ANON 0032107000-0032905fff 8384512 rw--- --100:2:aspacem 53: 0032906000-0061ffafff 758m --100:2:aspacem 54: RSVN 0061ffb000-0061ffbfff 4096 ----- SmFixed --100:2:aspacem 55: 0061ffc000-00bfbbffff 1499m --100:2:aspacem 56: ANON 00bfbc0000-00bfbd4fff 86016 rw--- --100:2:aspacem 57: 00bfbd5000-00bfff5fff 4329472 --100:2:aspacem 58: RSVN 00bfff6000-00ffffffff 1024m ----- SmFixed --100:2:aspacem >>> --100:1:main Address space manager is running --100:1:main Starting the dynamic memory manager ==100== ==100== Valgrind's memory management: out of memory: ==100== newSuperblock's request for 4194304 bytes failed. ==100== 25448448 bytes have already been allocated. ==100== Valgrind cannot continue. Sorry. ==100== ==100== There are several possible reasons for this. ==100== - You have some kind of memory limit in place. Look at the ==100== output of 'ulimit -a'. Is there a limit on the size of ==100== virtual memory or address space? ==100== - You have run out of swap space. ==100== - Valgrind has a bug. If you think this is the case or you are ==100== not sure, please let us know and we'll try to fix it. ==100== Please note that programs can take substantially more memory than ==100== normal when running under Valgrind tools, eg. up to twice or ==100== more, depending on the tool. On a 64-bit machine, Valgrind ==100== should be able to make use of up 32GB memory. On a 32-bit ==100== machine, Valgrind should be able to use all the memory available ==100== to a single process, up to 4GB if that's how you have your ==100== kernel configured. Most 32-bit Linux setups allow a maximum of ==100== 3GB per process. ==100== ==100== Whatever the reason, Valgrind cannot continue. Sorry. |
|
From: Julian S. <js...@ac...> - 2011-03-29 19:04:49
|
You might need to link the app with a non standard load address, in the same way that the valgrind executables are normally linked. See coregrind/link_tool_exe_linux.in for background. In short (I think) you need to get -Ttext=0x38000000 to the linker. Once done, you should have an entry point address a bit above that point: $ readelf -a memcheck/memcheck-x86-linux | grep Entry Entry point address: 0x38040f40 J On Tuesday, March 29, 2011, Jason Kraftcheck wrote: > On 03/29/2011 11:21 AM, Julian Seward wrote: > >> VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux a.out > > > >> Now I see the following error: > > Try again with > > > > VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux \ > > > > -d -d -v -v a.out > > > > so at least we can see what's going on at startup. There may > > be a lot of output. > > --100:1:debuglog DebugLog system started by Stage 2 (main), level 2 logging > requested > --100:1:main Welcome to Valgrind version 3.6.1 debug logging > --100:1:main Checking current stack is plausible > --100:1:main Checking initial stack was noted > --100:1:main Starting the address space manager > --100:2:aspacem sp_at_startup = 0x00bfff6780 (supplied) > --100:2:aspacem minAddr = 0x0004000000 (computed) > --100:2:aspacem maxAddr = 0x00bfff5fff (computed) > --100:2:aspacem cStart = 0x0004000000 (computed) > --100:2:aspacem vStart = 0x0061ffb000 (computed) > --100:2:aspacem suggested_clstack_top = 0x00beff6fff (computed) > --100:2:aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments, 0 > segnames) --100:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- > SmFixed --100:2:aspacem 1: 0004000000-0061ffafff 1503m > --100:2:aspacem 2: RSVN 0061ffb000-0061ffbfff 4096 ----- SmFixed > --100:2:aspacem 3: 0061ffc000-00bfff5fff 1503m > --100:2:aspacem 4: RSVN 00bfff6000-00ffffffff 1024m ----- SmFixed > --100:2:aspacem >>> > --100:2:aspacem Reading /proc/self/maps > --100:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps (59 > segments, 12 segnames) > --100:2:aspacem ( 0) /lib/libc-2.4.so > --100:2:aspacem ( 1) /lib/libpthread-2.4.so > --100:2:aspacem ( 2) /lib/libgcc_s.so.1 > --100:2:aspacem ( 3) /lib/libm-2.4.so > --100:2:aspacem ( 4) /lib/libstdc++.so.6.0.8 > --100:2:aspacem ( 5) /sbin.rd/ioproxy > --100:2:aspacem ( 6) /lib/ld-2.4.so > --100:2:aspacem ( 7) /dev/tree1 > --100:2:aspacem ( 8) /ciod.rd/ciod-message-buffer-24063 > --100:2:aspacem ( 9) /ciod.rd/ciod-message-buffer-24127 > --100:2:aspacem (10) /ciod.rd/ciod-message-buffer-24191 > --100:2:aspacem (11) /ciod.rd/ciod-message-buffer-24255 > --100:2:aspacem 0: RSVN 0000000000-0000991fff 9m ----- SmFixed > --100:2:aspacem 1: FILE 0000992000-0000ad4fff 1323008 r-x-- d=0x001 > i=207 o=0 (0) > --100:2:aspacem 2: FILE 0000ad5000-0000b91fff 774144 ----- d=0x001 > i=207 o=1323008 (0) > --100:2:aspacem 3: FILE 0000b92000-0000b96fff 20480 r---- d=0x001 > i=207 o=1376256 (0) > --100:2:aspacem 4: FILE 0000b97000-0000b97fff 4096 rw--- d=0x001 > i=207 o=1396736 (0) > --100:2:aspacem 5: ANON 0000b98000-0000b9afff 12288 rw--- > --100:2:aspacem 6: RSVN 0000b9b000-0000baafff 65536 ----- SmFixed > --100:2:aspacem 7: FILE 0000bab000-0000bbdfff 77824 r-x-- d=0x001 > i=249 o=0 (1) > --100:2:aspacem 8: FILE 0000bbe000-0000caafff 970752 ----- d=0x001 > i=249 o=77824 (1) > --100:2:aspacem 9: FILE 0000cab000-0000cabfff 4096 r---- d=0x001 > i=249 o=131072 (1) > --100:2:aspacem 10: FILE 0000cac000-0000cacfff 4096 rw--- d=0x001 > i=249 o=135168 (1) > --100:2:aspacem 11: ANON 0000cad000-0000caefff 8192 rw--- > --100:2:aspacem 12: RSVN 0000caf000-0000cbefff 65536 ----- SmFixed > --100:2:aspacem 13: FILE 0000cbf000-0000cd0fff 73728 r-x-- d=0x001 > i=219 o=0 (2) > --100:2:aspacem 14: FILE 0000cd1000-0000dbefff 974848 ----- d=0x001 > i=219 o=73728 (2) > --100:2:aspacem 15: FILE 0000dbf000-0000dbffff 4096 rw--- d=0x001 > i=219 o=131072 (2) > --100:2:aspacem 16: RSVN 0000dc0000-0000dcffff 65536 ----- SmFixed > --100:2:aspacem 17: FILE 0000dd0000-0000e70fff 659456 r-x-- d=0x001 > i=223 o=0 (3) > --100:2:aspacem 18: FILE 0000e71000-0000ecffff 389120 ----- d=0x001 > i=223 o=659456 (3) > --100:2:aspacem 19: FILE 0000ed0000-0000ed3fff 16384 r---- d=0x001 > i=223 o=720896 (3) > --100:2:aspacem 20: FILE 0000ed4000-0000ed4fff 4096 rw--- d=0x001 > i=223 o=737280 (3) > --100:2:aspacem 21: RSVN 0000ed5000-0000ee4fff 65536 ----- SmFixed > --100:2:aspacem 22: FILE 0000ee5000-0000fd4fff 983040 r-x-- d=0x001 > i=264 o=0 (4) > --100:2:aspacem 23: FILE 0000fd5000-0000fe4fff 65536 ----- d=0x001 > i=264 o=983040 (4) > --100:2:aspacem 24: FILE 0000fe5000-0000fe8fff 16384 r---- d=0x001 > i=264 o=983040 (4) > --100:2:aspacem 25: FILE 0000fe9000-0000fe9fff 4096 rw--- d=0x001 > i=264 o=999424 (4) > --100:2:aspacem 26: ANON 0000fea000-0000feffff 24576 rw--- > --100:2:aspacem 27: RSVN 0000ff0000-0000ffffff 65536 ----- SmFixed > --100:2:aspacem 28: FILE 0001000000-000101dfff 122880 r-x-- d=0x001 > i=297 o=0 (5) > --100:2:aspacem 29: RSVN 000101e000-00010fffff 925696 ----- SmFixed > --100:2:aspacem 30: FILE 0001100000-0001100fff 4096 rw--- d=0x001 > i=297 o=131072 (5) > --100:2:aspacem 31: ANON 0001101000-0001122fff 139264 rwx-- > --100:2:aspacem 32: RSVN 0001123000-0003ffffff 46m ----- SmFixed > --100:2:aspacem 33: 0004000000-002fffffff 704m > --100:2:aspacem 34: FILE 0030000000-003001ffff 131072 r-x-- d=0x001 > i=196 o=0 (6) > --100:2:aspacem 35: ANON 0030020000-0030022fff 12288 rw--- > --100:2:aspacem 36: FILE 0030023000-0030023fff 4096 rw--- d=0x001 > i=100 o=0 (7) > --100:2:aspacem 37: FILE 0030024000-0030024fff 4096 rw--- d=0x001 > i=100 o=0 (7) > --100:2:aspacem 38: FILE 0030025000-0030025fff 4096 rw--- d=0x001 > i=100 o=0 (7) > --100:2:aspacem 39: FILE 0030026000-0030026fff 4096 rw--- d=0x001 > i=100 o=0 (7) > --100:2:aspacem 40: 0030027000-00300fffff 888832 > --100:2:aspacem 41: FILE 0030100000-0030100fff 4096 r---- d=0x001 > i=196 o=131072 (6) > --100:2:aspacem 42: FILE 0030101000-0030101fff 4096 rw--- d=0x001 > i=196 o=135168 (6) > --100:2:aspacem 43: FILE 0030102000-0030502fff 4198400 rw--- d=0x001 > i=5414 o=0 (8) > --100:2:aspacem 44: FILE 0030503000-0030903fff 4198400 rw--- d=0x001 > i=5478 o=0 (9) > --100:2:aspacem 45: FILE 0030904000-0030d04fff 4198400 rw--- d=0x001 > i=5542 o=0 (10) > --100:2:aspacem 46: FILE 0030d05000-0031105fff 4198400 rw--- d=0x001 > i=5606 o=0 (11) > --100:2:aspacem 47: ANON 0031106000-0031106fff 4096 ----- > --100:2:aspacem 48: ANON 0031107000-0031905fff 8384512 rw--- > --100:2:aspacem 49: ANON 0031906000-0031906fff 4096 ----- > --100:2:aspacem 50: ANON 0031907000-0032105fff 8384512 rw--- > --100:2:aspacem 51: ANON 0032106000-0032106fff 4096 ----- > --100:2:aspacem 52: ANON 0032107000-0032905fff 8384512 rw--- > --100:2:aspacem 53: 0032906000-0061ffafff 758m > --100:2:aspacem 54: RSVN 0061ffb000-0061ffbfff 4096 ----- SmFixed > --100:2:aspacem 55: 0061ffc000-00bfbbffff 1499m > --100:2:aspacem 56: ANON 00bfbc0000-00bfbd4fff 86016 rw--- > --100:2:aspacem 57: 00bfbd5000-00bfff5fff 4329472 > --100:2:aspacem 58: RSVN 00bfff6000-00ffffffff 1024m ----- SmFixed > --100:2:aspacem >>> > --100:1:main Address space manager is running > --100:1:main Starting the dynamic memory manager > ==100== > ==100== Valgrind's memory management: out of memory: > ==100== newSuperblock's request for 4194304 bytes failed. > ==100== 25448448 bytes have already been allocated. > ==100== Valgrind cannot continue. Sorry. > ==100== > ==100== There are several possible reasons for this. > ==100== - You have some kind of memory limit in place. Look at the > ==100== output of 'ulimit -a'. Is there a limit on the size of > ==100== virtual memory or address space? > ==100== - You have run out of swap space. > ==100== - Valgrind has a bug. If you think this is the case or you are > ==100== not sure, please let us know and we'll try to fix it. > ==100== Please note that programs can take substantially more memory > than ==100== normal when running under Valgrind tools, eg. up to twice > or ==100== more, depending on the tool. On a 64-bit machine, Valgrind > ==100== should be able to make use of up 32GB memory. On a 32-bit > ==100== machine, Valgrind should be able to use all the memory > available ==100== to a single process, up to 4GB if that's how you > have your ==100== kernel configured. Most 32-bit Linux setups allow a > maximum of ==100== 3GB per process. > ==100== > ==100== Whatever the reason, Valgrind cannot continue. Sorry. > > --------------------------------------------------------------------------- > --- Enable your software for Intel(R) Active Management Technology to meet > the growing manageability and security demands of your customers. > Businesses are taking advantage of Intel(R) vPro (TM) technology - will > your software be a part of the solution? Download the Intel(R) > Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Jason K. <kra...@ca...> - 2011-03-29 20:30:10
|
On 03/29/2011 01:59 PM, Julian Seward wrote: > > You might need to link the app with a non standard load address, > in the same way that the valgrind executables are normally > linked. See coregrind/link_tool_exe_linux.in for background. > > In short (I think) you need to get -Ttext=0x38000000 to the linker. > > Once done, you should have an entry point address a bit > above that point: > > $ readelf -a memcheck/memcheck-x86-linux | grep Entry > Entry point address: 0x38040f40 > Thanks for the help. Unfortunately it results in a linker error that is beyond my understanding of what is going on: /bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux/bin/ld: parread: Not enough room for program headers (allocated 6, need 7) Section to Segment mapping: Segment Sections... 00: LOAD: .note.ABI-tag .note.BGP-tag .init 01: LOAD: .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata .except __libc_subfreeres __libc_atexit __libc_thread_subfreeres .gcc_except_table 02: LOAD: .eh_frame .tdata .tbss .ctors .dtors .jcr .data.rel.ro .got2 .data .got .sdata .sbss .bss __libc_freeres_ptrs 03: NOTE: .note.ABI-tag 04: NOTE: .note.BGP-tag 05: TLS: .tdata .tbss 06: STACK: /bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux/bin/ld: final link failed: Bad value |