search

casseopea2 / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

Problem With munmap() #145

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. ./configure
2. gmake
3.

What is the expected output? What do you see instead?
checking for working mmap... no. The src/config.h has
/* Define to 1 if you have a working `mmap' system call. */
/* #undef HAVE_MMAP */
This implies either mmap.h is not available or the call has failed. In 
wither case munmap() shouldnt be included in the code. There is a check 
for HAVE_MMAP but absence of which doesnt include the header mman.h before 
this function is used in low_level_alloc.cc as explained below.
The header is available on my system but it is not working as is claimed 
by the configure script so mman.h is not included at line on line 49 using
#ifdef HAVE_MMAP
#include <sys/mman.h>
#endif.
Now if mman.h is not included how can the program call munmap() at line 
285?
What version of the product are you using? On what operating system?
1.3 OpenVOS 17.0.1al

Please provide any additional information below.

Original issue reported on code.google.com by bornlibr...@gmail.com on 13 Jun 2009 at 3:16

Attachments:

GoogleCodeExporter commented 9 years ago 
The mmap call actually failed in the configure script because the check of 
return 
address of mmap call failed. The testmmap is a copy of the configure test 
program 
edited for brevity while checking the return of mmap call.
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-stratus-vos"...
(gdb) break 181
Breakpoint 1 at 0x2d32: file testmmap.c, line 181.
(gdb) r
Starting program: /%Vighnesh#m6_d06/users>awarikoo>testmmap.pm

Breakpoint 1, main ()
    at testmmap.c:181
181    if (data2 != data2_mmap)
(gdb) p data2
$1 = 0x40012000 ""
(gdb) p data2_mmap
$2 = (
    void *) 0xffffffff
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) q

Original comment by bornlibr...@gmail.com on 13 Jun 2009 at 4:10

GoogleCodeExporter commented 9 years ago 
You are definitely right that perftools currently needs a working mmap to run.  
I
have HAVE_MMAP checks scattered about, to try to isolate as much of that out as
possible, but there's still a requirement in low_level_alloc.cc.  (I'm also 
probably
not as good as I could be in using HAVE_MMAP in the unittests.)

It's possible one could rewrite the low_level_alloc.cc code to use sbrk if 
necessary,
but it's tricky.  I'm not sure an extent-based allocator like sbrk is a good 
fit for
what low_level_alloc does.  If you want to give it a go, and submit a patch, 
I'd be
happy to take a look!

But I think you what you really need to do is figure out why the configure test 
is
failing.  I recall sbrk doesn't work on your system either.  If neither sbrk 
nor mmap
works on your OS, you're going to have trouble running this library!  Or any 
program,
for that matter, since those are the only ways to get memory from the system 
(your
malloc implementation has to be using one or the other of these).  So I have to
assume mmap works, at least in some use cases, and it's just the configure test
that's failing to notice this or something.  An alternative is that while sbrk 
isn't
supported, brk or something is.  If so, and you can figure out how your OS gets
memory from the kernel, maybe you can add another system allocator or something 
to
handle it.

As for the configure script, the failure you point out is a real failure: 
0xffffffff
is MAP_FAILED.  But I'm looking in the perftools configure file and I don't see 
any
reference to data2_mmap.  Perhaps you added this in your rewrite of the 
configure
script.  To go any further, you'll need to attach a copy of testmmap.c.

Original comment by csilv...@gmail.com on 14 Jun 2009 at 4:52

GoogleCodeExporter commented 9 years ago 
Hello Owner
I am attaching the build log & the tespmmap.c & pointertest.c

Original comment by bornlibr...@gmail.com on 16 Jun 2009 at 10:20

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm sorry, it looks like I never got back to this.  I just saw it now!

I think this is an issue with OpenVOS -- perhaps it doesn't support mmap with a
non-NULL first argument?

One thing you can do is just change config.h to #define HAVE_MMAP, after running
configure.  If you do that, can you successfully build perftools?

Original comment by csilv...@gmail.com on 11 Sep 2009 at 6:54

GoogleCodeExporter commented 9 years ago 
Any more word on this?

Original comment by csilv...@gmail.com on 14 Oct 2009 at 11:30

GoogleCodeExporter commented 9 years ago 
It's been about a year now, so I'm closing the bug WillNotFix.  Feel free to 
reopen if you would like to restart debugging this.

Original comment by csilv...@gmail.com on 7 Jun 2010 at 10:43