Apache OpenOffice (AOO) Bugzilla – Issue 31409
Large memory leak in rsc2
Last modified: 2004-09-10 12:24:26 UTC
While building ooo20040704 my machine became very ill and ran out of memory. I found that rsc2 had already used 2Gb of memory and was still hungry.. :-/ It seems that it leaks large amounts of memory, and this becomes critical when building many languages at once. The killer was when trying to build sd/util with all languages. I ran valgrind to find out where this memory is being allocated, and that it is definately a leek: ==13197== 71712512 bytes in 280127 blocks are definitely lost in loss record 41 of 41 ==13197== at 0x3C02140D: malloc (vg_replace_malloc.c:105) ==13197== by 0x80634FC: RscMem::Malloc(unsigned short) (in /oo/680/java/openoffice.org680-0.m44+cvs040708/solver/680/unxlngi4.pro/bin/rsc2) ==13197== by 0x807C46B: MallocString() (in /oo/680/java/openoffice.org680-0.m44+cvs040708/solver/680/unxlngi4.pro/bin/rsc2) ==13197== by 0x807C6F0: MakeToken(YYSTYPE*) (in /oo/680/java/openoffice.org680-0.m44+cvs040708/solver/680/unxlngi4.pro/bin/rsc2) ==13197== by 0x807CB69: yylex() (in /oo/680/java/openoffice.org680-0.m44+cvs040708/solver/680/unxlngi4.pro/bin/rsc2) ==13197== by 0x8077C8B: yyparse() (in /oo/680/java/openoffice.org680-0.m44+cvs040708/solver/680/unxlngi4.pro/bin/rsc2) ==13197== by 0x807CF7A: parser(RscFileInst*) (in /oo/680/java/openoffice.org680-0.m44+cvs040708/solver/680/unxlngi4.pro/bin/rsc2) ==13197== by 0x80AEE69: RscCompiler::ParseOneFile(unsigned long, RscCmdLine::OutputFile const*, WriteRcContext const*) (in /oo/680/java/openoffice.org680-0.m44+cvs040708/solver/680/unxlngi4.pro/bin/rsc2) ==13197== by 0x80B03FB: RscCompiler::Link() (in /oo/680/java/openoffice.org680-0.m44+cvs040708/solver/680/unxlngi4.pro/bin/rsc2) ==13197== by 0x80ADEE2: RscCompiler::Start() (in /oo/680/java/openoffice.org680-0.m44+cvs040708/solver/680/unxlngi4.pro/bin/rsc2) [P2 because it breaks builds that build many languages at once]
the memory leak may not be fixable without rewriting the whole parser, since we don't know when yylex() is ready with the string. As a workaround compile fewer languages at a time, or recompile rsc2 while setting MINBUF in rsclex.hxx to something smaller than the current 256 (try 32). We will see if can do more. malloc /usr/lib/valgrind/vgskin_memcheck.so RscMem::Malloc(unsigned short) rsc/source/tools/rsctools.cxx:361 MallocString() rsc/source/parser/rsclex.cxx:153 MakeToken(YYSTYPE*) rsc/source/parser/rsclex.cxx:275 yylex() rsc/source/parser/rsclex.cxx:433 yyparse() bison.simple:432 parser(RscFileInst*) rsc/source/parser/rsclex.cxx:533 RscCompiler::ParseOneFile(unsigned long, RscCmdLine::OutputFile const*, WriteRcContext const*) rsc/source/rsc/rsc.cxx:837 RscCompiler::Link() rsc/source/rsc/rsc.cxx:1072 RscCompiler::Start() rsc/source/rsc/rsc.cxx:588 main rsc/source/prj/gui.cxx:151
cp->pl: as discussed, probably duplicate. Please have a look
*** Issue 22638 has been marked as a duplicate of this issue. ***
set target
.
In CWS vcl25 i checked in a version that does not waste the memory anymore; however since CWS bmpres01 the .srs files are parsed anew for every language rc file written. I hope that we can find a way to avoid that, too.
pl->ka: you said you would look into the multiple parse issue if time allowed; therefore i'll send this issue to you. If time doesn't permit the change please simply forward it to hjs for verification as the most critical issue is fixed.
accepted
Assign to me again; we will look into the reparsing matter again later; the memory leak is fixed for now.
fixed in CWS vcl25
verified in CWS vcl25
Can you outline what files are fixed so I can cross patch and verify whether my other problem is related.
Created attachment 17256 [details] diff of solution
attached diff (against m49) of changed files
merged in 680m54