|
List Info
Thread: bjam memory usage
|
|
| bjam memory usage |
  Germany |
2007-09-14 03:41:29 |
Currently, running the boost regression tests makes bjam use
an impressive
amount of 1273MB (!!!) of memory on my system.
I know there have been discussions of this excessive memory
usage in the
past. Among other things, using some special memory
management library was
discussed, is this still being pursued?
Markus
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
a>
|
|
| Re: bjam memory usage |

|
2007-09-14 03:55:17 |
Markus Schöpflin wrote:
> Currently, running the boost regression tests makes
bjam use an impressive
> amount of 1273MB (!!!) of memory on my system.
What are the exact command line options to bjam. Trunk or
RC? Does
this seem like a new problem?
- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
a>
|
|
| Re: bjam memory usage |
  Germany |
2007-09-14 04:19:44 |
Vladimir Prus wrote:
> Markus Schöpflin wrote:
>
>> Currently, running the boost regression tests makes
bjam use an impressive
>> amount of 1273MB (!!!) of memory on my system.
>
> What are the exact command line options to bjam.
/vol2/boost/boost/tools/jam/src/bin.osf/bjam --v2
-sBOOST_BUILD_PATH=/vol2/boost
-sBOOST_ROOT=/vol2/boost/boost
hp_cxx-71_006_tru64 hp_cxx-65_042_tru64 -d2 --dump-tests
-sBZIP2_INCLUDE=/usr/local/include
-sBZIP2_LIBPATH=/usr/local/lib
-sZLIB_INCLUDE=/usr/local/include
-sZLIB_LIBPATH=/usr/local/zlib
--build-dir=/vol2/boost/results
>Trunk or RC? Does
Trunk. Is there a current RC branch at the moment?
> this seem like a new problem?
No, bjam has always used insane amounts of memory when
running the
regression tests, it's just more exaggerated because of the
increased
amount of tests since 1.34.
Markus
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
a>
|
|
| Re: bjam memory usage |

|
2007-09-17 09:42:14 |
Rene Rivera wrote:
> Dave mentioned he might look at why it crashes when
using boehmgc. But
> as we all know he's a busy person If any
one else is brave enough,
> they can try it out with the svn bjam version (3.1.15),
just by adding
> --gc when building bjam.
>
> NOTE; Using boehmgc does help, when I run with it, it
does use less
> memory. It just crashes at some point :-(
I have built a version of bjam linked against boehm gc 7.0.
When this
version is run, it get tons of complaints from the gc:
GC_debug_register_finalizer called with non-base-pointer
0x8168fe0
GC_debug_register_finalizer called with non-base-pointer
0x8161f78
GC_debug_register_finalizer called with non-base-pointer
0x8161f78
...
Maybe this rings a bell with someone on what might be
wrong?
Markus
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
a>
|
|
| Re: bjam memory usage |
  Germany |
2007-09-17 09:42:14 |
Rene Rivera wrote:
> Dave mentioned he might look at why it crashes when
using boehmgc. But
> as we all know he's a busy person If any
one else is brave enough,
> they can try it out with the svn bjam version (3.1.15),
just by adding
> --gc when building bjam.
>
> NOTE; Using boehmgc does help, when I run with it, it
does use less
> memory. It just crashes at some point :-(
I have built a version of bjam linked against boehm gc 7.0.
When this
version is run, it get tons of complaints from the gc:
GC_debug_register_finalizer called with non-base-pointer
0x8168fe0
GC_debug_register_finalizer called with non-base-pointer
0x8161f78
GC_debug_register_finalizer called with non-base-pointer
0x8161f78
...
Maybe this rings a bell with someone on what might be
wrong?
Markus
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
a>
|
|
| bjam Build question |
  Canada |
2007-09-17 14:31:44 |
Hello,
I am trying to rebuild Bayes++ using bjam (on my intel based
mac
running OS X 10.4.8), however I get the error below. Is
bjam failing
to find gcc? Can you provide any other advice?
By "rebuild", I mean that I have built Bayes++
before on the same
machine, and am now having isolated problems instantiating a
formerly
functional class in Bayes++, and thought somehow my compiled
library
may have gotten corrupted.
Thank you,
Yon
[Mon Sep 17|yon|/Developer/YV-dev/Bayes++] bjam --v2
-sBOOST_ROOT="../
boost_1_33_1"
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/feature.
jam:431:
in feature.validate-value-string from module feature
error: "gcc" is not a known value of feature
<toolset>
error: legal values:
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/property
.jam:250:
in validate1 from module property
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/property
.jam:273:
in property.validate from module property
/Developer/YV-dev/boost_1_33_1/tools/build/v2/tools/builtin.
jam:176:
in variant from module builtin
project-root.jam:7: in modules.load from module
Jamfile</Developer/YV-
dev/Bayes++>
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/project.
jam:306:
in load-jamfile from module project
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/project.
jam:68:
in load from module project
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/project.
jam:164:
in project.find from module project
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build-system.j
am:136:
in load from module build-system
../boost_1_33_1/tools/build/v2/kernel/modules.jam:259: in
import from
module modules
../boost_1_33_1/tools/build/v2/kernel/bootstrap.jam:153: in
boost-
build from module
../boost_1_33_1/boost-build.jam:12: in module scope from
module
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
a>
|
|
| Re: bjam memory usage |
  United States |
2007-09-26 09:10:13 |
Vladimir Prus wrote:
> Markus Schöpflin wrote:
>
>> Currently, running the boost regression tests makes
bjam use an impressive
>> amount of 1273MB (!!!) of memory on my system.
>
> What are the exact command line options to bjam. Trunk
or RC? Does
> this seem like a new problem?
Hardly new. I reported several times that bjam took ~1GB for
1.34.x
runs. bjam has been like that for years.
Regards,
m
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
a>
|
|
| Re: bjam memory usage |
  United States |
2007-10-03 11:53:13 |
on Mon Sep 17 2007, Markus Schöpflin
<markus.schoepflin-AT-comsoft.de> wrote:
> Rene Rivera wrote:
>
>> Dave mentioned he might look at why it crashes when
using boehmgc. But
>> as we all know he's a busy person If any
one else is brave enough,
>> they can try it out with the svn bjam version
(3.1.15), just by adding
>> --gc when building bjam.
>>
>> NOTE; Using boehmgc does help, when I run with it,
it does use less
>> memory. It just crashes at some point :-(
>
> I have built a version of bjam linked against boehm gc
7.0. When this
> version is run, it get tons of complaints from the gc:
>
> GC_debug_register_finalizer called with
non-base-pointer 0x8168fe0
> GC_debug_register_finalizer called with
non-base-pointer 0x8161f78
> GC_debug_register_finalizer called with
non-base-pointer 0x8161f78
> ...
>
> Maybe this rings a bell with someone on what might be
wrong?
Hans Boehm has this to say about it:
The message means the GC_debug_register_finalizer was
passed an
address that at was at the wrong offset from a GC
allocated object.
It should normally be at a fixed nonzero offset, since it
should be
passed an object allocated by GC_debug_malloc, which adds
a header
with debug information.
The call stack at the call to GC_err_printf might well be
interesting.
Typically, you would be calling GC_MALLOC and
GC_REGISTER_FINALIZER
with GC_DEBUG defined to get here. An inconsistent
GC_DEBUG setting
for different compilation units might do this. IObj and
base in
GC_debug_register_finalizer would probably have to have
the same
value for this to be the case.
This error by itself is probably not
fatal. GC_debug_register_finalizer computes the right
object address
anyway. The real problem may be elsewhere.
Still, it seems worth investigating.
--
Dave Abrahams
Boost Consulting
http://www.boost-cons
ulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
a>
|
|
[1-8]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|