Question

A “mysterious” behavior was found in my code. Briefly speaking, the point is

• the line that works with a breakpoint does not work without breakpoints
• it has nothing to do with privileges (unlike a lot of questions about ‘Win32Exception’ do)

A somewhat similar symptom was reported here: MSBuild Script gets "Win32Exception: The system cannot find the File Specified" … in that both have something to do with debugging process. (I am not sure if it has something to do with my problem, though.)

I am writing a code to

1. produce a histogram in text format
2. launch ‘gnuplot’ by using ‘System.Diagnostics.Process.Start’ to plot the generated histogram
3. open the image file generated by gnuplot by also using ‘Process.Start(“generatedPlot.png”).

1,2 seem to be executed successfully, because I get a png image in the working directory.

However, in spite of the existence of the plot image, I get a ‘Win32Exception’ saying “The specified files was not found” when I try to open the file with

void GeneratePlot()
{
  // generate a png image called 'outputPath' with console 'gnuplot.exe'
  MyClass.gnuplot(dataFilePath,outputPath);
  MyClass.OpenFile(outputPath);
}

OpenFile is defined simply as

static void OpenFile(string fileToOpen)
{
  Process.Start(fileToOpen);  // this throws 'Win32Exception'  ...(*)
}

The mysterious thing is here: In order to debug this problem, I put a breaking point at (*). Then the exception is no longer thrown!

(NOTE: Because the plot image is successfully created, you don’t get the exception in the second run with the same ‘fileToOpen’. Therefore, please make sure you delete the generated plot image before debugging.)

I managed to find a way other than placing a breakpoint there, of course. What I did was just separating the execution of MyClass.gnuplot and MyClass.OpenFile:

void GeneratePlot()
{
  // some code
  MyClass.gnuplot(dataFilePath, outputPath);
}

void button1_Click(object sender, EventArgs e)
{
  MyClass.OpenFile(outputPath);
}

After I execute ‘GeneratePlot()’, hit ‘button1’. This time it shows the png image!

Just in case, I write a code like this to create a png plot image: (it works fine alone!)

static void gnuplot(string dataFilePath, string outputPath)
{
  Process p = new Process();
  p.StartInfo.FileName = \\path\\to\\gnuplot.exe;
  p.StartInfo.RedirectStandardInput = true;
  p.StartInfo.WorkingDirectory = Directory.GetWorkingDirectory();
  // some other StartInfo setting
  p.Start();

  // execute gnuplot with the following
  StreamWriter sw = new StreamWriter(p.StandardInput);
  sw.WriteLine("set terminal \"png\"");
  sw.WriteLine("set output " + outputPath);
  sw.WriteLine("plot '{0}'",dataFilePath);
}

I am curious about why this happens. Could you give me advise? Thank you very much in advance.

Answer 1

There might be a race conditon between the time the file is being created and written by gnuplot and the time that you attempt to open the file in your own process. I’ll bet that when you run this in the debugger, enough time has passed by the time the breakpoint is hit that the gnuplot process has closed the output file.

To solve this, you can wait some period of time after sending the plot command, or better yet, wait for the gnuplot process to exit.

static void gnuplot(string dataFilePath, string outputPath)
{
  Process p = new Process();
  p.StartInfo.FileName = \\path\\to\\gnuplot.exe;
  p.StartInfo.RedirectStandardInput = true;
  p.StartInfo.WorkingDirectory = Directory.GetWorkingDirectory();
  // some other StartInfo setting
  p.Start();

  // execute gnuplot with the following
  StreamWriter sw = new StreamWriter(p.StandardInput);
  sw.WriteLine("set terminal \"png\"");
  sw.WriteLine("set output " + outputPath);
  sw.WriteLine("plot '{0}'",dataFilePath);

  // ----> wait for gnuplot to exit before returning
  // (presumes that gnuplot exits shortly after executing the plot command)
  p.WaitForExit();
}

If the p.WaitForExit(); statement doesn’t work (ie, the gnuplot process doesn’t exit after executing the plot command), try Thread.Sleep(TimeSpan.FromSeconds(1.0)); (or some other period of time) instead.