> MM wrote the "OK"; it was difficult to follow which information was my > response, and which was MM's response to my response. >
Sorry, this is Microsoft Web access to Exchange > > 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. > > 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). > This is a little problem. I work in company which develop tax system for our republic (state). It is impossible for me to change version of AIX (currently 4.3.3.0) or Informix server on more then 100 computers in all country. I will try to change ESQL version on server, where I develop new application, but I am not sure I sucseed. > > OK; 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. > > > Some httpd configuration dirrectives > > KeepAlive On > > MaxKeepAliveRequests 10 > > KeepAliveTimeout 15 > > MinSpareServers 1 > > MaxSpareServers 1 > > StartServers 1 > > MaxClients 10 > > MaxRequestsPerChild 0 > > 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'? > MaxRequestsPerChild 0 mean unlimitted. Child process newer end. > > What 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. > I intend use user informix in first step only. I now this is dangerous but this certainly eliminate some error e.g. permission > > 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? If I comment out disconnect section, all is the same. Still segmentation fault in next pass as before > What happens if you don't do the connect > either? If I comment out connect section too, all looks good informix 33618 34550 3 09:50:20 - 0:00 /u/maras/apache/bin/httpd root 34550 1 0 08:50:17 - 0:00 /u/maras/apache/bin/httpd informix 44944 34550 3 09:53:45 - 0:00 /u/maras/apache/bin/httpd Process 33618 informix 33618 34550 0 09:50:20 - 0:00 /u/maras/apache/bin/httpd root 34550 1 0 08:50:17 - 0:00 /u/maras/apache/bin/httpd informix 44944 34550 2 09:53:45 - 0:00 /u/maras/apache/bin/httpd Process 44944 informix 33618 34550 1 09:50:20 - 0:00 /u/maras/apache/bin/httpd root 34550 1 0 08:50:17 - 0:00 /u/maras/apache/bin/httpd informix 44944 34550 0 09:53:45 - 0:00 /u/maras/apache/bin/httpd Process 33618 .... If I comment connect section, but disconnect section not, error raise [Tue Jan 7 09:53:46 2003] [error] [asp] [33618] [error] Can't call method " disconnect" on an undefined value at test.html line 24. <--> , /u/maras/perl/lib/site_perl/5.6.1/Apache/ASP.pm line 1578 > 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. I only try to print onstat -u (I added sleep(60); before disconnect in asp page, and connect is made (ses 253). before connect <onconfig.cm1> /usr/informix $ onstat -u Informix Dynamic Server 2000 Version 9.20.UC4X6 -- On-Line -- Up 1 days 12:02:27 -- 109088 Kbytes Userthreads address flags sessid user tty wait tout locks nreads nwrites 400d2018 ---P--D 1 root - 0 0 0 18 70 400d25d8 ---P--F 0 root - 0 0 0 0 956 400d2b98 ---P--- 5 root - 0 0 0 0 0 400d3158 ---P--B 6 root - 0 0 0 0 0 400d3718 Y--P--- 19 baranec - 4041f920 0 1 42 0 400d3cd8 ---P--D 10 root - 0 0 0 0 0 400d4298 Y--P--- 20 baranec - 404776e0 0 1 0 0 7 active, 128 total, 9 maximum concurrent before disconnect <onconfig.cm1> /usr/informix $ onstat -u Informix Dynamic Server 2000 Version 9.20.UC4X6 -- On-Line -- Up 1 days 12:02:39 -- 109088 Kbytes Userthreads address flags sessid user tty wait tout locks nreads nwrites 400d2018 ---P--D 1 root - 0 0 0 18 70 400d25d8 ---P--F 0 root - 0 0 0 0 956 400d2b98 ---P--- 5 root - 0 0 0 0 0 400d3158 ---P--B 6 root - 0 0 0 0 0 400d3718 Y--P--- 19 baranec - 4041f920 0 1 42 0 400d3cd8 ---P--D 10 root - 0 0 0 0 0 400d4298 Y--P--- 20 baranec - 404776e0 0 1 0 0 400d4858 Y--P--- 253 informix - 40534980 0 0 0 0 8 active, 128 total, 9 maximum concurrent after disconnect <onconfig.cm1> /usr/informix $ onstat -u Informix Dynamic Server 2000 Version 9.20.UC4X6 -- On-Line -- Up 1 days 12:07:17 -- 109088 Kbytes Userthreads address flags sessid user tty wait tout locks nreads nwrites 400d2018 ---P--D 1 root - 0 0 0 18 70 400d25d8 ---P--F 0 root - 0 0 0 0 956 400d2b98 ---P--- 5 root - 0 0 0 0 0 400d3158 ---P--B 6 root - 0 0 0 0 0 400d3718 Y--P--- 19 baranec - 4041f920 0 1 42 0 400d3cd8 ---P--D 10 root - 0 0 0 0 0 400d4298 Y--P--- 20 baranec - 404776e0 0 1 0 0 7 active, 128 total, 9 maximum concurrent > See the code at the top of > t/t00basic.t in the DBD::Informix source code. > > 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 round > > > > 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) > > There'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. > > > If I insert command kill 6,$$; in asp code, dbx output > > 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) > > Again, this doesn't look like anything to do with DBD::Informix per se, > but that is not definitive. > > 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/
