From bug-octave-request at bevo dot che dot wisc dot edu  Wed May 13 02:30:54 1998
Subject: popen2 does not correctly execute on Solaris 2.4
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: jwtaylor at vaughn dot physio-control dot com
Cc: bug-octave at bevo dot che dot wisc dot edu
Date: Wed, 13 May 1998 02:28:41 -0500 (CDT)

Digging way back in my mail, I found this:

On 30-Apr-1997, James W. Taylor <jwtaylor at mailhost dot physio-control dot com> wrote:

| I have octave installations on a Cyrex 586 Linux 2.0.30 machine
| and a Solaris 2.5, Sparc 20/270.
| 
| Both systems were compiled under gcc 2.7.2.1, from an unmodified 
| 2.0.5 octave distribution.
| 
| At Octave startup, on the Solaris machine, the system reports:
| 
| ---
| Octave, version 2.0.5 (sparc-sun-solaris2.5).
| Copyright (C) 1996 John W. Eaton.
| This is free software with ABSOLUTELY NO WARRANTY.
| For details, type `warranty'.
| ---

| Background:
| ----------
| I have been working intermittantly with a software
| simulation/validation system which operated by using "system" to
| start, and communicate with a proprietary detection algorithm.  Input
| was generated by octave, stored in a file, the detector operated on
| the stored data, and returned performance and detector results on stdout.
| 
| Didn't work - after several hundred thousand iterations, the system
| refused to start new processes. Unfortunately, I'm not free to send
| the detector code, and I could not recreate the problem with
| simplified systems - similiar sized random data, over which a CRC (gnu
| "cksum") was done.
| 
| Let me mention, only *one* external process runs at a time, each of
| which exits properly.  I am running with few shell limits, i.e.:
| 
| ---
| vaughn:~% limit
| cputime         unlimited
| filesize        unlimited
| datasize        2047MB
| stacksize       2047MB
| coredumpsize    unlimited
| descriptors     1024
| vmemorysize     unlimited
| ---
| 
| None of which are approached, as verified by "ps" an "vmstat".
| 
| Ahhh HA:
| -------
| Given no meat there for a proper bug report, in the same Solaris
| environment, I converted my scripts to provide data through stdin
| (which my detector already understood) and output though stdout.  I
| got SIGPIPE errors on the Solaris machine. My short tests ran
| perfectly on my Linux system. The following octave script, directly
| from the documentation, fails on my Solaris 2.5 machine and runs as
| documented on the Linux machine:
| 
| ---
|   [in, out, pid] = popen2 ("sort", "-nr");
|   fputs (in, "these\n");
|   fputs (in, "are\n");
|   fputs (in, "some\n");
|   fputs (in, "strings\n");
|   fclose (in);
|   while (isstr (s = fgets (out)))
|     fputs (stdout, s);
|   endwhile
|   fclose (out);
| ---
| 
| The first statement returns (on stderr):
| 
| ---
| sort: read error on stdin: Operation not applicable
| ---
| 
| however, popen2 returns (in, out, pid)
| ---
| in = 10
| out = 11
| pid = 6492
| ---
| 
| "fgets" returns "-1" thereafter.
| 
| "sort" operates correctly on stdin from a shell.
| 
| The only other item of note is that the process communication
| functions "octave_[io]procstream" use the "popen" call which on a
| Solaris 2.5 box are marked "MT unsafe" in the man pages. Am I
| running into problems due to the dual processor configuration of 
| this machine?

I think this problem should be fixed in recent releases of Octave.
I think the problem is that Octave was not always using the correct
file ids for creating the pipes in the popen2 call.  I made some
changes a while back that were supposed to keep the file ids returned
by Octave's popen2 function in sync with the actual system file ids.

Can someone verify that the problem is really fixed (it does seem to
work for me).

Thanks,

jwe