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: