On Fri, 10 Feb 2012, Dave Mitchell wrote:
> On Thu, Feb 09, 2012 at 11:10:17PM +0100, demerphq wrote:
> > Well perls fork() relies on threaded perl so it could very easily be
> > Dave's patch. Dave do you have access to a win32 build environment?
>
> I'm afraid not.
The problem is due to the getenv() call during interpreter cloning.
On Windows Perl keeps a virtual host environment for each interpreter,
with its own cwd, and its own set of environment variables. I don't
have time to figure out _why_ this is an issue, but maybe you can check
the environment variable during the BOOT section and just set a global
variable instead, to work around this issue?
if (getenv("PERL_DBI_XSBYPASS"))
use_xsbypass = atoi(getenv("PERL_DBI_XSBYPASS"));
On my old Windows 2000 system the test would simply abort with the
message "abnormal program termination". I was just guessing that
this is somehow triggered by the abort() function in the C runtime.
Setting a breakpoint on it confirms it, even though the stack trace
looks incomplete (I don't see PerlEnvGetenv() calling abort() directly):
MSVCRT!abort
perl514!PerlEnvGetenv+0x13 [perlhost.h @ 462]
DBI!dbi_bootinit+0x276 [DBI.xs @ 468]
DBI!XS_DBI__clone_dbis+0x71 [DBI.c @ 4280]
perl514!Perl_pp_entersub+0x701 [..\pp_hot.c @ 3049]
perl514!Perl_runops_standard+0xc [..\run.c @ 41]
perl514!Perl_call_sv+0x195 [perl.c @ 2633]
perl514!perl_clone_using+0x18ad [..\sv.c @ 13422]
perl514!PerlProcFork+0x89 [perlhost.h @ 1854]
perl514!Perl_pp_fork+0x42 [..\pp_sys.c @ 4044]
perl514!Perl_runops_standard+0xc [..\run.c @ 41]
perl514!S_run_body+0xf5 [perl.c @ 2351]
perl514!perl_run+0x179 [perl.c @ 2269]
perl514!RunPerl+0xed [perllib.c @ 270]
perl!main+0x12 [perlmain.c @ 22]
perl!mainCRTStartup+0xe3
KERNEL32!BaseProcessStart+0x3d
Anyways, I would suggest trying a workaround by moving the getenv()
call outside the cloning operation.
Cheers,
-Jan
