The call to Buf_DoneData was useless since ownership of the buffer data
has already been passwed on to loadedfile_create and the local variable
'buf' goes out of scope after that statement.
Except for cleaning up in debug mode, there is no reason to call
Buf_DoneData and then discard the returned value.
No functional change.
Previously, each time a .for directive pushed its buffer on the input
file stack, the current filename was duplicated. This was a waste of
memory.
The name of a file is typically only used while it is read in. There is
one situation when the filename is needed for longer, which is when a
target is defined.
Since .for loops are implemented as a special form of included files,
each .for loop duplicated the current filename as well.
$ cat << EOF > for.mk
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.for i in 1 2 3 4 5 6 7 8 9 0
.endfor
.endfor
.endfor
.endfor
.endfor
.endfor
.endfor
all:
@ps -o rsz -p ${.MAKE.PID}
EOF
$ make-2021.12.13.03.55.16 -r -f for.mk
RSZ
10720
$ ./make -r -f for.mk
RSZ
1716
The difference is 8 MB, which amounts to 1 million .for loops.
To trigger the memory leak, the expanded variable name must not be a
prefix of the textual variable name.
textual name expanded name
ok: UNDEF.${undef} UNDEF.
leak: UNDEF.${undef}. UNDEF..
The memory allocation was in LazyBuf_DoneGet. The substring for the
untaken branch had been allocated even though it was not necessary.
No functional change.
The newly added "variable" .SUFFIXES is short-lived as well, which makes
it necessary to distinguish between environment variables and
short-lived variables.
No binary change.
Since yesterday's addition of the short-lived "variable" named
.SUFFIXES, not only environment variables are short-lived. Clean up the
code to prepare for fixing the remaining memory leaks.
No functional change.
that change had no effect because vpanic() is marked __dead / noreturn
and thus the compiler would optimize away everything after a call to vpanic().
the original problem has now been fixed differently (but only for x86 so far).
when looking up function names for stack traces (where the addresses are the
return addresses of function calls), if the address is the first instruction
in the function, assume that the function being called is marked "noreturn"
and that the function containing the call is actually the function immediately
before the address that we looked up. to find the correct function name,
do the lookup again with (address - 1) and then add one to the offset within
the function that we find.
References to ${.SUFFIXES} are handled dynamically in
ParseVarnameLong by calling Suff_NamesStr.
The variable cannot be set normally.
Reviewed by: rillig
commit 2984e265cac6ef19a0de4fb21396fb87f45273d9
Merge: 6f5aada 359ab77
Author: Josh Boyer <jwboyer@kernel.org>
Date: Fri Sep 3 11:11:05 2021 -0400
Merge tag 'iwlwifi-fw-2021-09-02' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware into main
Revert accidentally released untested binaries
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
Done by removing tegra related directories in linux-firmware.
commit 2984e265cac6ef19a0de4fb21396fb87f45273d9
Merge: 6f5aada 359ab77
Author: Josh Boyer <jwboyer@kernel.org>
Date: Fri Sep 3 11:11:05 2021 -0400
Merge tag 'iwlwifi-fw-2021-09-02' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware into main
Revert accidentally released untested binaries
Signed-off-by: Josh Boyer <jwboyer@kernel.org>
Cherry picking files using the following method:
grep -R MODULE_FIRMWARE bsd/drm2/dist/drm/amd
Replace macros as needed.
Exclues navi10_mes.bin which doesn't exist on linux-firmware for some
reason.
The word 'set' sounded too much like it would replace the current file,
but instead the file is pushed to the stack, and the previous file is
continued later.
No functional change.
This affects many operations on variable expressions. Those using
LazyBuf_Done are affected, those using LazyBuf_DoneGet aren't.
$ cat <<'EOF' > lazybuf-memleak.mk
.for i in ${:U:range=5}
. for j in ${:U:range=1000}
. for k in ${:U:range=1000}
. if 0 && ${VAR:Dpattern\: that needs unescaping}
. endif
. endfor
. endfor
.endfor
all:
@ps -o vsz -p ${.MAKE.PID} | sed 1d
EOF
Before using LazyBuf for the modifier ':D':
$ make-2021.04.14.16.12.26 -r -f lazybuf-memleak.mk
VSZ RSZ
1357136 1336432
Using LazyBuf for the modifier ':D':
$ make-2021.04.14.16.59.34 -r -f lazybuf-memleak.mk
VSZ RSZ
1590864 1574164
This commit alone allocates around 150 MB more data, which matches
5_000_000 strings * 30 bytes/string.
It looks very wrong that the above simple makefile uses 1.3 GB of RAM at
all, and it had already done this in 2017, long before LazyBuf was
introduced. Before 2017.01.30.02.46.20, the above test makefile reports
way smaller numbers, but that's because the modifier ':range' did not
exist back then.
Without USE_COVERAGE, GCOV was undefined, the '2>&1' passed all error
messages to GCOV_PERL, when then discarded them. If the error messages
had been left on stderr, the error message 'sh: arch.o.gcda: not found'
would have been a clear indicator of the actual cause of an empty
coverage report.
simonb