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

Bleadperl 8165fae breaks Sys::AlarmCall #11260

Closed
p5pRT opened this issue Apr 17, 2011 · 7 comments
Closed

Bleadperl 8165fae breaks Sys::AlarmCall #11260

p5pRT opened this issue Apr 17, 2011 · 7 comments

Comments

@p5pRT
Copy link

p5pRT commented Apr 17, 2011

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

Searchable as RT88774$

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2011

From @cpansprout

See https://rt.cpan.org/Ticket/Display.html?id=67239 and​:

commit 8165fae
Author​: Nicholas Clark <nick@​ccl4.org>
Date​: Sun Apr 18 13​:24​:20 2010 +0100

  Move PERL_ASYNC_CHECK() from POPBLOCK() to the kill case of Perl_apply().
 
  This ensures that (safe) signals sent to the same process are still dispatched
  within the same statement (as before), without overloading the semantics of
  block popping.


Flags​:
  category=core
  severity=high


Site configuration information for perl 5.14.0​:

Configured by sprout at Sun Apr 3 16​:29​:04 PDT 2011.

Summary of my perl5 (revision 5 version 14 subversion 0) configuration​:
  Snapshot of​: aa6faf7
  Platform​:
  osname=darwin, osvers=10.5.0, archname=darwin-thread-multi-2level
  uname='darwin pint.local 10.5.0 darwin kernel version 10.5.0​: fri nov 5 23​:20​:39 pdt 2010; root​:xnu-1504.9.17~1release_i386 i386 '
  config_args='-Dusedevel -de -Duseithreads -Doptimize=-g'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
  optimize='-g',
  cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib
  libs=-ldbm -ldl -lm -lutil -lc
  perllibs=-ldl -lm -lutil -lc
  libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'

Locally applied patches​:
  RC0


@​INC for perl 5.14.0​:
  /usr/local/lib/perl5/site_perl/5.14.0/darwin-thread-multi-2level
  /usr/local/lib/perl5/site_perl/5.14.0
  /usr/local/lib/perl5/5.14.0/darwin-thread-multi-2level
  /usr/local/lib/perl5/5.14.0
  /usr/local/lib/perl5/site_perl
  .


Environment for perl 5.14.0​:
  DYLD_LIBRARY_PATH (unset)
  HOME=/Users/sprout
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/bin​:/bin​:/usr/sbin​:/sbin​:/usr/local/bin​:/usr/X11/bin​:/usr/local/bin
  PERL_BADLANG (unset)
  SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2011

From @cpansprout

Can this be made a blocker?

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2011

From @obra

On Sun 17.Apr'11 at 17​:18​:31 -0700, Father Chrysostomos wrote​:

Can this be made a blocker?

It now blocks. Thanks.

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2011

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Apr 19, 2011

From @iabyn

On Mon, Apr 18, 2011 at 12​:11​:07PM +1000, Jesse Vincent wrote​:

On Sun 17.Apr'11 at 17​:18​:31 -0700, Father Chrysostomos wrote​:

Can this be made a blocker?

It now blocks. Thanks.

Now fixed​:

commit 011c381
Author​: David Mitchell <davem@​iabyn.com>
AuthorDate​: Tue Apr 19 14​:17​:12 2011 +0100
Commit​: David Mitchell <davem@​iabyn.com>
CommitDate​: Tue Apr 19 14​:32​:42 2011 +0100

  dispatch signals when leaving an eval
 
  Currently PERL_ASYNC_CHECK is only called during scope exit in pp_leavetry
  and pp_levaeeval. This means that if the signal handler calls die, the
  eval won't catch it.
 
  This broke Sys​::AlarmCall's test suite, which was doing the equivalent of
 
  $SIG{ALRM} = sub { die };
  eval {
  alarm(1);
  select(undef, undef, undef, 10);
  }
  # expect the die to get caught and $@​ set here.
 
  Because the select was the last statement in the block, PERL_ASYNC_CHECK
  wasn't called next until the leave_scope at the end of leavetry.
  See RT #88774.
 
  The simple fix is to add a PERL_ASYNC_CHECK at the top of
  leavetry and leaveeval.

--
"Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit."
  -- Lady Croom, "Arcadia"

@p5pRT
Copy link
Author

p5pRT commented Apr 19, 2011

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

@p5pRT p5pRT closed this as completed Apr 19, 2011
@p5pRT
Copy link
Author

p5pRT commented Apr 19, 2011

From @nwc10

On Tue, Apr 19, 2011 at 02​:34​:09PM +0100, Dave Mitchell wrote​:

On Mon, Apr 18, 2011 at 12​:11​:07PM +1000, Jesse Vincent wrote​:

On Sun 17.Apr'11 at 17​:18​:31 -0700, Father Chrysostomos wrote​:

Can this be made a blocker?

It now blocks. Thanks.

Now fixed​:

Thanks. Your timing is perfect. I'd got the test case down to the same size as
yours, and had just started scratching my head about what was going on.
(Q​: "The signal clearly triggers inside the eval. So why on earth is the signal
handler getting run outside the eval?")

I'm glad that the fix is clean and simple, as I was concerned that it was
going to need something rather more "funky" (and hence risky)

(A​: Because if a PERL_ASYNC_CHECK() is missing from somewhere it should be,
the symptoms are equivalent to a signal being deferred due to a mask)

Nicholas Clark

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

1 participant