PHP :: Bug #22519 :: Apache catches SEGV

[2003-03-03 09:43 UTC] thomas dot mieslinger at gls-germany dot com

Hello,

In the errorlog of my Apache 1.3.27 I see these messages:

/export/opt/local/src/php-4.3.1/ext/informix/ifx.ec(2998) :  Freeing 0x08836314 (89 bytes), script=/export/web/htdocs-depotadm-v2/ww/export/opt/local/src/php-4.3.1/ext/informix/ifx.ec(2875) :  Freeing 0x08836FBC (84 bytes), script=/export/web/htdocs-depotadm-v2/ww/export/opt/local/src/php-4.3.1/ext/informix/ifx.ec(2998) :  Freeing 0x0839558C (266 bytes), script=/export/web/htdocs-depotadm-v2/w/export/opt/local/src/php-4.3.1/ext/informix/ifx.ec(2981) :  Freeing 0x08395504 (84 bytes), script=/export/web/htdocs-depotadm-v2/ww/export/opt/local/src/php-4.3.1/ext/informix/ifx.ec(2875) :  Freeing 0x08394F54 (84 bytes), script=/export/web/htdocs-depotadm-v2/ww[Mon Mar  3 15:07:02 2003] [notice] child pid 6240 exit signal Segmentation Fault (11)

When running in gdb I get this stacktrace
Starting program: /usr/local/apache/bin/httpd -f
/etc/apache/httpd.conf-test -X
[New LWP    2        ]
[New LWP    3        ]
[New LWP    4        ]
[New LWP    5        ]

Program received signal SIGSEGV, Segmentation fault.
0xdf8dcbce in memmove ()
(gdb) bt
#0  0xdf8dcbce in memmove ()
#1  0xdfbab6b3 in _sqlocwrite ()
#2  0xdfb9bfa3 in _sqg_blob ()
#3  0xdfba7b57 in _iqupdtargs ()
#4  0xdfba6650 in _iqftch ()
#5  0xdfba5ea4 in sqli_curs_fetch ()
#6  0x80db1f1 in zif_ifx_fetch_row (ht=1, return_value=0x87f1104,
this_ptr=0x0, return_value_used=1)
    at /export/opt/local/src/php-4.3.1/ext/informix/ifx.ec:1703
#7  0x80c42d0 in execute (op_array=0x8592ac8) at
/export/opt/local/src/php-4.3.1/Zend/zend_execute.c:1596
#8  0x80c44d0 in execute (op_array=0x887fb9c) at
/export/opt/local/src/php-4.3.1/Zend/zend_execute.c:1640
#9  0x80b3879 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /export/opt/local/src/php-4.3.1/Zend/zend.c:864
#10 0x8087290 in php_execute_script (primary_file=0x80477a8) at
/export/opt/local/src/php-4.3.1/main/main.c:1573
#11 0x80c923a in apache_php_module_main (r=0x82f1054,
display_source_mode=0)
    at /export/opt/local/src/php-4.3.1/sapi/apache/sapi_apache.c:55
#12 0x807d4a2 in send_php ()
#13 0x807d4f6 in send_parsed_php ()
#14 0x81b2131 in ap_invoke_handler ()
#15 0x81c82d4 in process_request_internal ()
#16 0x81c833e in ap_process_request ()
#17 0x81beaeb in child_main ()
#18 0x81becb5 in make_child ()
#19 0x81bee2e in startup_children ()
#20 0x81bf474 in standalone_main ()
#21 0x81bfce4 in main ()
#22 0x806e69b in _start ()

While creating a html Document the apache Process dies due to a Problem in the PHP/informix Code.

We're on IDS 7.31UC6X4 with ClientSDK 2.40UC1.

phpinfo:
System SunOS gpname 5.7 Generic_106542-23 i86pc
Build Date Feb 20 2003 11:15:07
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

[2003-03-19 10:15 UTC] thomas dot mieslinger at gls-germany dot com

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 $

[2003-03-19 11:28 UTC] sniper@php.net

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." ??

[2003-03-20 02:19 UTC] thomas dot mieslinger at gls-germany dot com

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.

[2003-08-20 12:02 UTC] thomas dot mieslinger at gls-germany dot com

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

[2003-08-20 17:44 UTC] sniper@php.net

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

[2003-08-20 17:45 UTC] sniper@php.net

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

[2003-08-26 00:56 UTC] sniper@php.net

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.

Patches

Pull Requests

History

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Fri Apr 19 18:01:28 2024 UTC