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 <
[email protected]> 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 <[email protected]> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>
>
>
> --
> Wan Mohd Fairuz WAN ISMAIL
> OMAP System Multimedia Integration Team (Trainee)
> Texas Instrument France
> [email protected]
> +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
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to