On 11/02/2012 13:55, Tim Bunce wrote:
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?
Seems to work fine.
I have other tests failing (85gofer.t) but it is nothing to do with this
issue and I'm looking into them.
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.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
