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

Not OK: perl v5.7.2 +DEVEL14368 on cygwin-multi-64int 1.3.6(0.4732) (UNINSTALLED) #4901

Closed
p5pRT opened this issue Jan 22, 2002 · 6 comments
Closed

Comments

@p5pRT
Copy link

p5pRT commented Jan 22, 2002

Migrated from rt.perl.org#8320 (status was 'resolved')

Searchable as RT8320$

@p5pRT
Copy link
Author

p5pRT commented Jan 22, 2002

From @ysth

This is a build failure report for perl from sthoenna@​efn.org,
generated with the help of perlbug 1.33 running under perl v5.7.2.

Haven't figured this one out yet, but here are the pieces​:

t/cmd/mod...........................ok
t/cmd/subval........................ok
t/cmd/switch........................ok
t/cmd/while.........................ok
t/run/exit..........................ok
t/run/fresh_perl....................

and hangs there. The culprit is the new test there​:

-cut-
######## [ID 20020104.007] "coredump on dbmclose"
package Foo;
eval { dbmclose %h }; # not all places have dbm* functions
if ($@​) {
  print "ok\n";
  exit 0;
}
package Foo;
sub new {
  my $proto = shift;
  my $class = ref($proto) || $proto;
  my $self = {};
  bless($self,$class);
  my %LT;
  dbmopen(%LT, "dbmtest", 0666) ||
  die "Can't open dbmtest because of $!\n";
  $self->{'LT'} = \%LT;
  return $self;
}
sub DESTROY {
  my $self = shift;
  dbmclose(%{$self->{'LT'}});
print "ok\n";
  return 1;
}
package main;
$test = Foo->new(); # must be package var
EXPECT
ok
######## [ID 20020104.007] "coredump on dbmclose" (deferred cleanup)
END
{
  1 while unlink 'dbmtest';
  1 while unlink <dbmtest.*>;
  print "ok\n";
}
EXPECT
ok
-cut-

First of all, this is wrong. The end block is invoked before the
destroy, so the cleanup won't happen for os's that won't unlink open
files, and "ok" will print whether or not dbmclose barfs.

But for cygwin here, the "1 while unlink 'dbmtest';" seems to loop forever.
Why unlink is returning true multiple times is beyond me. There seems to be
some sort of deferred unlink going on here...an open file is still present
after an unlink but goes away after it's closed.

Apologies if I'm missing the obvious, I've never done a cygwin build before.

Anyway, the following bypasses the problem. Perhaps someone could verify
that the test fails without the fix applied?

Inline Patch
--- t/run/fresh_perl.t.orig	Fri Jan 18 20:02:26 2002
+++ t/run/fresh_perl.t	Tue Jan 22 16:46:00 2002
@@ -780,15 +780,12 @@
 sub DESTROY {
         my $self = shift;
         dbmclose(%{$self->{'LT'}});
+        print "ok\n";
+        1 while unlink 'dbmtest';
+        1 while unlink <dbmtest.*>;
         return 1;
 }
 package main;
 $test = Foo->new(); # must be package var
-END
-{
-	1 while unlink 'dbmtest';
-	1 while unlink <dbmtest.*>;
-	print "ok\n";
-}
 EXPECT
 ok
End of Patch.

Flags​:
  category=install
  severity=none


Site configuration information for perl v5.7.2​:

Configured by sthoenna at Tue Jan 22 10​:28​:37 2002.

Summary of my perl5 (revision 5.0 version 7 subversion 2 patch 14368) configuration​:
  Platform​:
  osname=cygwin, osvers=1.3.6(0.4732), archname=cygwin-multi-64int
  uname='cygwin_98-4.10 yo 1.3.6(0.4732) 2001-12-08 17​:02 i686 unknown '
  config_args='-de -Dusedevel -Dusemultiplicity -Duse64bitint'
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define
  useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
  use64bitint=define use64bitall=undef uselongdouble=undef
  usemymalloc=y, bincompat5005=undef
  Compiler​:
  cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include',
  optimize='-O2',
  cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include'
  ccversion='', gccversion='2.95.3-5 (cygwin special)', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
  ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='ld2', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib /lib
  libs=-lgdbm -lcrypt -lutil
  perllibs=-lcrypt -lutil
  libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl5_7_2.a
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags=' -L/usr/local/lib'

Locally applied patches​:
  DEVEL14368


@​INC for perl v5.7.2​:
  lib
  /usr/local/lib/perl5/5.7.2/cygwin-multi-64int
  /usr/local/lib/perl5/5.7.2
  /usr/local/lib/perl5/site_perl/5.7.2/cygwin-multi-64int
  /usr/local/lib/perl5/site_perl/5.7.2
  /usr/local/lib/perl5/site_perl
  .


Environment for perl v5.7.2​:
  HOME=/cygdrive/c/home/sthoenna
  LANG (unset)
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/local/bin​:/usr/bin​:/bin​:/cygdrive/c/home/sthoenna/bin​:/cygdrive/c/PROGRA~1/YARNW​:/usr/bin​:/USR/LOCAL/EMACS/EMACS-20.7/BIN​:/cygdrive/c/WINDOWS​:/cygdrive/c/WINDOWS/COMMAND
  PERL_BADLANG (unset)
  SHELL (unset)

@p5pRT
Copy link
Author

p5pRT commented Jan 22, 2002

From @jhi

First of all, this is wrong. The end block is invoked before the
destroy, so the cleanup won't happen for os's that won't unlink open
files,

This is true...

and "ok" will print whether or not dbmclose barfs.

....but this is slightly irrelevant​: the whole "ok" printing could
be done away with-- the most important point is whether the dbmclose
core dumps or not.

But for cygwin here, the "1 while unlink 'dbmtest';" seems to loop forever.
Why unlink is returning true multiple times is beyond me. There seems to be
some sort of deferred unlink going on here...an open file is still present
after an unlink but goes away after it's closed.

Apologies if I'm missing the obvious, I've never done a cygwin build before.

Anyway, the following bypasses the problem. Perhaps someone could verify
that the test fails without the fix applied?

Unapplied #14106, and tested with the suggested change, worked,
put back #14106, applied the suggested change.

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2002

From @ysth

I wrote​:

But for cygwin here, the "1 while unlink 'dbmtest';" seems to loop forever.
Why unlink is returning true multiple times is beyond me. There seems to be
some sort of deferred unlink going on here...an open file is still present
after an unlink but goes away after it's closed.

cygwin does indeed do a deferred unlink for open files, in one of two ways​:
it does a CreateFile/CloseHandle with FILE_FLAG_DELETE_ON_CLOSE set.
in cases where it suspects that might not work (remote files, or windows 9x/me)
it also queues the file for deletion by an atexit routine (close_all_files).

This is a big problem since we recommend the '1 while unlink' syntax in
perlport​:

The portable idiom to remove all the versions of a file is

  1 while unlink "file";

This will terminate if the file is undeleteable for some reason
(protected, not there, and so on).

Options (none of which I like, most of which I personally am incapable of)​:

Change vms to set d_unlink_all_versions. Give them another method to
only delete the highest version. (boo hiss) And no longer recommend
'1 while unlink'. In fact, warn on it if possible.

Change perlport to say unlinking can't be portably done for both vms and
cygwin without explicit OS check. (boo hiss)

At compile time, somehow alter "1 while unlink LIST;" to just unlink
LIST unless running vms and !UNLINK_ALL_VERSIONS.

Get the cygwin people to change their code to return failure for the
second deferred unlink in a row for the same file. (This has a problem
if the file really was opened,unlinked,closed,opened,unlinked.)

Have our own unlink in cygwin.c that determines when a deferred unlink
is needed (by doing for ourselves everything the cygwin unlink does up
to before setting delete_on_close_ok, then calling cygwin's unlink if
deferred unlink needed) and track if we do two deferred unlinks in a
row for the same win32_name. (yuck)

Anyone have any brilliant ideas?

@p5pRT
Copy link
Author

p5pRT commented Aug 15, 2002

From @ysth

Filehandle leak fixed that was holding the file open.

@p5pRT
Copy link
Author

p5pRT commented Aug 15, 2002

@ysth - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this as completed Aug 15, 2002
@p5pRT
Copy link
Author

p5pRT commented Aug 15, 2002

From @ysth

Sorry, wrong comment. Test was fixed to work correctly.

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

No branches or pull requests

1 participant