On Sunday, January 5, 2003, at 08:18 AM, Maras Michal wrote:
MM wrote the "OK"; it was difficult to follow which information was my response, and which was MM's response to my response.-----Original Message----- From:�� Jonathan Leffler [mailto:[EMAIL PROTECTED]] Sent:�� Sat 04/01/2003 07:26 To:���� Maras Michal Cc:���� DBI Users Mailing List Subject:������� Re: mod_perl and connect by DBD::InformixMaras Michal wrote: >� I wrote simple Apache::ASP page > ------- > <HTML> > <BODY> > <% > use DBI; > use DBD::Informix; You don't need to 'use DBD::Informix'; it will be automagically loaded when you run the connect. OK
> my $dbh = DBI->connect("DBI:Informix:\@server", "", "",{ PrintError =>MM wrote "I added"; I'm not sure what he added, but I presume it was either PrintError=>1 or RaiseError=>1.
> 0, AutoCommit => 1, });
When there are problems, I'd recommend trying PrintError=>1 and/or
RaiseError=>1, especially if you aren't prepared to test whether
you've got a valid $dbh before trying to use it.
I added
> my $rc=$dbh->disconnect;MM added the version information. The DBI and DBD::Informix versions are OK. The version of IDS is barely OK; you should be on at least 9.21 and preferably 9.30. The only reason for staying with such an archaic version is if the o/s is too archaic to be supported by IDS 9.21 or later. You said AIX 4.3; however, if you mean 4.3.1 or 4.3.2, then you are no longer supported by IBM - the oldest current version is 4.3.3. If you're on AIX 4.3.3, then you can upgrade to IDS 9.30.
> %>
> </BODY>
> </HTML>
> -------
>
> This page (perl asp script) work fine, but only first time on
> apache child process. Second attemp to run this script cause
> segmentation fault of child apache process. When main apache
> process then create new child, all is OK, but only for one script
> run again, and so on.
>
> What is wrong?
>
> I run perl 5.6.1 without thread on AIX 4.3, apache 1.3.20� mod_perl/1.26
Apache 1.3.20 should be upgraded to avoid some security bugs (1.3.27
is current, I believe). You can debate whether Perl should be 5.8.0.
I don't keep the mod_perl version information at hand.� However, it is
also entirely fair to say that these versions are not relevant to the
problem.
You don't say which version of DBD::Informix or DBI you are using;
that would be useful to know. You also don't mention whether you are
using Apache::DBI; that too might be relevant. You don't say which
version of ESQL/C or the Informix database server you are using; those
might be relevant.
�DBI-1.32
DBD-Informix-1.00.PC2 (I try DBD-Informix-1.04.PC1 too
�with same result)
Informix Dynamic Server 2000 Version 9.20.UC4X6
INFORMIX-ESQL Version 9.14.UC1
Even more so, you should immediately upgrade to a more recent version of ESQL/C. I think version 9.14 was released in 1996 (maybe 1997) as part of CSDK 2.01; you should be aiming to use CSDK 2.70 or later (and hence ESQL/C 9.51 or later). There are even tests in the test suite that are documented to fail under CSDK 2.01 or ESQL/C 9.14 because of bugs in CSDK that were subsequently fixed. Note that if you have support for your server, you can obtain CSDK at no cost (though you have to pay for support on it if you want support on it).
It also isn't clear to me how you tell that the page works on theOK; it doesn't do anything beyond exercise the Informix connection. I don't know that I've ever tested DBD::Informix with no operations at all between connect and disconnect; the nearest routine approach to that is in t/t00basic.t where the code prints out some details (multiple calls to the FETCH function) before disconnecting. I wouldn't expect that to cause any trouble.
first pass -- the example does not seem to display anything.
My work up in detail is
My asp page is
----
<HTML>
<BODY>
<%
open(HAN,"ps -ef | grep httpd|grep maras|");
while(<HAN>) {
� print "$_<BR>\n";
� }
close HAN;
print "Process $$<BR>\n";
$dbType = "Informix";
$ENV{"INFORMIXDIR"}="/usr/informix";
$ENV{"INFORMIXSERVER"}="cm1";
use DBI;
�$dbh = DBI->connect("DBI:$dbType:\@cm1", "", "",
{ PrintError => 1, RaiseError=>1, AutoCommit => 1, });
if (!defined($dbh)) {
� print "DBI->connect on ${server_select}","Error connect ($DBI::err): $DBI::err
str";
� return;
� }
print "After connect<BR>\n";
�$rc=$dbh->disconnect;
if (!defined($rc)) {
� print "Error disconnect ($DBI::err): $DBI::errstr<BR>\n";
� }
print "After disconnect<BR>\n";
%>
</BODY>
</HTML>
----
Why MaxRequestsPerChild of 0 -- surely, a child has to serve at least one request to be of any use? Or is that zero an 'indefinitely large number of requests'?Some httpd configuration dirrectives KeepAlive On MaxKeepAliveRequests 10 KeepAliveTimeout 15 MinSpareServers 1 MaxSpareServers 1 StartServers 1 MaxClients 10 MaxRequestsPerChild 0
Apache processes immediately after atache startWhat is anything other than the database server doing running as informix? You should seldom need to run anything as user informix -- it is tantamount to running it as root. You should never connect to the database from a web-based process as user informix unless you know enough about how to handle Informix not to ask questions about why you should not do it. I would *never* connect to the database as user informix from a web-based process not distributed by Informix (IBM). I would doubly never run any server other than perhaps the one run by ISA (IBM Informix Server Administrator) as informix.
informix 28748 36952�� 0 16:01:18����� -� 0:00 /u/maras/apache/bin/httpd
��� root 36952���� 1�� 0 16:01:17����� -� 0:00 /u/maras/apache/bin/httpd
First pass (after first run asp page)OK. This is good tracing work - I see now why you're sure you've got a problem. There are various questions arising. What happens if you don't do the disconnect? What happens if you don't do the connect either? We need, in other words, to establish that we aren't running into problems independently of DBD::Informix and DBI. I will assume that you have done this and that DBD::Informix is part of the problem somehow. Have you thought of printing out some of the driver control information - such as the number of connections it has open. This might tell us something useful. See the code at the top of t/t00basic.t in the DBD::Informix source code.
Browser display.
informix 28748 36952 18 16:01:18 - 0:00 /u/maras/apache/bin/httpd
root 36952 1 0 16:01:17 - 0:00 /u/maras/apache/bin/httpd
informix 41720 36952 0 16:02:32 - 0:00 /u/maras/apache/bin/httpd
Process 28748
After connect
After disconnect
Second pass
Browser display.
informix 28748 36952 0 16:01:18 - 0:00 /u/maras/apache/bin/httpd
root 36952 1 0 16:01:17 - 0:00 /u/maras/apache/bin/httpd
informix 41720 36952 25 16:02:32 - 0:00 /u/maras/apache/bin/httpd
Process 41720
After connect
After disconnect
Next pass (again process 28748, then 41720, but both killed as
in apache error log)
[Sun Jan� 5 16:05:31 2003] [notice] child pid 28748 exit signal Segmentation fault (11)
[Sun Jan� 5 16:05:32 2003] [notice] child pid 41720 exit signal Segmentation fault (11)
Main apache process create new process 24488, run with it asp script,
and create new spare processes (I don't now why not one only)
Browser display.
informix 24488 36952 25 16:05:31 - 0:00 /u/maras/apache/bin/httpd
informix 28750 36952 0 16:05:32 - 0:00 /u/maras/apache/bin/httpd
root 36952 1 0 16:01:17 - 0:00 /u/maras/apache/bin/httpd
informix 42876 36952 0 16:05:32 - 0:00 /u/maras/apache/bin/httpd
Process 24488
After connect
After disconnect
Next
Browser display.
informix 24488 36952 0 16:05:31 - 0:00 /u/maras/apache/bin/httpd
informix 28750 36952 23 16:05:32 - 0:00 /u/maras/apache/bin/httpd
root 36952 1 0 16:01:17 - 0:00 /u/maras/apache/bin/httpd
informix 42876 36952 0 16:05:32 - 0:00 /u/maras/apache/bin/httpd
Process 28750
After connect
After disconnect
Next (again Segmentation fault, and creating new child
processes)
next entries in apache error log is
[Sun Jan� 5 16:12:08 2003] [notice] child pid 24488 exit signal Segmentation fault (11)
[Sun Jan� 5 16:12:09 2003] [notice] child pid 28750 exit signal Segmentation fault (11)
Browser display.
informix 24490 36952 0 16:12:11 - 0:00 /u/maras/apache/bin/httpd
informix 28752 36952 25 16:12:10 - 0:00 /u/maras/apache/bin/httpd
root 36952 1 0 16:01:17 - 0:00 /u/maras/apache/bin/httpd
informix 42878 36952 0 16:12:11 - 0:00 /u/maras/apache/bin/httpd
Process 28752
After connect
After disconnect
Have we got threaded code around? I assume not, but if the Apache servers are themselves multi-threaded and you didn't get DBD::Informix build with the threaded libraries (DBD_INFORMIX_ESQLC_LINKAGE="-shared -thread") then the problem could simply be that you aren't using the correct libraries. I rate this very low on the probability scale, but not at zero probability.
And� all roundThere's nothing in that stack trace from DBD::Informix or ESQL/C. However, since it is in a memory allocation routine, the trouble could be triggered by anything that goes trampling out of bounds. Now, I'm not aware of any such bugs in DBD::Informix or ESQL/C, but that doesn't mean there aren't some.
dbx output (from slightly different asp page, whitch
I run from FORM ACTION. In that case only one child apache
process killed, but asp page is little complikated)
platan:/u/maras/apache # dbx /u/maras/apache/bin/httpd core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]
Segmentation fault in sig_coredump at line 2750 in file ""
couldn't read "http_main.c"
(dbx) where
sig_coredump(sig = 11), line 2750 in "http_main.c"
_umalloc(??, ??) at 0xd302769c
replace(??, ??, ??, ??, ??) at 0xd3029134
_urealloc(??, ??) at 0xd302930c
cbase.realloc(??, ??) at 0xd301efc4
Perl_safesysrealloc(0x20127c48, 0xd0), line 129 in "util.c"
Perl_my_setenv(0x20109048, 0x200367b8), line 2010 in "util.c"
unnamed block $b1830, line 1712 in "mod_perl.c"
perl_setup_env(??), line 1712 in "mod_perl.c"
ptrgl._ptrgl(??) at 0xd0ea4cec
unnamed block $b1842, line 1477 in "mod_perl.c"
perl_call_handler(??, ??, ??), line 1477 in "mod_perl.c"
perl_run_stacked_handlers(??, ??, ??), line 1349 in "mod_perl.c"
perl_handler(??), line 875 in "mod_perl.c"
ap_invoke_handler(0x20107848), line 517 in "http_config.c"
process_request_internal(0x20107848), line 1307 in "http_request.c"
ap_process_request(0x20107848), line 1323 in "http_request.c"
unnamed block $b40, line 4209 in "http_main.c"
child_main(child_num_arg = 1), line 4209 in "http_main.c"
make_child(s = 0x2003d088, slot = 1, now = 1041779854), line 4368 in "http_main.c"
perform_idle_server_maintenance(), line 4532 in "http_main.c"
unnamed block $b33, line 4764 in "http_main.c"
standalone_main(argc = 1, argv = 0x2ff22bec), line 4764 in "http_main.c"
main(argc = 1, argv = 0x2ff22bec), line 5010 in "http_main.c"
(dbx)
If I insert command kill 6,$$; in asp code, dbx outputAgain, this doesn't look like anything to do with DBD::Informix per se, but that is not definitive.
looks (first pass after apache restart)
platan:/u/maras/apache # dbx /u/maras/apache/bin/httpd core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]
IOT/Abort trap in sig_coredump at line 2750 in file ""
couldn't read "http_main.c"
(dbx) where
sig_coredump(sig = 6), line 2750 in "http_main.c"
unnamed block $b1750, line 1565 in "doio.c"
Perl_apply(0x11e, 0x201e8418, 0x201e8418), line 1565 in "doio.c"
Perl_pp_kill(), line 3939 in "pp_sys.c"
Perl_runops_standard(), line 23 in "run.c"
S_call_body(0x2ff224e8, 0x0), line 1824 in "perl.c"
Perl_call_sv(0x2007c0d4, 0x4), line 1742 in "perl.c"
unnamed block $b1846, line 1635 in "mod_perl.c"
perl_call_handler(??, ??, ??), line 1635 in "mod_perl.c"
perl_run_stacked_handlers(??, ??, ??), line 1349 in "mod_perl.c"
perl_handler(??), line 875 in "mod_perl.c"
ap_invoke_handler(0x20107848), line 517 in "http_config.c"
process_request_internal(0x20107848), line 1307 in "http_request.c"
ap_process_request(0x20107848), line 1323 in "http_request.c"
unnamed block $b40, line 4209 in "http_main.c"
child_main(child_num_arg = 0), line 4209 in "http_main.c"
make_child(s = 0x2003d088, slot = 0, now = 1041780110), line 4368 in "http_main.c"
startup_children(number_to_start = 1), line 4395 in "http_main.c"
standalone_main(argc = 1, argv = 0x2ff22bec), line 4683 in "http_main.c"
main(argc = 1, argv = 0x2ff22bec), line 5010 in "http_main.c"
(dbx)
I still don't have much idea about what's up. I do think you should upgrade to a much later version of CSDK - and preferably to a later version of the IBM Informix database server too. Your Perl, DBI and DBD::Informix themselves are OK. ...http://perl.apache.org shows that mod_perl 1.26 was released in July 2001, and 1.27 in June 2002. And Apache 1.3.27 is indeed current in the 1.3.x family. I'm reluctant to point the finger too hard at them (Apache, mod_perl, Perl) because it just seems too unlikely.
Did you investigate Apache::DBI?
Have you checked that the database server shows the connections arriving and going away? With no delay between connect and disconnect, that might be difficult to spot; you can fix that by adding a 10-second sleep to the ASP and running 'onstat -u -r 3' which should then give you 3 or 4 entries with the ASP session showing up. Is there anything in the Informix log files to give warnings? Since you seem to be able to reconnect with no mention of rebooting IDS, I assume that the database server is unaffected by the tribulations of Apache.
Can you fake your ASP so that the first twice through the page, it does not actually connect with DBI, and then does it on the third time through? If that still crashed the server on the second cycle, I'd regard that as proof that the problem is not caused by DBD::Informix. Assuming it only crashes after DBD::Informix has been invoked, then I'm more concerned. If you can demonstrate the problem is with DBD::Informix, can you get Apache out of the loop and demonstrate the same problem? Can you write code that connects, disconnects, and loops back again after a short pause, and does that work correctly? Even when set up with no connection to a terminal?
You'd better copy my work email address - [EMAIL PROTECTED] - if you want more help during this week. I'm about to be away from home until Friday (business trip - no-one goes to Kansas for pleasure at this time of year!).
--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) #include <disclaimer.h>
"I don't suffer from insanity -- I enjoy every minute of it"
Guardian of DBD::Informix 1.04.PC1 -- http://dbi.perl.org/
