Re: [Boost-build] bjam memory consumption

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2006-04-11 10:19:51

Vladimir Prus wrote:
> On Friday 07 April 2006 09:58, Stefan Slapeta wrote:
> 
>> during my test runs for intel 9 and cw, bjam comsumes something between
>> 400 and 500 mb of virtual memory (win32 system). I really can't imagine
>> what this memory could be used for, but are there any ways to reduce
>> this hunger?
> 
> This would require help from you. Go to the "status" directory and run:
> 
>    bjam -n -a --v2 intel-win-9.0 cw-9.0 -d+10 > profile
> 
> Then, send me the 'profile' file and I'll see if there's something 
> particularly wrong there.

Do you know if bjam has been valgrinded to check for memory leaks? I tried 
it on some simple projects and valgrind showed a number of leaks, but I 
could not immediately spot how the leaks are created...

Here are the most prominent leaks reported, maybe they are of use to someone...

==8063== 218,804 bytes in 3,197 blocks are definitely lost in loss record 
13 of 21
==8063==    at 0x401A649: malloc (vg_replace_malloc.c:149)
==8063==    by 0x8058A7B: string_reserve_internal (strings.c:58)
==8063==    by 0x8058BCB: extend_full (strings.c:91)
==8063==    by 0x8058CA0: string_append (strings.c:113)
==8063==    by 0x805B3CF: builtin_normalize_path (builtins.c:1309)
==8063==    by 0x8053E80: parse_evaluate (parse.c:139)
==8063==    by 0x804AAB0: evaluate_rule (compile.c:1036)
==8063==    by 0x804A0D4: compile_rule (compile.c:597)
==8063==    by 0x8053E80: parse_evaluate (parse.c:139)
==8063==    by 0x80495AE: compile_append (compile.c:127)
==8063==    by 0x8053E80: parse_evaluate (parse.c:139)
==8063==    by 0x8049B07: compile_if (compile.c:317)

==8063== 241,164 (26,148 direct, 215,016 indirect) bytes in 2,179 blocks 
are definitely lost in loss record 14 of 21
==8063==    at 0x401A649: malloc (vg_replace_malloc.c:149)
==8063==    by 0x805080F: list_new (lists.c:84)
==8063==    by 0x8050889: list_copy (lists.c:113)
==8063==    by 0x8055B48: copysettings (rules.c:479)
==8063==    by 0x8052C22: make1c (make1.c:590)
==8063==    by 0x80523A6: make1 (make1.c:234)
==8063==    by 0x8050F99: make (make.c:173)
==8063==    by 0x804EE68: main (jam.c:496)

==8063== 367,884 bytes in 2,787 blocks are definitely lost in loss record 
16 of 21
==8063==    at 0x401BB12: realloc (vg_replace_malloc.c:306)
==8063==    by 0x8058B10: string_reserve_internal (strings.c:67)
==8063==    by 0x8058BCB: extend_full (strings.c:91)
==8063==    by 0x8058CA0: string_append (strings.c:113)
==8063==    by 0x805B3CF: builtin_normalize_path (builtins.c:1309)
==8063==    by 0x8053E80: parse_evaluate (parse.c:139)
==8063==    by 0x804AAB0: evaluate_rule (compile.c:1036)
==8063==    by 0x804A0D4: compile_rule (compile.c:597)
==8063==    by 0x8053E80: parse_evaluate (parse.c:139)
==8063==    by 0x80495AE: compile_append (compile.c:127)
==8063==    by 0x8053E80: parse_evaluate (parse.c:139)
==8063==    by 0x804AC76: compile_set (compile.c:1132)

HTH, Markus