-
Notifications
You must be signed in to change notification settings - Fork 555
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
Problem killing a pseudo-forked child on Win32 #8889
Comments
From @steve-m-hayCreated by steveh@Mugwump.uk.radan.comThe test program below doesn't work under bleadperl (currently at patchlevel 31123) on Win32. I believe the failure first occurred at patchlevel 29569. Under perl-5.8.7 it behaves as expected:
but under bleadperl (built in debug mode) the kill fails:
and under bleadperl built in release mode it crashes too:
This problem has been seen and discussed on perl5-porters in the past. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-12/msg00342.html my $child;
BEGIN {
$child = fork;
die "Fork failed" unless defined $child;
if (!$child) {
$SIG{INT} = sub {
print "Child $$ caught INT: exiting...\n";
exit;
};
sleep 2;
print "Child $$ exiting...\n";
exit;
}
}
print "Parent $$ forked child $child OK\n";
print "Parent $$ killing child $child...\n";
kill 'INT', $child
or print "Parent $$ failed to kill child $child: $!\n";
print "Parent $$ exiting...\n";
exit; Perl Info
|
From @iabyn[I've changed the subject line to match the new bug report filed On Tue, Jan 16, 2007 at 09:04:23AM +0000, Steve Hay wrote:
Looking at the chunk of code where it decides to set errno = EINVAL 5.8.7:
blead:
This seems to relate to testing whether the thread you're sending a I then see that the loop which waits for the thread to initialise *will hwnd = w32_pseudo_child_message_hwnds[child]; within the loop. Whether this would fix the problem of kill() returning "Invalid argument", I Dave -- |
The RT System itself - Status changed from 'new' to 'open' |
From @nwc10On Thu, May 03, 2007 at 10:39:23PM +0100, Dave Mitchell wrote:
IIRC that change is binary incompatible, because it adds a member: @@ -388,10 +408,11 @@
child_tab * children;
#ifdef USE_ITHREADS
DWORD pseudo_id;
- child_tab * pseudo_children;
+ pseudo_child_tab * pseudo_children;
#endif
void * internal_host;
struct thread_intern thr_intern;
+ HWND message_hwnd;
UINT timerid;
unsigned poll_count;
Sighandler_t sigtable[SIG_SIZE]; in the middle of a structure in a public header file. Nicholas Clark |
From @steve-m-hayDave Mitchell wrote:
It does indeed fix the kill() problem (and all the tests still pass), so The "Free to wrong pool" error remains, though, so I'll leave the bug -- |
From @janduboisOn Thu, 10 May 2007, Steve Hay wrote:
The error happens because the memory freed by line 823 in perl.c has not CopFILE_free(&PL_compiling); This happens in the child "process", not the main one. Currently this looks like an optimizer bug to me: When I compile with -Od Cheers, |
From @janduboisOn Thu, 10 May 2007, Steve Hay wrote:
I just looked at this again and realized that you are calling fork() Cheers, |
From @jdheddenSteve Hay wrote:
Jan Dubois wrote:
Creating threads in BEGIN blocks does work, although in some cases it |
From @cruciallyOn May 11, 2007, at 6:50 PM, Jerry D. Hedden wrote:
Does it reliably work in windows which has different memory pools for Artur |
From @steve-m-hayJan Dubois wrote:
I don't know what's supposed to work and what isn't, but the warning in http://search.cpan.org/~rgarcia/perl-5.9.4/pod/perlfork.pod#CAVEATS_AND_LIMITATIONS Of course, in my particular test script, the child isn't even trying to -- |
From @janduboisOn Sat, 05 May 2007, Nicholas Clark wrote:
That is indeed true. I don't think any code outside the core should access A bit more worrying is that any changes to PL_sys_intern will also change However, this is only a problem when you compile without MULTIPLICITY; otherwise #define PL_sys_intern (*Perl_Isys_intern_ptr(aTHX)) and the in-memory layout of the variables doesn't matter. So I guess my question is: should we make PL_sys_intern a pointer to allow Cheers,
|
From @janduboisOn Tue, 15 May 2007, Jan Dubois wrote:
However, when not using MULTIPLICITY all symbols are resolved by the loader Cheers, |
From @bulk88On Thu May 10 18:53:53 2007, jdb wrote:
In 5.17.6 running, in -Od win32 perl: #!/usr/bin/perl -w
#use Data::Dumper;
use warnings;
#use strict;
#use Devel::Peek qw(Dump);
#use B;
my $child;
BEGIN {
$child = fork;
die "Fork failed" unless defined $child;
if (!$child) {
$SIG{INT} = sub {
print "Child $$ caught INT: exiting...\n";
exit;
};
sleep 2;
print "Child $$ exiting...\n";
exit;
}
}
print "Parent $$ forked child $child OK\n";
print "Parent $$ killing child $child...\n";
kill 'INT', $child
or print "Parent $$ failed to kill child $child: $!\n";
print "Parent $$ exiting...\n";
exit; results in the same crash if (destruct_level == 0) {
DEBUG_P(debprofdump());
#if defined(PERLIO_LAYERS)
/* No more IO - including error messages ! */
PerlIO_cleanup(aTHX);
#endif
>>>>>>>>>>>>>>>>> CopFILE_free(&PL_compiling);
/* The exit() function will do everything that needs doing. */
return STATUS_EXIT;
} Child thread, (crashed)
I think this (fork in a BEGIN) is the last remaining issue in this Console output upto the crash on 5.17.6
-- |
This thread has stalled and it looks like it is no longer related to the ticket topic. Should we close and open a new issue? IMO, fork during BEGIN just... sounds like a bad idea. new threads on windows during BEGIN sounds insane |
Close it
…On Wed, Feb 12, 2020, 09:36 Todd Rinaldo ***@***.***> wrote:
This thread has stalled and it looks like it is no longer related to the
ticket topic. Should we close an open a new issue? IMO, fork during BEGIN
just... sounds like a bad idea. new threads on windows during BEGIN sounds
insane
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8889?email_source=notifications&email_token=ABL4FW42RKDEZKAD3NFFAWLRCQCN5A5CNFSM4KT26EZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELQ7SQY#issuecomment-585234755>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABL4FWYMB6NY3ZPYDUPE63DRCQCN5ANCNFSM4KT26EZQ>
.
|
Migrated from rt.perl.org#42869 (status was 'open')
Searchable as RT42869$
The text was updated successfully, but these errors were encountered: