On May 22, 11:46*am, S S <sarvesh.si...@gmail.comwrote:
Hi
I have my shared (.so) library which uses our own memory manager. 32
bit lib was working fine, but when we switched to 64 bit library, as
our own defined small pointer can not handle big addresses. I am
facing trouble as our memory manager do not handle big memory requests
but passes it on to system malloc() and malloc returns out of range
addresses which our small pointer can not accommodate. Whole of the
design is based on that small pointer and hence I can not avoid it.
Out of range addresses are returned due to the fact that malloc
internally uses mmap() call. I tried to disable it using mallopt() but
it is not getting disabled. I am using correct syntax, but I assume
there are some tricks to use it when using with shared library. So,
how to disable mmap() OR ask malloc to return addresses within range
in case of shared library ?
I would highly appreciate any suggestions.
I suggest you fix the program to use sufficiently large pointers,
anything else is a hack which will eventually come back to bite you.
All the rest of this is quite outside the scope of standard C++.
Even if you prevented malloc() from calling mmap(), there's nothing at
all preventing malloc() from returning a 64 bit pointer once it runs
out of heap space below 2G or 4G (depending on where your system puts
that line).
That being said, many systems allow a program to be compiled with
options that the entire program uses only 32 bit pointers, but it
sounds like your problem is that the base program is using full sized
pointers, but your shred library is not.
Many system will have some way to allocate memory specifically below
the 4G line, but it'll not be what malloc() calls by default, so you'd
have to write your own allocator. For example, on some *nix, you can
specify MAP_ADDR32 as a flag to mmap(). But you should ask for more
information in a newsgroups dedicated to your system.
