Oracle’s ‘proc’ program leaks temporary files

proc is a program that ‘compiles’ Pro*C into C or C++. It’s shocking that a big company like Oracle could produce something so shoddy.

Each time the program runs, it generates three temporary files in the current directory and leaves them there! After a few builds I’ve got thousands and thousands of these files. Sometimes I get so many of them that a simple “rm *” blows up with a command line too long error.

There’s no way to convince proc to put them anywhere other than the current directory. I can’t just remove all of the temporary files every time I call the program – that breaks parallel builds where two or more procs are running at the same time. In fact there’s no easy way at all to keep my working directory clear of these bloody files.

What the hell were Oracle’s engineers thinking when they wrote this turd? Do they ever use it themselves??

I despair.

Comment · Comments Feed · TrackBack

  1. MJH said,

    28 September, 2008 @ 16:16

    I have to deal with this sort of thing now and again, too. Usually, I first ltrace(1) the program and see if it refers to any environment variables with names that suggest they might influence the placement of the files.

    If I have no luck there, the next step is to craft up an LD_PRELOAD-able shim that, in this case, would record the filenames of the temp files as they’re created and then unlink them on exit.

  2. alex said,

    30 September, 2008 @ 09:22

    Yeah, been there. Done that.

    I can’t find an environment variable that affects the location of temporary files. I’d love to find one, but if it exists, it’s read directly from environ, and it has a very odd name.

    Playing with LD_PRELOAD would work in some places, but I’m building on eight architectures (including win32!) – so I don’t think it’s worth the bother.

  3. Ben Aveling said,

    4 October, 2008 @ 00:41

    If the names follow a regular pattern then you could automatically delete any such files that are older than an hour, a day, or whatever. Not perfect, but simple.

    Alternately, you could have a check of the process table or set a flag somewhere before running a cleanup – so that if there are two compiles running in parallel, the first one does nothing and the second one cleans up everything.

    Crazy that you should have to resort to such measures.

  4. alex said,

    6 October, 2008 @ 09:07

    That’s pretty much what I do – I wrote a little script that deletes all of the files that are more than a few minutes old. The script is run at the end of every build.

    I can’t do anything with process tables, because the parallel builds might be running on different machines.

  5. Guille said,

    22 October, 2008 @ 11:10

    This thread suggests that this is a version specific problem. I didn’t try it myself yet, but I will when I get the chance.

Leave a Comment