Re: DBD::Informix test failure for lvarchar

------=_Part_1977_25555725.1180802611259
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/1/07, Mark Abajian wrote:
>
> In reply to a recent inquiry about my post...
>
> I have not resolved the issue. There is no resolution yet from the
> Guardian of DBD::Informix.


Still true - but I will proffer the information that I too have problems now
which I clearly didn't when I released 2007.0226 (I don't release the code
with known-to-fail tests).

I will have to backtrack too, but I'm moderately sure that I'm using the
same CSDK and DBD::Informix, but newer versions of DBI. Why this would
matter is completely non-obvious - it is most likely that a bug has been
uncovered in DBD::Informix rather than anything else. OTOH, you're using
DBI 1.47, which is way older than the 1.54..1.56 versions.

In my none-too-copious so-called spare time, I will try to resolve this, but
I'd also take patches from anyone else who can resolve it.

Here is what I have learned on my own... (in all cases, this is using
> Informix IDS 10.00 on a remote host, and the client is on Solaris 8,
> DBI is 1.47)
>
>
> DBD-Informix-2007.0226 + CSDK-2.70.UC3 --> 91udts fails
>
> so I updated my CSDK:
> DBD-Informix-2007.0226 + CSDK-2.90.UC4 --> 93lvarchar fails (these
> are the latest clients, and so I made my bug report based on these)
>
> so I went retro on the Perl client:
> DBD-Informix-2007.0225 + CSDK-2.90.UC4 --> 93lvarchar fails
>
> so I went double-retro on the Perl client:
> DBD-Informix-2005.02 + CSDK-2.90.UC4 --> complete success
>
> But, it looks like the only reason that 2005.02 did *not* fail is
> because it does *not* perform the same tests on "LVARCHAR NOT NULL"
> that the 2007.0225 and .0226 clients perform.
>
> For now, I am using 2007.0226 (as in my bug report). Since we
> currently have no LVARCHAR columns in our data base, and we have no
> intention in the near term of using such, we have decided just to use
> this latest version. I asked the CPAN shell to do a force install.
>
> I hope this information proves useful.
> --
> Mark Abajian
>
>
>
>
> On Jun 1, 2007, at 2:38 AM, a colleague wrote:
> > Hi Mark,
> >
> >
> > I saw your recent question on the above, after a web search that I
> > made
> >
> > with the aim of resolving the same problem which I am also having!
> >
> >
> > If you were able to settle it, or work round it without too much fuss,
> >
> > I'd be very interested in the details.
> >
> >
> > If not, I'm afraid I have little to offer you for now, because
> > obviously
> >
> > I am in the same boat. But if you like I'll gladly share any
> > information
> >
> > I can unearth, not that I've had much luck so far.
> >
> >
> > Anyway, I look forward to hearing from you if you get a chance to
> > reply.
> >
> > Cheers
>
>
> On May 14, 2007, at 10:18 PM, Mark Abajian wrote:
>
> > [This is my second attempt to post. First was refused for overly-
> > long attachment.]
> >
> >
> > Hello.
> >
> > I hope I have enough information here for someone to assist with a
> > DBD::Informix problem.
> >
> >
> > I am installing DBD::Informix on a Solaris 8 host. We have a 32-
> > bit Perl 5.8.6, compiled with gcc 3.4.3. The Informix Client SDK
> > is 2.90UC4 (32-bit SPARC).
> >
> > The Informix server, on a Solaris 9 host, is IDS 10.00.FC4 (64-bit
> > SPARC).
> >
> > I ran into a problem with test t/t93lvarchar.t. It appears that
> > the script is failing to retrieve values for columns of type
> > "lvarchar not null". Otherwise, the build and tests seem just fine.
> >
> >
> > What is the status of this anomaly? (I saw similar postings dating
> > from 2002-2005.)
> > Is this anything to be concerned about if I have no columns of type
> > "lvarchar not null"?
> > Any recommendations?
> >
> > A bug report for "D t/t93lvarchar.t" is attached.
> >
> > Thank you for your assistance.
> > --
> > Mark Abajian
> >
> >
> >
>
>


--
Jonathan Leffler #include
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

------=_Part_1977_25555725.1180802611259--

Re: DBD::Informix test failure for lvarchar

Just to chime in, we have a similar problem at work: selecting a row with an
LVARCHAR column in it causes a segfault(!) for us. This happens on two of
our machines, but does not happen on a third. We have yet to narrow down
the exact differences. I'll post more when I have more information. In the
meantime, I just wanted to add my basic "we can't use LVARCHAR columns with
DBD::Informix either" report.

-John

Re: DBD::Informix test failure for lvarchar

On 6/2/07 5:42 PM, John Siracusa wrote:
> Just to chime in, we have a similar problem at work: selecting a row with an
> LVARCHAR column in it causes a segfault(!) for us. This happens on two of
> our machines, but does not happen on a third. We have yet to narrow down
> the exact differences. I'll post more when I have more information. In the
> meantime, I just wanted to add my basic "we can't use LVARCHAR columns with
> DBD::Informix either" report.

Sorry, this is using the latest DBD::Informix form CPAN, in case that wasn't
clear. We've tried a few minor revisions of the CSDK with no affect, but I
don't recall the exact versions. Again, more info to follow eventually...

-John

Re: DBD::Informix test failure for lvarchar

------=_Part_3570_27739100.1180935073491
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/2/07, John Siracusa wrote:
>
> On 6/2/07 5:42 PM, John Siracusa wrote:
> > Just to chime in, we have a similar problem at work: selecting a row
> with an
> > LVARCHAR column in it causes a segfault(!) for us. This happens on two
> of
> > our machines, but does not happen on a third. We have yet to narrow
> down
> > the exact differences. I'll post more when I have more information. In
> the
> > meantime, I just wanted to add my basic "we can't use LVARCHAR columns
> with
> > DBD::Informix either" report.
>
> Sorry, this is using the latest DBD::Informix form CPAN, in case that
> wasn't
> clear. We've tried a few minor revisions of the CSDK with no affect, but
> I
> don't recall the exact versions. Again, more info to follow eventually...
>


Just spent some 'spare time' building Perl 5.8.8 plus DBI 1.56 plus
DBD::Informix 2007.0226 plus ESQL/C 3.00.FC1 (more or less) on RedHat Linux
for PowerPC 64-bit, and (once some build issues are resolved), the damn
thing works without visible error (using an IDS 10.00.UC5 server on Solaris
10 running some 1,500 miles from where the Linux box is).

That's a pity! It looks like a memory allocation problem (I managed to get
a core dump out of CSDK 2.81.UC2 on Solaris 8, for example) and I was
planning to use valgrind on the code. In fact, I probably will still do
that, just to see whether there is anything egregious that valgrind detects
but the rest of the system does not (it just won't be tonight).

So, various issues:
1. The band-aids for CSDK 3.00 are imperfect; that alone means I must do a
new release of DBD::Informix before long. If/when you run into problems,
contact me - but the basic solution is to change ESQLC_VERSION < 300 into
ESQLC_VERSION < 400 in various locations; more than one file, sadly.
2. The exact details of the LVARCHAR misbehaviour are sadly dependent on
the version of CSDK and probably on the platform.
3. Despite earlier mention of different versions of DBI, I want to
re-emphasize that the only influence I think it has is on the visibility of
the problem - some versions of DBI make it easier to spot the trouble than
others - probably on a platform-specific basis.

Or, IOW, this is one of those hard bugs - I'm having trouble locating the
real problem.


--
Jonathan Leffler #include
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

------=_Part_3570_27739100.1180935073491--

Re: DBD::Informix test failure for lvarchar

On 6/2/07, John Siracusa wrote:
> Just to chime in, we have a similar problem at work: selecting a row with an
> LVARCHAR column in it causes a segfault(!) for us. This happens on two of
> our machines, but does not happen on a third. We have yet to narrow down
> the exact differences. I'll post more when I have more information. In the
> meantime, I just wanted to add my basic "we can't use LVARCHAR columns with
> DBD::Informix either" report.

Here's the info on machines where selecting a row with an lvarchar
column causes a segfault:

uname -a: Linux xxxx 2.6.17.1 #4 SMP Wed Nov 8 21:18:40 UTC 2006
x86_64 unknown unknown GNU/Linux

Perl 5.8.8
DBD::Informix 2007.0226
Informix CSDK 2.81.UC3

Here's the table definition:

create table lv
(
n lvarchar(2000) not null
)
extent size 4096 next size 4096
lock mode row;

Here's the test script:

#!/usr/bin/perl
use strict;
use DBI;
my $dbh = DBI->connect('dbi:Informix:...', '...', '...');
my $sth = $dbh->prepare('select n from lv');
$sth->execute;
$sth->fetch; # segfault happens here

-John