Mailing List Archive: Perl: porters

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678

Index | Next | Previous | View Threaded

perlbug-followup at perl

Apr 8, 2012, 11:45 AM

Post #1 of 17 (198 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678

forgot to add, the test program the above post was done with is "-e
"eval q{fork}""

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 8, 2012, 12:30 PM

Post #2 of 17 (188 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Sun Apr 08 11:45:45 2012, bulk88 wrote:
> forgot to add, the test program the above post was done with is "-e
> "eval q{fork}""
The bug is actually that there is no pad in the interpreter (null
pointer). Its an assert thats failing, "ASSERT_CURPAD_ACTIVE("pad_sv");"
in Perl_pad_sv. The assert is conditional on DEBUGGING flag in pad.h
___________________________________________________
#ifdef DEBUGGING
# define ASSERT_CURPAD_LEGAL(label) \
pad_peg(label); \
if (PL_comppad ? (AvARRAY(PL_comppad) != PL_curpad) : (PL_curpad !=
0)) \
Perl_croak(aTHX_ "panic: illegal pad in %s: 0x%"UVxf"[0x%"UVxf"]",\
label, PTR2UV(PL_comppad), PTR2UV(PL_curpad));

# define ASSERT_CURPAD_ACTIVE(label) \
pad_peg(label); \
if (!PL_comppad || (AvARRAY(PL_comppad) != PL_curpad)) \
Perl_croak(aTHX_ "panic: invalid pad in %s: 0x%"UVxf"[0x%"UVxf"]",\
label, PTR2UV(PL_comppad), PTR2UV(PL_curpad));
#else
# define ASSERT_CURPAD_LEGAL(label)
# define ASSERT_CURPAD_ACTIVE(label)
#endif
_____________________________________________________
So some people get the top_env panic, others get access vio.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

Attachments:

forkbugdb2.PNG (56.9 KB)

perlbug-followup at perl

Apr 8, 2012, 1:17 PM

Post #3 of 17 (188 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Sun Apr 08 12:30:34 2012, bulk88 wrote:
> The bug is actually that there is no pad in the interpreter (null
> pointer).

On my perl 5.12, curpad and comppad are non-null at the beginning (
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/win32/perlhost.h#l1696
) of the child thread. On perl 5.15 curpad and comppad are null at the
beginning of the child thread. Problem is in parent thread.

At
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/win32/perlhost.h#l1823
in child interpreter in 5.15, curpad is null after perl_clone_using, it
is non-null in 5.12.

At
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/sv.c#l13284
in 5.12, curpad and compad get set to non-poison/garbage pointers. In
5.15 PAD_CLONE_VARS (
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/pad.h#l339
) sets from poison/garbage to null pointers.

I might research it more today, or not, IDK. If someone is else is
faster than me, good.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 8, 2012, 2:07 PM

Post #4 of 17 (189 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Sun Apr 08 13:17:36 2012, bulk88 wrote:
comppad isn't found in the pointer table, this returns null in 5.15
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/sv.c#l11551

In 5.12, curpad is added with the following callstack.
___________________________________________________________
perl512.dll!Perl_ptr_table_store(interpreter * my_perl=0x008368b4,
ptr_tbl * const tbl=0x00838ec4, const void * const oldsv=0x0082b35c,
void * const newsv=0x0084e564) Line 10799 C
perl512.dll!Perl_sv_dup(interpreter * my_perl=0x008368b4, const sv *
const sstr=0x0082b35c, clone_params * const param=0x0006fa48) Line
10999 + 0x1b C
perl512.dll!S_sv_dup_inc_multiple(interpreter * my_perl=0x008368b4, sv
* const * source=0x0082d3f0, sv * * dest=0x0085a9b8, int items=0,
clone_params * const param=0x0006fa48) Line 10948 + 0x19 C
perl512.dll!Perl_sv_dup(interpreter * my_perl=0x008368b4, const sv *
const sstr=0x00397e9c, clone_params * const param=0x0006fa48) Line
11191 + 0x19 C
perl512.dll!Perl_sv_dup(interpreter * my_perl=0x008368b4, const sv *
const sstr=0x00397e6c, clone_params * const param=0x0006fa48) Line
11284 + 0x57 C
> perl512.dll!perl_clone_using(interpreter * proto_perl=0x00394194,
unsigned long flags=1, IPerlMem * ipM=0x00286074, IPerlMem *
ipMS=0x00286090, IPerlMem * ipMP=0x002860ac, IPerlEnv * ipE=0x002860c8,
IPerlStdIO * ipStd=0x00286100, IPerlLIO * ipLIO=0x0028619c, IPerlDir *
ipD=0x00286204, IPerlSock * ipS=0x00286230, IPerlProc * ipP=0x002862e0)
Line 12230 + 0x17 C
perl512.dll!PerlProcFork(IPerlProc * piPerl=0x00285eb0) Line 1859 +
0x65 C++
perl512.dll!Perl_pp_fork(interpreter * my_perl=0x00394194) Line
4082 + 0x16 C
perl512.dll!Perl_runops_debug(interpreter * my_perl=0x00394194) Line
2049 + 0xd C
perl512.dll!S_run_body(interpreter * my_perl=0x00394194, long
oldscope=1) Line 2308 + 0xd C
perl512.dll!perl_run(interpreter * my_perl=0x00394194) Line 2233 + 0xd C
perl512.dll!RunPerl(int argc=3, char * * argv=0x00282478, char * *
env=0x00285148) Line 270 + 0x9 C++
perl.exe!main(int argc=3, char * * argv=0x00282478, char * *
env=0x00282d68) Line 23 + 0x12 C
perl.exe!mainCRTStartup() Line 398 + 0xe C
kernel32.dll!_BaseProcessStart@4() + 0x23
_______________________________________________________________
In 5.12, the line that triggered the cloning is
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/sv.c#l13282
" PL_compcv = cv_dup(proto_perl->Icompcv, param);".
Somewhere between 5.12 and 5.15, sv_dup was gutted and turned into
sv_dup_common.

At this point,
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/sv.c#l13282
, in 5.12 compcv of parent interp is non-null, in 5.15 compcv of parent
interp is null. Therefore it wont get cloned into the "pointer table".

On entry to perl_clone_using
at
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/sv.c#l12779
, in 5.12, parent interp has non-null compcv. In 5.15, in parent interp
has null compcv.

On entry to pp_fork at
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/pp_sys.c#l3980
in 5.12 compcv in my_perl/parent interp is non null, in 5.15 it is null.

This is now an opcode problem.

_____________________________________________
perl512.dll!Perl_pp_fork(interpreter * my_perl=0x00394194) Line 4049 C
perl512.dll!Perl_runops_debug(interpreter * my_perl=0x00394194) Line
2049 + 0xd C
perl512.dll!S_run_body(interpreter * my_perl=0x00394194, long
oldscope=1) Line 2308 + 0xd C
perl512.dll!perl_run(interpreter * my_perl=0x00394194) Line 2233 + 0xd C
perl512.dll!RunPerl(int argc=3, char * * argv=0x00282478, char * *
env=0x00285148) Line 270 + 0x9 C++
perl.exe!main(int argc=3, char * * argv=0x00282478, char * *
env=0x00282d68) Line 23 + 0x12 C
perl.exe!mainCRTStartup() Line 398 + 0xe C
> kernel32.dll!_BaseProcessStart@4() + 0x23
_________________________________________________
> perl515.dll!Perl_pp_fork(interpreter * my_perl=0x00384194) Line 4035 C
perl515.dll!Perl_runops_debug(interpreter * my_perl=0x00384194) Line
2119 + 0xd C
perl515.dll!S_run_body(interpreter * my_perl=0x00384194, long
oldscope=1) Line 2400 + 0xd C
perl515.dll!perl_run(interpreter * my_perl=0x00384194) Line 2318 + 0xd C
perl515.dll!RunPerl(int argc=3, char * * argv=0x00342478, char * *
env=0x00345148) Line 270 + 0x9 C++
perl.exe!main(int argc=3, char * * argv=0x00342478, char * *
env=0x00342d68) Line 23 + 0x12 C
perl.exe!mainCRTStartup() Line 398 + 0xe C
kernel32.dll!_BaseProcessStart@4() + 0x23
___________________________________________________

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 8, 2012, 2:24 PM

Post #5 of 17 (186 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Sun Apr 08 13:17:36 2012, bulk88 wrote:
> I might research it more today, or not, IDK. If someone is else is
> faster than me, good.

Thank you very much for researching this. I’m afraid I don’t have
access to a (functional) Windows with a compiler, so I won’t be any
faster. :-)

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 8, 2012, 2:39 PM

Post #6 of 17 (189 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On perl 5.12 PP(pp_entereval) opcode sets compcv. On perl 5.15 it doesn't.

entereval calls, S_doeval. On 5.15, at, hmm, head git 5.15 doesn't match
my 5.15.9, in S_doeval, the line " else if (!startop)
LEAVE_with_name("evalcomp");" sets perl 5.15 compcv to null.
_______________________________________________________
if (gimme != G_ARRAY) PUSHs(&PL_sv_undef);
PUTBACK;
return FALSE;
}
else if (!startop) LEAVE_with_name("evalcomp");
CopLINE_set(&PL_compiling, 0);
if (startop) {
*startop = PL_eval_root;
} else
SAVEFREEOP(PL_eval_root);

DEBUG_x(dump_eval());
_____________________________________________________

In both 5.12 and 5.15, startop is null pointer on entry and remains
false throughout the body of S_doeval. In the calling function
"pp_entereval", startop parameter is const NULL pointer in both 5.12 and
5.15. Since 5.12 doesn't have " else if (!startop)
LEAVE_with_name("evalcomp");", compcv can not be set to null and 5.12
works without any problems. I think im probably done analyzing this.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 8, 2012, 3:12 PM

Post #7 of 17 (187 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

Here is where in LEAVE_with_name compcv is set to null. I guess a NULL
compcv cv is being saved onto the save stack.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

Attachments:

forkbugdb3.PNG (61.1 KB)

perlbug-followup at perl

Apr 8, 2012, 3:28 PM

Post #8 of 17 (188 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Sun Apr 08 15:12:29 2012, bulk88 wrote:
> Here is where in LEAVE_with_name compcv is set to null. I guess a NULL
> compcv cv is being saved onto the save stack.

compcv is null on entry to S_doeval in 5.15 and 5.12.

I will guess the bug is either a lack of a extra mortal/scope/save, or
the "else if (!startop) LEAVE_with_name("evalcomp");". I can't write a
fix since I dont know enough about perl interp internals, or why the
LEAVE_with_name is there in the first place. I'm done here. Not going to
put any more replys here unless someone else responds.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 9, 2012, 6:18 PM

Post #9 of 17 (188 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Sun Apr 08 15:28:23 2012, bulk88 wrote:
> On Sun Apr 08 15:12:29 2012, bulk88 wrote:
> > Here is where in LEAVE_with_name compcv is set to null. I guess a NULL
> > compcv cv is being saved onto the save stack.
>
> compcv is null on entry to S_doeval in 5.15 and 5.12.

The change that caused this crash (see subject) intentionally restored
compcv to its previous value before exiting S_doeval, so that XS code
run from sub foo { BEGIN { eval "xs_code()" } } would be able to see foo
in PL_compcv (since it is the currently compiling sub).

>
> I will guess the bug is either a lack of a extra mortal/scope/save, or
> the "else if (!startop) LEAVE_with_name("evalcomp");".

The purpose of the evalcomp scope (which I added earlier) is to undo
localisations that happen only for the sake of compiling the eval, so
that the eval can affect the calling compilation scope, making eval
'$^H{foo} = "bar"' equivalent to eval { $^H{foo} = "bar" }.

Earlier, you wrote:

> At
>
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/sv.c#l13284
> in 5.12, curpad and compad get set to non-poison/garbage pointers. In
> 5.15 PAD_CLONE_VARS (
>
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/pad.h#l339
> ) sets from poison/garbage to null pointers.

That may be the problem.

What happens if you apply the attached patch? This is a bit of a stab
in the dark, as I don’t understand in detail how PL_comppad is used.

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

Attachments:

open_wuMoVo3U.txt (0.57 KB)

perlbug-followup at perl

Apr 9, 2012, 8:38 PM

Post #10 of 17 (188 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Mon Apr 09 19:59:06 2012, jdb wrote:
> On Mon, 09 Apr 2012, Father Chrysostomos via RT wrote:
> > What happens if you apply the attached patch? This is a bit of a stab
> > in the dark, as I don’t understand in detail how PL_comppad is used.
>
> Excellent, this does indeed fix the crashes!

I’ve pushed it to the smoke-me/109718 branch. Let’s see what the
smokers make of it.

Believe or not, I’ve not even tried compiling it yet. :-)

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 9, 2012, 10:27 PM

Post #11 of 17 (189 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Mon Apr 09 20:38:49 2012, sprout wrote:
> On Mon Apr 09 19:59:06 2012, jdb wrote:
> > On Mon, 09 Apr 2012, Father Chrysostomos via RT wrote:
> > > What happens if you apply the attached patch? This is a bit of a stab
> > > in the dark, as I don’t understand in detail how PL_comppad is used.
> >
> > Excellent, this does indeed fix the crashes!
>
> I’ve pushed it to the smoke-me/109718 branch. Let’s see what the
> smokers make of it.

Could this getppid.t failure have anything to do with it, or is it
unrelated?

On Apr 9, 2012, at 9:53 PM, George Greer wrote:
>
> Smoke logs available at http://m-l.org/~perl/smoke/perl/
>
> Automated smoke report for 5.15.9 patch
66dd4310c0fc5d85e51003ee57996343616e1253 v5.15.9-124-g66dd431
> zwei: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (GenuineIntel 2668MHz)
(x86_64/8 cpu)
> on linux - 3.0.0-17-generic [debian]
> using clang version 4.2.1 Compatible Clang Compiler
> smoketime 57 minutes 42 seconds (average 14 minutes 26 seconds)
>
> Summary: FAIL(F)
>
> O = OK F = Failure(s), extended report at the bottom
> X = Failure(s) under TEST but not under harness
> ? = still running or test results not (yet) available
> Build failures during: - = unknown or N/A
> c = Configure, m = make, M = make (after miniperl), t = make test-prep
>
> v5.15.9-124-g66dd431 Configuration (common) -A -Dcc=clang
append:ccflags=" -fcatch-undefined-behavior -DPERL_POISON "
> ----------- ---------------------------------------------------------
> O O O O
> O O F O -Duseithreads
> | +--------- -DDEBUGGING
> +----------- no debugging
>
>
> Locally applied patches:
> uncommitted-changes
> SMOKE66dd4310c0fc5d85e51003ee57996343616e1253
>
> Testsuite was run only with 'harness'
>
> Failures: (common-args) -A -Dcc=clang append:ccflags="
-fcatch-undefined-behavior -DPERL_POISON "
> [default] -DDEBUGGING -Duseithreads
> ../t/op/getppid.t...........................................FAILED
> 6-7

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 10, 2012, 3:55 AM

Post #12 of 17 (191 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Mon Apr 09 18:18:56 2012, sprout wrote:
> On Sun Apr 08 15:28:23 2012, bulk88 wrote:
> > At
> >
>
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/sv.c#l13284
> > in 5.12, curpad and compad get set to non-poison/garbage pointers.
> In
> > 5.15 PAD_CLONE_VARS (
> >
>
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/pad.h#l339
> > ) sets from poison/garbage to null pointers.
>
> That may be the problem.
>
> What happens if you apply the attached patch? This is a bit of a stab
> in the dark, as I don’t understand in detail how PL_comppad is used.
>

I haven't tested your fix. compad becomes the pad in win32_start_child.
It can't be null, it will fail the asset/crash in pad_sv. pad_sv is used
here
http://perl5.git.perl.org/perl.git/blob/HEAD:/win32/perlhost.h#l1726 on
entry to child thread, inside the "dTARGET;". pad_sv asserts/crashes on
null pad. Contents of comppad are set by PAD_CLONE_VARS " PL_comppad
= MUTABLE_AV(ptr_table_fetch(PL_ptr_table, proto_perl->Icomppad));" Here
is a piece of macro expanded 5.15.9 pad_sv func, DEBUGGING is on.
___________________________________________
SV *
Perl_pad_sv (PerlInterpreter * my_perl, PADOFFSET po)
{
extern int Perl___notused (void);
;
if (!(my_perl->Icomppad)
||
((((my_perl->Icomppad))->sv_u.svu_array) != (my_perl->Icurpad)))
Perl_croak (my_perl, "panic: invalid pad in %s: 0x%" "lx" "[0x%"
"lx" "]", "pad_sv",
(UV) ((my_perl->Icomppad)), (UV) ((my_perl->Icurpad)));;
____________________________________________
beginning of win32_start_child, DEBUGGING on (not sure if it means
anything here)
_____________________________________________
static DWORD __stdcall
win32_start_child(LPVOID arg)
{
PerlInterpreter *my_perl = (PerlInterpreter*)arg;
int status;
HWND parent_message_hwnd;

Perl_set_context(my_perl);
win32_checkTLS(my_perl);

((my_perl->Isys_intern).pseudo_id) = GetCurrentThreadId();
#line 1713 "c:\\perl-5.15.9\\win32\\perlhost.h"
/* create message window and tell parent about it */
parent_message_hwnd = ((my_perl->Isys_intern).message_hwnd);
((my_perl->Isys_intern).message_hwnd) = win32_create_message_window();
if (parent_message_hwnd != 0)
PostMessageA(parent_message_hwnd, ((0x0400+30)),
((my_perl->Isys_intern).pseudo_id),
(LPARAM)((my_perl->Isys_intern).message_hwnd));

/* push a zero on the stack (we are the child) */
{
SV **sp = (my_perl->Istack_sp);
SV * targ = Perl_pad_sv(my_perl, (my_perl->Iop)->op_targ);
do { Perl_sv_setiv(my_perl, targ,(IV)(0)); do { do { if
(((targ)->sv_flags & 0x00400000)) Perl_mg_set(my_perl, targ); } while
(0); (*++sp = (targ)); } while (0); } while (0);
(my_perl->Istack_sp) = sp;
}

/* continue from next op */
(my_perl->Iop) = (my_perl->Iop)->op_next;
_________________________________________________
croak can't report the actual error ("invalid pad") that since there is
no scope to jump back to in this child interp, and croak instead dies
with "top_env".

The reason why compad is null/not found in pointer table is because
compcv was null when cv_dup aka sv_dup was called on it, read above
again, ill try to rephrase it here again,

In 5.12, the line that triggered the cloning is
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/sv.c#l13282
" PL_compcv = cv_dup(proto_perl->Icompcv, param);".
___________________________________________________
SV *
Perl_sv_dup(pTHX_ const SV *sstr, CLONE_PARAMS* param)
{
dVAR;
SV *dstr;

PERL_ARGS_ASSERT_SV_DUP;

if (!sstr)
return NULL;
____________________________________________________
Now me comparing 5.12 to 5.15, and me assuming 5.12's design is "right"
and 5.15's design is "wrong", might be a red herring here, but its the
only way I can discuss anything here since I an not an interp person.

If compcv is null, sv_dup does nothing, so comppad wont be added to the
pointer table, I believe this is true for 5.15 and 5.12. In perl 5.12,
the pad is duped and will be added to the pointer table by PAD_DUP macro
in sv_dup when sv_dup is done on a CV, here
http://perl5.git.perl.org/perl.git/blob/e42956688f2e0df936f1a42811962946e4e185bf:/sv.c#l11329
(this link isn't 5.12), in 5.15 this line doesn't exit anymore (PAD_DUP
replaced with a func), functionality is still there I think. I didn't
test this with a debugger for my guess about 5.15 that sv_dup dupes the
pad when sv_dup gets a CV.

I will try to run the patch sometime in the next day or 2 and i'll give
an update.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 10, 2012, 6:04 AM

Post #13 of 17 (186 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Tue Apr 10 04:30:45 2012, davem wrote:
> On Mon, Apr 09, 2012 at 06:18:57PM -0700, Father Chrysostomos via RT
> wrote:
> > What happens if you apply the attached patch? This is a bit of a
> stab
> > in the dark, as I don’t understand in detail how PL_comppad is used.
> > - PL_comppad = MUTABLE_AV(ptr_table_fetch(PL_ptr_table,
> proto_perl->Icomppad)); \
> > + PL_comppad = av_dup(proto_perl->Icomppad, param); \
>
> I don't think that's the most correct fix. The intention is that
> whatever
> is the currently executing CV should be cloned, and as a side-effect,
> its
> pad gets cloned. The PL_comppad code is then just updating the pointer
> on
> the assumption that someone else should already have cloned the CV.
> In the past, this worked because PL_compcv (which only has compile-
> time
> meaning) just happened to get left-over pointing at the currently
> executing eval CV.
>
> I suspect the correct fix is to ensure the current CV is always
> cloned;
> possibly by making sure blk_eval.cv is cloned within the CXt_EVAL
> branch
> of Perl_cx_dup, then after this line:
> PL_curstackinfo = si_dup(proto_perl->Icurstackinfo, param);
> repeating the PAD_CLONE_VARS to ensure that PL_comppad gets updated?
>
> Do you want to run with this, or should I?

If you are offering to take over, please go ahead. :-)

I need to ask the Windows users: Does perl -efork crash?

If it doesn’t, can you (Dave Mitchell) explain why not?

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 10, 2012, 6:07 AM

Post #14 of 17 (188 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Tue Apr 10 03:55:30 2012, bulk88 wrote:
> The reason why compad is null/not found in pointer table is because
> compcv was null when cv_dup aka sv_dup was called on it, read above
> again, ill try to rephrase it here again,

I understood that. I realise I may have been a bit terse.

>
> In 5.12, the line that triggered the cloning is
>
http://perl5.git.perl.org/perl.git/blob/03d9f026ae253e9e69212a3cf6f1944437e9f070:/sv.c#l13282
> " PL_compcv = cv_dup(proto_perl->Icompcv, param);".
> ___________________________________________________
> SV *
> Perl_sv_dup(pTHX_ const SV *sstr, CLONE_PARAMS* param)
> {
> dVAR;
> SV *dstr;
>
> PERL_ARGS_ASSERT_SV_DUP;
>
> if (!sstr)
> return NULL;
> ____________________________________________________
> Now me comparing 5.12 to 5.15, and me assuming 5.12's design is
> "right"
> and 5.15's design is "wrong", might be a red herring here, but its the
> only way I can discuss anything here since I an not an interp person.
>
> If compcv is null, sv_dup does nothing, so comppad wont be added to
> the
> pointer table, I believe this is true for 5.15 and 5.12. In perl 5.12,
> the pad is duped and will be added to the pointer table by PAD_DUP
> macro
> in sv_dup when sv_dup is done on a CV, here
>
http://perl5.git.perl.org/perl.git/blob/e42956688f2e0df936f1a42811962946e4e185bf:/sv.c#l11329
> (this link isn't 5.12), in 5.15 this line doesn't exit anymore
> (PAD_DUP
> replaced with a func), functionality is still there I think. I didn't
> test this with a debugger for my guess about 5.15 that sv_dup dupes
> the
> pad when sv_dup gets a CV.

What I was trying to say is that PL_compcv is *supposed* to be null in
that case.

The code for setting PL_comppad in the child thread was making untenable
assumptions and hence needs to be rewritten.

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 10, 2012, 1:13 PM

Post #15 of 17 (188 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

The av_dup patch worked for me. The getppid test isn't done on windows.
I have no other comments.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 10, 2012, 2:53 PM

Post #16 of 17 (189 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

On Tue Apr 10 07:08:11 2012, davem wrote:
> On Tue, Apr 10, 2012 at 12:21:30PM +0100, Dave Mitchell wrote:
> Actually, I misread a bit of code in cx_dup(); the CV *is* duplicated
> in
> the CXt_EVAL branch; which means I think your fix *is* safe and
> complete;
> it dups the pad, then later on the parent CV is also duped, and pick
> up
> the already-duped pad. So do please continue with it.

I’ve applied it as 253649d90a4.

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

perlbug-followup at perl

Apr 11, 2012, 2:11 PM

Post #17 of 17 (181 views)
Permalink

[perl #109718] fork.t fails on Win32 since v5.15.4-465-g676a678 [In reply to]

This ticket might not be completely resolved yet.

In <612945.556640625-sendEmail [at] hpwin>, Steve Hay’s smoke report says:

Failures: (common-args) -DCCTYPE=MSVC100
[default] -Duseithreads -Duselargefiles
[default] -DDEBUGGING -Duseithreads -Duselargefiles
./t/op/fork.t..............................................FAILED
24

Steve, are you able to find out when this particular failure started? I
don’t see this from any other Windows smokers.

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: resolved
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109718

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads