I recompilied PHP (see attached phpinfo and version string from ifx.ec) and it worked for two weeks. Now we see -439 again.

Hopefully I can attach a backtrace later this evening.

phpinfo:
PHP Version 4.3.2-dev

System SunOS gpname 5.7 Generic_106542-23 i86pc
Build Date Mar 7 2003 16:01:11
Configure Command './configure' '--with-informix' '--without-mysql' '--with-apache=../apache_1.3.27' '--enable-sockets' '--with-gd=/usr/local/' '--with-jpeg-dir=/usr/local/' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr/local/' '--enable-debug'
Server API Apache
Virtual Directory Support disabled
Configuration File (php.ini) Path /export/opt/local/lib/php.ini
PHP API 20020918
PHP Extension 20020429
Zend Extension 20021010
Debug Build yes
Thread Safety disabled
Registered PHP Streams php, http, ftp, compress.zlib

Zend logo This program makes use of the Zend Scripting Language Engine:
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies

ifx.ec:
$Id: ifx.ec,v 1.69.2.12 2003/02/27 09:00:51 nobbie Exp $

So what changed during the 2 weeks that made it to fail again? Are you absolutely sure this is PHP problem at all?
And what do you mean with "Now we see -439 again." ??

Trust me, we didn't change a bit with php, php.ini, apache or httpd.conf. OK the database grew and we changed some PHP scripts, but the bug appears on any page even if it worked for two weeks.
In some situations the -439 appears more often espeially when one or more really large selects are running (result set > 1M).

Now whats this when I say we see -439. When a php page is opened it first checks for some entries in the database. These calls die with error -439.

I am sure that it is an php problem because with dbaccess or perl I can connect to the databases and work with it.

Please tell me which Client SDK and Dynamic Server you use for the development of php/informix.

Hi,

I think the following helps with the -439 problem.

Art S. Kagel wrote in comp.databases.informix:

Your app probably has a SIGALARM() timeout handler that is trying to
detach from the engine before exiting with a DISCONNECT statement but the
engine cannot respond because it is busy with the long running statement
that caused the timeout.  The timeout handler has to execute the
sqlbreak() ESQL/C function to terminate the current statement which will
return with a -613 error.  Then either the handler can DISCONNECT
directly or just return and let the mainline code handle the -613 as a
timeout and exit gracefully.  Your choice.


And our Problem only happens when there are very long select run by php.

I recently compiled 4.3.2 with apache 2.0.47 (mpm-worker) and had also Problems with longer running statements (3-7 seconds) and alarm signals delivered to the wrong thread.... Are you interessted in debugging php 4 with apache 2 mpm-worker?

Thanks for your time Thomas

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

And no, we're not interestedin apache2 mpm-worker, it's experimental at best anyway. Use apache 1.3.28 which actually works.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.