bugGNU Octave - Bugs: bug #48149, popen2 on Windows requires delay


bug #48149: popen2 on Windows requires delay

Submitted by:  Rik <rik5>
Submitted on:  Mon 06 Jun 2016 04:02:22 PM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev 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 29 Jun 2016 11:53:46 PM UTC, comment #5:

I find that some of the stuff with Windows' API is so maddening that, rather than seek understanding, I just try and get working code.

If the number of code variants is small (use WaitForInputIdle / don't use WaitForInputIdle), I'd just test them one-by-one and see if it works.

Rik <rik5>
Project Administrator
Wed 29 Jun 2016 07:03:11 PM UTC, comment #4:

It also seems strange to me that the octave_popen2 function for Windows calls CloseHandle on the process handle and then returns. Is it really OK to do that before the child process exits?

John W. Eaton <jwe>
Project Administrator
Wed 29 Jun 2016 06:44:10 PM UTC, comment #3:

Looking at the documentation for CreateProcess:


it seems like maybe we should be calling WaitForInputIdle on the created process, but the documentation for that function:


says "If this process is a console application or does not have a message queue, WaitForInputIdle returns immediately."


John W. Eaton <jwe>
Project Administrator
Mon 06 Jun 2016 10:41:08 PM UTC, comment #2:

If I don't write anything to the input side of the pipe, but instead read from the output, then it returns -1. This seems to set the EOF on the pipe because if I then write to the input side the output always returns -1.

It seems that this sequence is required

1) popen2()
2) write to input
3) flush input or close input
4) pause
5) read from output

Rik <rik5>
Project Administrator
Mon 06 Jun 2016 09:18:50 PM UTC, comment #1:

If you never write to the input side of the pipe, does the output descriptor ever return EAGAIN (with sufficient pausing)? In other words, is it possible we could insert a delay inside popen2 to ensure that the output descriptor is "valid" after calling CreateProcess but before returning control to the caller?

Mike Miller <mtmiller>
Project Administrator
Mon 06 Jun 2016 04:02:22 PM UTC, original submission:

There is example code in the docstring for popen2. The code is

This works correctly on Linux, but fails on Windows. The problem is that the initial call to fgets (out) returns -1 (EOF) immediately. I can get the code to work by adding a small delay before starting the do loop.

This works

I tried using fflush (in) before fclose, but that didn't help. The problem is either in the popen2 call, which is Windows specific and located in liboctave/system/lo-sysdep.cc. Or Windows itself has problems with concurrency.

I've attached the test code to this bug report.

Rik <rik5>
Project Administrator


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

Attach Files:

Attached Files
file #37409:  tst_popen2.m added by rik5 (339B - d2l/unknowntype)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by cbm
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (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
    2016-07-03 cbm Carbon-Copy- => Added cbm
    2016-06-29 rik5 StatusNone => Confirmed
    2016-06-06 rik5 Attached File- => Added tst_popen2.m, #37409

    Back to the top

    Powered by Savane 3.3