Menu
▾
▴
Re: [Valgrind-users] UME Error 22
|
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 |
