mmap failing with EINVAL inside valgrind
in [Unix Programming]
|
From: guidoreina on 18 Sep 2009 03:31 On Sep 16, 10:10 am, guidoreina <guidore...(a)gmail.com> wrote: > On Sep 15, 3:20 pm, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > > > > > guidoreina <guidore...(a)gmail.com> writes: > > > On Sep 15, 2:09 pm, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > > >> guidoreina <guidore...(a)gmail.com> writes: > > >> > I tried with the google performance tools library, which I have read > > >> > they can also be used to detect memory leaks, but I get a SIGBUS when > > >> > POST++ is doing its stuff, it seems I will have to find the memory > > >> > leaks the hard way... > > > >> Assuming that you really saw a MAP_FIXED, eg, in strace-output, this > > >> call has been done by valgrind which always uses MAP_FIXED on this > > >> codepath, > > > [...] > > > > Yes, the POST++ code has MAP_FIXED. > > > The POST++-code does not have MAP_FIXED. Neither the file you linked to > > nor the original package. It uses a so-called hinted mapping, meaning, > > it requests that its database is mapped at the specificed address if > > possible and elswhere if not. > > I have just added some printfs to valgrind. Here is what I have seen: > > 1. In generic_PRE_sys_mmap: > arg4 & VKI_MAP_FIXED = true, then: mreq.rkind = MFixed > Later it calls: am_get_advisory > > 2. In am_get_advisory: > reqStart = 0x62500000, reqLen = 200003584 > > In: /* ------ Implement Policy Exception #1 ------ */ > iLo = 174, iHi = 202 > It fails in the first iteration of: for (i = iLo; i <= iHi; i++) { > nsegments[i].kind = SkAnonV /* anonymous mapping belonging to valgrind > */ > > So, as you pointed out, it seems this memory area is used by valgrind Aaaaalmost :(. I have changed valgrind's function: am_get_advisory to print which segments were being used. I have chosen another segment not used by valgrind (SkFree), at offset 0x67500000, I have removed the POST++ file, I have changed the base address and have recreated the POST++ file again with the new base address. valgrind managed to mmap the file... I got so happy... for a few seconds, then the program received SIGABRT when loading the objects from the POST++ file. Thank you very much for your help! Without your help I wouldn't have understood why I was getting EINVAL and wouldn't have managed to avoid it. On Wednesday I tried Purify in Solaris (my colleague told me we had Purify for Solaris), but I also got a SIGABRT with the POST++ stuff.
From: guidoreina on 21 Sep 2009 02:16
On Sep 18, 9:31 am, guidoreina <guidore...(a)gmail.com> wrote: > On Sep 16, 10:10 am, guidoreina <guidore...(a)gmail.com> wrote: > > > > > On Sep 15, 3:20 pm, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > > > > guidoreina <guidore...(a)gmail.com> writes: > > > > On Sep 15, 2:09 pm, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > > > >> guidoreina <guidore...(a)gmail.com> writes: > > > >> > I tried with the google performance tools library, which I have read > > > >> > they can also be used to detect memory leaks, but I get a SIGBUS when > > > >> > POST++ is doing its stuff, it seems I will have to find the memory > > > >> > leaks the hard way... > > > > >> Assuming that you really saw a MAP_FIXED, eg, in strace-output, this > > > >> call has been done by valgrind which always uses MAP_FIXED on this > > > >> codepath, > > > > [...] > > > > > Yes, the POST++ code has MAP_FIXED. > > > > The POST++-code does not have MAP_FIXED. Neither the file you linked to > > > nor the original package. It uses a so-called hinted mapping, meaning, > > > it requests that its database is mapped at the specificed address if > > > possible and elswhere if not. > > > I have just added some printfs to valgrind. Here is what I have seen: > > > 1. In generic_PRE_sys_mmap: > > arg4 & VKI_MAP_FIXED = true, then: mreq.rkind = MFixed > > Later it calls: am_get_advisory > > > 2. In am_get_advisory: > > reqStart = 0x62500000, reqLen = 200003584 > > > In: /* ------ Implement Policy Exception #1 ------ */ > > iLo = 174, iHi = 202 > > It fails in the first iteration of: for (i = iLo; i <= iHi; i++) { > > nsegments[i].kind = SkAnonV /* anonymous mapping belonging to valgrind > > */ > > > So, as you pointed out, it seems this memory area is used by valgrind > > Aaaaalmost :(. I have changed valgrind's function: am_get_advisory to > print which segments were being used. I have chosen another segment > not used by valgrind (SkFree), at offset 0x67500000, I have removed > the POST++ file, I have changed the base address and have recreated > the POST++ file again with the new base address. valgrind managed tommapthe file... I got so happy... for a few seconds, then the program > received SIGABRT when loading the objects from the POST++ file. > > Thank you very much for your help! Without your help I wouldn't have > understood why I was getting EINVAL and wouldn't have managed to avoid > it. On Wednesday I tried Purify in Solaris (my colleague told me we > had Purify for Solaris), but I also got a SIGABRT with the POST++ > stuff. Hi, I found the memory leak. I took gdb and started to go step by step until I found the big memory leak. Now I have been testing the program and it seems it doesn't leak anymore :) |