Dear Tim, There's a question for you at the bottom, which I've
repeated here, more or less.
What's the possible difference between:
use DBI;
and
use DBI;
use DBD::Informix;
in the context of this code? Also, the example code used $dbh->can()
as if it returns some sort of subroutine reference - whereas the
manual only says it returns true or false. Is the DBI manual
inaccurate or just incomplete and it actually returns something
usable?
On 5/17/05, Konstantin Solodovnikov <[EMAIL PROTECTED]> wrote:
> I'm having a problem with DBD::Informix when using it's functions via a
> 'goto &$sub' mechanism.
Que? What on earth is that? Why do you want to use it? Where did it ever work?
...more later...
> My program is a CGI script in perl, which provides web-access to a database
> in Informix.
> The problem happens in the situation when the program dies from a
> 'HandleError' handler, assigned to a DBD::Informix database handle.
> After the raised error is catched in the calling code,
> perl internal data structures seem to be in some inconsistent state
> and further actions may lead to a SIGBUS, depending on performed
> actions.
> The problem appears only if the corresponding DBD::Informix method,
> which enables the 'HandleError' handler, is called via a 'goto &$sub'
> mechanism.
Well, I'm not sure I want to look at a Perl manual to find out what it does.
Do I have to do that? :-0
...more below...
> The problem originally showed with perl 5.8.5 and DBD::Informix
> version 2003.04.
> But after moving to perl 5.8.6 and DBD::Informix 2005.01 the problem
> didn't eliminate.
>
> I opened a ticket on this case in perlbug, but they addressed me to
> the DBD::Informix oriented mailing list, so I hope someone here can
> reveal the source of the problem.
> Or at least help me to find an appropriate place to address with this
> problem.
Well, if the problem really is in DBD::Informix, then you've got the
correct place. However, there's enough magic around DBI, that I'd
like reassurance that the code works on some other database before I
expend much effort on debugging it -- I'm simply staggered that there
is a 'goto &$sub' mechanism in Perl that anyone would use.
> I made a simple test case, reproducing the situation (test.pl in the
> attachment).
> It works for me on my solaris8 both under perl 5.8.6 and 5.8.5 and with both
> DBD::Informix 2003.04 and 2005.01.
The good news - with the database name changed to something that works
on my machine, I surely get the core dump.
What does the $DBH->can() method do?
It's clear that you've done major work reducing a big program to a
pretty succinct test case - for which I thank you.
But I'm not in the least bit clear why you're going about the exercise
this way - my mind is stunned enough that I can't expand the example
into a program that would make sense when made up to full scale.
I've run the code with DBI_TRACE=9, and I'm not sure what's going on.
The syntax error is being diagnosed and a handle is therefore
destroyed. The prepare returns an undef; this goes to HandleError on
DBI::db=HASH(0x13ae80) via CODE(0x2bd2ec) (undef), generates the
string 'Test excception at coredumptest.pl line 30' (which is a mildly
hacked copy of your code - changing the database name, and removing
the unused qw(:sql_types) from 'use DBI;' and 'use DBD::Informix' -
both unneeded in the current test code. We then end up in '--
DBI::END' which calls disconnect_all for DBD::Informix::dr, which
doesn't have anything much to delete. disconnect_all returns. Then I
get a DESTROY command dispatched, a connection is disconnected, we go
into dbd_ix_db_destroy, which seems OK, then I see '! <- DESTROY=
undef during global destuction, etc. The last two lines of
output are:
! >> DESTROY DISPATCH ( DBI::db=HASH(0x2bd598) rc/1 @1go ima4
> In the end of the message goes the output of perlbug -d, just in case.
Thanks. About the only thing that's significantly different from my
setup is that you're
using GCC 3.3.2 whereas I'm not building with 4.0.0. You're also
using the 64-bit integer support which I don't - and you're doing so
with a 32-bit version of CSDK, It probably doesn't matter, but it
might just do so...
... pause ...
OK - the Camel book says 'goto LABEL' and 'goto EXPR' are rather like
Fortran computed gotos and just as good for maintenance programmers.
It says 'goto &NAME;' is OK for autoloaders who need to replace
themselves with the function that they just loaded. You aren't
autoloading that I can see, so...why?
More on the debugging. Really weird...
Change the 'use DBD::Informix' line into a comment and it doesn't crash.
I've no idea what that means - Tim, any ideas at all?
And Konstantin, what is the DBI->can() method for? It is documented
in DBI as returning true or false depending on whether a method is
implemented by the driver or a default method is provided by DBI
(perldoc DBI for v1.48). So, what made you think that it returned a
subroutine reference or name? Your usage of it bears no relation to
the documentation of it.
> Best regards,
> Konstantin Solodovnikov,
> JSC "Web Media Servises".
> [EMAIL PROTECTED]
>
> [Please do not change anything below this line]
> -----------------------------------------------------------------
> ---
> Flags:
> category=core
> severity=high
> ---
> Site configuration information for perl v5.8.6:
>
> Configured by ks at Sat May 14 15:02:16 MSD 2005.
>
> Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
> Platform:
> osname=solaris, osvers=2.8, archname=sun4-solaris
> uname='sunos netra-dev 5.8 generic_108528-19 sun4u sparc sunw,ultraax-i2'
> config_args='-Dcc=gcc -B/usr/ccs/bin -DDEBUGGING'
> hint=recommended, useposix=true, d_sigaction=define
> usethreads=undef use5005threads=undef useithreads=undef
> usemultiplicity=undef
> useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
> use64bitint=undef use64bitall=undef uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
> Compiler:
> cc='gcc -B/usr/ccs/bin', ccflags='-DDEBUGGING -fno-strict-aliasing -pipe
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
> optimize='-g',
> cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include'
> ccversion='', gccversion='3.3.2', gccosandvers='solaris2.8'
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
> ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=8
> alignbytes=8, prototype=define
> Linker and Libraries:
> ld='gcc -B/usr/ccs/bin', ldflags =' -L/usr/local/lib '
> libpth=/usr/local/lib /usr/lib /usr/ccs/lib
> libs=-lsocket -lnsl -ldl -lm -lc
> perllibs=-lsocket -lnsl -ldl -lm -lc
> libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
> gnulibc_version=''
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
> cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'
>
> Locally applied patches:
>
> ---
> @INC for perl v5.8.6:
> /usr/local/perl-5.8.6-test/lib/5.8.6/sun4-solaris
> /usr/local/perl-5.8.6-test/lib/5.8.6
> /usr/local/perl-5.8.6-test/lib/site_perl/5.8.6/sun4-solaris
> /usr/local/perl-5.8.6-test/lib/site_perl/5.8.6
> /usr/local/perl-5.8.6-test/lib/site_perl/5.8.5/sun4-solaris
> /usr/local/perl-5.8.6-test/lib/site_perl/5.8.5
> /usr/local/perl-5.8.6-test/lib/site_perl/5.8.0/sun4-solaris
> /usr/local/perl-5.8.6-test/lib/site_perl/5.8.0
> /usr/local/perl-5.8.6-test/lib/site_perl
> .
>
> ---
> Environment for perl v5.8.6:
> HOME=/home/ks
> LANG (unset)
> LANGUAGE (unset)
> LC_ALL=ru_RU.KOI8-R
>
> LD_LIBRARY_PATH=/home/informix/ids_9.30.uc1/lib:/home/informix/ids_9.30.uc1/
> lib/esql:/home/informix/ids_9.30.uc1/lib/tools:/usr/lib:/usr/local/lib
> LOGDIR (unset)
>
> PATH=/home/informix/ids_9.30.uc1/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/OBSDssh/bin:/usr/ccs/bin:/usr/local/bin:/usr/local/sbin:/etc/init.d
> PERL_BADLANG (unset)
> SHELL=/usr/bin/bash
>
>
--
Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h>
Guardian of DBD::Informix - v2005.01 - http://dbi.perl.org
"I don't suffer from insanity - I enjoy every minute of it."
