Re: speeding up XS_DBI_dispatch()
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. -- All wight. I will give you one more chance. This time, I want to hear no Wubens. No Weginalds. No Wudolf the wed-nosed weindeers. -- Life of Brian
Re: speeding up XS_DBI_dispatch()
On 10/02/12 10:01, 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. Have you any suggestion on how I could help debug this? I do have A windows machine which exhibits the problem. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: speeding up XS_DBI_dispatch()
On 10/02/12 10:54, Tim Bunce wrote: On Thu, Feb 09, 2012 at 09:53:08PM +, Martin J. Evans wrote: Something between 1.616_901 and 1.616_902 changed which breaks fork() in DBI on Windows. Ah, 1.616_901 and 1.616_902! So unrelated to Dave's method cache work. See if this works: - static int use_xsbypass = 1; + static int use_xsbypass = 0; Think I already tried that last night by setting the env var and it made no difference. Don't have the machine to hand right now although I could try and set it up here. If not, then it's probably something to do with the dPERINTERP changes. which is my suspicion. Running with a high trace level might shed some light but a strack trace of some kind would be ideal. I tried tracing but nothing stood out - I could post the end of the trace later. Tim. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
DBD::Oracle
Preparing a new database machine ... Do I need to worry? Linux 3.1.9-1.4-desktop/#1 x86_64 Xeon(R) CPU E5645 @ 2.40GHz/2395(6) x86_64 16060 Mb SQL*Plus: Release 11.2.0.3.0 Production on Fri Feb 10 14:30:25 2012 Running make test PERL_DL_NONLAZY=1 /pro/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/000-report-versions.t .. # Testing with Perl 5.014001, /pro/bin/perl t/000-report-versions.t .. 1/? # Carp version is 1.24 # Config version is undefined # DBI version is 1.617 # Data::Dumper version is 2.131 # Devel::Peek version is 1.07 # DynaLoader version is 1.13 # Encode version is 2.44 # Exporter version is 5.66 # ExtUtils::MakeMaker version is 6.62 # Math::BigInt version is 1.997 # Oraperl version is 1.44 # Scalar::Util version is 1.23 # Test::More version is 0.98 # Thread::Semaphore version is 2.12 # strict version is 1.04 # utf8 version is 1.09 # vars version is 1.02 # warnings version is 1.12 t/000-report-versions.t .. ok t/00versions.t ... # OCI client library version: 11.2.0.3 t/00versions.t ... 1/2 # database version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production t/00versions.t ... ok t/01base.t ... ok t/10general.t 1/30 # Failed test 'system exit 1 should return 256' # at t/10general.t line 41. # got: '-1' # expected: '256' # Failed test 'system exit 0 should return 0' # at t/10general.t line 42. # got: '-1' # expected: '0' t/10general.t 3/30 # Looks like you failed 2 tests of 30. t/10general.t Dubious, test returned 2 (wstat 512, 0x200) Failed 2/30 subtests t/12impdata.t ok t/14threads.t skipped: this linux perl 5.014001 not configured to support iThreads t/15nls.t ok t/20select.t . ok t/21nchar.t .. ok t/22nchar_al32utf8.t . ok t/22nchar_utf8.t . ok t/23wide_db.t skipped: Database character set is not Unicode t/23wide_db_8bit.t ... skipped: Database character set is not Unicode t/23wide_db_al32utf8.t ... skipped: Database character set is not Unicode t/24implicit_utf8.t .. ok t/25plsql.t .. ok t/26exe_array.t .. ok t/28array_bind.t . ok t/30long.t ... ok t/31lob.t skipped: see RT#69350 t/31lob_extended.t ... ok t/32xmltype.t ok t/34pres_lobs.t .. ok t/36lob_leak.t ... ok t/38taf.t ok t/40ph_type.t ok t/50cursor.t . ok t/51scroll.t . ok t/55nested.t . ok t/56embbeded.t ... ok t/58object.t . ok t/60reauth.t . skipped: ORACLE_USERID_2 not defined. t/70meta.t ... ok t/80ora_charset.t skipped: Database is set up as US7ASCII t/rt13865.t .. ok Test Summary Report --- t/10general.t (Wstat: 512 Tests: 30 Failed: 2) Failed tests: 1-2 Non-zero exit status: 2 Files=35, Tests=2008, 27 wallclock secs ( 0.43 usr 0.05 sys + 3.73 cusr 1.75 csys = 5.96 CPU) Result: FAIL Failed 1/35 test programs. 2/2008 subtests failed. Summary of my perl5 (revision 5 version 14 subversion 1) configuration: Platform: osname=linux, osvers=2.6.37.6-0.5-desktop, archname=x86_64-linux-ld uname='linux sv05 2.6.37.6-0.5-desktop #1 smp preempt 2011-04-25 21:48:33 +0200 x86_64 x86_64 x86_64 gnulinux ' config_args='-Duse64bitall -Duselongdouble -des' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=define usemymalloc=n, bincompat5005=undef Compiler: cc='ccache cc', ccflags ='-fPIC -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fPIC -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.5.1 20101208 [gcc-4_5-branch revision 167585]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8 alignbytes=16, prototype=define Linker and Libraries: ld='ccache cc', ldflags ='-L/pro/local/lib -fstack-protector' libpth=/pro/local/lib /lib/../lib64 /usr/lib/../lib64 /lib /usr/lib /usr/local/lib /lib64 /usr/lib64 /usr/local/lib64 libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.11.3.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.11.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef,
Re: DBD::Oracle
On Fri, 10 Feb 2012 14:30:03 +, Charles Jardine c...@cam.ac.uk wrote: On 10/02/12 13:32, H.Merijn Brand wrote: Preparing a new database machine ... Do I need to worry? t/10general.t 1/30 # Failed test 'system exit 1 should return 256' # at t/10general.t line 41. # got: '-1' # expected: '256' # Failed test 'system exit 0 should return 0' # at t/10general.t line 42. # got: '-1' # expected: '0' t/10general.t 3/30 # Looks like you failed 2 tests of 30. t/10general.t Dubious, test returned 2 (wstat 512, 0x200) This symptom indicates that the system built-in function is not working. Try perl -e 'print system(exit 1;), \n' $ perl -e 'print system(exit 1;), \n' 256 If this reproduces the problem, you have something nothing to do with databases to investigate. If it doesn't reproduce the problem, it may be that Oracle is messing with the SIGCHLD signal. Are you connecting directly to the database using the bequeather? I've never heard of anything called a bequeather :) If so, try connecting via SQL*Net instead. If avoiding the bequeather fixes the problem, try putting 'bequeath_detach = yes' in your sqlnet.ora file. This should allow you to use the bequeather and system at the same time. above test was without TWO_TASK. Using the listener, I get All tests successful. Files=35, Tests=2008, 31 wallclock secs ( 0.40 usr 0.04 sys + 3.69 cusr 1.28 csys = 5.41 CPU) Result: PASS PERL_DL_NONLAZY=1 /pro/bin/perl -Iblib/lib -Iblib/arch test.pl -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle
On 02/10/12 09:30, Charles Jardine wrote: t/10general.t Dubious, test returned 2 (wstat 512, 0x200) This symptom indicates that the system built-in function is not working. Try perl -e 'print system(exit 1;), \n' Hmmm... The test that is failing is is system(exit 1;), 18, 'system exit 1 should return 256'; which should be okay, but I'm suddenly thinking: on some shells 'exit' might not do what we would expect. Indeed, I just tried: $ perl -E'say system exit 1' -1 And yet the tests usually pass on my machine. I have to look at that in more details... Joy, `/anick
Re: DBD::Oracle
On Fri, 10 Feb 2012 09:56:59 -0500, Yanick Champoux yanick.champ...@gmail.com wrote: On 02/10/12 09:30, Charles Jardine wrote: t/10general.t Dubious, test returned 2 (wstat 512, 0x200) This symptom indicates that the system built-in function is not working. Try perl -e 'print system(exit 1;), \n' Hmmm... The test that is failing is is system(exit 1;), 18, 'system exit 1 should return 256'; which should be okay, but I'm suddenly thinking: on some shells 'exit' might not do what we would expect. Indeed, I just tried: My shell is not what most people use: % echo $SHELL $version /pro/bin/tcsh tcsh 6.17.02 (Astron) 2010-05-12 (x86_64-unknown-linux) options wide,nls,vi,kan,rh,color,ccat,filec,procura % perl -E'say system exit 1' -1 % perl -E'say system exit 0' -1 % perl -E'say system exit -1' -1 % echo $status 0 $ perl -E'say system exit 1' -1 And yet the tests usually pass on my machine. I have to look at that in more details... Joy, `/anick -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle
On 02/10/12 09:56, Yanick Champoux wrote: which should be okay, but I'm suddenly thinking: on some shells 'exit' might not do what we would expect. Indeed, I just tried: $ perl -E'say system exit 1' -1 And just to keep things interesting, I've noticed that I forgot the ending semi-colon that is in the test. But surely that won't-- $ perl -E'say system exit 1; say system exit 1;' -1 256 --make a difference... Uuuh, okay, I need to brush up my shell syntax skills. And should probably look into making that test slightly less shell-dependent. Joy, `/anick
Re: dPERINTERP/MY_CXT (was: speeding up XS_DBI_dispatch())
On Thu, Jan 26, 2012 at 12:26:44PM +, Tim Bunce wrote:
On Wed, Jan 25, 2012 at 05:37:13PM -0800, Jan Dubois wrote:
On Wed, 25 Jan 2012, Tim Bunce wrote:
On Wed, Jan 25, 2012 at 04:14:07PM +, Dave Mitchell wrote:
PS - I'm specifically being paid only to fix a performance issue on
non-threaded builds, so I won't be looking at threaded issues. But
dPERINTERP looks like bad news on threaded builds.
The dPERINTERP stuff was added by ActiveState years ago to support
MULTIPLICITY. I don't remember the details now. I do recall that driver
authors are encouraged to avoid using the DBIS macro due to the cost.
There's rarely a need now as DBI handles carry a pointer to the
dbi_state structure. The DBI::DBD docs say
Sorry, only skimming the conversation, so maybe this is obvious to
you: PERINTERP was a prototype from the 5.005 days for the MY_CXT
stuff that is now in the code. If you look at 5.8.1, then you'll see
MY_CXT being almost identical to PERINTERP in DBI. But switching to
MY_CXT should give you performance benefits on later Perl versions,
which have an improved MY_CXT implementation.
Great. Thanks Jan.
Anyone want to take a shot at that?
I attach two patches; the first replaces dPERINTERP with dMY_THX,
while the second extends this to the DBIS stuff too.
The headline figure (YMMV etc) is that on a recent threaded perl, these
two patches collectively make my mysql empty test loop twice as fast!!! :
while ($sth-fetch) { $c++ }
On a perl 5.10.0 (before dMY_THX was made much more efficient), the
speedup is less spectacular, but is still about 25%.
I'm assuming that these won't be applied until after the windows() fork
issue is fixed, so think of this email more as a preview.
The first fix is relatively straightforward, and is private to DBI.xs,
since the PERINTERP macros were kind of a prototype for MY_CXT anyway.
The second patch, which makes DBIS more efficient, is a lot more complex,
and more likely to break things (especially as it's changing a bunch of
macros that are directly #included by the DBD drivers. You may need to
bump API version numbers; I don't understand that bit.
It works by adding a C function, _dbi_state_lval(), to DBI.xs which
returns a pointer to the static(ish) dbistate struct that only DBI.xs
knows about. However, I couldn't find any way for DBD:: code to call
functions within DBI, so I did a little hack: I faked up an XS sub,
DBI::_dbi_state_lval(), whose CvXSUB points to the _dbi_state_lval
function. Since _dbi_state_lval() isn't actually an XS function,
perl-level code that tries to call DBI::_dbi_state_lval() will crash and
burn.
If anyone knows of a more elegant way to make a function from DBI.xs
available to DBD:: code, please let me know!
Anyway, at the DBD end of things, the code extracts the address of the
function from DBI::_dbi_state_lval's CvXSUB slot, and caches it in
a static var. Then in threaded builds, DBIS expands to a call to a static
function that calls _dbi_state_lval() which returns (MY_CXT.dbi_state).
In unthreaded builds, it just returns the value of a static var as normal.
Here are some timings; remember that MY_CXT was made a lot faster in
5.10.0, so I've included timings for 5.8.9 too. As you'd expect, only the
threaded build have a significant speed-up; I think the tiny speed-ups in
the non-threaded builds are just noise.
The three timings (in sec) for the basic while($sth-fetch){$c++} loop
are for:
(1) the baseline: r15128 plus my method cache code
(2) in addition, replace dPERINTERP with dMY_CXT
(3) in addition, fix DBIS
1 2 3
- -- --
40.10 - 29.965.8.9threaded, optimised
37.62 33.98 18.965.15.7 threaded, optimised
12.85 - 12.555.8.9 unthreaded, optimised
13.41 13.46 12.975.15.6 unthreaded, optimised
The big saving between (2) and (3) is due to DBD::mysql still using DBIS;
in particular, for every fetch call.
--
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.
diff --git a/DBI.xs b/DBI.xs
index ac161f4..887111d 100644
--- a/DBI.xs
+++ b/DBI.xs
@@ -16,8 +16,6 @@
#include sys/timeb.h
# endif
-#define MY_VERSION DBI( XS_VERSION )
-
/* The XS dispatcher code can optimize calls to XS driver methods,
* bypassing the usual call_sv() and argument handling overheads.
* Just-in-case it causes problems there's an (undocumented) way
@@ -277,40 +275,24 @@ static GV* inner_method_lookup(pTHX_ HV *stash, CV *cv,
const char *meth_name)
/* --- make DBI safe for multiple perl interpreters --- */
-/* Contributed by Murray Nesbitt of ActiveState */
-/* (This pre-dates, and should be replaced by, MY_CTX) */
+/* Originally contributed by Murray Nesbitt of
Re: DBD::Oracle
On Fri, 10 Feb 2012 10:22:20 -0500, Yanick Champoux yanick.champ...@gmail.com wrote: On 02/10/12 09:56, Yanick Champoux wrote: which should be okay, but I'm suddenly thinking: on some shells 'exit' might not do what we would expect. Indeed, I just tried: $ perl -E'say system exit 1' -1 And just to keep things interesting, I've noticed that I forgot the ending semi-colon that is in the test. But surely that won't-- $ perl -E'say system exit 1; say system exit 1;' -1 256 % perl -E'say system exit 1; say system exit 1;' -1 256 --make a difference... Uuuh, okay, I need to brush up my shell syntax skills. And should probably look into making that test slightly less shell-dependent. Joy, `/anick -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: dPERINTERP/MY_CXT (was: speeding up XS_DBI_dispatch())
On Fri, Feb 10, 2012 at 03:27:24PM +, Dave Mitchell wrote:
On Thu, Jan 26, 2012 at 12:26:44PM +, Tim Bunce wrote:
I attach two patches; the first replaces dPERINTERP with dMY_THX,
while the second extends this to the DBIS stuff too.
The headline figure (YMMV etc) is that on a recent threaded perl, these
two patches collectively make my mysql empty test loop twice as fast!!! :
while ($sth-fetch) { $c++ }
On a perl 5.10.0 (before dMY_THX was made much more efficient), the
speedup is less spectacular, but is still about 25%.
That's great news!
I'm assuming that these won't be applied until after the windows() fork
issue is fixed, so think of this email more as a preview.
*nods*
[...]
If anyone knows of a more elegant way to make a function from DBI.xs
available to DBD:: code, please let me know!
I hope to take a proper look in the next day or so.
1 2 3
- -- --
40.10 - 29.965.8.9threaded, optimised
37.62 33.98 18.965.15.7 threaded, optimised
12.85 - 12.555.8.9 unthreaded, optimised
13.41 13.46 12.975.15.6 unthreaded, optimised
Most excellent!
The big saving between (2) and (3) is due to DBD::mysql still using DBIS;
in particular, for every fetch call.
That should be a good reminder to driver authors to avoid using DBIS!
Thanks again Dave.
Tim.
Re: DBD::Oracle
On 10/02/12 14:56, H.Merijn Brand wrote: On Fri, 10 Feb 2012 14:30:03 +, Charles Jardine c...@cam.ac.uk wrote: On 10/02/12 13:32, H.Merijn Brand wrote: Preparing a new database machine ... Do I need to worry? t/10general.t 1/30 # Failed test 'system exit 1 should return 256' # at t/10general.t line 41. # got: '-1' # expected: '256' # Failed test 'system exit 0 should return 0' # at t/10general.t line 42. # got: '-1' # expected: '0' t/10general.t 3/30 # Looks like you failed 2 tests of 30. t/10general.t Dubious, test returned 2 (wstat 512, 0x200) This symptom indicates that the system built-in function is not working. Try perl -e 'print system(exit 1;), \n' $ perl -e 'print system(exit 1;), \n' 256 If this reproduces the problem, you have something nothing to do with databases to investigate. If it doesn't reproduce the problem, it may be that Oracle is messing with the SIGCHLD signal. Are you connecting directly to the database using the bequeather? I've never heard of anything called a bequeather :) If you call $ORACLE_HOME/bin/adapters, the list will include 'BEQ'. This is the bequeather, which is the adapter used to connect to a local database when ORACLE_HOME and ORACLE_SID are specified and TWO_TASK is not. The BEQ adapter is inconsistent with the with perl built-ins which use fork or popen unless you put 'bequeath_detach = yes' in sqlnet.ora. It is a pity that this sqlnet.ora option is not the default. If so, try connecting via SQL*Net instead. If avoiding the bequeather fixes the problem, try putting 'bequeath_detach = yes' in your sqlnet.ora file. This should allow you to use the bequeather and system at the same time. above test was without TWO_TASK. Using the listener, I get All tests successful. Files=35, Tests=2008, 31 wallclock secs ( 0.40 usr 0.04 sys + 3.69 cusr 1.28 csys = 5.41 CPU) Result: PASS PERL_DL_NONLAZY=1 /pro/bin/perl -Iblib/lib -Iblib/arch test.pl -- Charles Jardine - Computing Service, University of Cambridge c...@cam.ac.ukTel: +44 1223 334506, Fax: +44 1223 334679
RE: dPERINTERP/MY_CXT (was: speeding up XS_DBI_dispatch())
On Fri, 10 Feb 2012, Tim Bunce wrote: On Fri, Feb 10, 2012 at 03:27:24PM +, Dave Mitchell wrote: If anyone knows of a more elegant way to make a function from DBI.xs available to DBD:: code, please let me know! I hope to take a proper look in the next day or so. The standard way nowadays seems to be to use ExtUtils::Depends. I'm not convinced though that it is any more elegant than the method you are already using. An example module using ExtUtils::Depends is B::Hooks::OP::Check. It is important to also list all exported functions in the FUNCLIST parameter to MakeMaker; otherwise the symbols will not be exported on AIX and Windows. Personally I've just added names to FUNCLIST, and then called dlopen/dlsym or LoadLibrary/GetProcAddress on the embedding side (not actually another module, but an app hosting a Perl interpreter). Ideally you should be able to do this with the DynaLoader dl_load_file() and dl_find_symbol() functions, but I found some claims (in the FFI module docs) that this has problems on Windows. I don't know what those problems are, but it looks like dl_load_file() on Windows will return a handle to the current executable when the requested library cannot be found. I have no clue why it is doing that. So, in summary, I think the current approach isn't such a bad solution at all. :) Cheers, -Jan
Re: DBD::Oracle
On Fri, Feb 10, 2012 at 07:03:09PM +0100, H.Merijn Brand wrote: On Fri, 10 Feb 2012 17:28:11 +, Charles Jardine c...@cam.ac.uk wrote: If this reproduces the problem, you have something nothing to do with databases to investigate. If it doesn't reproduce the problem, it may be that Oracle is messing with the SIGCHLD signal. Are you connecting directly to the database using the bequeather? I've never heard of anything called a bequeather :) If you call $ORACLE_HOME/bin/adapters, the list will include 'BEQ'. This is the bequeather, which is the adapter used to connect to a local database when ORACLE_HOME and ORACLE_SID are specified and TWO_TASK is not. The BEQ adapter is inconsistent with the with perl built-ins which use fork or popen unless you put 'bequeath_detach = yes' in sqlnet.ora. It is a pity that this sqlnet.ora option is not the default. All tests then pass I'm sure a patch to the docs, expressing the above, would be welcome. Tim.
RE: speeding up XS_DBI_dispatch()
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
