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 FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating 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 File(s):

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
  • -unavailable- added by cbm
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Submitted the item)

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

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 03 Jul 2016 05:31:06 AM UTCcbmCarbon-Copy-=>Added cbm
    Wed 29 Jun 2016 11:53:46 PM UTCrik5StatusNone=>Confirmed
    Mon 06 Jun 2016 04:02:23 PM UTCrik5Attached File-=>Added tst_popen2.m, #37409

    Back to the top

    Powered by Savane 3.1-cleanup1