Re: DBD::Oracle
Yanick Champoux wrote: > 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... Ah, I can explain what's going on there. If you give Perl `system` a single argument, it looks at the contents of that string, and decides whether it's a "trivial" command. Trivial commands in this sense are, roughly, those that contain no awkward punctuation characters — which would imply that the command needs to be executed by a shell. If Perl thinks no shell is needed, it optimises by executing the command directly, saving a shell process. Otherwise, it passes the command to the appropriate shell as desired. In this case, if you do `system "exit 1;"`, the semicolon forces `system` to pass the command to a shell, and everything works as expected. On the other hand, `system "exit 1"` with no semicolon is executed directly. But there's no command named `exit` — it's a shell builtin (and has to be). So `system` is giving you the behaviour you get in the "command not found" case, namely a negative return value. -- Aaron Crane ** http://aaroncrane.co.uk/
Re: speeding up XS_DBI_dispatch()
On 11 February 2012 14:55, Tim Bunce wrote: > On Fri, Feb 10, 2012 at 04:48:38PM -0800, Jan Dubois wrote: >> 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. I am not so sure. During a clone, the internals are potentially in an indeterminate state. I could see it being argued that the only thing you should be doing during a clone is cloning, not environment lookups. But of course, if we can fix it that would be better. And the above is pure speculation. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Re: speeding up XS_DBI_dispatch()
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.
Re: speeding up XS_DBI_dispatch()
On 11/02/2012 00:48, 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?
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
Nice find Jan. Commenting out the getenv works for me.
Martin
