Junk *.tmp files in /tmp after compilation
Jean-Baptiste Faure
jbf.faure at sud-ouest.org
Thu Jan 3 11:12:47 PST 2013
Le 03/01/2013 16:48, Michael Meeks a écrit :
>
> On Thu, 2013-01-03 at 13:12 +0100, Jean-Baptiste Faure wrote:
>> I jump into this discussion because I sent the same question.
>
> :-)
>
>> Each time I build LO 4.0, I get ~459 new temporary files that are not
>> removed. I guess they are created during automated tests at the end of
>> the build. All files have .tmp extension, many of them (~222) are empty,
>> ~119 are recognized as RTF files, ~14 are ODF documents, ~74 are
>> archives but probably ooxml files, ~16 are images in various formats,
>> others have unknown type.
>
> Sounds like the best guess then is unit tests; here's how to help hunt
> down where they get leaked:
>
> clean /tmp/
>
> run 'make check' - see if that leaks the files - if so, it's the
> 'check' rule :-) Try narrowing that down; does 'make check' inside sw/
> dump stuff in /tmp (actually I'd try that first - it'd be faster.
What I did :
clean /tmp/
./g pull -r
make dev-install
-> 459 temp files left
clean /tmp/
make check
-> 461 temp files left
clean /tmp/
make check in .../sw
-> 423 temp files left
clean /tmp/
make check in .../sc
-> 11 temp files left
Another thing: make creates a temp dir in /tmp but never uses it, it
remains empty during the build. The name of this tempdir is a 6 random
alphabetical characters word. It is not removed when the build is completed.
>
> When we have a reasonably small rule that creates the problem; then we
> should do:
>
> 'strace -f -s 256 -o /tmp/slog make check'
>
> And then search for a known leaked tmp file in that log - then work the
> process id (the first item on each line) back - somewhere there is a
> 'clone(...) = <pid>' type call where <pid> is the pid of the process
> that wrote that file.
>
> Searching for the 'execve' shortly after that clone would give you the
> process name of the process that did it.
>
> Perhaps run that process in isolation to check. Then we'll need to
> investigate that process further, if it's a unit test in it - it'd be
> good to find a leak: we can presumably improve our test coverage by
> fixing it :-)
Hmm I am afraid that this is too difficult for me. Anyway I tried the
command 'strace -f -s 256 -o /tmp/slog make check' in .../sc. Then
exploring the slog file I found that several temp files are created and
removed. Temp files are created in alphabetical order.
In that case the first temp file is opened in a process with PID 32088.
The first line with this PID is :
execve("/home/jbf/LibO/master/solver/unxlngx6.pro/bin/cppunit/cppunittester",
["/home/jbf/LibO/master/solver/unxlngx6.pro/bin/cppunit/cppunittester",
"/home/jbf/LibO/master/workdir/unxlngx6.pro/LinkTarget/CppunitTest/libtest_sc_ucalc.so",
"--headless", ... (very long command)
2 lines before this one there is
32087 clone(child_stack=0,...) = 32088
Hope this helps
Best regards.
JBF
--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
More information about the LibreOffice
mailing list