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
perldoc -f alarm suggests example code that isn't safe against race conditions #10147
Comments
From espie@nerim.netThe example code for the use of alarm is wrong, wrong, wrong. There is a DEADLY race condition in there, the example code is overly eval { and so, we lost data from the socket. There's no way around it. OF COURSE, this doesn't happen often. Just can make things unreliable... If you want to keep the example, the code should at least mention that it |
From @craigberryOn Tue, Feb 9, 2010 at 10:06 PM, espie@nerim.net
Hmm. Even though signal delivery is blocked until sysread (the Perl <http://perldoc.perl.org/perlipc.html#Deferred-Signals-(Safe-Signals)> |
The RT System itself - Status changed from 'new' to 'open' |
From @ikegamiOn Thu, Feb 11, 2010 at 6:26 AM, Craig A. Berry <craig.a.berry@gmail.com>wrote:
With safe signals: 1. read system call ends No data is lost. padsv and sassign are never evaluated, so the error code is * -- Or whatever sysread does between the time read ends and sysread ends. |
From @ikegamiOn Thu, Feb 11, 2010 at 2:30 PM, Marc Espie <espie@nerim.net> wrote:
I'm am going from the docs for safe signals, provided in the post above I imagine it's quite hard to cause the problematic situation to occur. |
From @craigberryOn Thu, Feb 11, 2010 at 1:30 PM, Marc Espie <espie@nerim.net> wrote:
I included a link to the docs on deferred signals earlier. Those are It's easy to get confused between C signal handling terms that are Real blocking does come into play in step 7 of Eric's list, the If you look at the main run loop in run.c: int TAINT_NOT; you can see that inside the loop you're either executing the op,
Maybe, maybe not, depending on whether the syscall gets restarted when
Got that right. I appreciate your trying to improve things. I'm in |
From espie@nerim.netOn Thu, Feb 11, 2010 at 02:08:49PM -0500, Eric Brine wrote:
Is this behavior actually documented anywhere ? This is still bad, though, apart from that, the original example code as I read it implies that this isn't sane. I don't know about you, but I've fixed enough race conditions in various (the main issue with races being that they only occur unfrequently, so |
From espie@nerim.netOn Thu, Feb 11, 2010 at 05:26:24AM -0600, Craig A. Berry wrote:
Yes, even though. There's still a race. The window where it can go wrong is smaller, Think about two things: Basically, a line such as |
From @druud62Marc Espie wrote:
I dislike "eval {}; if ( The value of eval{} itself is available: eval { # propagate unexpected errors # timed out -- |
From @demerphqOn 15 February 2010 01:05, Dr.Ruud <rvtol+usenet@isolution.nl> wrote:
Thanks ruud. I would have said the same thing if you hadnt. Basically it is a categorical ERROR to test $@ to determine if an eval failed. You HAVE to force eval to return a non false value and check that it Any examples we have that replicate this error should be fixed. As far as I can tell we will never ever fix the bug that leaves us in cheers, -- |
From zefram@fysh.orgdemerphq wrote:
It's a categorical error because a signal handler might have clobbered If signal handlers are allowed to clobber $@ then you can't reliably use But something conceptually similar to what you suggest is indeed how to You're better off not throwing an exception from the signal handler. -zefram |
From @AbigailOn Tue, Feb 16, 2010 at 11:02:58AM +0000, Zefram wrote:
It's not just signal handlers. It's DESTROY as well (but that can be regarded sub DESTROY {eval {1}} I can't get it the other way (eval returning non-undef, with $@ set).
If we think this is the right way to do, there ought to be a way to have But I'm sure something somewhere will break if this starts happening.
Abigail |
From zefram@fysh.orgAbigail wrote:
Indeed. I've been campaigning for $@ (and the other global status
Throwing an exception from a signal handler could be done intentionally In the shorter term, I'm meant to be doing a module that will let you DESTROY { ... } (no "sub") and get the status variables implicitly localised. I've been -zefram |
From @davidnicolOn Tue, Feb 16, 2010 at 6:33 AM, Zefram <zefram@fysh.org> wrote:
I believe I submitted a patch that did exactly that, or a significant
its a debate for 2007 or 2008. And the consensus taken then was to
One concept that emerged from the discussion as a possible way forward Somebody somewhere may have been actually using exceptions raised http://use.perl.org/articles/08/03/29/224206.shtml is the This Week In |
From @iabynOn Thu, Feb 11, 2010 at 06:06:27PM -0600, Craig A. Berry wrote:
Here's a working demo. It requires a temporary hack to pp_sysread() to Inline Patchdiff --git a/pp_sys.c b/pp_sys.c
index e7cdb59..f21d77e 100644
--- a/pp_sys.c
+++ b/pp_sys.c
@@ -1780,6 +1780,7 @@ PP(pp_sysread)
/* This should not be marked tainted if the fp is marked clean */
if (!(IoFLAGS(io) & IOf_UNTAINT))
SvTAINTED_on(bufsv);
+ if (count==1) { int i; for (i=0; i<1000000000; i++) {} }
SP = ORIGMARK;
PUSHi(count);
RETURN;
system 'echo "ab" > /tmp/foo'; eval { gives as output: timeout out, retrying So, we think the sysread timed out and didn't read anything, but I rather wonder whether, now that we have safe signals (so that the "die" You can't rely on the alarm causing the system call to fail with C<$!> and thus that the correct way of doing a system call with timeout is now: { } -- |
From @jkeenanOn Fri Feb 26 13:50:43 2010, davem wrote:
I reviewed this three-year-old ticket tonight. The OP's complaint There was considerable back-and-forth in the ticket, but it's not clear We could use additional eyeballs on this ticket. Thank you very much. |
From @iabynOn Tue, Feb 19, 2013 at 05:47:21PM -0800, James E Keenan via RT wrote:
I think I demonstrated that it *was* possible to reproduce the race 1 the example needs replacing with something safer if we can think of I'm unlikely to doing further wok on this ticket for the moment. -- |
Migrated from rt.perl.org#72666 (status was 'open')
Searchable as RT72666$
The text was updated successfully, but these errors were encountered: