On Sat Mar 11 12:49:11 2017, jross@openvistas.net wrote:
Show quoted text> Hello!
>
> [informix@849341-CRN1 ~]$ /opt/tms/bin/InformixTechSupport -V
> Perl Version 5.024000
> DBI Version 1.636
> DBD::Informix Version 2015.1101
> IBM Informix CSDK Version 4.10, IBM Informix-ESQL Version 4.10.FC5DE
>
> This is on CentOS Linux release 7.3.1611 (Core).
>
> If I specify the username and password in the connection string the
> informix engine crashes every time. Leaving username and password empty
> works fine.
>
> Example:
>
> #!/usr/bin/perl
>
> use warnings;
> use strict;
> use DBI;
>
>
> my $hostname = 'web@cargonet_dbi4';
> my $dbh = DBI->connect
> (
> "DBI:Informix:".$hostname,
> 'nobody',
> 'mailonly66',
> { PrintError => 0, RaiseError => 1, AutoCommit => 0 }
> );
>
> # ----------------
> # open transaction
> # ----------------
> $dbh->do("begin");
>
> # --------------------------------------
> # prepare and execute 'select' statement
> # --------------------------------------
> my $sth1 =$dbh->prepare("select max(id) as id from load;");
> $sth1->execute();
>
> # ---------------------
> # fetch thru result set
> # ---------------------
> while (my $row = $sth1->fetchrow_hashref())
> {
>
> # --------
> # show row
> # --------
> print sprintf("%-2s \n", $row->{id});
>
> }
>
> # ---------------------------------------
> # commit transaction and close connection
> # ---------------------------------------
> $dbh->do("commit");
> $dbh->disconnect();
>
> exit 0;
>
> the online.log on the informix server shows this:15:08:06 Maximum server
> connections 1
> 15:08:06 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns
> blocked 0, Plog used 41, Llog used 23
>
> 15:18:09 stack trace for pid 34640 written to
> /opt/IBM/informix/tmp/af.4c45b81
> 15:18:09 Assert Failed: No Exception Handler
> 15:18:09 IBM Informix Dynamic Server Version 11.10.FC2
> 15:18:09 Who: Session(30, nobody@849341-CRN1.cargotel.com, 8486,
> 0x1ae5ec15b8)
> Thread(220, sqlexec, 1ae5e81058, 3)
> File: mtex.c Line: 475
> 15:18:09 Results: Exception Caught. Type: MT_EX_OS, Context: mem
> 15:18:09 Action: Please notify IBM Informix Technical Support.
> 15:18:09 See Also: /opt/IBM/informix/tmp/af.4c45b81
> 15:18:15 mtex.c, line 475, thread 220, proc id 34640, No Exception Handler.
> tail: cannot open '+4' for reading: No such file or directory
> grep: write error: Broken pipe
> postdrop: warning: uid=504: File too large
> send-mail: fatal: informix(504): message file too big
> 15:18:15 Fatal error in ADM VP at mt.c:13388
> 15:18:15 Unexpected virtual processor termination, pid = 34640, exit =
> 0x100
>
> tail: cannot open '+4' for reading: No such file or directory
> grep: write error: Broken pipe
> 15:18:15 PANIC: Attempting to bring system down
>
> The panic trace file can be downloaded from
>
>
http://cargotel-informix-panic.s3.amazonaws.com/af.4c45b81
>
> Using the same script but changing the connection string to:
>
> my $dbh = DBI->connect
> (
> "DBI:Informix:".$hostname,
> '',
> '',
> { PrintError => 0, RaiseError => 1, AutoCommit => 0 }
> );
>
> works fine.
>
> [rossj@849341-CRN1 ~]$ perl test_connection.pl
> 5911073
>
> We do not have this problem on CentOS 5 or CentOS 6.
Hi Jeff,
I'm sorry you're running into this problem. I'll be closing your second bug report as it should have been added as a comment to this one. Thanks for the extra information. Because DBD::Informix does not attempt to pass either username or password unless both are specified, it is no surprise that setting one or the other but not both works.
According to the extract from the Informix log file, you're using Informix 11.10 in the database server. That is very old (released 2007) and is an officially unsupported version of Informix. The oldest version that's supported by IBM is 11.50 — it might even be 11.70 now; the current version is 12.10. You are using CSDK 4.10, which the the version associated with Informix 12.10.
Clearly, you should not be able to crash the server. However, the server should not be crashing; nothing that can be done from a client program should crash the server. In the ordinary course of events, I'd encourage you to brush off your support for Informix and contact IBM/Informix Tech Support to get a server fix. However, given that the software is no longer supported by IBM, you'll have to go for the other recommended alternative — upgrade to a newer, supported version of Informix, such as 12.10.
Given that there is going to be resistance to upgrading, you're going to want to know what can be done by DBD::Informix. Ultimately, DBD::Informix can't prevent the server crashing. The obvious workaround is to use trusted connections without a username and password — not ideal, but known to work.
It would be possible to hack DBD::Informix so that it ignores the username and password and connects as if neither had been supplied. This would at least get any existing scripts that supply user credentials running again.
Hmmm; that's amusing — that last change in esqlc_v6.ec was made in 2007.
You could apply this patch to that file:
--- old.esqlc_v6.ec 2017-03-11 16:54:39.000000000 -0800
+++ esqlc_v6.ec 2017-03-11 16:55:02.000000000 -0800
@@ -81,6 +81,9 @@
EXEC SQL END DECLARE SECTION;
Boolean conn_ok = False;
+ user = 0;
+ pass = 0;
+
if (user != (char *)0 && pass != (char *)0)
{
/* User name and password provided */
It might leave some compilation warnings, but otherwise does the job. Golly, this is old code; it still has tabs in the source. I gave up on that about ten years ago.
If you need to use a username and password but the server crashes, we're into more difficult territory. What changed in Centos 7 compared with Centos 5 & 6? Have you tried connecting to the Informix database with username and password using any other programs? Does the esqlbasic program work? (It doesn't test connections with username and password, so it is only a minimally indicative test.). Suppose you run DB-Access; can you connect with a username and password? If you use the connect option, it allows you to specify the server name to connect to, and then you can specify the username and password too. Does that crash the server?
Assuming DB-Access doesn't crash the server, and that it is version 11.10 (dbaccess -V), then we're going to need to see whether the new CSDK is at fault somehow. For that, you need a custom program:
/* RT 120587 - IDS 11.10 crashing on Centos 7 (OK on Centos 5 & 6) */
#include <stdio.h>
int main(int argc, char **argv)
{
EXEC SQL BEGIN DECLARE SECTION;
char *dbname = "stores";
char *user = "informix";
char *pass = "informix";
EXEC SQL END DECLARE SECTION;
if (argc > 4)
{
fprintf(stderr, "Usage: %s [database@server [username [password]]]\n", argv[0]);
return 1;
}
if (argc > 1)
dbname = argv[1];
if (argc > 2)
user = argv[2];
if (argc > 3)
pass = argv[3];
if (argc != 4)
fprintf(stderr, "Connecting with default password '%s' - this had better fail!\n", pass);
EXEC SQL CONNECT TO :dbname USER :user USING :pass;
if (sqlca.sqlcode != 0)
{
fprintf(stderr, "Failed to connect to '%s' with username '%s' and given password\n",
dbname, user);
return 1;
}
else
{
printf("Successfully connected to '%s' with username '%s' and given password\n",
dbname, user);
}
return 0;
}
I called it 'server-crash.ec' and compiled it into 'server-crash'. It didn't crash my server, whether I gave a valid password or not. You're expected to run 'server-crash stores@centos_7 youruser chosenpassword', but be cautious about who you have around when typing the password as an argument, and clean up shell histories, etc. If the server crashes with that code and not with DB-Access, then we can provisionally point the finger at the CSDK (ESQL/C) code — it isn't backwards compatible with IDS 11.10, it would seem. That's unusual; it normally works with very old server versions, but it could be an issue by accident.
We might then need to review whether your using shared memory, sockets or some other connection method. Can you connect safely using a different type of connection. If you've not already configured multiple mechanisms, you will have to restart Informix to add them (but since it is crashing, that probably isn't a major problem). If you need assistance with this testing, please contact me again.
At this point, you've probably drowned in all the information. I'm sorry, but I'm trying to cover a lot of bases all at once in the faint hope that I'll cover all that's necessary to resolve the problem. I doubt if I'll have succeeded, but you've seen some ideas, etc.
If you need more assistance, you may copy my Gmail account. You should also include information from your sqlhosts file (and the relevant service entries in /etc/services if you're using that). In fact, you should provide most of the information that is request in the notes on how to report bugs. You might use the BugReport script — the most basic 'perl BugReport' would show most of the information I need.
Hope this has helped somewhat — at least in pointing how to go further to resolving the problem.
--
Jonathan Leffler <jonathan.leffler@gmail.com>
Guardian of DBD::Informix 2015.1101 -- see
http://dbi.perl.org/
"I don't suffer from insanity - I enjoy every minute of it!"
