perl 5.005_03 core dumps -- singal interrupt related #1005
Comments
From [email protected]Perl core dumps shortly after I send an interrupt signal to my program. Output from gdb: [bleh@nut src]$ gdb perl core warning: core file may not match specified executable file. The core occurs when I send an interrupt while the program (attached psftp.pl #!/usr/bin/perl #use Term::ReadLine; # Configuration # Location of helper programs (we assume its in path at the moment) my $version = "0.05"; # help related stuff my %optctl = (); #print "Term Type: " . $term->ReadLine() . "\n" if ( $DEBUG ); #$attrib->{"completion_word"} = [ sort(@commands) ]; # my $features = $term->Features(); my $INT; sub main_loop { sub open_host { sub close_host { sub get_auth_mode { sub write_pass { sub remote_cd { sub execute_remote_cmd { sub ssh_interface { sub do_remote_cd { sub do_remote_mkdir { sub do_remote_rm { sub do_remote_chown { sub do_remote_chmod { sub do_remote_pwd { sub do_remote_ls { sub do_remote_paged_ls { sub do_local_cd { sub do_local_ls { sub do_local_paged_ls { sub do_local_mkdir { sub do_local_rm { sub do_local_chown { sub do_local_chmod { sub do_put { put_files([ $file ],$remote,$options); sub do_mput { sub put_files { sub do_get { sub do_mget { sub get_file { sub do_help { sub load_help { sub do_exit { sub ssh_interrupt { sub do_set { sub do_save { sub shell_escape { #sub do_pick_completion { sub split_args { # END PSFTP.pl Perl Info |
From [Unknown Contact. See original ticket]<nads@bleh.org> writes:
Signals can do that to any perl. Only the most trivial of signal handlers There are various approaches to making signals usable which Both Tk and the Event modules have 'synchronous' signals implemented
Pretty typical ...
Far, far too complex. -- |
From [Unknown Contact. See original ticket]Nick Ing-Simmons writes:
This is wrong. No signal handlers are safe. Hope this helps (why should I repeat it again and again?), P.S.
I wonder why not we add something like $SIG{CHLD} = [inc => \$counter, set => [\$foo, 13], pid => \$pid]; and avoid all the problems with a Perl function call altogether... |
From @TimToadyIlya Zakharevich writes: Bletch, in a vague sort of way. Larry |
From [Unknown Contact. See original ticket]Larry Wall writes:
But comparing to what we have now it would be a paradise. ;-) Ilya |
From @TimToadyIlya Zakharevich writes: I was bletching the interface, not the implementation. I agree that An interesting question is where to install the checks in the regular In this scheme, here's our C signal handler: Signal_t Seems pretty safe to me. Larry |
From [Unknown Contact. See original ticket]On Mon, Jan 10, 2000 at 01:28:16PM -0800, Larry Wall wrote:
And I was saying that a change of the interface can make the
No, we do not *need* to delay sub invocations. Delaying the And if you want the delayed semantic, you may do $SIG{CHLD} = [delayed => sub {...} ]; And you can do $SIG{CHLD} = [delayed => sub {...}, repeated => [2, sub {...}] ]; which might mean that if another signal appears when one is delayed
Which is an obvious bletch. Ilya |
From @TimToadyIlya Zakharevich writes: And in what way does your proposal help this? What interrupts the : And if you want the delayed semantic, you may do That's more needless complexity. This should be hidden from the user. : > Of course, within regular expressions we'd have But then you're talking implementation again. I'd rather see the And the whole idea of signals is so busted anyway that I don't think a Larry |
From [Unknown Contact. See original ticket]On Mon, Jan 10, 2000 at 03:54:56PM -0800, Larry Wall wrote:
The kernel, of course.
Modification of existing variables is the smallest problem of Perl
Yes, it may be done. However, it is done *dangerously*, why in my And if you do not like the interface, write a module which sub { ++$count; return } to [ inc => \$count ]. Make assignment to $SIG autoload this module. Ilya |
From [Unknown Contact. See original ticket]Ilya Zakharevich (lists.p5p):
I hate to suggest this, but wouldn't The even-numbered elements to your anon array there (not even a hash. Either way, you lose. Blech, in fact. -- |
From @samtregarOn 11 Jan 2000, Simon Cozens wrote:
True, but currently a sub {} cannot be executed by a signal handler in a -sam |
From [Unknown Contact. See original ticket]On Mon, 10 Jan 2000 13:28:16 -0800 (PST) :We need to delay sub invocations until we know we're in a safe state, What about slow-running ops? It seems like some of them require more sys related: accept, close, connect, fcntl, flock, getc, ioctl, Those aren't that bad. It's the others that seem more challenging. indirect calls: sort, map, grep Where do those take the signal? What if it's a built-in sorting, such as What about system() and `backticks`? Are these part of the sys-related Is sleep() a sys-related case? What about list-context flipflops? "a" .. "zzzzz" takes a long time How about the dofile and require operators? Is it safe to permit Finally, let's have some fun ones. What about tie() and its related tie %mib, 'Tie::SMTP', $remhost; The tie itself might take a long time because $remhost is unreachable. But what if it's in XS code? How will reliable signal delivery interact --tom |
From [Unknown Contact. See original ticket]Larry> That's more needless complexity. Ilya> And if you do not like the interface, write a module which This still falls under the imprecation against `needless complexity'. Upon packing his bags in preparation for a journey, the savvy traveller --tom |
From [Unknown Contact. See original ticket]
Sort is a good example. I remember an IBM rep doing a demo of a little APL It went away, and could not be interrupted. He finally had to power cycle it |
From [Unknown Contact. See original ticket]At 06:59 AM 1/11/00 -0700, Tom Christiansen wrote:
What we'd need was a wedge into the long-running op at a safe place. We could do this either with an explicit wedge (essentially a yield()) That still gets us nowhere with potentially long running system calls,
Well, the wedge method would get us in for anything that didn't block, but Dan --------------------------------------"it's like this"------------------- |
From @TimToadyTom Christiansen writes: That's why I said, "at the iterator [un-sic] of any looping constructs." : Where do those take the signal? What if it's a built-in sorting, such as The proper check point is probably in qsortsv(), which is used to call all : What about system() and `backticks`? Are these part of the sys-related Any op of that sort can set a flag which says it's safe to call the sub : Is sleep() a sys-related case? Can be solved with either as above or via EINTR. : What about list-context flipflops? "a" .. "zzzzz" takes a long time "at the iterator of any looping constructs" : How about the dofile and require operators? Is it safe to permit The iterator of the compiler is byacc. : Finally, let's have some fun ones. What about tie() and its related If it's tied to Perl code, that operates at the granularity of the Perl : But what if it's in XS code? How will reliable signal delivery interact Existing XS code is a problem regardless. Inventing a new minilanguage First, we can do the deliver-immediately-on-duplicate-signal trick. Second, we could interrupt ourselves periodically with an interval timer Third, we could document how to install a check point, deal with EINTR, As far as I'm concerned, the main remaining issue is how to direct In short, this is all insane, but it's the sort of insanity we should Larry |
From [Unknown Contact. See original ticket]:As far as I'm concerned, the main remaining issue is how to direct I never did manage to get signal delivery working under :In short, this is all insane, but it's the sort of insanity we should
--tom |
From [Unknown Contact. See original ticket]At 11:37 AM 1/11/00 -0700, Tom Christiansen wrote:
Signals and threads are going to be a persistent problem. It's anyone's Then Linux adds more fun to the mix, as it's only mostly POSIX-compliant, Dan --------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]On Tue, Jan 11, 2000 at 10:31:36AM -0800, Larry Wall wrote:
Of course immediate atomic delivery solves this, as well as removes
If this delivery is unsafe, then this is just putting things under the carpet.
Let me repeat one of the reference points: close to impossible under OS/2. Ilya |
From [Unknown Contact. See original ticket]Simon Cozens writes:
Hmm, is not this what I proposed?
You cannot run arbitrary code in an immediate sighandler. If you
Their lazyness is nothing of our concern. Ilya |
From [Unknown Contact. See original ticket]Tom Christiansen writes:
"This" is what? Needless for what?
Hmm, is not it prose? Did anybody find any technical contents in this? Ilya |
From @TimToadyIlya Zakharevich writes: But your delivery doesn't deliver, in the sense of guaranteeing the : > First, we can do the deliver-immediately-on-duplicate-signal trick. As I recall, you're the one who proposed immediate delivery on a second : > As far as I'm concerned, the main remaining issue is how to direct Let me point out that we don't have to deliver C level signals to Larry |
From @TimToadyIlya Zakharevich writes: Yes, and it's still relatively useless in the overall scheme of things. : > This seems wasteful: We can make that restriction relatively insignificant. : > If you allow, say, a `[code => sub { ... }]', everyone will use that You mean, their laziness is nothing of *your* concern. It is certainly Larry |
From [Unknown Contact. See original ticket]On Tue, Jan 11, 2000 at 01:03:04PM -0800, Larry Wall wrote:
It is good that our schemes are so close. But mine is better ;-): you First I failed to see how your scheme will make script notice the signal. $SIG{} = [die => $message]; will die atomically, but may leave things in a non-consistent state. a) set a variable; All things in a)..d) can be made atomically without any damage. e) So question is: are we going to make a major rewrite just to allow
Not a tiny bit easier: you still need to unblock the thread. Ilya |
From [Unknown Contact. See original ticket]On Tue, Jan 11, 2000 at 01:11:11PM -0800, Larry Wall wrote:
Hmm, is it the reason why now *by default* h2xs produces almost Ilya |
From [Unknown Contact. See original ticket]Ilya Zakharevich wrote:
hm, and I thought laziness was one of the three great vitues of a programmer. maybe I'm being hubristic. Greg |
From [Unknown Contact. See original ticket]On Tue, Jan 11, 2000 at 04:35:27PM -0500, london@pixelmagic.com wrote:
It is a virtue of a programmer, but not in *another* programmer. ;-) An attempt to grant lazyness to signal-handler's programmers is Ilya |
From [Unknown Contact. See original ticket]At 04:19 PM 1/11/00 -0500, Ilya Zakharevich wrote:
g) Queue up another I/O request You're letting the crippled signal implementation limit you.
So? Unless the thread is waiting on a blocking system call it's not a big Dan --------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]On Tue, Jan 11, 2000 at 04:32:46PM -0500, Dan Sugalski wrote:
If die() were safe, all these would easy to implement...
Why do you thing it is not going to be waiting on a blocking system
What made you thingk cond_wait() is not a blocking system call? Ilya |
From @TimToadyIlya Zakharevich writes: Only for some values of "you". If you increment a variable then some : First I failed to see how your scheme will make script notice the signal. Eh? I never said anything like that... : This is indeed a questionable behaviour. What are other things people Forcing the script to check the variable periodically. : b) increment a variable; Forcing the script to check the variable periodically. : c) exit(); Can be optimized away as a subroutine with a known constant value. :-) : d) wait() and assign the result; Again, somebody's gotta check for the result explicitly if they care. : e) wait() and append the result to an array/hash; : All things in a)..d) can be made atomically without any damage. e) Seems unlikely, since you probably have to allow malloc in there somewhere : This leaves 'f', which is much better in your setup. And you left out: g) anything else you might want to do safely in a signal handler. : So question is: are we going to make a major rewrite just to allow I don't think it's a major rewrite. All we have to do is make sure our check points can reach a consistent : > : Let me repeat one of the reference points: close to impossible under OS/2. How does OS/2 unblock a thread? Obviously it can, or threads would never Larry |
From [Unknown Contact. See original ticket]At 09:28 PM 1/11/00 -0500, Ilya Zakharevich wrote:
Yes I do, and no it isn't. Perl code does a cond_wait. The cond_wait code And yes, a new thread for long syscalls is inefficient. (And a completely
Yeah, and....? The underlying code for the other threads (assuming that Yes, it does mean a bit of extra code in the core, but it's not code that's Dan --------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]On Wed, Jan 12, 2000 at 10:18:24AM -0500, dan@sidhe.org wrote:
So what? I know (from kernel traffic) they are aware of and fixing the
What's the difference? Memory sharing is the same, right?
Yes. That's one of the reasons I felt that linux might be an
I never understood the alure of routing all the signals to a single
True.
As seen from here, that doesn't sound conclusive one way or the other. -- |
From [Unknown Contact. See original ticket]At 10:35 AM 1/12/00 -0500, Joshua N Pritikin wrote:
Good. I hadn't seen that, but I only skim the weekly summaries occasionally.
Yes, though there's more to a thread than memory sharing. (You can
In some ways it is, for the synchronous signals--they're more installed
It makes handling the event signals easier. You just route 'em all to a Dan --------------------------------------"it's like this"------------------- |
From @TimToadyFisher Mark writes: Depends on how you implement your character insertion, your screen Larry |
From [Unknown Contact. See original ticket]On Wed, Jan 12, 2000 at 10:56:06AM -0500, dan@sidhe.org wrote:
Yah, they're definitely aware of that.
I don't know. At least the control is in the hands of the developer. On
I'm still mystified. Obviously the library/kernel can do this static Signal_t process_sighandler(int sig) { kill(ParentPID, sig); } Am I missing something? -- |
From [Unknown Contact. See original ticket]At 11:17 AM 1/12/00 -0500, Joshua N Pritikin wrote:
Well, POSIX doesn't, really. More to the point it explicitly makes the I think part of this is to accommodate those systems that use a LWP/Kernel POSIX threads are a sort of cross-platform compromise. Not 100% great, but
Nope. But that's error prone and, more to the point, platform-specific in a Not that we can't (or shouldn't) deal with it at the perl level, of course. Dan --------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]Larry Wall wrote:
actually, its called "gedi" and should be rolled into the Tk800.017 release. ok, ok, a lot of the underlying code is C (character inserts, and the like) Greg |
From [Unknown Contact. See original ticket]On Wed, Jan 12, 2000 at 10:20:18AM -0500, Dan Sugalski wrote:
As I demonstrated, they are for a large (though not enormous) subset Ilya |
From [Unknown Contact. See original ticket]At 02:49 PM 1/12/00 -0500, Ilya Zakharevich wrote:
s/want to do/think they're limited to doing/; Coming from a platform with very strong asynchronous leanings (VMS), it's Dan --------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]On Wed, Jan 12, 2000 at 10:28:40AM -0500, Dan Sugalski wrote:
If it were correct, sure. But it is not. This will not "wake it", it
Then why did you mention cond_waits?
How would you know whether it is likely to do it or not? This is the Ilya |
From [Unknown Contact. See original ticket]On Wed, Jan 12, 2000 at 03:06:16PM -0500, Dan Sugalski wrote:
OS/2 also might have a nice System Exception model, but this still Ilya |
From [Unknown Contact. See original ticket]At 04:07 PM 1/12/00 -0500, Ilya Zakharevich wrote:
Which model, VMS' asyc system? Sure, some of them. There are limits to Dan --------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]On Wed, Jan 12, 2000 at 04:19:26PM -0500, Dan Sugalski wrote:
Which is basically the same as with OS/2: you cannot use any Ilya |
From [Unknown Contact. See original ticket]At 04:22 PM 1/12/00 -0500, Ilya Zakharevich wrote:
Yeah, but there really aren't any "interesting" CRTL calls. (Well, except Not that this really matters for perl, since the signal handlers won't be Dan --------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]Ilya Zakharevich (lists.p5p):
In short, you wish to deny other people the chance to be virtuous? :) -- |
From [Unknown Contact. See original ticket]Simon Cozens writes:
Do you imply that virtuousness is always a kind of lazyness? Ilya |
From @chipdudeAccording to Ilya Zakharevich:
Your point is well-taken. On the other hand, good design often comes down to taste and Sometimes the only available alternative to being vague and indirect |
From [Unknown Contact. See original ticket]On Wed, Jan 12, 2000 at 02:22:30PM -0800, Chip Salzenberg wrote:
Nobody will argue the role of metaphores and friends as vehicles of Most of the time it boils down to the question of taste, which is Ilya |
From [Unknown Contact. See original ticket]
You're overreaching there. Taste certainly *does* count, and it Oh, taste might not count so much for all people at all times, but Now if you go look at Perl, you'll see that shirking complexity and In particular, when Larry himself is the one deciding that some Left to ourselves, Ilya, neither you nor I am ever going to create While I have your attention, thank you very much for your misplaced Since you were apparently unable or unwilling to understand my point --tom "Make is like Pascal. Everyone likes it so much they can't |
From [Unknown Contact. See original ticket]It's not that easy. Any significant task will require some complexity. I don't think Ilya is enamored of complexity, I just think that he - Your resident anthropologist If I have offended anyone by the above characterizations, I do most |
From [Unknown Contact. See original ticket]Joshua N Pritikin <joshua.pritikin@db.com> writes:
I am in both camps - on the one hand it is my _impression_ that Event
Which is a weakness. Modern Tcl/Tk can at least "tolerate" multiple threads.
Which is another weakness. If Event offered a solution to perl/Tk's Win32
It may be so different that the current abstractions make no sense. I think we have a nasty case of chicken-and-egg here: Event is not finished till it can do Win32. Thus I suspect that what it really needs is ActiveState (e.g. Sarathy), -- |
From [Unknown Contact. See original ticket]Larry Wall <larry@wall.org> writes:
The main drawback of ptked is the load time ;-) -- |
From @gsarOn Sun, 16 Jan 2000 15:37:16 GMT, Nick Ing-Simmons wrote:
I haven't had time to do anything serious with the Event stuff, but Let's keep this on the agenda for the 5.7.x development series. Sarathy |
From [Unknown Contact. See original ticket]On Sun, Jan 16, 2000 at 03:37:16PM +0000, nick@ing-simmons.net wrote:
Yes, that is the situation. I am happy to add whatever thread support -- |
Migrated from rt.perl.org#1955 (status was 'resolved')
Searchable as RT1955$
The text was updated successfully, but these errors were encountered: