Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

forking on Tru64 (alpha-dec-osf) #2096

Closed
p5pRT opened this issue Jun 15, 2000 · 16 comments
Closed

forking on Tru64 (alpha-dec-osf) #2096

p5pRT opened this issue Jun 15, 2000 · 16 comments

Comments

@p5pRT
Copy link

p5pRT commented Jun 15, 2000

Migrated from rt.perl.org#3387 (status was 'open')

Searchable as RT3387$

@p5pRT
Copy link
Author

p5pRT commented May 9, 2000

From nwhite@incyte.com

Hello,
I am having difficulty with perl's behaviour regarding forking and
filehandles on alpha machines. I've posted the problem in detail to
comp.lang.perl.misc to no avail​:

http​://x29.deja.com/[ST_rn=ps]/getdoc.xp?AN=616626501&CONTEXT=957551601.942669865&hitnum=1

http​://x29.deja.com/[ST_rn=ps]/getdoc.xp?AN=618007855&CONTEXT=957551601.942669865&hitnum=0

If the links do not work, I've appended a copy below.

Many thanks in advance for any guidance.
Regards,
Neill

***************MESSAGE 1************************

I'm having some difficulty using fork with open filehandles
on alpha machines. It seems that a fork() on an alpha machine
confuses the state of any open filehandles in the parent
process. I've written a little program that illustrates
the problem​:

#!/usr/local/bin/perl -w

open( FILE, "file" ) or die "Couldn't open file\n";

while( <FILE> ){
  chomp $_;
  if ( $pid = fork() ){
  # PARENT PROCESS
  print STDERR "reading line $. = $_\n";
  }
  elsif ( defined $pid ){
  # CHILD PROCESS
  close FILE or die "Couldn't close FILE\n";
  exit( 0 );
  }
  else{
  die "Couldn't fork\n";
  }
  sleep 2;
}

where "file" is
line1
line2
line3
line4

Now, on a linux machine running perl 5.005_03 for i386-linux, the
results are as expected​:
reading line 1 = line1
reading line 2 = line2
reading line 3 = line3
reading line 4 = line4

On an OSF1 v4.0 1229 alpha running perl 5.005_03 for alpha-dec_osf, I
get​:
reading line 1 = line1
reading line 2 = line2
reading line 3 = line3
reading line 4 = line4
reading line 5 = line1
reading line 6 = line2
reading line 7 = line3
reading line 8 = line4
reading line 9 = line1
reading line 10 = line2
reading line 11 = line3
reading line 12 = line4
...
(infinite loop)

This program illustrates how the filehandle gets confused
but does not illustrate intermittent data corruption from
the open filehandle, which I've experienced.

Is this a bug with 5.005_03 for alpha-dec_osf?

My apologizes if this question has been answered recently.
My search for a similar post yielded 1 hit with no reply​:
http​://x44.deja.com/[ST_rn=ps]/getdoc.xp?AN=477485997&CONTEXT=956886684.

385089536&hitnum=75

Regards,
Neill

@p5pRT
Copy link
Author

p5pRT commented May 9, 2000

From nwhite@incyte.com

nwhite.vcf

@p5pRT
Copy link
Author

p5pRT commented Jun 15, 2000

From nwhite@incyte.com

This is a bug report for perl from nwhite@​incyte.com,
generated with the help of perlbug 1.26 running under perl 5.00503.

There seems to be a problem with open filehandles getting
confused when the fork() command is executed. The problem
only seems to occur on my dec-alpha. This program should
illustrate the problem​:

#!/usr/local/bin/perl -w

open( FILE, "file" ) or die "Couldn't open file\n";

while( <FILE> ){
  if ( $pid = fork() ){
  # PARENT PROCESS
  print STDERR "reading line $. = $_";
  }
  elsif ( defined $pid ){
  # CHILD PROCESS
  close FILE or die "Couldn't close FILE\n";
  exit( 0 );
  }
  else{
  die "Couldn't fork\n";
  }

  sleep 2;
}

File "file" contains​:
line1
line2
line3
line4
~

The output should be​:
reading line 1 = line1
reading line 2 = line2
reading line 3 = line3
reading line 4 = line4

The output is​:
reading line 1 = line1
reading line 2 = line2
reading line 3 = line3
reading line 4 = line4
reading line 5 = line1
reading line 6 = line2
reading line 7 = line3
reading line 8 = line4
reading line 9 = line1
reading line 10 = line2
reading line 11 = line3
reading line 12 = line4
reading line 13 = line1
reading line 14 = line2
reading line 15 = line3
reading line 16 = line4
reading line 17 = line1
...


Site configuration information for perl 5.00503​:

Configured by root at Fri Aug 6 17​:00​:28 PDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration​:
  Platform​:
  osname=dec_osf, osvers=4.0, archname=alpha-dec_osf
  uname='osf1 miracle.incyte.com v4.0 1091 alpha '
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef useperlio=undef d_sfio=undef
  Compiler​:
  cc='cc', optimize='-O4', gccversion=
  cppflags='-std -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C'
  ccflags ='-std -fprm d -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C'
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=8, ptrsize=8, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
  alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='ld', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc /usr/lib /var/shlib
  libs=-lgdbm -ldbm -ldb -lm
  libc=/usr/shlib/libc.so, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-rpath,/usr/local/lib/perl5/5.00503/alpha-dec_osf/CORE'
  cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -O4 -msym -s -L/usr/local/lib'

Locally applied patches​:
 


@​INC for perl 5.00503​:
  /opt/bob/master/dev/COMMON/lib
  /opt/bob/master/dev/COMMON/bin
  /u/binf/nwhite/PERLLIB
  /usr/local/biobin
  ~dmh/devel/gold/common
  /usr/local/lib/perl5/5.00503/alpha-dec_osf
  /usr/local/lib/perl5/5.00503
  /usr/local/lib/perl5/site_perl/5.005/alpha-dec_osf
  /usr/local/lib/perl5/site_perl/5.005
  .


Environment for perl 5.00503​:
  HOME=/u/binf/nwhite
  LANG (unset)
  LANGUAGE (unset)
  LD_LIBRARY_PATH=/opt/oracle/product/8.0.5/lib​:/usr/ucblib​:/usr/dt/lib​:/opt/bob/master/dev/OSF/lib​:/opt/oracle/product/8.0.5/lib
  LOGDIR (unset)
  PATH=/opt/bob/master/dev/OSF/tccs/bin​:/opt/bob/master/dev/OSF/bin​:/opt/bob/master/dev/COMMON/bin​:.​:/u/binf/nwhite/bin​:/u/binf/nwhite/bin/OSF​:/u/binf/nwhite/bin/scripts​:/Office51/bin​:/data/java/bin​:/usr/local/bin​:/usr/local/biobin​:/opt/pure/purify-4.5-beta-L4-solaris2​:/opt/pure/quantify-4.2-solaris2​:/usr/bin/X11​:/u/binf/dmh/OSF/bin​:/u/binf/slink/bin​:/bin​:/usr/bin​:/usr/ucb​:/usr/etc​:/usr/sbin​:/usr/openwin/bin​:/usr/xpg4/bin​:/opt/SUNWsunpc/bin​:/usr/local/mmxp​:/data/jbuilder30/bin​:/opt/bob/master/dev/OSF/bin​:/opt/bob/master/dev/COMMON/bin​:/opt/bob/master/dev/COMMON/sql​:/opt/bob/master/dev/OSF/tccs/bin​:/var/opt/bob/tccsRoot/bobHead/src/Admin​:/opt/oracle/product/8.0.5/bin​:/opt/oracle/product/8.0.5/bin​:/opt/bob/slave/OSF/bin​:/opt/bob/master/dev/OSF/bin​:/net_home/orabob/OSF/bin​:/u/binf/nwhite/acedb/bin/OSF
  PERLLIB=/opt/bob/master/dev/COMMON/lib​:/opt/bob/master/dev/COMMON/bin​:/u/binf/nwhite/PERLLIB​:/usr/local/biobin​:~dmh/devel/gold/common
  PERL_BADLANG (unset)
  SHELL=/bin/tcsh

@p5pRT
Copy link
Author

p5pRT commented Jun 16, 2000

From [Unknown Contact. See original ticket]

At 17​:47 -0700 2000-06-15, Neill White wrote​:

There seems to be a problem with open filehandles getting
confused when the fork() command is executed. The problem
only seems to occur on my dec-alpha.

Wow. That's really odd. There have been similar bug reports for
5.005_03 having to do with filehandles not being flushed ahead of a
fork, and these have been addressed (though not entirely laid to
rest) in the current stable release, 5.6.0. It doesn't look as if
you're seeing exactly that kind of failure, though. Besides, AFAICT,
the Alpha is not among the platforms where problems have been
reported. (See the 5.6.0 perlport man page.).

A few questions​:

1. Is output the same whether STDERR is directed to a terminal
  (which really ought to make the stdio package flush every time
  it sees a newline) or a file (which might (or might not) change
  stderr flushing behaviour)?

2. Does replacing sleep 2 in your program with the (more
  fastidious) wait change /eliminate the symptoms?

3. How does the corresponding C program behave on the Alpha and on
  other platforms?
--- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ---
#include <stdio.h>
#include <unistd.h>

int
main(int ac, char **av) {
  FILE *f;
  char b[256];
  int l = 0;
  int pid;

  if ((f = fopen("file", "r")) == NULL) {
  perror("Couldn't open file");
  exit(2);
  }

  while(fgets(b, sizeof b, f) != NULL) {
  l++;
  if ( pid = fork() ) {
  /* PARENT PROCESS */
  fprintf(stderr, "reading line %d = %s", l, b);
  }
  else if ( pid == 0) {
  /* CHILD PROCESS */
  if (fclose(f) != 0) {
  perror("Couldn't close file");
  exit(1);
  }
  exit( 0 );
  }
  else{
  perror("Couldn't fork");
  }
  }
  (void) sleep(2);
}
--- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ---

4. Does wait() instead of sleep(2) in the C code change things?

5. Does perl 5.6.0 change/eliminate the symptoms?

@p5pRT
Copy link
Author

p5pRT commented Jun 18, 2000

From @ysth

In article <p04320400b56f95025ade@​[192.168.1.4]>,
Dominic Dunlop <domo@​computer.org> wrote​:

At 17​:47 -0700 2000-06-15, Neill White wrote​:

There seems to be a problem with open filehandles getting
confused when the fork() command is executed. The problem
only seems to occur on my dec-alpha.

Wow. That's really odd. There have been similar bug reports for
5.005_03 having to do with filehandles not being flushed ahead of a
fork, and these have been addressed (though not entirely laid to
rest) in the current stable release, 5.6.0. It doesn't look as if
you're seeing exactly that kind of failure, though. Besides, AFAICT,
the Alpha is not among the platforms where problems have been
reported. (See the 5.6.0 perlport man page.).

A few questions​:

I see this problem on os2 5.6.0. The C program also fails, with
both sleep and wait.

@p5pRT
Copy link
Author

p5pRT commented Jun 19, 2000

From [Unknown Contact. See original ticket]

At 02​:16 -0700 2000-06-18, Yitzchak Scott-Thoennes wrote​:

I see this problem on os2 5.6.0. The C program also fails, with
both sleep and wait.

Hmmm. May be a different problem. Are the failure symptoms of the
Perl program identical to those in Neill White's original report?
How flaky do you find fork() in general? README.os2 has much to say
about it, what you have to do to make it work, and when it won't work
even so. Does this help you?

@p5pRT
Copy link
Author

p5pRT commented Jun 19, 2000

From @ysth

In article <p04320400b573c51b5032@​[192.168.1.4]>,
Dominic Dunlop <domo@​computer.org> wrote​:

At 02​:16 -0700 2000-06-18, Yitzchak Scott-Thoennes wrote​:

I see this problem on os2 5.6.0. The C program also fails, with
both sleep and wait.

Hmmm. May be a different problem. Are the failure symptoms of the
Perl program identical to those in Neill White's original report?

Yes.

How flaky do you find fork() in general? README.os2 has much to say
about it, what you have to do to make it work, and when it won't work
even so. Does this help you?

Sadly, README.os2 (aka perlos2.pod) is out of date. The problem it
describes with forking after loading a dynamic extension was fixed in
EMX 0.9d (21-Dec-1998).

@p5pRT
Copy link
Author

p5pRT commented Jun 21, 2000

From [Unknown Contact. See original ticket]

Apologies for the hand-washing tone of what follows...

At 20​:27 -0700 2000-06-19, Yitzchak Scott-Thoennes wrote​:

Hmmm. May be a different problem. Are the failure symptoms of the
Perl program identical to those in Neill White's original report?

Yes.

Well, I think we've reached the stage where someone who can see the
problem is going to have to dive in with a debugger (Debugging
forking programs. Fun) and see what's happening. I'm not that
person, as I'm not running anything that shows the behaviour. Sorry.

Sadly, README.os2 (aka perlos2.pod) is out of date. The problem it
describes with forking after loading a dynamic extension was fixed in
EMX 0.9d (21-Dec-1998).

Oh dear. As I don't run OS/2, and as quite a lot of the README is
concerned with this erstwhile bug, I don't feel qualified to fix the
documentation. Would anyone who is running OS/2 care to have a shot?
(Cc to Rocco Caputo, who provided an OS/2 patch for 5.6.0 as a
possible patsy, um, knight in shining armour.)

@p5pRT
Copy link
Author

p5pRT commented Jun 29, 2000

From @ysth

I'm resending this, since I don't see it in my perl5-porters spool.
(Perhaps I never sent it in the first place?) If someone does
update README.os2, please send a copy to Ilya asking him to review
it if he has time. (He may have left p5p, but he is still the
maintainer of the emx port).

In article <p04320401b57637341967@​[192.168.1.4]>,
Dominic Dunlop <domo@​computer.org> wrote​:

At 20​:27 -0700 2000-06-19, Yitzchak Scott-Thoennes wrote​:

Sadly, README.os2 (aka perlos2.pod) is out of date. The problem it
describes with forking after loading a dynamic extension was fixed in
EMX 0.9d (21-Dec-1998).

Oh dear. As I don't run OS/2, and as quite a lot of the README is
concerned with this erstwhile bug, I don't feel qualified to fix the
documentation. Would anyone who is running OS/2 care to have a shot?
(Cc to Rocco Caputo, who provided an OS/2 patch for 5.6.0 as a
possible patsy, um, knight in shining armour.)

It's been on my list to look at doing for a long time now. A number
of things in the README need updating (for instance, many of the URLs
are out of date). But I haven't had time. If anyone else out there
does work on this, note that I don't think the warning about forking
after loading dynamic extensions should still be in there somewhere
and direct people to upgrade emx.

@p5pRT
Copy link
Author

p5pRT commented May 1, 2006

From @smpeters

[nwhite@​incyte.com - Thu Jun 15 10​:48​:05 2000]​:

This is a bug report for perl from nwhite@​incyte.com,
generated with the help of perlbug 1.26 running under perl 5.00503.

There seems to be a problem with open filehandles getting
confused when the fork() command is executed. The problem
only seems to occur on my dec-alpha. This program should
illustrate the problem​:

#!/usr/local/bin/perl -w

open( FILE, "file" ) or die "Couldn't open file\n";

while( <FILE> ){
if ( $pid = fork() ){
# PARENT PROCESS
print STDERR "reading line $. = $_";
}
elsif ( defined $pid ){
# CHILD PROCESS
close FILE or die "Couldn't close FILE\n";
exit( 0 );
}
else{
die "Couldn't fork\n";
}

sleep 2;

}

File "file" contains​:
line1
line2
line3
line4
~

The output should be​:
reading line 1 = line1
reading line 2 = line2
reading line 3 = line3
reading line 4 = line4

The output is​:
reading line 1 = line1
reading line 2 = line2
reading line 3 = line3
reading line 4 = line4
reading line 5 = line1
reading line 6 = line2
reading line 7 = line3
reading line 8 = line4
reading line 9 = line1
reading line 10 = line2
reading line 11 = line3
reading line 12 = line4
reading line 13 = line1
reading line 14 = line2
reading line 15 = line3
reading line 16 = line4
reading line 17 = line1
...

---

I've been able to replicate the above problem on Tru64, in the Perl
above and the similar C code also attached to this ticket. I have also
tried the magic _exit() trick that helps Solaris, which didn't work.
Any one else have an idea of how fork() is different on Tru64?

@p5pRT
Copy link
Author

p5pRT commented Jan 12, 2008

From perl@franz-fischer.de

Hello,

I came across this bug while debugging a foomatic-filters standalone
setup, where I got duplicate lines in the postscript output fed to
ghostscript.

After some further testing with the attached forktest.c program
(which is based on the sources posted earlier) I found the following​:

  - The effect of getting duplicate input is present in
  perl5.8.0 (as delivered with Tru64 5.1B-3) and my locally
  compiled perl5.8.7.

  - The effect is not perl specific, as the test with the C
  program show.

  - The effect happens only with seekable input​:
  Running
  ./forktest forktest.in
  or
  ./forktest <forktest.in
  produces more than the expected 4 lines of output,
  while
  cat forktest.in | ./forktest
  produces exactly the expected 4 lines of output.

  - The effect seems to be caused by the child process
  closing (explicitly or implicitly by exiting) the
  file pointer inherited from the parent process.
  If the child sleeps long enough before exiting,
  no duplicated input is seen​:
  ./forktest -l forktest.in
  produces the expected 4 lines of output, while
  ./forktest -cl forktest.in
  (explicit close before long sleep)
  shows duplicate input.

  - The effect is also present on HP-UX B.11.11,
  so I assume that it comes from the very early days
  of UN*X.

@p5pRT
Copy link
Author

p5pRT commented Jan 12, 2008

From perl@franz-fischer.de

forktest.c

@p5pRT
Copy link
Author

p5pRT commented Jan 12, 2008

From perl@franz-fischer.de

forktest.in

@p5pRT
Copy link
Author

p5pRT commented Jan 12, 2008

From perl@franz-fischer.de

Some additional info regarding my previous comment​:

  - HP-UX is somewhat different​: Input duplication seems to happen
  only if the child process explicitly closes the inherited file
  pointer (forktest -c), and can be ``cured'' by a pair of
  fgetpos(3) / fsetpos(3) in the parent process (forktest -cf).

  - The fgetpos / fsetpos pair does not help on Tru64 V5.1B-3
  (OSF1 ofen.local V5.1 2650 alpha)

@p5pRT
Copy link
Author

p5pRT commented Jan 12, 2008

From [Unknown Contact. See original ticket]

Some additional info regarding my previous comment​:

  - HP-UX is somewhat different​: Input duplication seems to happen
  only if the child process explicitly closes the inherited file
  pointer (forktest -c), and can be ``cured'' by a pair of
  fgetpos(3) / fsetpos(3) in the parent process (forktest -cf).

  - The fgetpos / fsetpos pair does not help on Tru64 V5.1B-3
  (OSF1 ofen.local V5.1 2650 alpha)

@toddr
Copy link
Member

toddr commented Feb 1, 2020

Given the reporter can no longer be reached by email and the hp problem is different I am going to close this. If new information can be provided we can open a new ticket

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants