On Fri, Feb 10, 2012 at 04:48:38PM -0800, Jan Dubois wrote:
> 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?
When called from BOOT dbi_bootinit() gets passed a NULL parent_dbis
parameter, but when called from CLONE it's not null, so this might be a
good fix:
@@ -579,7 +579,10 @@
gv_fetchpv("DBI::lasth", GV_ADDMULTI, SVt_PV);
gv_fetchpv("DBI::rows", GV_ADDMULTI, SVt_PV);
- if (getenv("PERL_DBI_XSBYPASS"))
+ /* we only need to check the env var on the initial boot
+ * which is handy because it can core dump during CLONE on windows
+ */
+ if (!parent_dbis && getenv("PERL_DBI_XSBYPASS"))
use_xsbypass = atoi(getenv("PERL_DBI_XSBYPASS"));
}
Martin, could you try that?
> 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]
>
> Anyways, I would suggest trying a workaround by moving the getenv()
> call outside the cloning operation.
Hopefully the above will do the trick. Meanwhile, aborting if getenv is
called during a CLONE sure seems like a bug worthy of a ticket for p5p.
Thanks Jan!
Tim.
