Re: Junk *.tmp files in /tmp after compilation

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.