Re: ANNOUNCE: DBD::Oracle 1.25 Release Candidate
John Scoles wrote: Well story two of the 'two bit' version of DBD::Oracle 1.25 You can find release candidate 2 here http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.25-RC2.tar.gz This one has some minor changes from Martin Evans, though I could not find any issues with the Makfile.PL myself. and hopefully I got rid of the warning error in the .xs file for OCILobLocatorIsInit_log_stat And of course the usual bunch of POD changes. Cheers John Scoles -- New! Learn why how to love your data with Pythian's new webinar series. Topics, details register: http://www.pythian.com/webinars Sorry for taking so long to try this RC. The gzipped tar file you reference appears to be doubly gzipped BTW. OCILobLocatorIsInit problem still seems to exist for me: cc -c -I/home/oracle/instantclient_11_1//sdk/include -I/usr/local/lib/perl/5.10.0/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DVERSION=\1.25\ -DXS_VERSION=\1.25\ -fPIC -I/usr/lib/perl/5.10/CORE -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\11.1.0.6\ -DORA_OCI_102 Oracle.c Oracle.xs: In function ‘XS_DBD__Oracle__db_ora_lob_is_init’: Oracle.xs:486: warning: passing argument 4 of ‘OCILobLocatorIsInit’ makes pointer from integer without a cast /home/oracle/instantclient_11_1//sdk/include/ociap.h:7297: note: expected ‘boolean *’ but argument is of type ‘boolean’ Other than the usual 26exe_array test this seems to work ok here. Hope you enjoyed YAPC::EU 2010. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: patch full of dark magic
On Sat, 07 Aug 2010 23:12:48 +0200, David E. Wheeler
da...@kineticode.com wrote:
On Aug 7, 2010, at 2:07 AM, Cosimo Streppone wrote:
My really *ignorant* wild guess is that exit just avoids the
troubles bits of DESTROY() that are causing segfaults
without actually solving the problem.
So the issue is that it segfaults when you exit in DESTROY (which is
called during global destruction)? If so, this simple script should
segfault for you:
package Foo;
sub DESTROY { exit; }
my $foo = bless {}, 'Foo';
I couldn't try this yet, but, I don't think this
would segfault.
What I *guess* happens is that the 'exit' will cause
the script to immediately exit, skipping the nasty
part that would otherwise segfault.
Oops. Try unless to if in this bit, please:
fail 'Child should be inactive on DESTROY'
if $self-FETCH('Active');
Will try and let you know.
--
Cosimo
Re: patch full of dark magic
On Aug 9, 2010, at 8:21 AM, Cosimo Streppone wrote:
package Foo;
sub DESTROY { exit; }
my $foo = bless {}, 'Foo';
I couldn't try this yet, but, I don't think this
would segfault.
What I *guess* happens is that the 'exit' will cause
the script to immediately exit, skipping the nasty
part that would otherwise segfault.
Which nasty part?
Oops. Try unless to if in this bit, please:
fail 'Child should be inactive on DESTROY'
if $self-FETCH('Active');
Will try and let you know.
Thanks!
David
RE: patch full of dark magic
On Mon, 09 Aug 2010, Cosimo Streppone wrote:
On Sat, 07 Aug 2010 23:12:48 +0200, David E. Wheeler
da...@kineticode.com wrote:
On Aug 7, 2010, at 2:07 AM, Cosimo Streppone wrote:
My really *ignorant* wild guess is that exit just avoids the
troubles bits of DESTROY() that are causing segfaults
without actually solving the problem.
I tried to look into this on the weekend, but ran out of time. I didn't
get *any* segfaults though, neither from 16destroy.t nor from any of the
samples below.
I *did* only get 18 passing tests instead of 20 from 16destroy.t though.
So the issue is that it segfaults when you exit in DESTROY (which is
called during global destruction)? If so, this simple script should
segfault for you:
package Foo;
sub DESTROY { exit; }
my $foo = bless {}, 'Foo';
I couldn't try this yet, but, I don't think this
would segfault.
What I *guess* happens is that the 'exit' will cause
the script to immediately exit, skipping the nasty
part that would otherwise segfault.
exit() should not prevent DESTROY methods and END blocks from being called,
but I haven't checked what happens during global destruction.
The way to exit without any further processing whatsoever is POSIX::_exit().
On Windows however this will terminate both parent and child in a forking
scenario because they are threads in the same process, and POSIX::_exit()
will terminate the whole process, not just the current thread.
Oops. Try unless to if in this bit, please:
fail 'Child should be inactive on DESTROY'
if $self-FETCH('Active');
Will try and let you know.
Can you let me know Perl version is actually giving you a segfault? I tried
both 5.10.1 and 5.12.1 and neither crashed, just didn't print any results for
tests 19 and 20.
Cheers,
-Jan
Re: patch full of dark magic
On Aug 9, 2010, at 9:51 AM, Jan Dubois wrote: I tried to look into this on the weekend, but ran out of time. I didn't get *any* segfaults though, neither from 16destroy.t nor from any of the samples below. I *did* only get 18 passing tests instead of 20 from 16destroy.t though. Yes, I think we've fixed that. Hope to commit it today once I have confirmation of my patch. exit() should not prevent DESTROY methods and END blocks from being called, but I haven't checked what happens during global destruction. The way to exit without any further processing whatsoever is POSIX::_exit(). On Windows however this will terminate both parent and child in a forking scenario because they are threads in the same process, and POSIX::_exit() will terminate the whole process, not just the current thread. That seems to be what's happening. The current code calls exit() in the child thread, and that kills the parent, too, but DESTROY apparently isn't called. Which is odd. Will try and let you know. Can you let me know Perl version is actually giving you a segfault? I tried both 5.10.1 and 5.12.1 and neither crashed, just didn't print any results for tests 19 and 20. Some details in the previous thread here: groups.google.com/group/perl.dbi.dev/browse_thread/thread/f683b62a637aeb76 Cosimo was getting segfaults with: This is perl, v5.10.0 built for MSWin32-x86-multi-thread. Best, David
PgDay Stuttgart, Germany, 6-8/12/2010
The next European PostgreSQL day is going to be between 6-8 December in Stuttgart, Germany. http://www.pgday.eu/ It seems like a very cool conference and it might be interesting to offer some Perl related talks there. It might be interesting to talk on how to use Pg from Perl, DBIx::Class or PgTAP just to throw in a couple of ideas. regards Gabor
Re: patch full of dark magic
In data 09 agosto 2010 alle ore 17:27:52, David E. Wheeler
da...@kineticode.com ha scritto:
On Aug 9, 2010, at 8:21 AM, Cosimo Streppone wrote:
package Foo;
sub DESTROY { exit; }
my $foo = bless {}, 'Foo';
I couldn't try this yet, but, I don't think this
would segfault.
What I *guess* happens is that the 'exit' will cause
the script to immediately exit, skipping the nasty
part that would otherwise segfault.
Which nasty part?
Ehm... scrap that :)
Your patch with 'unless' reversed to 'if' works fine.
Just for clarity, here's the full DESTROY() of 16destroy.t:
sub DESTROY {
if ($expect_active 0) { # inside child
my $self = shift;
exit ($self-FETCH('Active') || 0) unless $^O eq 'MSWin32';
# On Win32, the forked child is actually a thread. So don't
exit,
# and report failure directly.
fail 'Child should be inactive on DESTROY'
if $self-FETCH('Active');
} else {
return $expect_active
? ok( shift-FETCH('Active'), 'Should be active in
DESTROY')
: ok( !shift-FETCH('Active'), 'Should not be active in
DESTROY');
}
}
Will try and let you know.
Thanks!
Done. Passes all tests. This is perl 5.10.0
on MSWin32 + MSVC9 (cc='cl' and ccversion '15.00.21022.08')
--
Cosimo
Re: patch full of dark magic
On Aug 9, 2010, at 1:06 PM, Cosimo Streppone wrote: Which nasty part? Ehm... scrap that :) Your patch with 'unless' reversed to 'if' works fine. Thanks! Committed in r14317. Just for clarity, here's the full DESTROY() of 16destroy.t: Yep, thanks. Will try and let you know. Thanks! Done. Passes all tests. This is perl 5.10.0 on MSWin32 + MSVC9 (cc='cl' and ccversion '15.00.21022.08') W00t! Tim, I think we're ready for another dev release, especially since I added this test to the MANIFEST. Best, David
Re: patch full of dark magic
In data 09 agosto 2010 alle ore 22:42:59, David E. Wheeler da...@kineticode.com ha scritto: On Aug 9, 2010, at 1:06 PM, Cosimo Streppone wrote: Which nasty part? Ehm... scrap that :) Your patch with 'unless' reversed to 'if' works fine. Thanks! Committed in r14317. Confirmed. r14317 passes all tests. -- Cosimo
RE: patch full of dark magic
On Mon, 09 Aug 2010, David E. Wheeler wrote:
Tim, I think we're ready for another dev release, especially since I added
this test to the MANIFEST.
Running tests on the latest ActivePerl shows 2 issues:
1) t/01basics.t fails to load DBD::Oracle (because I don't have the Oracle
client
libraries installed on the test machine). This produces a popup that the
user
has to explicitly dismiss. The test then passes without errors.
You could use Win32API::File::SetErrorMode() to disable these popups and
return a failure code for loading the extension instead.
Win32API::File is a core module since 5.10, so you would need to check if you
can load it (untested):
if ($^O eq MSWin32 eval { require Win32API::File }) {
Win32API::File::SetErrorMode(Win32API::File::SEM_FAILCRITICALERRORS);
}
2) t/50dbm_simple.t is missing one test:
Test Summary Report
---
t/50dbm_simple.t (Wstat: 65280 Tests: 26 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 27 tests but ran 26.
t/zvg_50dbm_simple.t (Wstat: 65280 Tests: 26 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 27 tests but ran 26.
t/zvn_50dbm_simple.t (Wstat: 65280 Tests: 26 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 27 tests but ran 26.
t/zvp_50dbm_simple.t (Wstat: 65280 Tests: 26 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 27 tests but ran 26.
t/zvxgn_50dbm_simple.t (Wstat: 65280 Tests: 26 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 27 tests but ran 26.
t/zvxgnp_50dbm_simple.t (Wstat: 65280 Tests: 26 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 27 tests but ran 26.
t/zvxgp_50dbm_simple.t (Wstat: 65280 Tests: 26 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 27 tests but ran 26.
t/zvxnp_50dbm_simple.t (Wstat: 65280 Tests: 26 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 27 tests but ran 26.
Files=171, Tests=6376, 98 wallclock secs ( 0.28 usr + 2.67 sys = 2.95 CPU)
Result: FAIL
Failed 8/171 test programs. 0/6376 subtests failed.
NMAKE : fatal error U1077: 'C:\Perl1201\bin\perl.exe' : return code '0xff'
Stop.
Not sure what the issue is; maybe the fact that old versions of
DBD::CSV and SQL::Statement are already installed in the tree?
Here is the verbose output of one test:
C:\tmp\dbiperl -Mblib t\50dbm_simple.t
Using DBM modules: SDBM_File
Using MLDBM serializers:
Test count: 1 x ( ( 5 + 22 ) + 0 x ( 5 + 25 ) ) = 27
1..27
--- Using SDBM_File () ---
# DBD::DBM 0.05 using SDBM_File (1.06)
# DBD::File 0.39 using IO::File (1.14)
# DBI::DBD::SqlEngine 0.01 using DBI::SQL::Nano 1.014245
# DBI 1.614
# OS MSWin32 (5.00)
# Perl 5.012001 (MSWin32-x86-multi-thread)
ok 1 - dbm_versions
ok 2 - The object isa DBI::db
ok 3
ok 4
ok 5
ok 6 - DROP TABLE IF EXISTS SDBM_File_fruit
ok 7 - CREATE TABLE SDBM_File_fruit (dKey INT, dVal VARCHAR(10))
ok 8 - INSERT INTO SDBM_File_fruit VALUES (1,'oranges' )
ok 9 - INSERT INTO SDBM_File_fruit VALUES (2,'to_change' )
ok 10 - INSERT INTO SDBM_File_fruit VALUES (3, NULL )
ok 11 - INSERT INTO SDBM_File_fruit VALUES (4,'to delete' )
ok 12 - INSERT INTO SDBM_File_fruit VALUES (?,?)
ok 13 - INSERT INTO SDBM_File_fruit VALUES (6,'to delete' )
ok 14 - INSERT INTO SDBM_File_fruit VALUES (7,'to_delete' )
ok 15 - DELETE FROM SDBM_File_fruit WHERE dVal='to delete'
ok 16 - $sth-execute(DELETE FROM SDBM_File_fruit WHERE dVal='to delete') == $s
th-rows
ok 17 - UPDATE SDBM_File_fruit SET dVal='apples' WHERE dKey=2
ok 18 - $sth-execute(UPDATE SDBM_File_fruit SET dVal='apples' WHERE dKey=2) ==
$sth-rows
ok 19 - DELETE FROM SDBM_File_fruit WHERE dKey=7
ok 20 - $sth-execute(DELETE FROM SDBM_File_fruit WHERE dKey=7) == $sth-rows
ok 21 - SELECT * FROM SDBM_File_fruit ORDER BY dKey DESC
ok 22 - SELECT results
ok 23 - DELETE FROM SDBM_File_fruit
ok 24 - $sth-execute(DELETE FROM SDBM_File_fruit) == $sth-rows
ok 25 # skip execute failed: No such column 'COUNT*' at C:\tmp\dbi\blib\lib/DBI/
DBD/SqlEngine.pm line 732
#
ok 26 # skip execute failed: No such column 'COUNT*' at C:\tmp\dbi\blib\lib/DBI/
DBD/SqlEngine.pm line 732
#
# Looks like you planned 27 tests but ran 26.
Cheers,
-Jan
Re: patch full of dark magic
On Aug 9, 2010, at 4:21 PM, Jan Dubois wrote: On Mon, 09 Aug 2010, David E. Wheeler wrote: Tim, I think we're ready for another dev release, especially since I added this test to the MANIFEST. Running tests on the latest ActivePerl shows 2 issues: 1) t/01basics.t fails to load DBD::Oracle (because I don't have the Oracle client libraries installed on the test machine). This produces a popup that the user has to explicitly dismiss. The test then passes without errors. Why does it try to load DBD::Oracle? The DBI has no dependency on any DBDs other than those it ships with. Best, David
RE: patch full of dark magic
On Mon, 09 Aug 2010, Jan Dubois wrote: On Mon, 09 Aug 2010, David E. Wheeler wrote: Tim, I think we're ready for another dev release, especially since I added this test to the MANIFEST. Running tests on the latest ActivePerl shows 2 issues: Sorry, forgot to mention one untidiness: The warning about site_lib coming after the normal library directories in @INC is not correct for 5.12 and later, which have changed the @INC order to: sitelib, vendorlib, privlib. So this warning should only be displayed for older Perl versions. Cheers, -Jan
RE: patch full of dark magic
On Mon, 09 Aug 2010, David E. Wheeler wrote:
On Aug 9, 2010, at 4:21 PM, Jan Dubois wrote:
On Mon, 09 Aug 2010, David E. Wheeler wrote:
Tim, I think we're ready for another dev release, especially since I added
this test to the MANIFEST.
Running tests on the latest ActivePerl shows 2 issues:
1) t/01basics.t fails to load DBD::Oracle (because I don't have the Oracle
client
libraries installed on the test machine). This produces a popup that the
user
has to explicitly dismiss. The test then passes without errors.
Why does it try to load DBD::Oracle? The DBI has no dependency on any DBDs
other than those it ships with.
DBI-installed_versions will attempt to load *all* installed drivers.
But I see now that that test is only executed if you are running from a GIT
or SVN checkout, so maybe it doesn't really matter. If you want to add
the safeguard for it, here is a tested patch (the untested version was missing
one pair of parens):
Index: t/01basics.t
===
--- t/01basics.t(revision 14317)
+++ t/01basics.t(working copy)
@@ -290,6 +290,10 @@
SKIP: {
skip 'developer tests', 4 unless -d .svn || -d .git;
+ if ($^O eq MSWin32 eval { require Win32API::File }) {
+
Win32API::File::SetErrorMode(Win32API::File::SEM_FAILCRITICALERRORS());
+ }
+
print Test DBI-installed_versions (for @drivers)\n;
print (If one of those drivers, or the configuration for it, is bad\n;
print then these tests can kill or freeze the process here. That's not
the DBI's fault.)\n;
Cheers,
-Jan
