|
From: Wan M. F. W. I. <wan...@mc...> - 2011-04-28 13:34:23
|
Hi, I'm conducting some test today using Valgrind on Android (can be referred here https://bugs.kde.org/show_bug.cgi?id=266035#c28). The test program runs well alone but when tested on valgrind, it gave me this error. /data # valgrind ./hello-arm-bionic valgrind: mmap(0x0, 2952865436) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. strace valgrind ./hello-arm-bionic gives me: /data # strace valgrind --tool=none ./hello-arm-bionic execve("/data/psi_omap_builds_users/x0152532/valgrind/bin/valgrind", ["valgrind", "--tool=none", "./hello-arm-bionic"], [/* 13 vars */]) = 0 uname({sys="Linux", node="localhost", ...}) = 0 brk(0) = 0x95000 brk(0x95d00) = 0x95d00 syscall_983045(0x954c0, 0x91b40, 0xffffffe0, 0x10, 0x932e8, 0x8, 0x10, 0xf0005, 0x91bfc, 0x4, 0x28, 0x954c0, 0, 0xbe8d7a90, 0xc88c, 0xc89c, 0x40000110, 0x954c0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0 brk(0xb6d00) = 0xb6d00 brk(0xb7000) = 0xb7000 open("./hello-arm-bionic", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0 \204\0\000"..., 4096) = 4096 close(3) = 0 readlink("/proc/self/exe", "/data/psi_omap_builds_users/x0152532/valgrind/bin/valgrind", 4096) = 58 execve("/data/psi_omap_builds_users/x0152532/valgrind/lib/valgrind/none-arm-linux", ["valgrind", "--tool=none", "./hello-arm-bionic"], [/* 14 vars */]) = 0 open("/proc/self/maps", O_RDONLY) = 3 read(3, "38000000-38204000 r-xp 00008000 "..., 100000) = 359 read(3, "", 99641) = 0 close(3) = 0 mmap2(0x61723000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x61723000 getrlimit(0x2, 0x38cb0d84, 0, 0, 0) = 0 setrlimit(RLIMIT_DATA, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0 getrlimit(0x3, 0x38cb0d8c, 0, 0, 0) = 0 rt_sigprocmask(SIG_UNBLOCK, [ILL FPE], [], 8) = 0 rt_sigaction(SIGILL, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGFPE, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGILL, {0x38077cd0, [], SA_NOMASK}, NULL, 8) = 0 rt_sigaction(SIGFPE, {0x38077cd0, [], SA_NOMASK}, NULL, 8) = 0 rt_sigaction(SIGILL, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGFPE, {SIG_DFL}, NULL, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 getcwd("/data", 4095) = 6 open("./hello-arm-bionic", O_RDONLY) = 3 stat64("./hello-arm-bionic", {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0 geteuid32() = 0 fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0 lseek(3, 0, SEEK_SET) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0 \204\0\000"..., 4096) = 4096 lseek(3, 0, SEEK_SET) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0 \204\0\000"..., 52) = 52 lseek(3, 52, SEEK_SET) = 52 read(3, "\1\0\0p�\4\0\0�\204\0\0�\204\0\0\10\0\0\0\10\0\0\0\4\0"..., 192) = 192 lseek(3, 244, SEEK_SET) = 244 read(3, "/system/bin/linker\0", 19) = 19 open("/system/bin/linker", O_RDONLY) = 4 lseek(4, 0, SEEK_SET) = 0 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\0\20\0�"..., 52) = 52 lseek(4, 52, SEEK_SET) = 52 read(4, "\1\0\0\0�\0\0\0\0\0\0\0\0\0\0�\0\0\0\0\0\0\0\0\4\0\0\0"..., 160) = 160 mmap2(0x8000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x8000 fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0 readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22 mmap2(0x9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1) = 0x9000 fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0 readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22 write(2, "valgrind: mmap(0x0, 2952865436) "..., 80valgrind: mmap(0x0, 2952865436) failed in UME with error 22 (Invalid argument). ) = 80 write(2, "valgrind: this can be caused by "..., 88valgrind: this can be caused by executables with very large text, data or bss segments. ) = 88 SYS_248(0x1, 0, 0, 0, 0 <unfinished ... exit status 1> Any idea on this error? I appreciate any idea to debug this problem. Thanks. Regards, -- Wan Mohd Fairuz WAN ISMAIL 15 Le Palais des Fleurs, 74 Boulevard Raymond Poincare, 06160 Juan les Pins, FRANCE. http://www.watt.com.my +6 017 2071591 |
|
From: Konstantin S. <kon...@gm...> - 2011-05-02 16:12:00
|
On Thu, Apr 28, 2011 at 5:12 PM, Wan Mohd Fairuz Wan Ismail < wan...@mc...> wrote: > Hi, > I'm conducting some test today using Valgrind on Android (can be referred > here https://bugs.kde.org/show_bug.cgi?id=266035#c28). The test program > runs well alone but when tested on valgrind, it gave me this error. > > > /data # valgrind ./hello-arm-bionic > valgrind: mmap(0x0, 2952865436) failed in UME with error 22 (Invalid argument). > > Last time we saw this particular error message it was caused by doing exec("/proc/self/exe"), which is currently not supported by valgrind. I also think we had the same problem somewhere in Android. --kcc > valgrind: this can be caused by executables with very large text, data or bss > segments. > > > > strace valgrind ./hello-arm-bionic gives me: > > > > /data # strace valgrind --tool=none ./hello-arm-bionic > execve("/data/psi_omap_builds_users/x0152532/valgrind/bin/valgrind", ["valgrind", "--tool=none", "./hello-arm-bionic"], [/* 13 vars */]) = 0 > uname({sys="Linux", node="localhost", ...}) = 0 > brk(0) = 0x95000 > brk(0x95d00) = 0x95d00 > syscall_983045(0x954c0, 0x91b40, 0xffffffe0, 0x10, 0x932e8, 0x8, 0x10, 0xf0005, 0x91bfc, 0x4, 0x28, 0x954c0, 0, 0xbe8d7a90, 0xc88c, 0xc89c, 0x40000110, 0x954c0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0 > brk(0xb6d00) = 0xb6d00 > brk(0xb7000) = 0xb7000 > open("./hello-arm-bionic", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0 \204\0\000"..., 4096) = 4096 > close(3) = 0 > readlink("/proc/self/exe", "/data/psi_omap_builds_users/x0152532/valgrind/bin/valgrind", 4096) = 58 > execve("/data/psi_omap_builds_users/x0152532/valgrind/lib/valgrind/none-arm-linux", ["valgrind", "--tool=none", "./hello-arm-bionic"], [/* 14 vars */]) = 0 > open("/proc/self/maps", O_RDONLY) = 3 > read(3, "38000000-38204000 r-xp 00008000 "..., 100000) = 359 > read(3, "", 99641) = 0 > close(3) = 0 > mmap2(0x61723000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x61723000 > getrlimit(0x2, 0x38cb0d84, 0, 0, 0) = 0 > setrlimit(RLIMIT_DATA, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0 > getrlimit(0x3, 0x38cb0d8c, 0, 0, 0) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ILL FPE], [], 8) = 0 > rt_sigaction(SIGILL, NULL, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGFPE, NULL, {SIG_DFL}, 8) = 0 > rt_sigaction(SIGILL, {0x38077cd0, [], SA_NOMASK}, NULL, 8) = 0 > rt_sigaction(SIGFPE, {0x38077cd0, [], SA_NOMASK}, NULL, 8) = 0 > rt_sigaction(SIGILL, {SIG_DFL}, NULL, 8) = 0 > rt_sigaction(SIGFPE, {SIG_DFL}, NULL, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > getcwd("/data", 4095) = 6 > open("./hello-arm-bionic", O_RDONLY) = 3 > stat64("./hello-arm-bionic", {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0 > geteuid32() = 0 > fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0 > lseek(3, 0, SEEK_SET) = 0 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0 \204\0\000"..., 4096) = 4096 > lseek(3, 0, SEEK_SET) = 0 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0 \204\0\000"..., 52) = 52 > lseek(3, 52, SEEK_SET) = 52 > read(3, "\1\0\0p�\4\0\0�\204\0\0�\204\0\0\10\0\0\0\10\0\0\0\4\0"..., 192) = 192 > lseek(3, 244, SEEK_SET) = 244 > read(3, "/system/bin/linker\0", 19) = 19 > open("/system/bin/linker", O_RDONLY) = 4 > lseek(4, 0, SEEK_SET) = 0 > read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\0\20\0�"..., 52) = 52 > lseek(4, 52, SEEK_SET) = 52 > read(4, "\1\0\0\0�\0\0\0\0\0\0\0\0\0\0�\0\0\0\0\0\0\0\0\4\0\0\0"..., 160) = 160 > mmap2(0x8000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x8000 > fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0 > readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22 > mmap2(0x9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1) = 0x9000 > fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0 > readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22 > write(2, "valgrind: mmap(0x0, 2952865436) "..., 80valgrind: mmap(0x0, 2952865436) failed in UME with error 22 (Invalid argument). > ) = 80 > write(2, "valgrind: this can be caused by "..., 88valgrind: this can be caused by executables with very large text, data or bss segments. > ) = 88 > SYS_248(0x1, 0, 0, 0, 0 <unfinished ... exit status 1> > > > > Any idea on this error? I appreciate any idea to debug this problem. Thanks. > > > > Regards, > > > -- > Wan Mohd Fairuz WAN ISMAIL > > 15 Le Palais des Fleurs, > 74 Boulevard Raymond Poincare, > 06160 Juan les Pins, FRANCE. > http://www.watt.com.my > +6 017 2071591 > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
|
From: John R. <jr...@bi...> - 2011-05-02 19:38:13
|
> /data # strace valgrind --tool=none ./hello-arm-bionic
[snip]
> mmap2(0x8000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x8000
> fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0
> readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22
> mmap2(0x9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1) = 0x9000
> fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0
> readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22
> write(2, "valgrind: mmap(0x0, 2952865436) "..., 80valgrind: mmap(0x0, 2952865436) failed in UME with error 22 (Invalid argument).
At the lowest level, a request such as mmap(0, 2.9GB, ...) is too large on any 32-bit system.
There is at most 3GB of user address space (at least 1GB of the 4GB is for the operating system);
valgrind and the app must share that 3GB together. Does the app normally want 2.9GB?
In general don't count on anything more than 1.2GB or so.
Also, /data/hello-arm-bionic probably is the same as the executable ./hello-arm-bionic,
so all that readlink() and mmap2() probably are connected with execve("/proc/self/exe", ...)
which is known not to work in valgrind. Instead, find the original name via the
AT_EXECFN tag in Elf32_auxv_t.
--
|
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-05-02 20:41:13
|
Hi,
After a bit digging, I found out that the 2.9GB of request is made by
/system/bin/linker (it failed on the check_mmap of the interpreter -
somewhere in switch case PT_INTERP). I will dig deeper and post here what I
found but if someone has something that can help, please post it here. I's
suspecting that the culprit here is the Android's linker and not the test
program itself.
On Mon, May 2, 2011 at 9:38 PM, John Reiser <jr...@bi...> wrote:
> > /data # strace valgrind --tool=none ./hello-arm-bionic
> [snip]
> > mmap2(0x8000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
> 0x8000
> > fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0
> > readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22
> > mmap2(0x9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1)
> = 0x9000
> > fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0
> > readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22
> > write(2, "valgrind: mmap(0x0, 2952865436) "..., 80valgrind: mmap(0x0,
> 2952865436) failed in UME with error 22 (Invalid argument).
>
> At the lowest level, a request such as mmap(0, 2.9GB, ...) is too large on
> any 32-bit system.
> There is at most 3GB of user address space (at least 1GB of the 4GB is for
> the operating system);
> valgrind and the app must share that 3GB together. Does the app normally
> want 2.9GB?
> In general don't count on anything more than 1.2GB or so.
>
> Also, /data/hello-arm-bionic probably is the same as the executable
> ./hello-arm-bionic,
> so all that readlink() and mmap2() probably are connected with
> execve("/proc/self/exe", ...)
> which is known not to work in valgrind. Instead, find the original name
> via the
> AT_EXECFN tag in Elf32_auxv_t.
>
> --
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
Wan Mohd Fairuz WAN ISMAIL
OMAP System Multimedia Integration Team (Trainee)
Texas Instrument France
f-w...@ti...
+33 (0)4 93 22 20 16
+33 (0)6 43 46 13 39
15 Le Palais des Fleurs,
74 Boulevard Raymond Poincare,
06160 Juan les Pins, FRANCE.
http://www.watt.com.my
+6 017 2071591
|
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-05-03 06:58:10
|
Hi,
I found out that the 2952865436 value comes from this code (elf.c). I think
it's about determining the size of the linker and somehow interp_size got
the value of end, in this case end is calculated to a value of 2952865436.
Does this mean that the segments of interp is not close to each other as
assumed by Julian Seward (the author)? I tried to hard coded a random value
to the size and it works (not really). The result come out wrong, but
valgrind shows the output.
Any idea on this one? Thanks.
case PT_INTERP: {
HChar *buf = VG_(malloc)("ume.LE.1", ph->p_filesz+1);
Int j;
Int intfd;
Int baseaddr_set;
vg_assert(buf);
VG_(pread)(fd, buf, ph->p_filesz, ph->p_offset);
buf[ph->p_filesz] = '\0';
sres = VG_(open)(buf, VKI_O_RDONLY, 0);
if (sr_isError(sres)) {
VG_(printf)("valgrind: m_ume.c: can't open interpreter\n");
VG_(exit)(1);
}
intfd = sr_Res(sres);
interp = readelf(intfd, buf);
if (interp == NULL) {
VG_(printf)("valgrind: m_ume.c: can't read interpreter\n");
return 1;
}
VG_(free)(buf);
baseaddr_set = 0;
for (j = 0; j < interp->e.e_phnum; j++) {
ESZ(Phdr) *iph = &interp->p[j];
ESZ(Addr) end;
if (iph->p_type != PT_LOAD)
continue;
if (!baseaddr_set) {
interp_addr = iph->p_vaddr;
interp_align = iph->p_align;
baseaddr_set = 1;
}
/* assumes that all segments in the interp are close */
end = (iph->p_vaddr - interp_addr) + iph->p_memsz;
if (end > interp_size)
interp_size = end;
}
On Mon, May 2, 2011 at 10:41 PM, Wan Mohd Fairuz Wan Ismail <
wan...@mc...> wrote:
> Hi,
> After a bit digging, I found out that the 2.9GB of request is made by
> /system/bin/linker (it failed on the check_mmap of the interpreter -
> somewhere in switch case PT_INTERP). I will dig deeper and post here what I
> found but if someone has something that can help, please post it here. I's
> suspecting that the culprit here is the Android's linker and not the test
> program itself.
>
>
>
>
> On Mon, May 2, 2011 at 9:38 PM, John Reiser <jr...@bi...> wrote:
>
>> > /data # strace valgrind --tool=none ./hello-arm-bionic
>> [snip]
>> > mmap2(0x8000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
>> 0x8000
>> > fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0
>> > readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22
>> > mmap2(0x9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1)
>> = 0x9000
>> > fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0
>> > readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22
>> > write(2, "valgrind: mmap(0x0, 2952865436) "..., 80valgrind: mmap(0x0,
>> 2952865436) failed in UME with error 22 (Invalid argument).
>>
>> At the lowest level, a request such as mmap(0, 2.9GB, ...) is too large on
>> any 32-bit system.
>> There is at most 3GB of user address space (at least 1GB of the 4GB is for
>> the operating system);
>> valgrind and the app must share that 3GB together. Does the app normally
>> want 2.9GB?
>> In general don't count on anything more than 1.2GB or so.
>>
>> Also, /data/hello-arm-bionic probably is the same as the executable
>> ./hello-arm-bionic,
>> so all that readlink() and mmap2() probably are connected with
>> execve("/proc/self/exe", ...)
>> which is known not to work in valgrind. Instead, find the original name
>> via the
>> AT_EXECFN tag in Elf32_auxv_t.
>>
>> --
>>
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today. Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>
>
>
> --
> Wan Mohd Fairuz WAN ISMAIL
> OMAP System Multimedia Integration Team (Trainee)
> Texas Instrument France
> f-w...@ti...
> +33 (0)4 93 22 20 16
> +33 (0)6 43 46 13 39
>
>
> 15 Le Palais des Fleurs,
> 74 Boulevard Raymond Poincare,
> 06160 Juan les Pins, FRANCE.
> http://www.watt.com.my
> +6 017 2071591
>
>
--
Wan Mohd Fairuz WAN ISMAIL
15 Le Palais des Fleurs,
74 Boulevard Raymond Poincare,
06160 Juan les Pins, FRANCE.
http://www.watt.com.my
+6 017 2071591
|
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-05-03 13:07:22
|
Hi, It's me again to share my findings that is now beyond my comprehension.. Please correct me if I'm wrong. The situation: The function load_ELF (elf.c) will try to load the executable and the interpreter to the memory. For android's /system/bin/linker, the calculated interp_size value is 2952865436. The formula end = (iph->p_vaddr - interp_addr) + iph->p_memsz; gives us 0xb001269c = (0xb0009000 - 0x0) + 0x969c so that's why we have interp_size as big as 2.9GB. So I tried to do interp_size = end & 0xFFFFF.. There is no more UME 22 Error but I got a Segmentation fault (the program works fine alone). Strace output (test program alone): http://pastebin.com/KJreG9rJ Valgrind output with debug (plus my own debug): http://pastebin.com/Nzh92Lv4 p/s : valgrind compiled statically using arm-none-linux-gnueabi Any idea on this? Thanks Regards, Fairuz On Tue, May 3, 2011 at 8:58 AM, Wan Mohd Fairuz Wan Ismail < wan...@mc...> wrote: > Hi, > I found out that the 2952865436 value comes from this code (elf.c). I think > it's about determining the size of the linker and somehow interp_size got > the value of end, in this case end is calculated to a value of 2952865436. > Does this mean that the segments of interp is not close to each other as > assumed by Julian Seward (the author)? I tried to hard coded a random value > to the size and it works (not really). The result come out wrong, but > valgrind shows the output. > > Any idea on this one? Thanks. > > > > case PT_INTERP: { > HChar *buf = VG_(malloc)("ume.LE.1", ph->p_filesz+1); > Int j; > Int intfd; > Int baseaddr_set; > > vg_assert(buf); > VG_(pread)(fd, buf, ph->p_filesz, ph->p_offset); > buf[ph->p_filesz] = '\0'; > > sres = VG_(open)(buf, VKI_O_RDONLY, 0); > if (sr_isError(sres)) { > VG_(printf)("valgrind: m_ume.c: can't open interpreter\n"); > VG_(exit)(1); > } > intfd = sr_Res(sres); > > interp = readelf(intfd, buf); > if (interp == NULL) { > VG_(printf)("valgrind: m_ume.c: can't read interpreter\n"); > return 1; > } > VG_(free)(buf); > > baseaddr_set = 0; > for (j = 0; j < interp->e.e_phnum; j++) { > ESZ(Phdr) *iph = &interp->p[j]; > ESZ(Addr) end; > > if (iph->p_type != PT_LOAD) > continue; > > if (!baseaddr_set) { > interp_addr = iph->p_vaddr; > interp_align = iph->p_align; > baseaddr_set = 1; > } > > /* assumes that all segments in the interp are close */ > end = (iph->p_vaddr - interp_addr) + iph->p_memsz; > > if (end > interp_size) > interp_size = end; > } > > > On Mon, May 2, 2011 at 10:41 PM, Wan Mohd Fairuz Wan Ismail < > wan...@mc...> wrote: > >> Hi, >> After a bit digging, I found out that the 2.9GB of request is made by >> /system/bin/linker (it failed on the check_mmap of the interpreter - >> somewhere in switch case PT_INTERP). I will dig deeper and post here what I >> found but if someone has something that can help, please post it here. I's >> suspecting that the culprit here is the Android's linker and not the test >> program itself. >> >> >> >> >> On Mon, May 2, 2011 at 9:38 PM, John Reiser <jr...@bi...> wrote: >> >>> > /data # strace valgrind --tool=none ./hello-arm-bionic >>> [snip] >>> > mmap2(0x8000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = >>> 0x8000 >>> > fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0 >>> > readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22 >>> > mmap2(0x9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, >>> 0x1) = 0x9000 >>> > fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0 >>> > readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22 >>> > write(2, "valgrind: mmap(0x0, 2952865436) "..., 80valgrind: mmap(0x0, >>> 2952865436) failed in UME with error 22 (Invalid argument). >>> >>> At the lowest level, a request such as mmap(0, 2.9GB, ...) is too large >>> on any 32-bit system. >>> There is at most 3GB of user address space (at least 1GB of the 4GB is >>> for the operating system); >>> valgrind and the app must share that 3GB together. Does the app normally >>> want 2.9GB? >>> In general don't count on anything more than 1.2GB or so. >>> >>> Also, /data/hello-arm-bionic probably is the same as the executable >>> ./hello-arm-bionic, >>> so all that readlink() and mmap2() probably are connected with >>> execve("/proc/self/exe", ...) >>> which is known not to work in valgrind. Instead, find the original name >>> via the >>> AT_EXECFN tag in Elf32_auxv_t. >>> >>> -- >>> >>> >>> ------------------------------------------------------------------------------ >>> WhatsUp Gold - Download Free Network Management Software >>> The most intuitive, comprehensive, and cost-effective network >>> management toolset available today. Delivers lowest initial >>> acquisition cost and overall TCO of any competing solution. >>> http://p.sf.net/sfu/whatsupgold-sd >>> _______________________________________________ >>> Valgrind-users mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>> >> >> >> >> -- >> Wan Mohd Fairuz WAN ISMAIL >> OMAP System Multimedia Integration Team (Trainee) >> Texas Instrument France >> f-w...@ti... >> +33 (0)4 93 22 20 16 >> +33 (0)6 43 46 13 39 >> >> >> 15 Le Palais des Fleurs, >> 74 Boulevard Raymond Poincare, >> 06160 Juan les Pins, FRANCE. >> http://www.watt.com.my >> +6 017 2071591 >> >> > > > -- > Wan Mohd Fairuz WAN ISMAIL > > 15 Le Palais des Fleurs, > 74 Boulevard Raymond Poincare, > 06160 Juan les Pins, FRANCE. > http://www.watt.com.my > +6 017 2071591 > > -- Wan Mohd Fairuz WAN ISMAIL OMAP System Multimedia Integration Team (Trainee) Texas Instrument France f-w...@ti... +33 (0)4 93 22 20 16 +33 (0)6 43 46 13 39 15 Le Palais des Fleurs, 74 Boulevard Raymond Poincare, 06160 Juan les Pins, FRANCE. http://www.watt.com.my +6 017 2071591 |
|
From: John R. <jr...@bi...> - 2011-05-03 14:17:53
|
> The formula end = (iph->p_vaddr - interp_addr) + iph->p_memsz; gives us 0xb001269c = (0xb0009000 - 0x0) + 0x969c so that's why we have interp_size as big as 2.9GB. So I tried to do interp_size = end & 0xFFFFF.. There is no more UME 22 Error but I got a Segmentation fault (the program works fine > alone). Please run these two readelf commands and post the results: readelf --segments ./hello-arm-bionic # the name of the main program readelf --segments _interpreter_name_ # /lib/ld-linux*.so.* or something similar -- |
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-05-03 14:24:15
|
Here you are:
x0152532@unx0152532:~/mydroid$ readelf --segments ./hello-arm-bionic
Elf file type is EXEC (Executable file)
Entry point 0x8420
There are 6 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x0004cc 0x000084cc 0x000084cc 0x00008 0x00008 R 0x4
PHDR 0x000034 0x00008034 0x00008034 0x000c0 0x000c0 R E 0x4
INTERP 0x0000f4 0x000080f4 0x000080f4 0x00013 0x00013 R 0x1
[Requesting program interpreter: /system/bin/linker]
LOAD 0x000000 0x00008000 0x00008000 0x004d4 0x004d4 R E 0x1000
LOAD 0x001000 0x00009000 0x00009000 0x000fc 0x00110 RW 0x1000
DYNAMIC 0x001020 0x00009020 0x00009020 0x000c0 0x000c0 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .ARM.exidx
01
02 .interp
03 .interp .hash .dynsym .dynstr .rel.plt .plt .text .rodata
.ARM.extab .ARM.exidx
04 .preinit_array .init_array .fini_array .ctors .dynamic .got .bss
05 .dynamic
x0152532@unx0152532:~/mydroid$ readelf --segments ./linker
Elf file type is EXEC (Executable file)
Entry point 0xb0001000
There are 5 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x0000d4 0x00000000 0xb0000000 0x00000 0x00000 R 0x1000
LOAD 0x001000 0xb0001000 0xb0001000 0x073bc 0x073bc R E 0x1000
LOAD 0x009000 0xb0009000 0xb0009000 0x0068c 0x0969c RW 0x1000
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0
EXIDX 0x008004 0xb0008004 0xb0008004 0x003b8 0x003b8 R 0x4
Section to Segment mapping:
Segment Sections...
00
01 .text .rodata .ARM.extab .ARM.exidx
02 .preinit_array .init_array .fini_array .ctors .data.rel.ro .got
.data .bss
03
04 .ARM.exidx
http://pastebin.com/B9UJcAjt
<http://pastebin.com/B9UJcAjt>Thanks.
On Tue, May 3, 2011 at 4:17 PM, John Reiser <jr...@bi...> wrote:
> > The formula end = (iph->p_vaddr - interp_addr) + iph->p_memsz; gives us
> 0xb001269c = (0xb0009000 - 0x0) + 0x969c so that's why we have interp_size
> as big as 2.9GB. So I tried to do interp_size = end & 0xFFFFF.. There is no
> more UME 22 Error but I got a Segmentation fault (the program works fine
> > alone).
>
> Please run these two readelf commands and post the results:
> readelf --segments ./hello-arm-bionic # the name of the main
> program
> readelf --segments _interpreter_name_ # /lib/ld-linux*.so.* or
> something similar
>
> --
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
Wan Mohd Fairuz WAN ISMAIL
15 Le Palais des Fleurs,
74 Boulevard Raymond Poincare,
06160 Juan les Pins, FRANCE.
http://www.watt.com.my
+6 017 2071591
|
|
From: John R. <jr...@bi...> - 2011-05-03 15:28:26
|
> x0152532@unx0152532:~/mydroid$ readelf --segments ./linker
>
> Elf file type is EXEC (Executable file)
> Entry point 0xb0001000
> There are 5 program headers, starting at offset 52
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x0000d4 0x00000000 0xb0000000 0x00000 0x00000 R 0x1000
> LOAD 0x001000 0xb0001000 0xb0001000 0x073bc 0x073bc R E 0x1000
> LOAD 0x009000 0xb0009000 0xb0009000 0x0068c 0x0969c RW 0x1000
OK, so there are TWO bugs, one in the construction of ./linker
and one in valgrind's load_ELF(). The Phdr for an empty region (0==.p_memsz):
LOAD 0x0000d4 0x00000000 0xb0000000 0x00000 0x00000 R 0x1000
is a bug in the construction of ./linker because it is a waste of space.
Empty regions occur _EVERYWHERE_, no one needs to be told about them.
And it isn't even aligned properly: .p_align should divide (.p_vaddr - .p_offset).
If you want a one-page "guard" hole with no access allowed, then:
LOAD 0x000000 0xb0000000 0xb0000000 0x00000 0x01000 0x1000
Note that .p_flags is 0 (no PF_X, no PF_R, no PF_W) and .p_align does divide
(.p_vaddr - .p_offset), and that .p_vaddr==.p_paddr because there is no reason
for them to differ.
However, because of the stupidity in ./linker, then load_ELF() must defend itself
by ignoring empty regions:
if (iph->p_type != PT_LOAD
|| iph->p_memsz == 0) /* ignore empty PT_LOAD */
continue;
--
|
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-05-04 07:40:48
|
Hi, I applied your patch and it seems to progress. The end value seems correct now. 0x1169c = (0xb0009000 - 0xb0001000) + 0x969c So, no more 2.9GB allocation which is good. Thanks to you. Then I re-test valgrind on Android and got this error : full output here -> http://pastebin.com/Gcz60MMM link_image[1947]: 6854 could not load needed library '/data/psi_omap_builds_users/x0152532/valgrind/lib/valgrind/vgpreload_core-arm-linux.so' for '/data/hello-arm-bionic' (reloc_library[1311]: 6854 cannot locate '__libc_freeres'... )CANNOT LINK EXECUTABLE I tried with --run-libc-freeres=no and have no luck with it either. This is objdump of vgpreload_core-arm-linux.so (on Android) : http://pastebin.com/X0Ngr8JP So effectively, there is no __libc_freeres in the symbol table. So, to verify things, I did the same objdump on vgpreload_core-x86-linux.so on my dev machine and __libc_freeres is in the symbol table. 0000000000000000 *UND* 0000000000000000 __libc_freeres 0000000000000000 D *UND* 0000000000000000 __libc_freeres Any idea on what are the cause of this missing libc_freeres? Thanks. However, because of the stupidity in ./linker, then load_ELF() must defend > itself > by ignoring empty regions: > > if (iph->p_type != PT_LOAD > || iph->p_memsz == 0) /* ignore empty PT_LOAD */ > continue; > > -- Wan Mohd Fairuz WAN ISMAIL |
|
From: John R. <jr...@bi...> - 2011-05-04 15:30:15
|
> This is objdump of vgpreload_core-arm-linux.so (on Android) : http://pastebin.com/X0Ngr8JP I see: 0000052c g F .text 00000070 _vgnU_freeres which might be related to an intended replacement for __libc_freeres. > So effectively, there is no __libc_freeres in the symbol table. So, to verify things, I did the same objdump on vgpreload_core-x86-linux.so on my dev machine and __libc_freeres is in the symbol table. > > 0000000000000000 *UND*0000000000000000 __libc_freeres > 0000000000000000 D *UND*0000000000000000 __libc_freeres > > Any idea on what are the cause of this missing libc_freeres? When I run "readelf --all /lib/libc.so.6" on x86_64 then I see: 6489: 472f4e50 129 FUNC GLOBAL DEFAULT 13 __libc_freeres so that symbol is in glibc-2.13. What is the output from: $ ldd ./hello-arm-bionic ### print the shared libs needed by the app and what is the status of __libc_freeres with respect to each of the libraries named by ldd? At the time that memcheck fails, which files are mapped? $ cat /proc/<pid>/maps -- |
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-05-05 12:15:55
|
Hi, > What is the output from: > $ ldd ./hello-arm-bionic ### print the shared libs needed by the app > and what is the status of __libc_freeres with respect to each of the > libraries named by ldd? > Surprisingly, ldd says my program is not a dynamic executable but readelf -a hello-arm-bionic shows the need of libc.so shared library. (Full output of readelf here -> http://pastebin.com/b8cnfyrK). FYI, I use agcc from http://plausible.org/andy/agcc to compile hello-arm-bionic. The command line to compile is a long one as we can see here http://pastebin.com/7hwc98Y4. There is no __lib_freeres in Android's libc.so as objdump -tTx libc.so gives nothing. I tried to skip the __libc_freeres call but now then it complains about "cannot locate getpagesize" (output here -> http://pastebin.com/d3TNmSSn). Also, I tried to substitute __libc_freeres with _vgnU_freeres but it gave me the same error on "cannot locate getpagesize". So I look up getpagesize in the .so and it's in there: x0152532@unx0152532:~/remote-x0152532$ objdump -tT valgrind/lib/valgrind/vgpreload_memcheck-arm-linux.so | grep getpagesize 00000000 *UND* 00000000 getpagesize 00000000 D *UND* 00000000 getpagesize p/s: I copy the same valgrind binary and test it on ARM Ubuntu machine and it works like a charm. So this is either the Android's linker or Android's libc, =) > At the time that memcheck fails, which files are mapped? > $ cat /proc/<pid>/maps Sorry but how to do cat /proc/<pid>/maps if the valgrind is already failed? -- Wan Mohd Fairuz WAN ISMAIL |
|
From: John R. <jr...@bi...> - 2011-05-05 15:28:43
|
> What is the output from:
> $ ldd ./hello-arm-bionic ### print the shared libs needed by the app
> and what is the status of __libc_freeres with respect to each of the
> libraries named by ldd?
>
>
> Surprisingly, ldd says my program is not a dynamic executable
See /usr/bin/ldd, which is a shell script. It means that ldd has not been
integrated into your environment (what is ldd.RTLDLIST ?) or that the PT_INTERP
/system/bin/linker does not observe all the conventions regarding:
${rtld} --verify "$file"
This means that ldd does not work. [What facility does your environment provide
for listing the actual {libname ==> file} resolution and the transitive closure
of DT_NEEDED shared libraries for an app?]
> but readelf -a hello-arm-bionic shows the need of libc.so shared library. (Full output of readelf here -> http://pastebin.com/b8cnfyrK). FYI, I use agcc from http://plausible.org/andy/agcc to compile hello-arm-bionic. The command line to
> compile is a long one as we can see here http://pastebin.com/7hwc98Y4.
>
> There is no __lib_freeres in Android's libc.so as objdump -tTx libc.so gives nothing.
>
> I tried to skip the __libc_freeres call but now then it complains about "cannot locate getpagesize" (output here -> http://pastebin.com/d3TNmSSn). Also, I tried to substitute __libc_freeres with _vgnU_freeres but it gave me the same error on "cannot locate getpagesize". So I look up getpagesize in
> the .so and it's in there:
>
> x0152532@unx0152532:~/remote-x0152532$ objdump -tT valgrind/lib/valgrind/vgpreload_memcheck-arm-linux.so | grep getpagesize
> 00000000 *UND*00000000 getpagesize
> 00000000 D *UND*00000000 getpagesize
>
> p/s: I copy the same valgrind binary and test it on ARM Ubuntu machine and it works like a charm. So this is either the Android's linker or Android's libc, =)
Yes, the environment is different enough to cause problems. All of the
GLOBAL *UND* [undefined] symbols from vgpreload_memcheck-arm-linux.so
must be resolvable.
For the specific case of getpagesize, in the valgrind source I see:
./config.h.in~:/* Define to 1 if you have the `getpagesize' function. */
So there is a disagreement about the configuration: the build environment
has decided that the runtime environment _will_ have it, but the run-time
environment does not supply it. So either add getpagesize to the run-time
environment, or convince the build environment that getpagesize is not present.
Similarly for the other GLOBAL *UND* symbols in vgpreload_memcheck-arm-linux.so.
[Haven't other Android developers run into these problems before?]
> At the time that memcheck fails, which files are mapped?
> $ cat /proc/<pid>/maps
>
>
> Sorry but how to do cat /proc/<pid>/maps if the valgrind is already failed?
Run valgrind under gdb and plant some breakpoints (or convince valgrind to invoke
gdb upon detecting such an error; perhaps "--db-attach=yes" is enough), then use
another terminal. Or, in gdb:
(gdb) info proc ### note the PID
(gdb) shell cat /proc/<pid>/maps
--
|
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-05-06 14:24:53
|
Hi, Change of information: After recompiling valgrind, now I _do_ have __libc_freeres symbol in vgpreload_core-arm-linux.s (http://pastebin.com/LijCA8Km) but I still got cannot "locate __libc_freeres" error. integrated into your environment (what is ldd.RTLDLIST ?) or that the > PT_INTERP > /system/bin/linker does not observe all the conventions regarding: > ${rtld} --verify "$file" > This means that ldd does not work. [What facility does your environment > provide > for listing the actual {libname ==> file} resolution and the transitive > closure > of DT_NEEDED shared libraries for an app?] > You are right, in the ldd.RTLDLIST there are only RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2" so I suppose it's normal that ldd did not work for android's linker. However I do have readelf -d that works as I posted in earlier message that will also list down the shared library. > Yes, the environment is different enough to cause problems. All of the > GLOBAL *UND* [undefined] symbols from vgpreload_memcheck-arm-linux.so > must be resolvable. > As posted above http://pastebin.com/LijCA8Km shows that there are some symbols that are undefined. I see that in x86, these symbols are also undefined. I don't really know what happens in the background if a symbol is undefined but there is no problem running valgrind on x86 with these undefined symbol. -- Wan Mohd Fairuz WAN ISMAIL |
|
From: John R. <jr...@bi...> - 2011-05-06 15:32:42
|
> As posted above http://pastebin.com/LijCA8Km shows that there are some symbols that are undefined. I see that in x86, these symbols are also undefined. I don't really know what happens in the background if a symbol is undefined but there is no problem running valgrind on x86 with these undefined symbol. You must find out where is [and why is] 'getpagesize' in your environment. For instance, on amd64 it is undefined in vgpreload_memcheck-amd64-linux.so: 000000208a28 000200000007 R_X86_64_JUMP_SLO 0000000000000000 getpagesize + 0 2: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND getpagesize 79: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND getpagesize but defined in /lib64/libc.so.6: 873: 0000003d25ed8e80 23 FUNC WEAK DEFAULT 12 getpagesize@@GLIBC_2.2.5 1796: 0000003d25ed8e80 23 FUNC GLOBAL DEFAULT 12 __getpagesize@@GLIBC_2.2.5 1977: 0000000000000000 0 FILE LOCAL DEFAULT ABS getpagesize.c 5027: 0000003d25ed8e80 23 FUNC LOCAL DEFAULT 12 __GI___getpagesize 6204: 0000003d25ed8e80 23 FUNC WEAK DEFAULT 12 getpagesize 6768: 0000003d25ed8e80 23 FUNC GLOBAL DEFAULT 12 __getpagesize On amd64, then either memcheck actually does not call getpagesize(), or libc supplies a definition. Apparently in your environment memcheck does call getpagesize, but you get a complaint that memcheck cannot see any definition for it. Therefore, add the obvious definition to vgpreload_core-arm-linux.so and vgpreload_memcheck-arm-linux.so. Specifically, insert: int getpagesize() { return 4096; } into appropriate source file(s), then re-make valgrind until there is no more "UND getpagesize". Alternatively, figure out what valgrind/config.h.in is doing with HAVE_GETPAGESIZE, then change so that it reflects reality for your _runtime_ environment. Again, re-make valgrind until there is no more "UND getpagesize". -- |
|
From: Tom H. <to...@co...> - 2011-05-03 15:03:46
|
On 03/05/11 14:07, Wan Mohd Fairuz Wan Ismail wrote: > The situation: > The function load_ELF (elf.c) will try to load the executable and the > interpreter to the memory. For android's /system/bin/linker, the > calculated interp_size value is 2952865436. > > The formula end = (iph->p_vaddr - interp_addr) + iph->p_memsz; gives > us 0xb001269c = (0xb0009000 - 0x0) + 0x969c so that's why we have > interp_size as big as 2.9GB. So I tried to do interp_size = end & > 0xFFFFF.. There is no more UME 22 Error but I got a Segmentation fault > (the program works fine alone). Basically valgrind is trying to cheat, and instead of mapping each LOAD segment in the ELF file separately it is trying to map one block of contiguous memory and then load each segment at the correct offset in that block. Unfortunately it seems that the Android interpreter is linked in such a way that the load segments are a long way apart, so it winds up trying to allocate a very large block of memory, most of which won't be used. If you can run readelf then try "readelf -l /system/bin/linker" and let us see the output - you may have to copy the linker off onto a conventional system and run readelf there. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-05-03 15:05:16
|
Hi, x0152532@unx0152532:~/mydroid$ readelf -l ./linker Elf file type is EXEC (Executable file) Entry point 0xb0001000 There are 5 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x0000d4 0x00000000 0xb0000000 0x00000 0x00000 R 0x1000 LOAD 0x001000 0xb0001000 0xb0001000 0x073bc 0x073bc R E 0x1000 LOAD 0x009000 0xb0009000 0xb0009000 0x0068c 0x0969c RW 0x1000 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0 EXIDX 0x008004 0xb0008004 0xb0008004 0x003b8 0x003b8 R 0x4 Section to Segment mapping: Segment Sections... 00 01 .text .rodata .ARM.extab .ARM.exidx 02 .preinit_array .init_array .fini_array .ctors .data.rel.ro .got .data .bss 03 04 .ARM.exidx Here you are. Thanks. On Tue, May 3, 2011 at 3:22 PM, Tom Hughes <to...@co...> wrote: > On 03/05/11 14:07, Wan Mohd Fairuz Wan Ismail wrote: > > > The situation: > > The function load_ELF (elf.c) will try to load the executable and the > > interpreter to the memory. For android's /system/bin/linker, the > > calculated interp_size value is 2952865436. > > > > The formula end = (iph->p_vaddr - interp_addr) + iph->p_memsz; gives > > us 0xb001269c = (0xb0009000 - 0x0) + 0x969c so that's why we have > > interp_size as big as 2.9GB. So I tried to do interp_size = end & > > 0xFFFFF.. There is no more UME 22 Error but I got a Segmentation fault > > (the program works fine alone). > > Basically valgrind is trying to cheat, and instead of mapping each LOAD > segment in the ELF file separately it is trying to map one block of > contiguous memory and then load each segment at the correct offset in > that block. > > Unfortunately it seems that the Android interpreter is linked in such a > way that the load segments are a long way apart, so it winds up trying > to allocate a very large block of memory, most of which won't be used. > > If you can run readelf then try "readelf -l /system/bin/linker" and let > us see the output - you may have to copy the linker off onto a > conventional system and run readelf there. > > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ > -- Wan Mohd Fairuz WAN ISMAIL OMAP System Multimedia Integration Team (Trainee) Texas Instrument France f-w...@ti... +33 (0)4 93 22 20 16 +33 (0)6 43 46 13 39 15 Le Palais des Fleurs, 74 Boulevard Raymond Poincare, 06160 Juan les Pins, FRANCE. http://www.watt.com.my +6 017 2071591 |