mzhaom / gperftools

Fast, multi-threaded malloc() and nifty performance analysis tools
https://code.google.com/p/gperftools/
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Error In sbrk() Function Usage #142

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?
As the configure shows checking for sbrk... no & the config.h file has not 
defined HAVE_SBRK this function should not be compiled. However I get 
if /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -
I./src  -I./src   -DNO_TCMALLOC_SAMPLES  -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_minimal_internal_la-system-alloc.lo -MD -MP -
MF ".deps/libtcmalloc_minimal_internal_la-system-alloc.Tpo" -c -o 
libtcmalloc_minimal_internal_la-system-alloc.lo `test -f 'src/system-
alloc.cc' || echo './'`src/system-alloc.cc; \
then mv -f ".deps/libtcmalloc_minimal_internal_la-system-
alloc.Tpo" ".deps/libtcmalloc_minimal_internal_la-system-alloc.Plo"; else 
rm -f ".deps/libtcmalloc_minimal_internal_la-system-alloc.Tpo"; exit 1; fi
 g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -DNO_TCMALLOC_SAMPLES -
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_minimal_internal_la-system-alloc.lo -
MD -MP -MF .deps/libtcmalloc_minimal_internal_la-system-alloc.Tpo -c 
src/system-alloc.cc -o libtcmalloc_minimal_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:184: error: `sbrk' was not declared in this scope
src/system-alloc.cc:184: warning: unused variable 'sbrk'
src/system-alloc.cc:189: error: `sbrk' was not declared in this scope

What version of the product are you using? On what operating system?
Version 1.3 On Stratus OpenVOS 17.0.1al. However this doesnt seem to be a 
problem of the operating system as the function is being executed even 
when the function is not defined.

Please provide any additional information below.

Original issue reported on code.google.com by bornlibr...@gmail.com on 11 Jun 2009 at 9:44

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
This should be fixed in perftools 1.4, just released.

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