mmap failing with EINVAL inside valgrind
in [Unix Programming]
|
From: guidoreina on 15 Sep 2009 02:11 Hi, 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... Thank you for all your help, Guido
From: Rainer Weikusat on 15 Sep 2009 08:09 guidoreina <guidoreina(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, no matter if the application originally specified it. For a so-called 'hinted mapping', valgrind tries either the given address if the area in question isn't used by valgrind itself or an area valgrind considers to be free if not. It returns EINVAL if no suitable area could be found. Otherwise, it calls into the kernel with the start address returned by its search. Should the kernel deny the mapping, valgrind again searches for a suitable free area, this time ignoring the address given in the application call, and tries to mmap that if such an area is found (using MAP_FIXED). Should the kernel deny the second mapping, too, EINVAL is returned. This means that either an area large enough to be used for the POST++-mapping wasn't available according to the memory map managed by valgrind or 'something strange' (and probably, unintended) is going on within valgrind itself. It should be possible to research this further by inserting suitable diagnotisc output statements into the two involved valgrind-routines, generic_PRE_sys_mmap in coregrind/m_syswrap/syswrap_generic.c and am_get_advisory in coregrind/m_aspacemgr/aspacemgr-linux.c
From: guidoreina on 15 Sep 2009 08:48 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, no matter if the application originally specified it. For a > so-called 'hinted mapping', valgrind tries either the given address if > the area in question isn't used by valgrind itself or an area valgrind > considers to be free if not. It returns EINVAL if no suitable area > could be found. Otherwise, it calls into the kernel with the start > address returned by its search. Should the kernel deny the mapping, > valgrind again searches for a suitable free area, this time ignoring > the address given in the application call, and tries tommapthat if > such an area is found (using MAP_FIXED). Should the kernel deny the > second mapping, too, EINVAL is returned. > > This means that either an area large enough to be used for the > POST++-mapping wasn't available according to the memory map managed by > valgrind or 'something strange' (and probably, unintended) is going on > within valgrind itself. It should be possible to research this further > by inserting suitable diagnotisc output statements into the two > involved valgrind-routines, generic_PRE_sys_mmap in > coregrind/m_syswrap/syswrap_generic.c and am_get_advisory in > coregrind/m_aspacemgr/aspacemgr-linux.c Hi Rainer, Yes, the POST++ code has MAP_FIXED. I can modify valgrinds source code and put some printf's to find out what it doesn't like about the memory address. I will post my findings here :). Thank you.
From: Rainer Weikusat on 15 Sep 2009 09:20 guidoreina <guidoreina(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.
From: guidoreina on 16 Sep 2009 04:10
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 |