|
From: smiley g. <smi...@ya...> - 2004-06-03 08:04:33
|
Hello pals,
I am trying to use valgrind(addrcheck) with a big
program. when i rebuild the whole application with
debug symbols the size of the executable is
572,973,914 bytes.(546MB)
I use RedHat Linux.
I get the following error message:
==31711== Reading syms from <executable>
==31711== mmap failed on <executable>
and no line numbers are reported.
Looking at the address map in coregrind/ume.c
I made the following change in coregrind/vg_main.c
> #define VALGRIND_MAPSIZE (128*1024*1024)
---
< #define VALGRIND_MAPSIZE (1024*1024*1024)
i.e I increased the valgrind base to mmap region to 1G
enabling the printf in vg_main.c I get the following.
client base: 0
valgrind base--end: b0000000--bfff0000 (fff0000)
valgrind mmap end: b8000000
client base--end: 0--9c000000 (9c000000)
client mapbase: 75000000
shadow base--end: 9c100000--af900000 (13800000)
after the change to vg_main.c I get the following
output
client base: 0
valgrind base--end: 78000000--bfff0000 (47ff0000)
valgrind mmap end: b8000000
client base--end: 0--68000000 (68000000)
client mapbase: 4e000000
shadow base--end: 68100000--75100000 (d000000)
Even after such a change the same error message
appears. This happens because find_map_space tries to
search below 0xb0000000 only and not the new valgrind
base 0x78000000
find_map_space: ret starts as 0xB0000000-0xD2271000
client=0
s->addr=0xB0000000 len=90112 (0xB0016000)
ret=0xB0000000
s->addr=0xB729F000 len=3452928 (0xB75EA000)
ret=0xB0016000
s->addr=0xB75FC000 len=16384 (0xB7600000)
ret=0xB75EA000
s->addr=0xB8000000 len=880640 (0xB80D7000)
ret=0xB7600000
s->addr=0xB80D7000 len=133271552 (0xBFFF0000)
ret=0xB80D7000
s == NULL
find_map_space(0xB0000000, 572985344, 0) -> 0x0
==31711== mmap failed on <executable>
In stage2.c there is hardcoded value for 0xb0000000.
165 info.map_base = 0xb0000000;
and I updated it to
165 info.map_base = 0x78000000;
This seems to help, I don't see mmap failed problem
any more and I am seeing line numbers too.
Is this a healthy change ?
Is there anything else I missed out.
Thanks,
Smile.
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-03 08:33:40
|
On Thu, 3 Jun 2004, smiley glitter wrote: > I am trying to use valgrind(addrcheck) with a big > program. when i rebuild the whole application with > debug symbols the size of the executable is > 572,973,914 bytes.(546MB) > > I get the following error message: > > ==31711== Reading syms from <executable> > ==31711== mmap failed on <executable> > I made the following change in coregrind/vg_main.c > > > #define VALGRIND_MAPSIZE (128*1024*1024) > --- > < #define VALGRIND_MAPSIZE (1024*1024*1024) > > In stage2.c there is hardcoded value for 0xb0000000. > 165 info.map_base = 0xb0000000; > and I updated it to > 165 info.map_base = 0x78000000; > > This seems to help, I don't see mmap failed problem > any more and I am seeing line numbers too. > > Is this a healthy change ? If it works for you, sure :) > Is there anything else I missed out. We've seen this before, see bugs.kde.org/show_bug.cgi?id=82301. Good to see you found a workaround, I've added that information to the bug report. Thanks for the info. N |
|
From: smiley g. <smi...@ya...> - 2005-01-31 15:05:28
|
This is in reference to the discussion in the following bug: http://bugs.kde.org/show_bug.cgi?id=82301 My executable reaches 900MB when built with debug information and can grow more. Though increasing the space alloted to valgrind proved helpful (see mail at the bottom - same as comment #1 in bug) it reduces the space for the client. So either no debug info or no memcheck was my situation. Reading the symbols and debug info from the executable happens before execution of the client program. So I tried a mmap of the executable in the client space instead of valgrind's space to read symbols. Should we bother about a client and valgrind memory split as there is no client yet at this stage. Please let me know if I have missed something. Its a rudimentary fix, please forgive me for that. Its against valgrind 2.1.2 - forgive me for that too. $ diff vg_symtab2.c ../../temp/valgrind-2.1.2_org/coregrind/ 1150d1149 < static int first_time = 1; 1188,1195c1187 < if(n_oimage > 524288000 && first_time) < { < oimage = (Addr)mmap_inner(NULL, n_oimage, VKI_PROT_READ, VKI_MAP_PRIVATE|VKI_MAP_NOSYMS, fd, 0); < first_time = 0; < } < else < { < oimage = (Addr)VG_(mmap)( NULL, n_oimage, --- > oimage = (Addr)VG_(mmap)( NULL, n_oimage, 1197,1198c1189 < 0, fd, 0); < } --- > 0, fd, 0 ); $ diff vg_mylibc.c ../../temp/valgrind-2.1.2_org/coregrind/ 252c252 < Addr mmap_inner(void *start, UInt length, UInt prot, UInt flags, UInt fd, UInt offset) --- > static Addr mmap_inner(void *start, UInt length, UInt prot, UInt flags, UInt fd, UInt offset) Thanks, Madhan. ====================================================== ====================================================== ====================================================== --- Nicholas Nethercote <nj...@ca...> wrote: > On Thu, 3 Jun 2004, smiley glitter wrote: > > > I am trying to use valgrind(addrcheck) with a big > > program. when i rebuild the whole application with > > debug symbols the size of the executable is > > 572,973,914 bytes.(546MB) > > > > I get the following error message: > > > > ==31711== Reading syms from <executable> > > ==31711== mmap failed on <executable> > > > I made the following change in coregrind/vg_main.c > > > > > #define VALGRIND_MAPSIZE (128*1024*1024) > > --- > > < #define VALGRIND_MAPSIZE (1024*1024*1024) > > > > In stage2.c there is hardcoded value for > 0xb0000000. > > 165 info.map_base = 0xb0000000; > > and I updated it to > > 165 info.map_base = 0x78000000; > > > > This seems to help, I don't see mmap failed > problem > > any more and I am seeing line numbers too. > > > > Is this a healthy change ? > > If it works for you, sure :) > > > > Is there anything else I missed out. > > We've seen this before, see > bugs.kde.org/show_bug.cgi?id=82301. Good to > see you found a workaround, I've added that > information to the bug report. > Thanks for the info. > > N __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 |
|
From: Nicholas N. <nj...@ca...> - 2005-01-31 21:08:15
|
On Mon, 31 Jan 2005, smiley glitter wrote: > My executable reaches 900MB when built with debug > information and can grow more. Though increasing the > space alloted to valgrind proved helpful (see mail at > the bottom - same as comment #1 in bug) it reduces the > space for the client. So either no debug info or no > memcheck was my situation. > > Reading the symbols and debug info from the executable > happens before execution of the client program. So I > tried a mmap of the executable in the client space > instead of valgrind's space to read symbols. That may be true for the initial executable, but when .so files are loaded later, the client is already running. > Should we bother about a client and valgrind memory > split as there is no client yet at this stage. Probably a better way to do this is to incrementally load the debug information, rather than mapping in the entire file. I've added a note to bug #82301 about this. N |
|
From: smiley g. <smi...@ya...> - 2005-02-01 13:09:48
|
I was too happy to know that Valgrind now uses the system pthread library. When I tried it I found that the absence of support for the lock prefix causes issues and makes my executable hang. http://bugs.kde.org/show_bug.cgi?id=85756 Is there an alternative for this. LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0xF 0xB1 0xA lock at 0x3566379B: __pthread_mutex_lock_internal (in /lib/tls/libpthread-0.60.so) LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0x83 0x29 0x1 lock at 0x3566398C: __pthread_mutex_unlock_usercnt (in /lib/tls/libpthread-0.60.so) ==15508== TRANSLATE: 0x356F74D0 redirected to 0x34149DE4 ==15508== TRANSLATE: 0x356F6F90 redirected to 0x341499C4 LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0xF 0xB1 0x13 lock at 0x35665257: __pthread_once_internal (in /lib/tls/libpthread-0.60.so) LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0xF 0xB1 0xA lock at 0x35664CA5: __pthread_key_create_internal (in /lib/tls/libpthread-0.60.so) LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0x83 0x29 0x1 lock at 0x35664CD5: __pthread_key_create_internal (in /lib/tls/libpthread-0.60.so) LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0x83 0x3 0x1 lock at 0x356652B2: __pthread_once_internal (in /lib/tls/libpthread-0.60.so) LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0xF 0xB1 0xA lock at 0x356637CC: __pthread_mutex_lock_internal (in /lib/tls/libpthread-0.60.so) __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo |
|
From: Tom H. <to...@co...> - 2005-02-01 15:23:16
|
In message <200...@we...>
smiley glitter <smi...@ya...> wrote:
> I was too happy to know that Valgrind now uses the
> system pthread library. When I tried it I found that
> the absence of support for the lock prefix causes
> issues and makes my executable hang.
>
> http://bugs.kde.org/show_bug.cgi?id=85756
>
> Is there an alternative for this.
How do you know that it is the lock prefix is causing the problem?
> LOCK LOCK LOCK LOCK LOCK
Current CVS builds do not print this so what are you running to
produce this message?
> disInstr: unhandled instruction bytes: 0xF0 0xF 0xB1 0xA
That is a cmpxchg instruction (with lock) that is supported so
you shouldn't get that message. It won't be executed with lock
but it will be executed.
I don't know what it is that you are running, but it doesn't seem
to be the CVS code.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|