popen bug?

[Fabio Somenzi <fsomenzi at uswest dot net>]

I'm trying to compile ddd-3.1.2 with b20.1. I'm running Windows
98. ddd is the data display debugger (http://www.cs.tu-bs.de/softech/ddd/)

After minor changes, compilation goes through, but there are run-time
problems. Specifically, calls to popen fail---almost always.

ddd calls popen in several places. When invoked with the
--check-configuration option, ddd uses a popen call to locate the X
libraries.  I'm enclosing a small program (carved out of the ddd
sources) that illustrates the process.

The small program works. (I should say "has worked all the times I've
tried it.) ddd normally does not work. I say normally, because on one
occasion it did work. (If I didn't have a log file, I'd doubt I was
dreaming.)  The behavior of ddd when it fails is rather consistent.
When it calls popen, an error window pops up saying that ddd has
performed an illegal operation and will be shut down.

Occasionally, however, there will be a message about failed
synchronization with the child process.

The problem persists even if I replace the shell command with a simple
"echo" of the expected result. I've tried with CYGWIN both unset and
set to "tty". I'm not sure it was supposed to matter, but it didn't
make any difference in my case.

The following piece of information may be relevant. On the one
occasion in which the program worked, I had just recompiled it from
scratch after removing -O2 from the optimization flags. (To see if the
problem was with the optimizer.)  The new executable passed the
--check-configuration step. I then fired up ddd in normal mode, and it
came up clean, connecting (via popen) to gdb.  Therefore, this
executable ran twice in a row with no problems. After a couple of
minutes of exultation, I moved the .exe to my /usr/bin directory and
tried to run ddd on a program of mine. It failed for the usual reason.
I then put the executable back in its place, relinked, recompiled, all
to no avail.

Since then, I must have tried to run ddd at least 100 times, with as
many failures. If I assume that the problem is with some race in the
execution of popen, I can't explain very well the fluke of two
consecutive successful runs. On the other hand, if the problem were at
the linking stage... (Back in the old days of b18 there was such a
problem with dlls, if memory does not fail me.) Then again, why would
"mv" affect a working executable?

Well, I'm not sure the conjecture of the linker problem makes a lot of
sense. I'm not sufficiently familiar with the internals of ld and
cygwin to tell.  Also, I should add that I've searched the archives
for info on popen, but only found one message reporting a problem with
it. Apologies if I've missed a previous discussion of this issue, and
thanks in advance for any light you may shed on it.

Fabio


--------------------------------------------------
#include <stdio.h>
#include <errno.h>
#include <stream.h>
#include <stdlib.h>
#include <string.h>
#define PATH_MAX 1000

int main()
{
    static const char shell_command[] = "tmp=${TMPDIR-/tmp}/xc$$;\
export tmp;mkdir $tmp;trap \"cd /; rm -fr $tmp; exit 2\" 1 2 15;cd $tmp;\
echo \"findx:\" > Imakefile;echo \"	@echo \\${LIBDIR}\" >> Imakefile;\
xmkmf > /dev/null      2> /dev/null;make findx             2> /dev/null;\
cd /;rm -fr $tmp            2> /dev/null;exit 0";

    cout << shell_command << "\n";

    FILE *fp = popen(shell_command, "r");
    if (fp == 0) {
	cout << strerror(errno) << "\n";
	cout.flush();
	exit(2);
    }
    char buffer[PATH_MAX];
    buffer[0] = '\0';
    fgets(buffer, sizeof(buffer), fp);
    pclose(fp);

    int len = strlen(buffer);
    if (len > 0 && buffer[len - 1] == '\n')
	buffer[len - 1] = '\0';

    cout << buffer << "\n";
    cout.flush();

    exit(0);

}
--------------------------------------------------

-- 
Fabio Somenzi
University of Colorado
Fabio@Colorado.EDU

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".