Closed GoogleCodeExporter closed 9 years ago
Oops, you're right. This should be easy to fix for the next release.
In the meantime, if you want to patch this up so you can continue to test, put
#ifdef HAVE_SBRK
at the beginning of SbrkSysAllocator::Alloc in system-alloc.cc, and
#endif
at the end of SbrkSysAllocator::Alloc.
That said, sbrk is posix standard, and I'm surprised OpenVOS wouldn't have it.
Try
grep -rw sbrk /usr/include
to see if it shows up anywhere. Is it not in /usr/include/unistd.h?
Original comment by csilv...@gmail.com
on 12 Jun 2009 at 3:21
Oh, never mind, I'm mistaken: it looks like sbrk is intentionally not part of
the
posix standard. So that explains why OpenVOS doesn't have it. In any case,
the next
release should have this fixed up.
Original comment by csilv...@gmail.com
on 12 Jun 2009 at 3:22
After implementing the suggestion I am facing the following warning:
if /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I./src -
I./src -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare
-
fno-exceptions -D_POSIX_C_SOURCE=200112L -D_BSD_SOURCE -D_SYSV -
D_VOS_EXTENDED_NAMES -MT libtcmalloc_internal_la-system-alloc.lo -MD -MP -
MF ".deps/libtcmalloc_internal_la-system-alloc.Tpo" -c -o
libtcmalloc_internal_la-
system-alloc.lo `test -f 'src/system-alloc.cc' || echo
'./'`src/system-alloc.cc; \
then mv -f ".deps/libtcmalloc_internal_la-system-
alloc.Tpo" ".deps/libtcmalloc_internal_la-system-alloc.Plo"; else rm -
f ".deps/libtcmalloc_internal_la-system-alloc.Tpo"; exit 1; fi
g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -DNDEBUG -Wall -Wwrite-strings -
Woverloaded-virtual -Wno-sign-compare -fno-exceptions -D_POSIX_C_SOURCE=200112L
-
D_BSD_SOURCE -D_SYSV -D_VOS_EXTENDED_NAMES -MT libtcmalloc_internal_la-system-
alloc.lo -MD -MP -MF .deps/libtcmalloc_internal_la-system-alloc.Tpo -c
src/system-
alloc.cc -o libtcmalloc_internal_la-system-alloc.o
src/system-alloc.cc: In member function `virtual void* SbrkSysAllocator::Alloc
(size_t, size_t*, size_t)':
src/system-alloc.cc:221:POST
http://code.google.com/p/google-perftools/issues/update.do HTTP/1.1 warning:
control reaches end of non-void function
Original comment by bornlibr...@gmail.com
on 15 Jun 2009 at 5:32
Sorry, my suggestion wasn't quite right. Try this instead:
---
--- /tmp/g4-500/cache/depot/opensource/google-perftools/src/system-alloc.cc#32
2009-06-11 23:30:32.000000000 -0400
+++ /tmp/g4-500/cache/depot/opensource/google-perftools/src/system-alloc.cc#33
2009-06-15 15:37:40.000000000 -0400
@@ -150,6 +150,10 @@
void* SbrkSysAllocator::Alloc(size_t size, size_t *actual_size,
size_t alignment) {
+#ifndef HAVE_SBRK
+ failed_ = true;
+ return NULL;
+#else
// Check if we should use sbrk allocation.
// FLAGS_malloc_skip_sbrk starts out as false (its uninitialized
// state) and eventually gets initialized to the specified value. Note
@@ -216,6 +220,7 @@
ptr += alignment - (ptr & (alignment-1));
}
return reinterpret_cast<void*>(ptr);
+#endif // HAVE_SBRK
}
void SbrkSysAllocator::DumpStats(TCMalloc_Printer* printer) {
---
Original comment by csilv...@gmail.com
on 15 Jun 2009 at 8:00
Thank you. This patch took care of the error. However I am concerned that
without
sbrk & mmap how will the program behave.
Original comment by bornlibr...@gmail.com
on 16 Jun 2009 at 10:22
This should be fixed in perftools 1.4, just released.
Original comment by csilv...@gmail.com
on 11 Sep 2009 at 6:48
Original issue reported on code.google.com by
bornlibr...@gmail.com
on 11 Jun 2009 at 9:44Attachments: