RE: DBD::Informix and SIGBUS in perl

[Konstantin Solodovnikov]

Tim Bunce [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
 On Tue, May 17, 2005 at 04:17:15PM -0700, Jonathan Leffler wrote:

  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?

 There's fairly deep magic going on here.  Returning a code-ref is
 undocumented because of potential problems. And guess what...
 here's a problem.

Well, it seems to me that if there are some potential problems,
it should be documented that usage of can()'s return value as a subref
(as some people got used) is a bad practice.
In any case, such a limitation breaks standard behaviour, implemented in
the 'UNIVERSAL' module.

   sub prepare_sql
   {
   # uncommenting the next line will avoid core dump
   # return $DBH-prepare( 'select * from ');
my $sub = $DBH-can( 'prepare');
@_ = ( $DBH, 'select * from ' );
goto $sub;
   }

 Messing with @_ before using goto  is just asking for trouble.

Hmm ... Is it a peculiarity of DBI, or DBD::Informix?
I made up another test case, without DBI and DBD::Informix.
It obtains a subroutine reference by calling a blessed reference's 'can()'
method,
 plays with @_ and calls the subroutine via 'goto $sub'.
After that things go the same way: dying, catching, etc.
But no cores, no SIGBUS'es ...

Anyway, it seems to me that any experiments with pure perl code
shoud not bring perl's internal data structures to an inconsistent
state, as we see in this example.
Am not i right?


 Bottom line: If it hurts then stop doing it.

That's the easiest way for me. I already have a workaround which solves
the problem, at least for this very code. I just call the subroutine
reference
as $sub-(@params);
Hope, this won't bring me problems in future.

Best regards,
Konstantin Solodovnikov,
JSC Web Media Servises.
[EMAIL PROTECTED]

Re: DBD::Informix and SIGBUS in perl

[Konstantin Solodovnikov]

Jonathan Leffler [EMAIL PROTECTED] wrote in message ...

 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?

It worked fine for me every time I used it in an AUTOLOAD routine.

 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?

I *am* autoloading. But I stripped AUTOLOAD function from the example
to make it shorter and clearer, because the code shows the effect both
with or without the AUTOLOAD function.

 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.

Well, DBI-can() returns a good sub reference for me, and it works fine, if
not interrupted by an SQL error.
But you are quite right about disadvantages of relying on undocumented
features of DBI API.
Could anyone point me at a more convenient way of implementing
an AUTOLOAD function?

BTW, if noone can rely on output of DBI-can() being a valid subroutine ref,
it surely breaks standards (see man UNIVERSAL).
And at least using it this way must be explicitly mentioned in the docs as a
bad practice.

Best regards,
Konstantin Solodovnikov,
JSC Web Media Servises.
[EMAIL PROTECTED]

DBD::Informix and SIGBUS in perl

[Konstantin Solodovnikov]

Hi,

I'm having a problem with DBD::Informix when using it's functions via a
'goto $sub' mechanism.

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.

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.

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.

In the end of the message goes the output of perlbug -d, just in case.
 
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

test.pl
Description: Binary data