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

 
 

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

Submitter:  None
Submitted:  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 Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group Member
Wed 12 Mar 2014 08:42:23 AM UTC, comment #4: 

... just tried the Windows build from the web site
http://wiki.octave.org/Octave_for_Microsoft_Windows#Octave_3.8.0_MXE_Builds

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
octave: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.

Anonymous
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>
Group 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>
Group Member
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>
Group 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'


Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group 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.13-f8d8.
    Corresponding source code