bugGNU Octave - Bugs: bug #41836, plot command: temporaray file...


bug #41836: plot command: temporaray file names not unique

Submitted by:  None
Submitted on:  Tue 11 Mar 2014 05:16:11 PM UTC  
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Duplicate Assigned to:  None
Originator Name:  Martin Hepperle Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  3.6.4
Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Wed 12 Mar 2014 01:01:53 PM UTC, comment #5: 

Ok, closing as a duplicate report. Please follow up with further comments on bug #36688.

Mike Miller <mtmiller>
Project Administrator
Wed 12 Mar 2014 08:42:23 AM UTC, comment #4: 

... just tried the Windows build from the web site

GNU Octave, version 3.8.1
... lines skipped ...
Octave was configured for "i686-w64-mingw32".
... lines skipped ...
octave:1> tempname()
ans = C:\Users\ea55\AppData\Local\Temp\oct-1
octave:1> tempname()
ans = C:\Users\ea55\AppData\Local\Temp\oct-2
octave:2> tempname()
ans = C:\Users\ea55\AppData\Local\Temp\oct-3

Shows the same behavior.

Windows has a simple function to create temporaray file names ('limited' to 65000 variants)

UINT WINAPI GetTempFileName(
  In   LPCTSTR lpPathName,
  In   LPCTSTR lpPrefixString,
  In   UINT uUnique,
  Out  LPTSTR lpTempFileName

Another more safe option is to use the following COM function to create a unique ID

HRESULT CoCreateGuid(
  Out  GUID *pguid

Header: Objbase.h, Library: Ole32.lib, DLL: Ole32.dll

I don't know about the GNU libraries, though.

Tue 11 Mar 2014 07:05:59 PM UTC, comment #3: 

Looks like a duplicate to me.  Changeset c936beeda029 removed the tempname.c and tempnam.c files.  If those files are removed, does the situation improve?  I'll have to try that and rebuild for Windows to check.

With those files removed it's also not clear to me whether we are using a tempnam replacement from gnulib or just expecting it to come from the system library.

John W. Eaton <jwe>
Project Administrator
Tue 11 Mar 2014 06:47:57 PM UTC, comment #2: 

I think this is a duplicate of bug #36688, or is there something different about this specific case that I missed?

Mike Miller <mtmiller>
Project Administrator
Tue 11 Mar 2014 06:25:40 PM UTC, comment #1: 

I think this works properly for me on my Debian system where temporary files in the ghostscript command have names like "/tmp/oct-XfcHDE.eps".

Are we ultimately using the gnulib version of tmpnam?  If not, then maybe we should be.  If so, then it looks like a bug in gnulib because I don't think it should be returning file names that would be likely to collide with other generated names.

John W. Eaton <jwe>
Project Administrator
Tue 11 Mar 2014 05:16:11 PM UTC, original submission:  

Currently I am running several shell scripts at the same time in parallel on a multi-core system. These also call octave to create some plots.
When it comes to plotting to a bitmap file the results get mixed up.

The reason is that the plot command creates temporary files whose names are just numbered per session (1, 2, ...)
If two octave sessions are running at the same time, chances are that they want to use the same file which fails or that a later run overwrites the temporary plot file.

To repair this, the temporary file names would have to be unique. At least to a high degree of probability, e.g. using the rand() function.
A better approach would be to create a file name, test for its existence and if so, increment a counter, otherwise create the file to "reserve" it.

The current code uses tmpnam() which should be replaced (probably tmpnam () should be modified to create at least a pseudo unique file name.

The following example shows the temporary file name (oct-7.eps):

octave:1> x = linspace(0,3,50);
octave:2> y = sin(x);
octave:2> plot(x,y);
octave:3> print('test.png','-dpng','-debug');
Ghostscript command: '"D:\Program_Files_(x86)\Octave3.6.1_gcc4.6.2\gs\gs9.04\bin/gswin32c.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=png16m -dTextAlphaBits
=4 -dGraphicsAlphaBits=4 -r150x150 -dEPSCrop -sOutputFile=wbd.png C:\Users\ea55\AppData\Local\Temp\oct-3.eps'
gnuplot-pipeline: '"D:\Program_Files_(x86)\Octave3.6.1_gcc4.6.2\gs\gs9.04\bin/gswin32c.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=png16m -dTextAlphaBits=4
-dGraphicsAlphaBits=4 -r150x150 -dEPSCrop -sOutputFile=wbd.png C:\Users\ea55\AppData\Local\Temp\oct-7.eps & del C:\Users\ea55\AppData\Local\Temp\oct-3.eps'



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-03-12 mtmiller StatusNone => Duplicate
        Open/ClosedOpen => Closed
    2014-03-11 mtmiller Dependencies- => Depends on bugs #36688

    Back to the top

    Powered by Savane 3.5