Bug #50512 [Com]: Yuml is missing in HTML translation table

[neil at weboutreach dot co dot uk]

Edit report at http://bugs.php.net/bug.php?id=50512edit=1

 ID: 50512
 Comment by: neil at weboutreach dot co dot uk
 Reported by:anotherhero at gmail dot com
 Summary:Yuml is missing in HTML translation table
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   *
 PHP Version:5.*, 6
 Block user comment: N
 Private report: N

 New Comment:

It appears also that the following are missing:



lsquo;

rsquo;

ldquo;

rdquo;


Previous Comments:

[2009-12-18 10:52:14] anotherhero at gmail dot com

Not that I've noticed, at least none that got a lower case variant but
missing their upper case relative or visa versa.


[2009-12-18 09:20:04] j...@php.net

Indeed it is missing. Any idea if any other such are missing there?
Quick look would suggest there aren't but.. :)


[2009-12-18 07:26:10] anotherhero at gmail dot com

Description:

The HTML entity for Ÿ which is Yuml; is missing

Reproduce code:
---
?php

var_dump(get_html_translation_table(HTML_ENTITIES));

Expected result:

I expect the capital version of yuml; which is in there to be also in
there.







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50512edit=1

#43506 [Com]: com_get_active_object always fails

[tom dot neil dot bell at gmail dot com]

 ID:   43506
 Comment by:   tom dot neil dot bell at gmail dot com
 Reported By:  bvandermerwe at kbcat dot com
 Status:   Open
 Bug Type: COM related
 Operating System: Windows XP
 PHP Version:  5.2.5
 New Comment:

Suffered this issue today trying enumerate a internet explorer 
window. Turns out Internet Explorer doesn't register it self with the 
Running Object Table so this function returns that error. 

Work arounds are to either create a Browser Helper Object that will 
add the IE instance to the ROT, or enumerate all windows via the 
Shell.Application COM and iterate through them looking for 
iexplore.exe . 

Tom


Previous Comments:


[2007-12-05 18:14:58] bvandermerwe at kbcat dot com

Description:

com_get_active_object always returns Operation Unavailable  even when
it should work for sure. Let me demonstrate:

Start up Microsoft Word (for example) on the server machine where
Apache and PHP are running. Then put the following text in a file called
x.vbs:

Dim app
Set app = GetObject(,Word.Application)
if app is nothing then
   wscript.echo Got nothing
else
   wscript.echo Got it!
end if

Execute it by typing: cscript x.vbs.
Note that it works fine. Yet the following line in a PHP script always
returns Operation Unavailable :

$obj = com_get_active_object(Word.Application); 

Using: $obj = new COM(Word.Application) works (meaning PHP COM is
working).

I just upgraded Apache to 2.2.6 and PHP 5.2.5 (using the Windows
installation executable binaries with pretty much default settings,
except PHP is in c:\PHP525 and I checked the options for MS and MYSQL
databases). Bugzilla and several PHP applications all work fine. 

But it seems com_get_active_object *always* fails. I have Googled and I
can not find any examples of it out there or any security or other
settings related to it.

If it just calls GetObject, then how come calling GetObject from
VBScript works but in PHP does not? I did discover that some GetObject
calls are disabled under IIS for security reasons, but I am using Apache
and there is no reference to any setting that needs to be turned on
before this will work.

Reproduce code:
---
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml; lang=en-US
head
meta http-equiv=Content-Type content=text/html; charset=iso-8859-1
/
titleTest/title
/head
body
?php
  echo(pAttempting to retrieve COM Object/p);
  $obj = com_get_active_object(Word.Application);  //Fails!  
  if ($obj) {
echo(pObject Found/p);
  } else {
echo(pObject NOT Found/p);
  }
?
/body
/html


Expected result:

No error. You should see:

Attempting to retrieve COM Object

Object Found

Actual result:
--
You see:

Attempting to retrieve COM Object

If PHP error tracing is enabled you also see:

Fatal error: Uncaught exception 'com_exception' with message 'Operation
unavailable ' in C:\ApacheDocumentRoot\test_com.php:10 Stack trace: #0
C:\ApacheDocumentRoot\test_com.php(10):
com_get_active_object('Word.Application') #1 {main} thrown in
C:\ApacheDocumentRoot\test_com.php on line 10





-- 
Edit this bug report at http://bugs.php.net/?id=43506edit=1

#44645 [Com]: php5ts.dll Crash (x86_64 base machines)

[neil dot smith at coull dot com]

 ID:   44645
 Comment by:   neil dot smith at coull dot com
 Reported By:  gary dot wilson at coull dot biz
 Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: Windows Server 2003
 PHP Version:  5.2.5
 New Comment:

[5 Jul 12:38pm UTC] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes

[3 Jun 4:11pm UTC] neil dot smith at coull dot com

Debug backtrace was already provided on 3rd June as required - was that
not the information you were requesting ? 

Please consider reactivating this bug and reviewing the backtrace
provided. We can retry the repro case and provide additional information
if needed, but that appears to be what was requested.


Previous Comments:


[2008-07-18 21:30:55] madhav_2k at yahoo dot com

i am getting the same error as well. 

Httpd.exe - Application error

The instruction at xxx referenced memory at xxx. The memory
could not be read

This has completely halted my development and has pretty much rendered
PHP on my laptop unusable. 

I use a Dell Latitude with a Intel Centrino Duo Core processor running
Win2k Sp2. 

Software versions are MySQL 5.1 , Apache webserver 2.2 and Php 5.2.3 

This has become a major showstopper and a quick resolution is highly
desirable!!



[2008-07-13 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2008-07-05 12:38:11] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.

We also need the script. Is apache a x64 or x86 build (aka runs under
32bit or 64bit OS mode)?

If not already done, please use the pdb files (debug pack) so we can
see where it crashes (not only which functions).



[2008-07-05 12:23:26] donald dot lam at live dot com

This problem also occurred on my windows 2000 Pro system.
It was happened on installing phpBB with WAMP server and firebird DB.

Windows events log as following:
=
Event Type: Error
Event Source:   Application Error
Event Category: (100)
Event ID:   1000
Date:   2008/7/5
Time:   ‰ºŒß 08:12:04
User:   N/A
Computer:   XPDON
Description:
Faulting application httpd.exe, version 2.2.8.0, faulting module
php5ts.dll, version 5.2.6.6, fault address 0xb4f0.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
: 41 70 70 6c 69 63 61 74   Applicat
0008: 69 6f 6e 20 46 61 69 6c   ion Fail
0010: 75 72 65 20 20 68 74 74   ure  htt
0018: 70 64 2e 65 78 65 20 32   pd.exe 2
0020: 2e 32 2e 38 2e 30 20 69   .2.8.0 i
0028: 6e 20 70 68 70 35 74 73   n php5ts
0030: 2e 64 6c 6c 20 35 2e 32   .dll 5.2
0038: 2e 36 2e 36 20 61 74 20   .6.6 at 
0040: 6f 66 66 73 65 74 20 30   offset 0
0048: 30 30 30 62 34 66 30  000b4f0 


Apache log as following:
==
[Sat Jul 05 20:12:13 2008] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
[Sat Jul 05 20:12:14 2008] [notice] Apache/2.2.8 (Win32) PHP/5.2.6
configured -- resuming normal operations
[Sat Jul 05 20:12:14 2008] [notice] Server built: Jan 18 2008 00:37:19
[Sat Jul 05 20:12:14 2008] [notice] Parent: Created child process 3204
[Sat Jul 05 20:12:14 2008] [notice] Child 3204: Child process is
running
[Sat Jul 05 20:12:14 2008] [notice] Child 3204: Acquired the start
mutex.
[Sat Jul 05 20:12:14 2008] [notice] Child 3204: Starting 64 worker
threads.
[Sat Jul 05 20:12:14 2008] [notice] Child 3204: Starting thread to
listen on port 80.
[Sat Jul 05 20:13:37 2008] [notice] Parent: Received shutdown signal --
Shutting down the server.
[Sat Jul 05 20:13:37 2008] [notice] Child 3204: Exit event signaled.
Child process is ending.
[Sat Jul 05 20:13:38 2008] [notice] Child 3204: Released the start
mutex
[Sat Jul 05 20:13:39 2008] [notice] Child 3204: All worker threads have
exited.
[Sat Jul 05 20:13:39 2008] [notice] Child 3204: Child process is
exiting
[Sat Jul 05 20:13:39 2008] [notice] Parent: Child process

#44645 [Com]: php5ts.dll Crash (x86_64 base machines)

[neil dot smith at coull dot com]

 ID:   44645
 Comment by:   neil dot smith at coull dot com
 Reported By:  gary dot wilson at coull dot biz
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows Server 2003
 PHP Version:  5.2.5
 New Comment:

Correction to last statement : 

Adding memcache caching of DB response resulted in non-repro

DB requests were not fully removed in the test harness code. With DB
requests prevented, this bug is still repro under high request loads (so
it not specifically MySQL / DB connection dependent).

Fault address remains at 0x926a in php5ts.dll


Previous Comments:


[2008-06-03 16:11:02] neil dot smith at coull dot com

The following should be a crash dump illustrating the problem.

It was generated as per instructions Generating backtrace without
compiler at http://bugs.php.net/bugs-generating-backtrace-win32.php


Configuration : Apache/2.2.3 (Win32) PHP/5.2.5, WinXP SP3


The isue occurred during load testing using JMeter on a script which
made moderate MySQL use and medium-heavy XML DOM node creation.

Adding memcache caching of DB response resulted in non-repro, which IMO
may indicate some involvement of number of DB connections or similar
(running script threads between them had around 876 instances of DB
connections in
TCP   192.168.2.38:3061192.168.2.15:3306   TIME_WAIT state)



==  Follows  =


 
 Analysis Summary  
  Type Description Recommendation 
  Error WARNING - DebugDiag was not able to locate debug symbols for
php5ts.dll, so the information below may be incomplete.



In
httpd__PID__3584__Date__06_03_2008__Time_04_57_08PM__928__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!zend_mm_shutdown+f49 in
C:\Applications\php5\php5ts.dll from The PHP Group has caused an access
violation exception (0xC005) when trying to read from memory
location 0x000c on thread 246
 Please follow up with the vendor The PHP Group for
C:\Applications\php5\php5ts.dll
 
  Information DebugDiag determined that this dump file
(httpd__PID__3584__Date__06_03_2008__Time_04_57_08PM__928__Second_Chance_Exception_C005.dmp)
is a crash dump and did not perform any hang analysis. If you wish to
enable combined crash and hang analysis for crash dumps, edit the
CrashHangAnalysis.asp script (located in the DebugDiag\Scripts folder)
and set the g_DoCombinedAnalysis constant to True.   
 
 


 
 Analysis Details  
  


 Your browser settings are currently prohibiting this report's scripts
from running.

This is preventing some features of this analysis report from
displaying properly. To enable scripts to run, right-click the security
warning above and choose Allow Blocked Content... or enable the Allow
active content to run in files on My Computer* setting on the Advanced
tab of your Internet Options dialog to avoid being prompted in the
future 





Table Of Contents
httpd__PID__3584__Date__06_03_2008__Time_04_57_08PM__928__Second_Chance_Exception_C005.dmp

   Faulting Thread

   Faulting Module Information



 Report for
httpd__PID__3584__Date__06_03_2008__Time_04_57_08PM__928__Second_Chance_Exception_C005.dmp




Report for
httpd__PID__3584__Date__06_03_2008__Time_04_57_08PM__928__Second_Chance_Exception_C005.dmp
Type of Analysis Performed   Crash Analysis 
Machine Name   DEVBOX_NS 
Operating System   Windows XP Service Pack 2 
Number Of Processors   2 
Process ID   3584 
Process Image   C:\Applications\Apache2.2\bin\httpd.exe 
System Up-Time   06:41:14 
Process Up-Time   00:00:05 


Thread 246 - System ID 3348
Entry point   msvcrt!_endthreadex+3a 
Create time   03/06/2008 16:57:04 
Time spent in user mode   0 Days 0:0:0.187 
Time spent in kernel mode   0 Days 0:0:0.78 






Function Arg 1 Arg 2 Arg 3   Source 
php5ts!zend_mm_shutdown+f49 058ab930 0003 100b5f17
php5ts!efree+39 008ca860 069f8c4c 10095f13
php5ts!zval_dtor_func+27 008ca848 069f8c65 100993d3
php5ts!zval_ptr_dtor+23 069f8c4c 069f8a38 069f8bc0
php5ts!zend_hash_add_or_update+1b3 069f8be8 102c6940
0005
php5ts!zend_reflection_class_factory+215d 06977098 05f72178

php5ts!zend_reflection_class_factory+204d  069f89d8

php5ts!execute_internal+37 0530f674 0001 058aa688
php_xdebug_2_0_3_5_2_5!get_module+367c 0530f674 0001

php5ts!execute+a37 0530f674 058aa688 1001c3e5
php5ts!execute+245 069d96d0 058aa688 0530f748
php_xdebug_2_0_3_5_2_5!get_module+27ff 069d96d0 058aa688
05f89340
php5ts!execute+b48 0530f748 058aa688 1001c3e5
php5ts!execute+245 05f89340 058aa688 0530f81c
php_xdebug_2_0_3_5_2_5!get_module+27ff 05f89340 058aa688
05f8aea0
php5ts

#44645 [Com]: php5ts.dll Crash (x86_64 base machines)

[neil dot smith at coull dot com]

 ID:   44645
 Comment by:   neil dot smith at coull dot com
 Reported By:  gary dot wilson at coull dot biz
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows Server 2003
 PHP Version:  5.2.5
 New Comment:

The following should be a crash dump illustrating the problem.

It was generated as per instructions Generating backtrace without
compiler at http://bugs.php.net/bugs-generating-backtrace-win32.php


Configuration : Apache/2.2.3 (Win32) PHP/5.2.5, WinXP SP3


The isue occurred during load testing using JMeter on a script which
made moderate MySQL use and medium-heavy XML DOM node creation.

Adding memcache caching of DB response resulted in non-repro, which IMO
may indicate some involvement of number of DB connections or similar
(running script threads between them had around 876 instances of DB
connections in
TCP   192.168.2.38:3061192.168.2.15:3306   TIME_WAIT state)



==  Follows  =


 
 Analysis Summary  
  Type Description Recommendation 
  Error WARNING - DebugDiag was not able to locate debug symbols for
php5ts.dll, so the information below may be incomplete.



In
httpd__PID__3584__Date__06_03_2008__Time_04_57_08PM__928__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!zend_mm_shutdown+f49 in
C:\Applications\php5\php5ts.dll from The PHP Group has caused an access
violation exception (0xC005) when trying to read from memory
location 0x000c on thread 246
 Please follow up with the vendor The PHP Group for
C:\Applications\php5\php5ts.dll
 
  Information DebugDiag determined that this dump file
(httpd__PID__3584__Date__06_03_2008__Time_04_57_08PM__928__Second_Chance_Exception_C005.dmp)
is a crash dump and did not perform any hang analysis. If you wish to
enable combined crash and hang analysis for crash dumps, edit the
CrashHangAnalysis.asp script (located in the DebugDiag\Scripts folder)
and set the g_DoCombinedAnalysis constant to True.   
 
 


 
 Analysis Details  
  


 Your browser settings are currently prohibiting this report's scripts
from running.

This is preventing some features of this analysis report from
displaying properly. To enable scripts to run, right-click the security
warning above and choose Allow Blocked Content... or enable the Allow
active content to run in files on My Computer* setting on the Advanced
tab of your Internet Options dialog to avoid being prompted in the
future 





Table Of Contents
httpd__PID__3584__Date__06_03_2008__Time_04_57_08PM__928__Second_Chance_Exception_C005.dmp

   Faulting Thread

   Faulting Module Information



 Report for
httpd__PID__3584__Date__06_03_2008__Time_04_57_08PM__928__Second_Chance_Exception_C005.dmp




Report for
httpd__PID__3584__Date__06_03_2008__Time_04_57_08PM__928__Second_Chance_Exception_C005.dmp
Type of Analysis Performed   Crash Analysis 
Machine Name   DEVBOX_NS 
Operating System   Windows XP Service Pack 2 
Number Of Processors   2 
Process ID   3584 
Process Image   C:\Applications\Apache2.2\bin\httpd.exe 
System Up-Time   06:41:14 
Process Up-Time   00:00:05 


Thread 246 - System ID 3348
Entry point   msvcrt!_endthreadex+3a 
Create time   03/06/2008 16:57:04 
Time spent in user mode   0 Days 0:0:0.187 
Time spent in kernel mode   0 Days 0:0:0.78 






Function Arg 1 Arg 2 Arg 3   Source 
php5ts!zend_mm_shutdown+f49 058ab930 0003 100b5f17
php5ts!efree+39 008ca860 069f8c4c 10095f13
php5ts!zval_dtor_func+27 008ca848 069f8c65 100993d3
php5ts!zval_ptr_dtor+23 069f8c4c 069f8a38 069f8bc0
php5ts!zend_hash_add_or_update+1b3 069f8be8 102c6940
0005
php5ts!zend_reflection_class_factory+215d 06977098 05f72178

php5ts!zend_reflection_class_factory+204d  069f89d8

php5ts!execute_internal+37 0530f674 0001 058aa688
php_xdebug_2_0_3_5_2_5!get_module+367c 0530f674 0001

php5ts!execute+a37 0530f674 058aa688 1001c3e5
php5ts!execute+245 069d96d0 058aa688 0530f748
php_xdebug_2_0_3_5_2_5!get_module+27ff 069d96d0 058aa688
05f89340
php5ts!execute+b48 0530f748 058aa688 1001c3e5
php5ts!execute+245 05f89340 058aa688 0530f81c
php_xdebug_2_0_3_5_2_5!get_module+27ff 05f89340 058aa688
05f8aea0
php5ts!execute+b48 0530f81c 058aa688 1001c3e5
php5ts!execute+245 05f8aea0 058aa688 0530f8f0
php_xdebug_2_0_3_5_2_5!get_module+27ff 05f8aea0 058aa688
05edebb0
php5ts!execute+b48 0530f8f0 058aa688 1001c3e5
php5ts!execute+245 05edebb0 058aa688 05f65d10
php_xdebug_2_0_3_5_2_5!get_module+27ff 05edebb0 058aa688
05a10d50
php5ts!execute+e3a8 104b4ce0 1001e005 05f61d78
php5ts!execute+1e33

#38613 [Fbk-Opn]: SNMP issues via Apache but ok via PHP CLI

[neil at fissure dot net]

 ID:   38613
 User updated by:  neil at fissure dot net
 Reported By:  neil at fissure dot net
-Status:   Feedback
+Status:   Open
 Bug Type: SNMP related
 Operating System: CentOS release 4.3
 PHP Version:  5.1.5
 New Comment:

I figured it was a PHP issue as it matched a similar bug 
report which was acknowledged to be due to a code change 
in PHP.

In that bug, sniper AT php.net, who make the change, 
said they were using Apache 2 (and would test with 
Apache 1.x if they got a chance). So I'm figuring this 
issue lies with PHP and Apache 1.x

I'm happy to do any requested testing/diagnostics if you 
can give me some pointers.

I'm getting the same errors as in bug 32680 (which was 
acknowledged to be a PHP issue, not say an Apache 
issue).

Thanks for your time, Neil.


Previous Comments:


[2006-08-28 06:22:20] [EMAIL PROTECTED]

Why do you think it's a PHP issue?




[2006-08-27 02:26:12] neil at fissure dot net

Description:

Similar to bug:
#32680  PHP_MSHUTDOWN PHP_MINIT

PHP gives errors when used as an Apache Module, but the 
same source code works via PHP CLI

Reproduce code:
---
error_reporting(E_ALL);

$host = xxx;
$community = xxx;

$syscontact = snmpget($host, $community, system.sysName.0);

PRINT BR$syscontact\n;

Expected result:

BRSTRING: 7200

Actual result:
--
Warning: snmpget() [function.snmpget]: Could not open 
snmp connection: Unknown host in /usr/local/apache/
htdocs/xxx/snmpwalk.php3 on line 9

I'm running:
PHP Version 5.1.6
'./configure' '--with-mysql' '--with-mysqli' '--enable-
mbstring' '--with-zlib-dir=/usr' '--with-curl' '--with-
snmp' '--with-apache=../apache_1.3.37' '--enable-ucd-
snmp-hack'

('--enable-ucd-snmp-hack' was added in troubleshooting)

Using:
Name   : net-snmp
Arch   : i386
Version: 5.1.2
Release: 11.EL4.6

Once, but only once stracing the httpd process, I saw:
write(2, No support for requested transpo..., 48) = 48
which I believe came from net-snmp





-- 
Edit this bug report at http://bugs.php.net/?id=38613edit=1

#38613 [Opn]: SNMP issues via Apache but ok via PHP CLI

[neil at fissure dot net]

 ID:   38613
 User updated by:  neil at fissure dot net
 Reported By:  neil at fissure dot net
 Status:   Open
 Bug Type: SNMP related
 Operating System: CentOS release 4.3
 PHP Version:  5.1.5
 New Comment:

Commenting out this line, in the 
PHP_MSHUTDOWN_FUNCTION(snmp) function of:
src/web/php-5.1.6/ext/snmp/snmp.c

diff snmp.c snmp.c.orig 
223c223
 /*snmp_shutdown(snmpapp); */
---
   snmp_shutdown(snmpapp);

but possibly at the risk of re-introducing the memory 
leak it was added to combat?


Previous Comments:


[2006-08-30 16:56:20] neil at fissure dot net

I figured it was a PHP issue as it matched a similar bug 
report which was acknowledged to be due to a code change 
in PHP.

In that bug, sniper AT php.net, who make the change, 
said they were using Apache 2 (and would test with 
Apache 1.x if they got a chance). So I'm figuring this 
issue lies with PHP and Apache 1.x

I'm happy to do any requested testing/diagnostics if you 
can give me some pointers.

I'm getting the same errors as in bug 32680 (which was 
acknowledged to be a PHP issue, not say an Apache 
issue).

Thanks for your time, Neil.



[2006-08-28 06:22:20] [EMAIL PROTECTED]

Why do you think it's a PHP issue?




[2006-08-27 02:26:12] neil at fissure dot net

Description:

Similar to bug:
#32680  PHP_MSHUTDOWN PHP_MINIT

PHP gives errors when used as an Apache Module, but the 
same source code works via PHP CLI

Reproduce code:
---
error_reporting(E_ALL);

$host = xxx;
$community = xxx;

$syscontact = snmpget($host, $community, system.sysName.0);

PRINT BR$syscontact\n;

Expected result:

BRSTRING: 7200

Actual result:
--
Warning: snmpget() [function.snmpget]: Could not open 
snmp connection: Unknown host in /usr/local/apache/
htdocs/xxx/snmpwalk.php3 on line 9

I'm running:
PHP Version 5.1.6
'./configure' '--with-mysql' '--with-mysqli' '--enable-
mbstring' '--with-zlib-dir=/usr' '--with-curl' '--with-
snmp' '--with-apache=../apache_1.3.37' '--enable-ucd-
snmp-hack'

('--enable-ucd-snmp-hack' was added in troubleshooting)

Using:
Name   : net-snmp
Arch   : i386
Version: 5.1.2
Release: 11.EL4.6

Once, but only once stracing the httpd process, I saw:
write(2, No support for requested transpo..., 48) = 48
which I believe came from net-snmp





-- 
Edit this bug report at http://bugs.php.net/?id=38613edit=1

#38613 [NEW]: SNMP issues via Apache but ok via PHP CLI

[neil at fissure dot net]

From: neil at fissure dot net
Operating system: CentOS release 4.3
PHP version:  5.1.5
PHP Bug Type: SNMP related
Bug description:  SNMP issues via Apache but ok via PHP CLI

Description:

Similar to bug:
#32680  PHP_MSHUTDOWN PHP_MINIT

PHP gives errors when used as an Apache Module, but the 
same source code works via PHP CLI

Reproduce code:
---
error_reporting(E_ALL);

$host = xxx;
$community = xxx;

$syscontact = snmpget($host, $community, system.sysName.0);

PRINT BR$syscontact\n;

Expected result:

BRSTRING: 7200

Actual result:
--
Warning: snmpget() [function.snmpget]: Could not open 
snmp connection: Unknown host in /usr/local/apache/
htdocs/xxx/snmpwalk.php3 on line 9

I'm running:
PHP Version 5.1.6
'./configure' '--with-mysql' '--with-mysqli' '--enable-
mbstring' '--with-zlib-dir=/usr' '--with-curl' '--with-
snmp' '--with-apache=../apache_1.3.37' '--enable-ucd-
snmp-hack'

('--enable-ucd-snmp-hack' was added in troubleshooting)

Using:
Name   : net-snmp
Arch   : i386
Version: 5.1.2
Release: 11.EL4.6

Once, but only once stracing the httpd process, I saw:
write(2, No support for requested transpo..., 48) = 48
which I believe came from net-snmp

-- 
Edit bug report at http://bugs.php.net/?id=38613edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38613r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38613r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38613r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38613r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38613r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38613r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38613r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38613r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38613r=support
Expected behavior:http://bugs.php.net/fix.php?id=38613r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38613r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38613r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38613r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38613r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38613r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38613r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38613r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38613r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38613r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38613r=mysqlcfg

#30818 [NEW]: CLI Access Violation in XP

[neil dot r dot haslewood at web dot de]

From: neil dot r dot haslewood at web dot de
Operating system: Windows XP Pro (SP2 build 2600)
PHP version:  5.0.2
PHP Bug Type: CGI related
Bug description:  CLI Access Violation in XP

Description:

cscript /nologo configure.js --enable-snapshot-build --with-gd=shared

PHP API 20031224
PHP Extension   20040412

Tried enclosed from command line and encountered the following several
times:

Windows Error Report Popup states:
'CLI has encountered a problem and needs to close'

Visual C++ debugger traps error:
'Unhandled exception in php.exe (PHP5TS.DLL): 0xC005: Access
Violation'

Reproduce code:
---
C:\Documents and Settings\Mephp -a
Interactive mode enabled
?php
$s1 = 'ababab abab ab ab';
$s2 = abbaaab bbaab aaba;
$r = /^((ab)+\s)*(ab)+$/;
if(preg_match($r, $s1)){
echo $s1 valid;
}
else{
echo $s2 invalid;
}
ababab abab ab ab valid

Windows Error Report Popup then reveals:
'CLI has encountered a problem and needs to close'

Visual C debugger traps error

Expected result:

$s1 valid


-- 
Edit bug report at http://bugs.php.net/?id=30818edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=30818r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=30818r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=30818r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30818r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30818r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=30818r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=30818r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=30818r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30818r=support
Expected behavior:   http://bugs.php.net/fix.php?id=30818r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=30818r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=30818r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30818r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=30818r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30818r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=30818r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30818r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=30818r=float
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=30818r=mysqlcfg

#29370 [Com]: Crash apache.exe (php5ts.dll)

[neil at ncsconsulting dot com]

 ID:   29370
 Comment by:   neil at ncsconsulting dot com
 Reported By:  anthony dot debhian at only-for dot info
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Windows XP
 PHP Version:  5.0.0
 New Comment:

This crash still happens with 4.3.9RC1. 
I haven't tried php5 yet


Previous Comments:


[2004-08-11 08:14:44] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

This works fine for me here...



[2004-08-11 04:08:38] neil at ncsconsulting dot com

Confirming on Redhat 9, apache 1.3.31, php 4.3.8 
 
running php crash.php gives segfault.  Running through 
apache gives dreaded 'child exit signal segfault'. 
 
Program received signal SIGSEGV, Segmentation fault. 
[Switching to Thread 1080494848 (LWP 26212)] 
0x081b555a in _efree () 
(gdb) bt 
#0  0x081b555a in _efree () 
#1  0x081c9e7f in zend_hash_destroy () 
#2  0x081c3aa5 in _zval_dtor () 
#3  0x081bcbbc in _zval_ptr_dtor () 
#4  0x081d3682 in execute () 
#5  0x081d447d in execute () 
#6  0x081c53bf in zend_execute_scripts () 
#7  0x08198d0e in php_execute_script () 
#8  0x081e341f in main () 
#9  0x42015704 in __libc_start_main () 
from /lib/tls/libc.so.6



[2004-08-10 17:44:07] hazer at chipshot dot net

Reproducable on Apache 2.0.48 mod_ssl OpenSSL0.9.7c PHP 5.0.0 Linux
Kernel 2.6.7 GCC 3.2.2

Run through CLI it gives a seg fault.

Viewed via web it gives nothing, even if there is something to be
output before the code in question. It doesn't look like we can expect
this to be used for 'hiding' pages on the server, but there is
something that needs to be looked at...



[2004-08-09 22:41:52] brian at centurionservice dot com

Confirmed bug on RedHat 9, Apache 2.0.50, PHP 4.3.8. Reports a
segmentation fault in the Apache error log and no entry in the access
log. httpd seems to recover fine with no user interaction nessesary.

Seg fault if ran through the CLI version on RedHat 9, PHP 4.3.8.

Crashes on Windows XP, PHP 5 using the CLI version.



[2004-08-09 17:31:34] sbrown at truckstuffusa dot com

Sorry, fogot to mention I'm running Redhat 9 here.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/29370

-- 
Edit this bug report at http://bugs.php.net/?id=29370edit=1

#29370 [Com]: Crash apache.exe (php5ts.dll)

[neil at ncsconsulting dot com]

 ID:   29370
 Comment by:   neil at ncsconsulting dot com
 Reported By:  anthony dot debhian at only-for dot info
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP
 PHP Version:  5.0.0
 New Comment:

Confirming on Redhat 9, apache 1.3.31, php 4.3.8 
 
running php crash.php gives segfault.  Running through 
apache gives dreaded 'child exit signal segfault'. 
 
Program received signal SIGSEGV, Segmentation fault. 
[Switching to Thread 1080494848 (LWP 26212)] 
0x081b555a in _efree () 
(gdb) bt 
#0  0x081b555a in _efree () 
#1  0x081c9e7f in zend_hash_destroy () 
#2  0x081c3aa5 in _zval_dtor () 
#3  0x081bcbbc in _zval_ptr_dtor () 
#4  0x081d3682 in execute () 
#5  0x081d447d in execute () 
#6  0x081c53bf in zend_execute_scripts () 
#7  0x08198d0e in php_execute_script () 
#8  0x081e341f in main () 
#9  0x42015704 in __libc_start_main () 
from /lib/tls/libc.so.6


Previous Comments:


[2004-08-10 17:44:07] hazer at chipshot dot net

Reproducable on Apache 2.0.48 mod_ssl OpenSSL0.9.7c PHP 5.0.0 Linux
Kernel 2.6.7 GCC 3.2.2

Run through CLI it gives a seg fault.

Viewed via web it gives nothing, even if there is something to be
output before the code in question. It doesn't look like we can expect
this to be used for 'hiding' pages on the server, but there is
something that needs to be looked at...



[2004-08-09 22:41:52] brian at centurionservice dot com

Confirmed bug on RedHat 9, Apache 2.0.50, PHP 4.3.8. Reports a
segmentation fault in the Apache error log and no entry in the access
log. httpd seems to recover fine with no user interaction nessesary.

Seg fault if ran through the CLI version on RedHat 9, PHP 4.3.8.

Crashes on Windows XP, PHP 5 using the CLI version.



[2004-08-09 17:31:34] sbrown at truckstuffusa dot com

Sorry, fogot to mention I'm running Redhat 9 here.



[2004-08-09 17:30:27] sbrown at truckstuffusa dot com

Confirmed this condition also exists on php 4.3.8 on Apache 2.0.50. 
Ran both segments of code given below.  Each time the output of the
script was good, but there was no access/error log generated by Apache.



[2004-08-09 11:12:16] mart at __no_spam__spin dot ee

I got the crach with PHP 4.3.7 + Apache 1.3.31 + Linux
and PHP 4.3.4 + Apache 2.0.47 + Linux RH9.
It didn't work with PHP 4.3.5 + Apache 1.3.29 + Win2K.

A bit minimized version of this crash code:
?php
 function funcfunc($array){
  foreach($array as $key=$value) { $src.=$key; }
  return $src;
 }

 function funcfunc2($array){
  foreach($array['foo'] as $key=$value) { }
 }

 $a['x']['y']=;
 $array=funcfunc($a);
 funcfunc2($array);
?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/29370

-- 
Edit this bug report at http://bugs.php.net/?id=29370edit=1

#11058 [Com]: php_network_getaddresses: getaddrinfo failed

[neil dot giarratana at lucidus dot net]

 ID:   11058
 Comment by:   neil dot giarratana at lucidus dot net
 Reported By:  pat at mail dot rit dot edu
 Status:   Bogus
 Bug Type: Network related
 Operating System: OpenBSD 2.6
 PHP Version:  4.0.6
 New Comment:

Don't know if this helps at all but on RH9, if I do a service network
restart, all is well again and I don't get that error anymore. Beats
the heck out of restarting the whole server


Previous Comments:


[2004-06-30 18:17:09] webmaster at hg-carstyling dot de

i have that problem, too, on 4 machines running RH9, FC1 and FC2. I
spend some whole days to solve it, but cannot get the basic of this
problem.

On 1 machine i have serveral virt. domains, were i enter the hostnames
of 2 domains in /etc/hosts, what results in a fix on one domain,
another domain on the same machine was not affected and the error stays
as bevor.

I Tryed out, to fix my /var/named/my.stupid.zone, were i found a
missconfiguration by redhat-config-bind. I fix the config, checked my
nameserver out and hes runnin fine with no errors, but the getadress
error stays as bevor and was not affected. I am not really sure, if my
dns is perfectly configured, but i get no errors there and funcionality
is given, expecting the getadress error by php.

Over that, i cannot see anybody, who has full fixed this problem , so
its a discussion worth, but where ?!

I thing, it makes sense, if the Developers, that does or maintain the
filesocket functions of php, has a deeper look in this Problem, even if
its not php based, but they will have a clear overview, of what happened
and maybe they can give us a hint. What about the sockets ?

I thing, it is any incompatibility btw. named and the network classes
of php, especaially php mail and file network structures or classes,
maybe sockets ?!

On RH8 there are no such errors. In any case, this costs lotsa time :(
...



[2004-06-10 14:40:34] austinputman at hotmail dot com

I had the same problem as pat at mail dot rit dot edu using
fsockopen().

He/she uses:

fsockopen(http://www.php.net/;, 80, $errno, $errstr, 30);

But you shouldn't use 'http://' in the server name part. So use this
instead.

fsockopen(www.php.net, 80, $errno, $errstr, 30);

Maybe this will not solve everybodies problem, but it sure solved mine.



[2004-05-26 21:45:26] jpipes1 at columbus dot rr dot com

We have this darn error occur once every few months; our site relies
heavily on fopen's to URL resources on our own servers (to separate
templates out...), and I have run into these darn errors with
absolutely no help from anyone on any forums.  This error is NOT fixed.
 It has to do with something that changed from 4.0.16 to 4.3.4 on Apache
1.3.27 running RedHat 9 too.  Please somebody look into this problem.  

Errors only happen once out of every, say, 20 times, and it always
issues the getaddrinfo failed warnings.  Then, the warnings start to
happen more and more frequently, on code that has been unchanged in
months.  Finally, a restart clears it and we go on for a few months til
another restart.

I'm not a C programmer or a Linux guru and I wouldn't know where to
start with debugging this stuff, but if someone could take a look at
it, it would be helpful.  Navigating around these bug indexes is
driving me nuts...

Sounds like some sort of memory leak or something (i.e. the warnings
happening after quite some time, then more frequently until a
restart...)



[2004-05-13 00:34:48] cosas at minovela dot com

i've just installed redhat 9, then the latest version of mysql, php and
apache, and i got the error when i tried to run my scripts...



[2004-05-13 00:32:49] cosas at minovela dot com

so nobody give us a solution? 
i can't upgrade to latest version if i want to use fsockopen :(



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/11058

-- 
Edit this bug report at http://bugs.php.net/?id=11058edit=1

#27852 [NEW]: mktime does not work when DST kicks in

[neil dot walker at syntegra dot com]

From: neil dot walker at syntegra dot com
Operating system: any
PHP version:  Irrelevant
PHP Bug Type: Date/time related
Bug description:  mktime does not work when DST kicks in

Description:

Hello,



The following code



Code:



?php

   $n=date(w,mktime(0,0,0,3,29,2004));

   echo pre;

   for($i=1;$i32;$i++)

   {

  $d=date(D dS M Y,mktime(0,0,0,3,$i,2004));

  $n=date(w,mktime(0,0,0,3,$i,2004));

  echo $d,: day of week is $nbr /;

   }

   echo /pre;

?





Outputs the details of March this year. Look at 28th March. It thinks it’s
the 27th! Now I know this is the change to daylight saving but mktime says
all should be well! However, if I change the hour to be 12 (right smack in
the middle) it gets the week day right (0 and not 6) but it still thinks
its Saturday.  I'm in the UK and the clocks changed on this day.





Mon 01st Mar 2004: day of week is 1

Tue 02nd Mar 2004: day of week is 2

Wed 03rd Mar 2004: day of week is 3

Thu 04th Mar 2004: day of week is 4

Fri 05th Mar 2004: day of week is 5

Sat 06th Mar 2004: day of week is 6

Sun 07th Mar 2004: day of week is 0

Mon 08th Mar 2004: day of week is 1

Tue 09th Mar 2004: day of week is 2

Wed 10th Mar 2004: day of week is 3

Thu 11th Mar 2004: day of week is 4

Fri 12th Mar 2004: day of week is 5

Sat 13th Mar 2004: day of week is 6

Sun 14th Mar 2004: day of week is 0

Mon 15th Mar 2004: day of week is 1

Tue 16th Mar 2004: day of week is 2

Wed 17th Mar 2004: day of week is 3

Thu 18th Mar 2004: day of week is 4

Fri 19th Mar 2004: day of week is 5

Sat 20th Mar 2004: day of week is 6

Sun 21st Mar 2004: day of week is 0

Mon 22nd Mar 2004: day of week is 1

Tue 23rd Mar 2004: day of week is 2

Wed 24th Mar 2004: day of week is 3

Thu 25th Mar 2004: day of week is 4

Fri 26th Mar 2004: day of week is 5

Sat 27th Mar 2004: day of week is 6

Sat 27th Mar 2004: day of week is 6

Mon 29th Mar 2004: day of week is 1

Tue 30th Mar 2004: day of week is 2

Wed 31st Mar 2004: day of week is 3





Reproduce code:
---
?php

   $n=date(w,mktime(0,0,0,3,29,2004));

   echo pre;

   for($i=1;$i32;$i++)

   {

  $d=date(D dS M Y,mktime(0,0,0,3,$i,2004));

  $n=date(w,mktime(0,0,0,3,$i,2004));

  echo $d,: day of week is $nbr /;

   }

   echo /pre;

?



Expected result:

the correct dates, refer to description

Actual result:
--
the wrong dates. refer to description

-- 
Edit bug report at http://bugs.php.net/?id=27852edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27852r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27852r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27852r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27852r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27852r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27852r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27852r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27852r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27852r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27852r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27852r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27852r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27852r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27852r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27852r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27852r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27852r=float

#22072 [Fbk-Opn]: connection_status() always returning 0

[neil at mpfreescene dot com]

 ID:   22072
 User updated by:  neil at mpfreescene dot com
 Reported By:  neil at mpfreescene dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: FREEBSD 4.7-STABLE
 PHP Version:  4.3.2
 New Comment:

Test the new CVS, it is still doing the same.


Previous Comments:


[2003-07-31 20:27:20] [EMAIL PROTECTED]

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-07-24 03:35:38] neil at mpfreescene dot com

Does PHP 5 include this bug, will this ever get fixed ?



[2003-02-19 10:48:26] jorgeg at gtsf dot com

Hope this helps. Two other functions affected:
ignore_user_abort(), connection_aborted()

The first one is useless, it keeps running the script regardless the
param has been set to true or false. The second one is always 0.

Apache 2.0.44, PHP 4.3.0, Windows 2k



[2003-02-06 04:36:28] neil at mpfreescene dot com

To further assist you in your diagnosis, I have supplied you with
additional parameters to the script that is failing.


Firstly you can run the script

http://www.mpfreescene.com/test/

Secondly you can see the source

http://www.mpfreescene.com/test/?option=source

Thirdly you can see phpinfo

http://www.mpfreescene.com/test/?option=info

Forthly you can see the output.txt file, i.e. the result of the failing
script :-

http://www.mpfreescene.com/test/?option=data




Just to recap, this identical script works fine on apache 1,  I have
been to apache they are pushing it back as an php error [the error they
found in an apache2 specific library maybe ?].  And the problem is I
run the script, whenI press stop, it continues to run in the background
and completes normally, i.e. it doesnt recogonise the user abort.



Thanks for your help in this matteer.



[2003-02-05 15:58:50] crockett at horizon dot bc dot ca

connection_status() always returns zero on Win32 4.3.0 running IIS.
Yes, ignore_user_abort(true) is set.

Bradley Crockett



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/22072

-- 
Edit this bug report at http://bugs.php.net/?id=22072edit=1

#22072 [Ver]: connection_status() always returning 0

[neil at mpfreescene dot com]

 ID:   22072
 User updated by:  neil at mpfreescene dot com
 Reported By:  neil at mpfreescene dot com
 Status:   Verified
 Bug Type: Apache2 related
 Operating System: FREEBSD 4.7-STABLE
 PHP Version:  4.3.2
 New Comment:

Does PHP 5 include this bug, will this ever get fixed ?


Previous Comments:


[2003-02-19 10:48:26] jorgeg at gtsf dot com

Hope this helps. Two other functions affected:
ignore_user_abort(), connection_aborted()

The first one is useless, it keeps running the script regardless the
param has been set to true or false. The second one is always 0.

Apache 2.0.44, PHP 4.3.0, Windows 2k



[2003-02-06 04:36:28] neil at mpfreescene dot com

To further assist you in your diagnosis, I have supplied you with
additional parameters to the script that is failing.


Firstly you can run the script

http://www.mpfreescene.com/test/

Secondly you can see the source

http://www.mpfreescene.com/test/?option=source

Thirdly you can see phpinfo

http://www.mpfreescene.com/test/?option=info

Forthly you can see the output.txt file, i.e. the result of the failing
script :-

http://www.mpfreescene.com/test/?option=data




Just to recap, this identical script works fine on apache 1,  I have
been to apache they are pushing it back as an php error [the error they
found in an apache2 specific library maybe ?].  And the problem is I
run the script, whenI press stop, it continues to run in the background
and completes normally, i.e. it doesnt recogonise the user abort.



Thanks for your help in this matteer.



[2003-02-05 15:58:50] crockett at horizon dot bc dot ca

connection_status() always returns zero on Win32 4.3.0 running IIS.
Yes, ignore_user_abort(true) is set.

Bradley Crockett



[2003-02-05 09:05:27] neil at mpfreescene dot com

This bug is effecting the connection_status() function in apache 2.x

Okay, getting back to a long standing bug, which we kind of come to the
conclusion last time that it may be a bug in apache 2.x because it
works in apache 1.

Well time has come on, I have submitted the bug to apache after they
fixed the incorrect bytes logged bug, and this is what they have come
up with :-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16426

ok, I've grabbed the current php source and looked into sapi_apache2.c.
It's
definitely a php bug. Line 90 shows:

if (ap_pass_brigade(f-next, bb) != APR_SUCCESS) {
php_handle_aborted_connection();
}

which won't match in most cases. Also Line 252 and 498.
AFAICS mod_php should (additionally) check connection-aborted.

(marking this bug invalid again)





-- 
Edit this bug report at http://bugs.php.net/?id=22072edit=1

#22072 [Ver]: connection_status() always returning 0

[neil at mpfreescene dot com]

 ID:   22072
 User updated by:  neil at mpfreescene dot com
 Reported By:  neil at mpfreescene dot com
 Status:   Verified
 Bug Type: Apache2 related
 Operating System: FREEBSD 4.7-STABLE
 PHP Version:  4.3.1-dev
 New Comment:

I see we are moving into new versions of php since this bug was
VERIFIED.

Have we any ETA for when it may be cured ?  Or has it already been
cured in newer versions ?


Previous Comments:


[2003-02-19 10:48:26] jorgeg at gtsf dot com

Hope this helps. Two other functions affected:
ignore_user_abort(), connection_aborted()

The first one is useless, it keeps running the script regardless the
param has been set to true or false. The second one is always 0.

Apache 2.0.44, PHP 4.3.0, Windows 2k



[2003-02-18 02:43:04] neil at mpfreescene dot com

Just checking in with you guys, does it look like a problem that will
be fixed any time soon ?

Im guessing that Status : Verified does mean that you too can see the
error I speak of ? :)



Many thanks.



[2003-02-06 04:36:28] neil at mpfreescene dot com

To further assist you in your diagnosis, I have supplied you with
additional parameters to the script that is failing.


Firstly you can run the script

http://www.mpfreescene.com/test/

Secondly you can see the source

http://www.mpfreescene.com/test/?option=source

Thirdly you can see phpinfo

http://www.mpfreescene.com/test/?option=info

Forthly you can see the output.txt file, i.e. the result of the failing
script :-

http://www.mpfreescene.com/test/?option=data




Just to recap, this identical script works fine on apache 1,  I have
been to apache they are pushing it back as an php error [the error they
found in an apache2 specific library maybe ?].  And the problem is I
run the script, whenI press stop, it continues to run in the background
and completes normally, i.e. it doesnt recogonise the user abort.



Thanks for your help in this matteer.



[2003-02-06 01:55:15] neil at mpfreescene dot com

Installed this morning, fresh.

Absolutley no difference whatso ever, not even a little bit, still the
same 0's being reported via connection_status when the stop button is
pressed.



[2003-02-05 16:08:19] [EMAIL PROTECTED]

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





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/22072

-- 
Edit this bug report at http://bugs.php.net/?id=22072edit=1

#14254 [Com]: SQLERROR -439

[neil dot wilkinson at transport dot nsw dot gov dot au]

 ID:   14254
 Comment by:   neil dot wilkinson at transport dot nsw dot gov dot au
 Reported By:  cedric dot boudin at iconmedialab dot com
 Status:   Closed
 Bug Type: Informix related
 Operating System: Solaris 8
 PHP Version:  4.0.6
 New Comment:

This problem still exists and does indeed occur most often when the
database is busy.

However, there will always be situations where the database is busy, so
increasing performance will only help in some situations.

The problem appears to be to do with how PHP responds to the callback
functions.  I believe that the apache and native ESQL libraries are bug
free in this respect because embedded perl, etc (hitting the same
database from the same machine using the same ESQL libraries) never has
this problem.

Is there anyone out there that understands the PHP IFX source code and
could fix the callback functionality.  Failing that I could have a go
if given some assistance.

FYI, the server specifics are:

Solaris 2.6
Apache 1.3.27
PHP 4.2.3
ESQL 7.24.UC6
Informix 7.30.UC8

Please do not close this bug unless the problem has been solved. 
Several instances around this bug have been closed by the solution
upgrade hardware where there is clearly still an error to be fixed.

Regards,


Neil Wilkinson
--


Previous Comments:


[2002-07-06 17:35:16] pschmidt at naxs dot net

Well, I see this problem every time I run my scripts.  We are running:

PHP 4.2.1
Apache 1.3.24
ESQL/C Version 9.51

Some of the Informix tables are large.

Since I am seeing this consistently, I would really like to see a fix
to this problem.  My scripts are somewhat complicated.  But I can
reproduce the problem with a simple script.  It contains:

---
?php

// create connection
$connection = ifx_connect(deleted, deleted, deleted)
or die(Couldn't create connection.);


// create SQL statement
$sql = SELECT f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13,
f14 FROM T1 where f1  500;

// execute SQL query and get result
$sql_result = ifx_query($sql,$connection)
or die(Couldn't execute query);

// format result in HTML table
ifx_htmltbl_result($sql_result,border=1);

// free resources and close connection
ifx_free_result($sql_result);
ifx_close($connection);

?
---

To reproduce this, I hit the refresh button on the browser before the
page had downloaded.

I tried switching it to pconnect and still got SQLCODE=-439 failures. 
Although the table is big, I think the load was light (I tried this on
a Saturday afternoon.) 

Anyone that has questions, feel free to send them to me at
[EMAIL PROTECTED]

Best Regards,
Paul Schmidt
Action Web Creations



[2002-05-25 13:15:11] [EMAIL PROTECTED]

Your problem seems to be a pure performance issue. 
Unfortunately these kinds of problems present themselves in 
a non-deterministic fashion, which makes the symptoms hard 
or impossible to debug. The cure, however, seems clear: 
upgrade to PHP 4.2, upgrade the hardware, install Zend 
Optimizer, buy Zend Cache -- anything to match your server 
resources with the increased load on your system. 

Based on your description of the scripts used, PHP 4 alone 
should bring a huge performance increase. Your client's 
possible unwillingness to pay for upgrades is quite simply 
*their problem*. Hang in there, iconites ;-)





[2002-05-25 09:13:10] alan dot frostick at iconmedialab dot com

Referring to Bug #14254.

I can give some background clues which might help in resolving the
intermittent SQLCODE=-439 error faster.
I support the php scripts for the same server which Cedric supports.
We
have noted that our client has increased their volume of data and
traffic to the site dramatically since their intranet's inception over
a
year ago.

They're still using php3 (we're trying to convince them to pay us to
convert their scripts to php4, but presently can't guarantee this
would
resolve the problem since it's still being reported by others using
php4).

The effect seen is a refusal to connect to informix, caused by a peak
in
traffic. It's not something which is easily duplicated in a test
environment, and is a mercurial problem in that as soon as it occurs,
it
often dissappears again as suddenly. We've seen it occur regularly for
up to 40 minutes and then go away for several days.

Recently the complaint has been that some scripts simply return an
empty
page. On investigation this week I discovered these scripts were
building massive arrays while remaining connected to informix, and
apparently exceeding maximum script memory. It happens within 4-5
seconds so can't be the result of a timeout.

I suspect this is giving rise to accumulated garbage

#22072 [Ver]: connection_status() always returning 0

[neil at mpfreescene dot com]

 ID:   22072
 User updated by:  neil at mpfreescene dot com
 Reported By:  neil at mpfreescene dot com
 Status:   Verified
 Bug Type: Apache2 related
 Operating System: FREEBSD 4.7-STABLE
 PHP Version:  4.3.1-dev
 New Comment:

Just checking in with you guys, does it look like a problem that will
be fixed any time soon ?

Im guessing that Status : Verified does mean that you too can see the
error I speak of ? :)



Many thanks.


Previous Comments:


[2003-02-06 04:36:28] neil at mpfreescene dot com

To further assist you in your diagnosis, I have supplied you with
additional parameters to the script that is failing.


Firstly you can run the script

http://www.mpfreescene.com/test/

Secondly you can see the source

http://www.mpfreescene.com/test/?option=source

Thirdly you can see phpinfo

http://www.mpfreescene.com/test/?option=info

Forthly you can see the output.txt file, i.e. the result of the failing
script :-

http://www.mpfreescene.com/test/?option=data




Just to recap, this identical script works fine on apache 1,  I have
been to apache they are pushing it back as an php error [the error they
found in an apache2 specific library maybe ?].  And the problem is I
run the script, whenI press stop, it continues to run in the background
and completes normally, i.e. it doesnt recogonise the user abort.



Thanks for your help in this matteer.



[2003-02-06 01:55:15] neil at mpfreescene dot com

Installed this morning, fresh.

Absolutley no difference whatso ever, not even a little bit, still the
same 0's being reported via connection_status when the stop button is
pressed.



[2003-02-05 16:08:19] [EMAIL PROTECTED]

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-02-05 15:58:50] crockett at horizon dot bc dot ca

connection_status() always returns zero on Win32 4.3.0 running IIS.
Yes, ignore_user_abort(true) is set.

Bradley Crockett



[2003-02-05 09:05:27] neil at mpfreescene dot com

This bug is effecting the connection_status() function in apache 2.x

Okay, getting back to a long standing bug, which we kind of come to the
conclusion last time that it may be a bug in apache 2.x because it
works in apache 1.

Well time has come on, I have submitted the bug to apache after they
fixed the incorrect bytes logged bug, and this is what they have come
up with :-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16426

ok, I've grabbed the current php source and looked into sapi_apache2.c.
It's
definitely a php bug. Line 90 shows:

if (ap_pass_brigade(f-next, bb) != APR_SUCCESS) {
php_handle_aborted_connection();
}

which won't match in most cases. Also Line 252 and 498.
AFAICS mod_php should (additionally) check connection-aborted.

(marking this bug invalid again)





-- 
Edit this bug report at http://bugs.php.net/?id=22072edit=1

#22072 [Com]: connection_status() always returning 0

[neil]

 ID:   22072
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Apache2 related
 Operating System: FREEBSD 4.7-STABLE
 PHP Version:  4.3.0
 New Comment:

To further assist you in your diagnosis, I have supplied you with
additional parameters to the script that is failing.


Firstly you can run the script

http://www.mpfreescene.com/test/

Secondly you can see the source

http://www.mpfreescene.com/test/?option=source

Thirdly you can see phpinfo

http://www.mpfreescene.com/test/?option=info

Forthly you can see the output.txt file, i.e. the result of the failing
script :-

http://www.mpfreescene.com/test/?option=data




Just to recap, this identical script works fine on apache 1,  I have
been to apache they are pushing it back as an php error [the error they
found in an apache2 specific library maybe ?].  And the problem is I
run the script, whenI press stop, it continues to run in the background
and completes normally, i.e. it doesnt recogonise the user abort.



Thanks for your help in this matteer.


Previous Comments:


[2003-02-06 01:55:15] [EMAIL PROTECTED]

Installed this morning, fresh.

Absolutley no difference whatso ever, not even a little bit, still the
same 0's being reported via connection_status when the stop button is
pressed.



[2003-02-05 16:08:19] [EMAIL PROTECTED]

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-02-05 15:58:50] [EMAIL PROTECTED]

connection_status() always returns zero on Win32 4.3.0 running IIS.
Yes, ignore_user_abort(true) is set.

Bradley Crockett



[2003-02-05 09:05:27] [EMAIL PROTECTED]

This bug is effecting the connection_status() function in apache 2.x

Okay, getting back to a long standing bug, which we kind of come to the
conclusion last time that it may be a bug in apache 2.x because it
works in apache 1.

Well time has come on, I have submitted the bug to apache after they
fixed the incorrect bytes logged bug, and this is what they have come
up with :-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16426

ok, I've grabbed the current php source and looked into sapi_apache2.c.
It's
definitely a php bug. Line 90 shows:

if (ap_pass_brigade(f-next, bb) != APR_SUCCESS) {
php_handle_aborted_connection();
}

which won't match in most cases. Also Line 252 and 498.
AFAICS mod_php should (additionally) check connection-aborted.

(marking this bug invalid again)





-- 
Edit this bug report at http://bugs.php.net/?id=22072edit=1

#22072 [NEW]: connection_status() always returning 0

[neil]

From: [EMAIL PROTECTED]
Operating system: FREEBSD 4.7-STABLE
PHP version:  4.3.0
PHP Bug Type: *General Issues
Bug description:  connection_status() always returning 0

This bug is effecting the connection_status() function in apache 2.x

Okay, getting back to a long standing bug, which we kind of come to the
conclusion last time that it may be a bug in apache 2.x because it works
in apache 1.

Well time has come on, I have submitted the bug to apache after they fixed
the incorrect bytes logged bug, and this is what they have come up with
:-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16426

ok, I've grabbed the current php source and looked into sapi_apache2.c.
It's
definitely a php bug. Line 90 shows:

if (ap_pass_brigade(f-next, bb) != APR_SUCCESS) {
php_handle_aborted_connection();
}

which won't match in most cases. Also Line 252 and 498.
AFAICS mod_php should (additionally) check connection-aborted.

(marking this bug invalid again)

-- 
Edit bug report at http://bugs.php.net/?id=22072edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22072r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22072r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22072r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22072r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22072r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22072r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22072r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22072r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22072r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22072r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22072r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22072r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22072r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22072r=gnused

#22072 [Fbk-Opn]: connection_status() always returning 0

[neil]

 ID:   22072
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: FREEBSD 4.7-STABLE
 PHP Version:  4.3.0
 New Comment:

Installed this morning, fresh.

Absolutley no difference whatso ever, not even a little bit, still the
same 0's being reported via connection_status when the stop button is
pressed.


Previous Comments:


[2003-02-05 16:08:19] [EMAIL PROTECTED]

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-02-05 15:58:50] [EMAIL PROTECTED]

connection_status() always returns zero on Win32 4.3.0 running IIS.
Yes, ignore_user_abort(true) is set.

Bradley Crockett



[2003-02-05 09:05:27] [EMAIL PROTECTED]

This bug is effecting the connection_status() function in apache 2.x

Okay, getting back to a long standing bug, which we kind of come to the
conclusion last time that it may be a bug in apache 2.x because it
works in apache 1.

Well time has come on, I have submitted the bug to apache after they
fixed the incorrect bytes logged bug, and this is what they have come
up with :-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16426

ok, I've grabbed the current php source and looked into sapi_apache2.c.
It's
definitely a php bug. Line 90 shows:

if (ap_pass_brigade(f-next, bb) != APR_SUCCESS) {
php_handle_aborted_connection();
}

which won't match in most cases. Also Line 252 and 498.
AFAICS mod_php should (additionally) check connection-aborted.

(marking this bug invalid again)





-- 
Edit this bug report at http://bugs.php.net/?id=22072edit=1

#17774 [Bgs-Opn]: connection_status() not returning correct result

[neil]

 ID:   17774
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Scripting Engine problem
-Operating System: FREEBSD 4.5-STABLE
+Operating System: FREEBSD 4.7-STABLE
-PHP Version:  4.0CVS-2002-06-15
+PHP Version:  PHP/4.3.0RC3
 New Comment:

Okay, so we got the problem down to apache 2.x.  ANyway, I got time to
install apache 1.3.27.

Now my system is running this :-

SERVER_SOFTWARE Apache/1.3.27 (Unix) PHP/4.3.0RC3 

And the problem still exists.

I run the exact same script as shown above, which yourselfs have
verified should return a '1'.  The script is returning a 0, even if I
press the STOP button.

I have not bothered to compile gzip into this apache installation, to
ensure it is not that which causes a problem.


http://admin.mghost.net/~neil/test/ - script
http://admin.mghost.net/~neil/test/output.txt - output file
http://admin.mghost.net/~neil/test/test.cgi - standard perl diver
script, to show details of my server.


Previous Comments:


[2002-12-08 17:01:42] [EMAIL PROTECTED]

This may interest you :-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8996

Obviously if apaches log files are doing htat, then its completely the
fault of apache 2 :-/



[2002-12-08 10:46:28] [EMAIL PROTECTED]

This report describes another problem:

  http://bugs.php.net/bug.php?id=14542

So there is clearly some bug in there. But for aborts it definately
works (on apache1) so you should report this
to apache folks too, would be nice to hear what they think of it.. :)




[2002-12-08 08:23:31] [EMAIL PROTECTED]

Okay, I should report this to Apache then ?  This is a fault in there
software ?



[2002-12-08 03:17:06] [EMAIL PROTECTED]

For me your test script makes output.txt contain 1 when I press 'stop'
button in my browser.

But I'm using Apache 1.3.27. And so should you as Apache2 is still beta
quality.




[2002-12-07 08:47:29] [EMAIL PROTECTED]

Okay, time has moved on, plenty of new versions have come out, ive kept
up to the very latest all along, alas, as expected, it still doesnt
work.

Can I just get a clarification of what should happen when a user
presses the stop button on the following script ?  My guess is that it
should put a 1 or a 2 into the file, not a 0!


-
?
function exitfp() {
$fp = fopen(/usr/home/neil/public_html/test/output.txt,a);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
set_time_limit(0);
ignore_user_abort(false);
$m = '10';
while(connection_aborted() != true and $a != $m){
$c = 0;
while($c != 4096){
print connection_status();
$c = $c + 1;
$d = $d + 1;
if($d == 128){
$d = 0;
printbr;
}
flush();
}
$a = $a + 1;
sleep('5');
}

exitfp();

?

---


You keep telling me this function is fixed, but surely the above code
shuld have an output different to 0 if the user presses the stop button
?


Heres some version info from my server

FreeBSD admin.mghost.net 4.7-STABLE FreeBSD 4.7-STABLE #5: Sun Dec  1
00:39:59 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ADMIN
 i386


Apache/2.0.43 (Unix) PHP/4.3.0RC2



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17774

-- 
Edit this bug report at http://bugs.php.net/?id=17774edit=1

#17774 [Opn-Bgs]: connection_status() not returning correct result

[neil]

 ID:   17774
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.7-STABLE
 PHP Version:  PHP/4.3.0RC3
 New Comment:

ignore that, its working now, but it wasnt a minute ago.


Previous Comments:


[2002-12-13 04:04:08] [EMAIL PROTECTED]

Okay, so we got the problem down to apache 2.x.  ANyway, I got time to
install apache 1.3.27.

Now my system is running this :-

SERVER_SOFTWARE Apache/1.3.27 (Unix) PHP/4.3.0RC3 

And the problem still exists.

I run the exact same script as shown above, which yourselfs have
verified should return a '1'.  The script is returning a 0, even if I
press the STOP button.

I have not bothered to compile gzip into this apache installation, to
ensure it is not that which causes a problem.


http://admin.mghost.net/~neil/test/ - script
http://admin.mghost.net/~neil/test/output.txt - output file
http://admin.mghost.net/~neil/test/test.cgi - standard perl diver
script, to show details of my server.



[2002-12-08 17:01:42] [EMAIL PROTECTED]

This may interest you :-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8996

Obviously if apaches log files are doing htat, then its completely the
fault of apache 2 :-/



[2002-12-08 10:46:28] [EMAIL PROTECTED]

This report describes another problem:

  http://bugs.php.net/bug.php?id=14542

So there is clearly some bug in there. But for aborts it definately
works (on apache1) so you should report this
to apache folks too, would be nice to hear what they think of it.. :)




[2002-12-08 08:23:31] [EMAIL PROTECTED]

Okay, I should report this to Apache then ?  This is a fault in there
software ?



[2002-12-08 03:17:06] [EMAIL PROTECTED]

For me your test script makes output.txt contain 1 when I press 'stop'
button in my browser.

But I'm using Apache 1.3.27. And so should you as Apache2 is still beta
quality.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17774

-- 
Edit this bug report at http://bugs.php.net/?id=17774edit=1

#17774 [Fbk-Opn]: connection_status() not returning correct result

[neil]

 ID:   17774
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

Okay, I should report this to Apache then ?  This is a fault in there
software ?


Previous Comments:


[2002-12-08 03:17:06] [EMAIL PROTECTED]

For me your test script makes output.txt contain 1 when I press 'stop'
button in my browser.

But I'm using Apache 1.3.27. And so should you as Apache2 is still beta
quality.




[2002-12-07 08:47:29] [EMAIL PROTECTED]

Okay, time has moved on, plenty of new versions have come out, ive kept
up to the very latest all along, alas, as expected, it still doesnt
work.

Can I just get a clarification of what should happen when a user
presses the stop button on the following script ?  My guess is that it
should put a 1 or a 2 into the file, not a 0!


-
?
function exitfp() {
$fp = fopen(/usr/home/neil/public_html/test/output.txt,a);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
set_time_limit(0);
ignore_user_abort(false);
$m = '10';
while(connection_aborted() != true and $a != $m){
$c = 0;
while($c != 4096){
print connection_status();
$c = $c + 1;
$d = $d + 1;
if($d == 128){
$d = 0;
printbr;
}
flush();
}
$a = $a + 1;
sleep('5');
}

exitfp();

?

---


You keep telling me this function is fixed, but surely the above code
shuld have an output different to 0 if the user presses the stop button
?


Heres some version info from my server

FreeBSD admin.mghost.net 4.7-STABLE FreeBSD 4.7-STABLE #5: Sun Dec  1
00:39:59 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ADMIN
 i386


Apache/2.0.43 (Unix) PHP/4.3.0RC2



[2002-10-08 04:51:49] [EMAIL PROTECTED]

Just to keep you informed on this, I have now deleted my old install of
apache and installed a FRESH copy of apache 2.0.43 and the latest CVS
at the time, im still using the same php.ini file.

The problem still exists in its entirety.



[2002-09-30 15:17:24] [EMAIL PROTECTED]

Yes I am, however it didnt do this on the CVS install under a week ago,
thats irrespective of my problem, Im not all that fussed wether it
displays the zero or not, it really doesnt assist me in my long
standing problem with the code I want to write that depends on the STOP
buttong being pressed and detecting this.



[2002-09-30 15:05:02] [EMAIL PROTECTED]

Do you have output compression enabled, whether via PHP or via Apache
(mod_gzip module for example) ?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17774

-- 
Edit this bug report at http://bugs.php.net/?id=17774edit=1

#17774 [Bgs]: connection_status() not returning correct result

[neil]

 ID:   17774
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

This may interest you :-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8996

Obviously if apaches log files are doing htat, then its completely the
fault of apache 2 :-/


Previous Comments:


[2002-12-08 10:46:28] [EMAIL PROTECTED]

This report describes another problem:

  http://bugs.php.net/bug.php?id=14542

So there is clearly some bug in there. But for aborts it definately
works (on apache1) so you should report this
to apache folks too, would be nice to hear what they think of it.. :)




[2002-12-08 08:23:31] [EMAIL PROTECTED]

Okay, I should report this to Apache then ?  This is a fault in there
software ?



[2002-12-08 03:17:06] [EMAIL PROTECTED]

For me your test script makes output.txt contain 1 when I press 'stop'
button in my browser.

But I'm using Apache 1.3.27. And so should you as Apache2 is still beta
quality.




[2002-12-07 08:47:29] [EMAIL PROTECTED]

Okay, time has moved on, plenty of new versions have come out, ive kept
up to the very latest all along, alas, as expected, it still doesnt
work.

Can I just get a clarification of what should happen when a user
presses the stop button on the following script ?  My guess is that it
should put a 1 or a 2 into the file, not a 0!


-
?
function exitfp() {
$fp = fopen(/usr/home/neil/public_html/test/output.txt,a);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
set_time_limit(0);
ignore_user_abort(false);
$m = '10';
while(connection_aborted() != true and $a != $m){
$c = 0;
while($c != 4096){
print connection_status();
$c = $c + 1;
$d = $d + 1;
if($d == 128){
$d = 0;
printbr;
}
flush();
}
$a = $a + 1;
sleep('5');
}

exitfp();

?

---


You keep telling me this function is fixed, but surely the above code
shuld have an output different to 0 if the user presses the stop button
?


Heres some version info from my server

FreeBSD admin.mghost.net 4.7-STABLE FreeBSD 4.7-STABLE #5: Sun Dec  1
00:39:59 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ADMIN
 i386


Apache/2.0.43 (Unix) PHP/4.3.0RC2



[2002-10-08 04:51:49] [EMAIL PROTECTED]

Just to keep you informed on this, I have now deleted my old install of
apache and installed a FRESH copy of apache 2.0.43 and the latest CVS
at the time, im still using the same php.ini file.

The problem still exists in its entirety.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17774

-- 
Edit this bug report at http://bugs.php.net/?id=17774edit=1

#17774 [Com]: connection_status() not returning correct result

[neil]

 ID:   17774
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

Okay, time has moved on, plenty of new versions have come out, ive kept
up to the very latest all along, alas, as expected, it still doesnt
work.

Can I just get a clarification of what should happen when a user
presses the stop button on the following script ?  My guess is that it
should put a 1 or a 2 into the file, not a 0!


-
?
function exitfp() {
$fp = fopen(/usr/home/neil/public_html/test/output.txt,a);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
set_time_limit(0);
ignore_user_abort(false);
$m = '10';
while(connection_aborted() != true and $a != $m){
$c = 0;
while($c != 4096){
print connection_status();
$c = $c + 1;
$d = $d + 1;
if($d == 128){
$d = 0;
printbr;
}
flush();
}
$a = $a + 1;
sleep('5');
}

exitfp();

?

---


You keep telling me this function is fixed, but surely the above code
shuld have an output different to 0 if the user presses the stop button
?


Heres some version info from my server

FreeBSD admin.mghost.net 4.7-STABLE FreeBSD 4.7-STABLE #5: Sun Dec  1
00:39:59 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ADMIN
 i386


Apache/2.0.43 (Unix) PHP/4.3.0RC2


Previous Comments:


[2002-10-08 04:51:49] [EMAIL PROTECTED]

Just to keep you informed on this, I have now deleted my old install of
apache and installed a FRESH copy of apache 2.0.43 and the latest CVS
at the time, im still using the same php.ini file.

The problem still exists in its entirety.



[2002-09-30 15:17:24] [EMAIL PROTECTED]

Yes I am, however it didnt do this on the CVS install under a week ago,
thats irrespective of my problem, Im not all that fussed wether it
displays the zero or not, it really doesnt assist me in my long
standing problem with the code I want to write that depends on the STOP
buttong being pressed and detecting this.



[2002-09-30 15:05:02] [EMAIL PROTECTED]

Do you have output compression enabled, whether via PHP or via Apache
(mod_gzip module for example) ?



[2002-09-30 15:00:28] [EMAIL PROTECTED]

Hmm, I probably look a bit thick rite now, but belive I had tried both
values of ignore_user_abort, being set to false and true, but alwasy
the same result, oops on my part for not realins to change it back to
false, I did that and still the same result.

I assume that you mean by output_buffers being set to on, is in teh
php.ini ?

Well This is a clipit of my php.ini

; a value for this directive (e.g., output_buffering=4096).
output_buffering = Off


I havnt changed my php.ini in all my installs [/usr/local/lib/php.ini]
so that has been always set to Off.

So anyway, ive tried with the ignore_user_abort(false); set and still
it ignores the user abort and 50 seconds later produces a file that
contains a '0'.

I havnt changed anything since the last CVS a few days/weeks ago, yet
it is no longer displaying a 0 in the browser it is just going with
behaviour like it is buffering it, like you already suggested.



[2002-09-30 14:43:02] [EMAIL PROTECTED]

If you did a clean install you have output buffering enabled, meaning
that PHP won't send the browser data until it filled the buffer of 4k
or the script has stopped running. This is why it does not output
anything right away. The other 'problem' can be explain by the fact you
likely have 'ignore_user_abort' enabled, meaning that the script will
run till completion even if the user connection was terminated or timed
out.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17774

-- 
Edit this bug report at http://bugs.php.net/?id=17774edit=1

#14740 [Com]: fsockopen() won't timeout

[neil]

 ID:   14740
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Sockets related
 Operating System: Win98 and Win2k
 PHP Version:  4.1.0
 Assigned To:  jason
 New Comment:

I can confirm this function stalls when connecting to (remote)
firewalled ports, on 4.0.6, it works fine on 4.1.2 and I will suggest
my ISP upgrade. Both are redhat/apache.

Question : You refer to the CVS builds having fixed this - which is the
minimal build version for this bug to be fixed ?

Thanks for your help.
Neil Smith


Previous Comments:


[2002-06-10 23:56:07] [EMAIL PROTECTED]

This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/. In case this was a documentation 
problem, the fix will show up soon at http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites.
Thank you for the report, and for helping us make PHP better.





[2002-05-29 00:33:54] [EMAIL PROTECTED]

Will work on fix, should be available shortly

-Jason



[2002-03-22 13:54:22] [EMAIL PROTECTED]

Note on the previous report -- setting an integer for timeout (e.g. 1)
does not change the behaviour.  It still takes 3-4 seconds without
timing out.



[2002-03-22 13:49:59] [EMAIL PROTECTED]

System: RedHat Linux
PHP 4.0.6
I'm specifying a timeout of 0.2 seconds, but the fsockopen() function
is taking as long as 3-4 seconds with slow domains (I know
www.krasnapolsky.sr to be slow).  This example took about 3.6 seconds.

CODE:
echo microtime();
echo fsockopen(www.krasnapolsky.sr, 80, $errno,
$errstr, 0.2);
echo microtime();
echo Error Number = $errno, Error String = $errstr;

RESULT:
0.39859300 1016822517
Resource id #1
0.04482100 1016822521
Error Number = 0, Error String = 

So the socket is opened -- it just took way longer than I intended to
allow it.



[2002-02-12 17:13:35] [EMAIL PROTECTED]

The Win32 code does not set a timeout. The comment at the end refers to
there being a problm on linux, which I could not reproduce.

Winsock does support non-blocking IO, but is set up quite differently
than BSD sockets.


-Jason



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14740

-- 
Edit this bug report at http://bugs.php.net/?id=14740edit=1

#17774 [Com]: connection_status() not returning correct result

[neil]

 ID:   17774
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

Just to keep you informed on this, I have now deleted my old install of
apache and installed a FRESH copy of apache 2.0.43 and the latest CVS
at the time, im still using the same php.ini file.

The problem still exists in its entirety.


Previous Comments:


[2002-09-30 15:17:24] [EMAIL PROTECTED]

Yes I am, however it didnt do this on the CVS install under a week ago,
thats irrespective of my problem, Im not all that fussed wether it
displays the zero or not, it really doesnt assist me in my long
standing problem with the code I want to write that depends on the STOP
buttong being pressed and detecting this.



[2002-09-30 15:05:02] [EMAIL PROTECTED]

Do you have output compression enabled, whether via PHP or via Apache
(mod_gzip module for example) ?



[2002-09-30 15:00:28] [EMAIL PROTECTED]

Hmm, I probably look a bit thick rite now, but belive I had tried both
values of ignore_user_abort, being set to false and true, but alwasy
the same result, oops on my part for not realins to change it back to
false, I did that and still the same result.

I assume that you mean by output_buffers being set to on, is in teh
php.ini ?

Well This is a clipit of my php.ini

; a value for this directive (e.g., output_buffering=4096).
output_buffering = Off


I havnt changed my php.ini in all my installs [/usr/local/lib/php.ini]
so that has been always set to Off.

So anyway, ive tried with the ignore_user_abort(false); set and still
it ignores the user abort and 50 seconds later produces a file that
contains a '0'.

I havnt changed anything since the last CVS a few days/weeks ago, yet
it is no longer displaying a 0 in the browser it is just going with
behaviour like it is buffering it, like you already suggested.



[2002-09-30 14:43:02] [EMAIL PROTECTED]

If you did a clean install you have output buffering enabled, meaning
that PHP won't send the browser data until it filled the buffer of 4k
or the script has stopped running. This is why it does not output
anything right away. The other 'problem' can be explain by the fact you
likely have 'ignore_user_abort' enabled, meaning that the script will
run till completion even if the user connection was terminated or timed
out.



[2002-09-30 14:33:47] [EMAIL PROTECTED]

This is an old posting of the bug, it was back in the days when I was
with rackshack and running freebsd 4.5-STABLE.

I am now running freebsd 4.7-RELEASE 2 and amn with a different ISP,
thus a totally different machine.

From your very latest CVS, I just downloaded and installed 5 minutes
ago this error is still occuring.

In fact your latest version is even worse, now the script, which I will
detail below doesnt print anything in the browser it just waits, and
you press stop say after 5 seconds, approx 45 seconds later [thats a
total of 50 1 second sleep attempts] the script writes to the outpout
file the connection_status, which is a 0, this is saying that the
script finsihed normally, this is WRONG according to your own manual of
which it shgould report connection status 1, which is unatural
termination of the script.

This bug is not fixed, it cannot be me I have been through all flavours
and rebuilds of freebsd and every time the same error!

This is the script, still the same as it was before the latest cvs
install that now doesnt display anything, you can view this script at
http://admin.mghost.net/~neil/test/index.php, the output file is
http://admin.mghost.net/~neil/test/wank.txt.


?
function exitfp() {
$fp = fopen(wank.txt,w);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
flush();
ignore_user_abort(true);
$m = '50';
while(connection_aborted() != true and $m  $a){
sleep('1');
print connection_status();
flush();
$a = $a + 1;
}

exitfp();

?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17774

-- 
Edit this bug report at http://bugs.php.net/?id=17774edit=1

#17774 [Csd-Opn]: connection_status() not returning correct result

[neil]

 ID:   17774
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

This is an old posting of the bug, it was back in the days when I was
with rackshack and running freebsd 4.5-STABLE.

I am now running freebsd 4.7-RELEASE 2 and amn with a different ISP,
thus a totally different machine.

From your very latest CVS, I just downloaded and installed 5 minutes
ago this error is still occuring.

In fact your latest version is even worse, now the script, which I will
detail below doesnt print anything in the browser it just waits, and
you press stop say after 5 seconds, approx 45 seconds later [thats a
total of 50 1 second sleep attempts] the script writes to the outpout
file the connection_status, which is a 0, this is saying that the
script finsihed normally, this is WRONG according to your own manual of
which it shgould report connection status 1, which is unatural
termination of the script.

This bug is not fixed, it cannot be me I have been through all flavours
and rebuilds of freebsd and every time the same error!

This is the script, still the same as it was before the latest cvs
install that now doesnt display anything, you can view this script at
http://admin.mghost.net/~neil/test/index.php, the output file is
http://admin.mghost.net/~neil/test/wank.txt.


?
function exitfp() {
$fp = fopen(wank.txt,w);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
flush();
ignore_user_abort(true);
$m = '50';
while(connection_aborted() != true and $m  $a){
sleep('1');
print connection_status();
flush();
$a = $a + 1;
}

exitfp();

?


Previous Comments:


[2002-09-29 22:47:09] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Using latest CVS snapshot I cannot replicate the problem you've
described. According to
http://www.php.net/manual/en/features.connection-handling.php
0 - NORMAL, and 0 is what gets printed to the browser. Upon untimely
termination of script, 1 is written to the output file, which means
that connection was aborted.



[2002-09-25 12:40:54] [EMAIL PROTECTED]

An ammendmant to my last two posts.

I would expect the script to put a '1' into wank.txt if somebody
presses the STOP button on there browser.

However the output I am getting is a '0' to say it disconnected
regulary.



[2002-09-25 08:33:25] [EMAIL PROTECTED]

Oh yeah, running that script, if I press the STOP button halfway
through, after a while it will output 0 into wank.txt, which is
wrong, it should put 2 is it? for connection closed.



[2002-09-25 08:31:31] [EMAIL PROTECTED]

I found there may be flaws with that code, so I wrote something else to
test if the function was fixed, and it appears not, here is the code,
if somebody cancels I would expect it to put '0' into wank.txt :-

?
function exitfp() {
$fp = fopen(wank.txt,w);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
flush();
ignore_user_abort(true);
$m = '50';
while(connection_aborted() != true and $m  $a){
sleep('1');
print connection_status();
flush();
$a = $a + 1;
}

exitfp();

?



[2002-09-25 07:38:18] [EMAIL PROTECTED]

According to Bug #17265 this problem should be fixed rite?

Well I downloaded the latest CVS like 5 minutes ago.

THe following code snippets should return into a file that the
connection was aborted, if this function was really fixed, rite?? well
the outputs I am getting into my temp files to check the output of the
script is 6077440 - 6076648 - 0 - not aborted - Keep-Alive

Heres the script :-


while(!feof($pl_of) and !connection_aborted()) {
$pl_buffer = fread($pl_of, 1024);
echo($pl_buffer);
flush();
$pl_sent = $pl_sent + 1024;
}


fclose

#17774 [Fbk-Opn]: connection_status() not returning correct result

[neil]

 ID:   17774
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

Hmm, I probably look a bit thick rite now, but belive I had tried both
values of ignore_user_abort, being set to false and true, but alwasy
the same result, oops on my part for not realins to change it back to
false, I did that and still the same result.

I assume that you mean by output_buffers being set to on, is in teh
php.ini ?

Well This is a clipit of my php.ini

; a value for this directive (e.g., output_buffering=4096).
output_buffering = Off


I havnt changed my php.ini in all my installs [/usr/local/lib/php.ini]
so that has been always set to Off.

So anyway, ive tried with the ignore_user_abort(false); set and still
it ignores the user abort and 50 seconds later produces a file that
contains a '0'.

I havnt changed anything since the last CVS a few days/weeks ago, yet
it is no longer displaying a 0 in the browser it is just going with
behaviour like it is buffering it, like you already suggested.


Previous Comments:


[2002-09-30 14:43:02] [EMAIL PROTECTED]

If you did a clean install you have output buffering enabled, meaning
that PHP won't send the browser data until it filled the buffer of 4k
or the script has stopped running. This is why it does not output
anything right away. The other 'problem' can be explain by the fact you
likely have 'ignore_user_abort' enabled, meaning that the script will
run till completion even if the user connection was terminated or timed
out.



[2002-09-30 14:33:47] [EMAIL PROTECTED]

This is an old posting of the bug, it was back in the days when I was
with rackshack and running freebsd 4.5-STABLE.

I am now running freebsd 4.7-RELEASE 2 and amn with a different ISP,
thus a totally different machine.

From your very latest CVS, I just downloaded and installed 5 minutes
ago this error is still occuring.

In fact your latest version is even worse, now the script, which I will
detail below doesnt print anything in the browser it just waits, and
you press stop say after 5 seconds, approx 45 seconds later [thats a
total of 50 1 second sleep attempts] the script writes to the outpout
file the connection_status, which is a 0, this is saying that the
script finsihed normally, this is WRONG according to your own manual of
which it shgould report connection status 1, which is unatural
termination of the script.

This bug is not fixed, it cannot be me I have been through all flavours
and rebuilds of freebsd and every time the same error!

This is the script, still the same as it was before the latest cvs
install that now doesnt display anything, you can view this script at
http://admin.mghost.net/~neil/test/index.php, the output file is
http://admin.mghost.net/~neil/test/wank.txt.


?
function exitfp() {
$fp = fopen(wank.txt,w);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
flush();
ignore_user_abort(true);
$m = '50';
while(connection_aborted() != true and $m  $a){
sleep('1');
print connection_status();
flush();
$a = $a + 1;
}

exitfp();

?



[2002-09-29 22:47:09] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Using latest CVS snapshot I cannot replicate the problem you've
described. According to
http://www.php.net/manual/en/features.connection-handling.php
0 - NORMAL, and 0 is what gets printed to the browser. Upon untimely
termination of script, 1 is written to the output file, which means
that connection was aborted.



[2002-09-25 12:40:54] [EMAIL PROTECTED]

An ammendmant to my last two posts.

I would expect the script to put a '1' into wank.txt if somebody
presses the STOP button on there browser.

However the output I am getting is a '0' to say it disconnected
regulary.



[2002-09-25 08:33:25] [EMAIL PROTECTED]

Oh yeah, running that script, if I press the STOP button halfway
through, after

#17774 [Fbk-Opn]: connection_status() not returning correct result

[neil]

 ID:   17774
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

Yes I am, however it didnt do this on the CVS install under a week ago,
thats irrespective of my problem, Im not all that fussed wether it
displays the zero or not, it really doesnt assist me in my long
standing problem with the code I want to write that depends on the STOP
buttong being pressed and detecting this.


Previous Comments:


[2002-09-30 15:05:02] [EMAIL PROTECTED]

Do you have output compression enabled, whether via PHP or via Apache
(mod_gzip module for example) ?



[2002-09-30 15:00:28] [EMAIL PROTECTED]

Hmm, I probably look a bit thick rite now, but belive I had tried both
values of ignore_user_abort, being set to false and true, but alwasy
the same result, oops on my part for not realins to change it back to
false, I did that and still the same result.

I assume that you mean by output_buffers being set to on, is in teh
php.ini ?

Well This is a clipit of my php.ini

; a value for this directive (e.g., output_buffering=4096).
output_buffering = Off


I havnt changed my php.ini in all my installs [/usr/local/lib/php.ini]
so that has been always set to Off.

So anyway, ive tried with the ignore_user_abort(false); set and still
it ignores the user abort and 50 seconds later produces a file that
contains a '0'.

I havnt changed anything since the last CVS a few days/weeks ago, yet
it is no longer displaying a 0 in the browser it is just going with
behaviour like it is buffering it, like you already suggested.



[2002-09-30 14:43:02] [EMAIL PROTECTED]

If you did a clean install you have output buffering enabled, meaning
that PHP won't send the browser data until it filled the buffer of 4k
or the script has stopped running. This is why it does not output
anything right away. The other 'problem' can be explain by the fact you
likely have 'ignore_user_abort' enabled, meaning that the script will
run till completion even if the user connection was terminated or timed
out.



[2002-09-30 14:33:47] [EMAIL PROTECTED]

This is an old posting of the bug, it was back in the days when I was
with rackshack and running freebsd 4.5-STABLE.

I am now running freebsd 4.7-RELEASE 2 and amn with a different ISP,
thus a totally different machine.

From your very latest CVS, I just downloaded and installed 5 minutes
ago this error is still occuring.

In fact your latest version is even worse, now the script, which I will
detail below doesnt print anything in the browser it just waits, and
you press stop say after 5 seconds, approx 45 seconds later [thats a
total of 50 1 second sleep attempts] the script writes to the outpout
file the connection_status, which is a 0, this is saying that the
script finsihed normally, this is WRONG according to your own manual of
which it shgould report connection status 1, which is unatural
termination of the script.

This bug is not fixed, it cannot be me I have been through all flavours
and rebuilds of freebsd and every time the same error!

This is the script, still the same as it was before the latest cvs
install that now doesnt display anything, you can view this script at
http://admin.mghost.net/~neil/test/index.php, the output file is
http://admin.mghost.net/~neil/test/wank.txt.


?
function exitfp() {
$fp = fopen(wank.txt,w);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
flush();
ignore_user_abort(true);
$m = '50';
while(connection_aborted() != true and $m  $a){
sleep('1');
print connection_status();
flush();
$a = $a + 1;
}

exitfp();

?



[2002-09-29 22:47:09] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Using latest CVS snapshot I cannot replicate the problem you've
described. According to
http://www.php.net/manual/en/features.connection-handling.php
0 - NORMAL, and 0 is what gets printed

#17774 [Com]: connection_status() not returning correct result

[neil . doody]

 ID:   17774
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

According to Bug #17265 this problem should be fixed rite?

Well I downloaded the latest CVS like 5 minutes ago.

THe following code snippets should return into a file that the
connection was aborted, if this function was really fixed, rite?? well
the outputs I am getting into my temp files to check the output of the
script is 6077440 - 6076648 - 0 - not aborted - Keep-Alive

Heres the script :-


while(!feof($pl_of) and !connection_aborted()) {
$pl_buffer = fread($pl_of, 1024);
echo($pl_buffer);
flush();
$pl_sent = $pl_sent + 1024;
}


fclose ($pl_of);
if ($pl_sent = $pl_filesize){
$pl_totalsent = 100%;
}else{
$pl_totalsent = round((100 / $pl_filesize *
$pl_sent),2) . %;
}
if (connection_aborted() == true){
$temp = 'aborted';
}else{
$temp = 'not aborted';
}

$pl_totalsent = $pl_sent - $pl_filesize -  .
connection_status() .  -
  . $temp .  -  . $_SERVER['HTTP_CONNECTION'];


Previous Comments:


[2002-07-07 13:10:32] [EMAIL PROTECTED]

Has this bug been looked in to at all?
Under FreeBSD, connection_status /always/ returns 0.
I've never tried it with any other flavours of BSD.

Regards,
David.



[2002-06-29 20:52:35] [EMAIL PROTECTED]

Just thought id enquire a little about this Bug, has it been a bug fora
 long time?  Do you think it will be sorted any time soon ?

Do you think we may see it repaired for PHP 4.3.0-STABLE ?



[2002-06-15 19:51:50] [EMAIL PROTECTED]

There's already some reports about this. But it's nice to have
another.




[2002-06-15 16:37:11] [EMAIL PROTECTED]

Im runnig PHP 4.3.0CVS on Apache 2.x

My problem is that I have written a script that sends
content-dispostion headers to the browser and starts a download.

When they user cancels the downloads, connection_status() is not
reflecting this.  I would assume that it shuold return a value of 1,
USER ABORTED.

Instead the script continues to run in the background by sending the
file somewhere (limbo?).  The script then reaches the end and
terminates normally.

After the script has terminated normally the value for
connection_status() is still set at 0 NORMAL.

Ive registered a shutdown function and tried all different methods like
connection_aborted() which is FALSE, ive set ignore_user_abort() to
TRUE and FALSE, but still alwasy the same result.

A problem arrises that it is entering false information to my weblogs,
i.e. its saying that the entire file was transferred when indeed it was
canceled half way through.

Im reading the file with fread() in 1K chunks and flushing in between,
so as the script does not buffer everything and terminate prematurly,
this is verified by the dump I have constructed at the end of the
script to tell me what connection_status() is saying, which doesnt get
written until you press to cancel the download or complete the
download, so the script is definatly midway in progress at that time.


Ive read in teh user contributed notes of somebody else expierencing
the same problem as me, that was back in FEB-2002.  The hack he has
written to use netstat is far to resource intensive.




-- 
Edit this bug report at http://bugs.php.net/?id=17774edit=1

#17265 [Com]: function connection_xxxx() and ignore_user_abort don't work

[neil . doody]

 ID:   17265
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: FreeBSD4.5
 PHP Version:  4.1.2
 Assigned To:  zeev
 New Comment:

If this was really fixed, then Bug #17774 would also be fixed ?


Previous Comments:


[2002-09-19 11:11:22] [EMAIL PROTECTED]

Issue (1) should be fixed.

As for issue (2) - it should be working fine.  Note that disconnected
links are only detected while PHP sends out output.  If you have a
script that just performs computations and doesn't emit output while
doing that, PHP has no way of detecting that the connection was closed.



[2002-09-19 06:49:25] [EMAIL PROTECTED]

Ive been updating my version of PHP every week in the hope that this
problem is fixed.

alas, it still does not work.

Has anyone any feedback on this bug, when it may be fixed?



[2002-09-05 15:56:57] [EMAIL PROTECTED]

Another one for Zeev to fix.. :)




[2002-09-05 13:42:59] [EMAIL PROTECTED]

This bug is trivially reproduceable with the following code fragment:

while (1) {
sleep(3);

$status = connection_status();
syslog(1, connection status is $status);
$status = connection_aborted();
syslog(1, connection aborted is $status);
}   

It happens consistently using php4.1.2 compiled under OpenBSD 2.8.

If you watch the error log, the connection_status() always returns 0,
whether or not the stop button has been pressed.  Similarly,
connection_aborted() always returns 0.



[2002-06-07 20:53:02] [EMAIL PROTECTED]

the functions do work if you hve a sleep() with more then one second
everything below don't work.

some one should fix that bug



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17265

-- 
Edit this bug report at http://bugs.php.net/?id=17265edit=1

#17774 [Com]: connection_status() not returning correct result

[neil . doody]

 ID:   17774
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

I found there may be flaws with that code, so I wrote something else to
test if the function was fixed, and it appears not, here is the code,
if somebody cancels I would expect it to put '0' into wank.txt :-

?
function exitfp() {
$fp = fopen(wank.txt,w);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
flush();
ignore_user_abort(true);
$m = '50';
while(connection_aborted() != true and $m  $a){
sleep('1');
print connection_status();
flush();
$a = $a + 1;
}

exitfp();

?


Previous Comments:


[2002-09-25 07:38:18] [EMAIL PROTECTED]

According to Bug #17265 this problem should be fixed rite?

Well I downloaded the latest CVS like 5 minutes ago.

THe following code snippets should return into a file that the
connection was aborted, if this function was really fixed, rite?? well
the outputs I am getting into my temp files to check the output of the
script is 6077440 - 6076648 - 0 - not aborted - Keep-Alive

Heres the script :-


while(!feof($pl_of) and !connection_aborted()) {
$pl_buffer = fread($pl_of, 1024);
echo($pl_buffer);
flush();
$pl_sent = $pl_sent + 1024;
}


fclose ($pl_of);
if ($pl_sent = $pl_filesize){
$pl_totalsent = 100%;
}else{
$pl_totalsent = round((100 / $pl_filesize *
$pl_sent),2) . %;
}
if (connection_aborted() == true){
$temp = 'aborted';
}else{
$temp = 'not aborted';
}

$pl_totalsent = $pl_sent - $pl_filesize -  .
connection_status() .  -
  . $temp .  -  . $_SERVER['HTTP_CONNECTION'];



[2002-07-07 13:10:32] [EMAIL PROTECTED]

Has this bug been looked in to at all?
Under FreeBSD, connection_status /always/ returns 0.
I've never tried it with any other flavours of BSD.

Regards,
David.



[2002-06-29 20:52:35] [EMAIL PROTECTED]

Just thought id enquire a little about this Bug, has it been a bug fora
 long time?  Do you think it will be sorted any time soon ?

Do you think we may see it repaired for PHP 4.3.0-STABLE ?



[2002-06-15 19:51:50] [EMAIL PROTECTED]

There's already some reports about this. But it's nice to have
another.




[2002-06-15 16:37:11] [EMAIL PROTECTED]

Im runnig PHP 4.3.0CVS on Apache 2.x

My problem is that I have written a script that sends
content-dispostion headers to the browser and starts a download.

When they user cancels the downloads, connection_status() is not
reflecting this.  I would assume that it shuold return a value of 1,
USER ABORTED.

Instead the script continues to run in the background by sending the
file somewhere (limbo?).  The script then reaches the end and
terminates normally.

After the script has terminated normally the value for
connection_status() is still set at 0 NORMAL.

Ive registered a shutdown function and tried all different methods like
connection_aborted() which is FALSE, ive set ignore_user_abort() to
TRUE and FALSE, but still alwasy the same result.

A problem arrises that it is entering false information to my weblogs,
i.e. its saying that the entire file was transferred when indeed it was
canceled half way through.

Im reading the file with fread() in 1K chunks and flushing in between,
so as the script does not buffer everything and terminate prematurly,
this is verified by the dump I have constructed at the end of the
script to tell me what connection_status() is saying, which doesnt get
written until you press to cancel the download or complete the
download, so the script is definatly midway in progress at that time.


Ive read in teh user contributed notes of somebody else expierencing
the same problem as me, that was back in FEB-2002.  The hack he has
written to use netstat is far to resource intensive.




-- 
Edit this bug report at http://bugs.php.net/?id=17774edit=1

#17774 [Com]: connection_status() not returning correct result

[neil . doody]

 ID:   17774
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

Oh yeah, running that script, if I press the STOP button halfway
through, after a while it will output 0 into wank.txt, which is
wrong, it should put 2 is it? for connection closed.


Previous Comments:


[2002-09-25 08:31:31] [EMAIL PROTECTED]

I found there may be flaws with that code, so I wrote something else to
test if the function was fixed, and it appears not, here is the code,
if somebody cancels I would expect it to put '0' into wank.txt :-

?
function exitfp() {
$fp = fopen(wank.txt,w);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
flush();
ignore_user_abort(true);
$m = '50';
while(connection_aborted() != true and $m  $a){
sleep('1');
print connection_status();
flush();
$a = $a + 1;
}

exitfp();

?



[2002-09-25 07:38:18] [EMAIL PROTECTED]

According to Bug #17265 this problem should be fixed rite?

Well I downloaded the latest CVS like 5 minutes ago.

THe following code snippets should return into a file that the
connection was aborted, if this function was really fixed, rite?? well
the outputs I am getting into my temp files to check the output of the
script is 6077440 - 6076648 - 0 - not aborted - Keep-Alive

Heres the script :-


while(!feof($pl_of) and !connection_aborted()) {
$pl_buffer = fread($pl_of, 1024);
echo($pl_buffer);
flush();
$pl_sent = $pl_sent + 1024;
}


fclose ($pl_of);
if ($pl_sent = $pl_filesize){
$pl_totalsent = 100%;
}else{
$pl_totalsent = round((100 / $pl_filesize *
$pl_sent),2) . %;
}
if (connection_aborted() == true){
$temp = 'aborted';
}else{
$temp = 'not aborted';
}

$pl_totalsent = $pl_sent - $pl_filesize -  .
connection_status() .  -
  . $temp .  -  . $_SERVER['HTTP_CONNECTION'];



[2002-07-07 13:10:32] [EMAIL PROTECTED]

Has this bug been looked in to at all?
Under FreeBSD, connection_status /always/ returns 0.
I've never tried it with any other flavours of BSD.

Regards,
David.



[2002-06-29 20:52:35] [EMAIL PROTECTED]

Just thought id enquire a little about this Bug, has it been a bug fora
 long time?  Do you think it will be sorted any time soon ?

Do you think we may see it repaired for PHP 4.3.0-STABLE ?



[2002-06-15 19:51:50] [EMAIL PROTECTED]

There's already some reports about this. But it's nice to have
another.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17774

-- 
Edit this bug report at http://bugs.php.net/?id=17774edit=1

#17774 [Com]: connection_status() not returning correct result

[neil . doody]

 ID:   17774
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: FREEBSD 4.5-STABLE
 PHP Version:  4.0CVS-2002-06-15
 New Comment:

An ammendmant to my last two posts.

I would expect the script to put a '1' into wank.txt if somebody
presses the STOP button on there browser.

However the output I am getting is a '0' to say it disconnected
regulary.


Previous Comments:


[2002-09-25 08:33:25] [EMAIL PROTECTED]

Oh yeah, running that script, if I press the STOP button halfway
through, after a while it will output 0 into wank.txt, which is
wrong, it should put 2 is it? for connection closed.



[2002-09-25 08:31:31] [EMAIL PROTECTED]

I found there may be flaws with that code, so I wrote something else to
test if the function was fixed, and it appears not, here is the code,
if somebody cancels I would expect it to put '0' into wank.txt :-

?
function exitfp() {
$fp = fopen(wank.txt,w);
fputs($fp, connection_status());
fclose($fp);
}
register_shutdown_function('exitfp');

if(connection_aborted() != true){print 0;}
flush();
ignore_user_abort(true);
$m = '50';
while(connection_aborted() != true and $m  $a){
sleep('1');
print connection_status();
flush();
$a = $a + 1;
}

exitfp();

?



[2002-09-25 07:38:18] [EMAIL PROTECTED]

According to Bug #17265 this problem should be fixed rite?

Well I downloaded the latest CVS like 5 minutes ago.

THe following code snippets should return into a file that the
connection was aborted, if this function was really fixed, rite?? well
the outputs I am getting into my temp files to check the output of the
script is 6077440 - 6076648 - 0 - not aborted - Keep-Alive

Heres the script :-


while(!feof($pl_of) and !connection_aborted()) {
$pl_buffer = fread($pl_of, 1024);
echo($pl_buffer);
flush();
$pl_sent = $pl_sent + 1024;
}


fclose ($pl_of);
if ($pl_sent = $pl_filesize){
$pl_totalsent = 100%;
}else{
$pl_totalsent = round((100 / $pl_filesize *
$pl_sent),2) . %;
}
if (connection_aborted() == true){
$temp = 'aborted';
}else{
$temp = 'not aborted';
}

$pl_totalsent = $pl_sent - $pl_filesize -  .
connection_status() .  -
  . $temp .  -  . $_SERVER['HTTP_CONNECTION'];



[2002-07-07 13:10:32] [EMAIL PROTECTED]

Has this bug been looked in to at all?
Under FreeBSD, connection_status /always/ returns 0.
I've never tried it with any other flavours of BSD.

Regards,
David.



[2002-06-29 20:52:35] [EMAIL PROTECTED]

Just thought id enquire a little about this Bug, has it been a bug fora
 long time?  Do you think it will be sorted any time soon ?

Do you think we may see it repaired for PHP 4.3.0-STABLE ?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17774

-- 
Edit this bug report at http://bugs.php.net/?id=17774edit=1

#19580 [NEW]: Warning: incfile() [function.incfile]: 0 bytes of buffered data lost

[neil . doody]

From: [EMAIL PROTECTED]
Operating system: FREEBSD 4.7-RELEASE 2
PHP version:  4CVS-2002-09-24
PHP Bug Type: Unknown/Other Function
Bug description:  Warning: incfile() [function.incfile]: 0 bytes of buffered data lost

Running on Apache 2.0.42-Alpha2 with the latest CVS of PHP im getting the
following error that is produced with the code shown below, I have never
had this problem before nad the code has not changed for almost a year now
:-


Warning: incfile() [function.incfile]: 0 bytes of buffered data lost
during conversion to FILE*! in /usr/home/mpfreesc/public_html/index.php on
line 41


Code :-

function incfile($pt_infile) {
global $argv;
global $REMOTE_ADDR;
ob_start();
include($pt_infile);
$pt_ret_str = ob_get_contents();
ob_end_clean();
return $pt_ret_str;
}
-- 
Edit bug report at http://bugs.php.net/?id=19580edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19580r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19580r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19580r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19580r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19580r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19580r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19580r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19580r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19580r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19580r=globals

#19496 [Fbk-Opn]: Apache 2.40 Core Dump

[neil . doody]

 ID:   19496
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: FreeBSD 4.7-PRERELEASE #2
 PHP Version:  4CVS-2002-09-19
 New Comment:

Okay,I got the latest version and I enabled the debugging.

[LATEST CORE DUMP DEBUG AT THE BOTTOM]

Firstly can I say that this newer version is worse in that configure
fails.

HEres some of the errors when running buildconf :-



buildconf: automake version 1.6.3 (ok)
buildconf: libtool version 1.4.1 (ok)
rebuilding configure
ext/yaz/config.m4:32: /usr/local/bin/gm4: Warning: Excess arguments to
built-in `m4_if' ignored
configure:88216: error: possibly undefined macro: AS_ESCAPE
configure:88217: error: possibly undefined macro: m4_warn
configure:88219: error: possibly undefined macro: _AS_ECHO
rebuilding acconfig.h
rebuilding main/php_config.h.in

ext/yaz/config.m4:32: /usr/local/bin/gm4: Warning: Excess arguments to
built-in `m4_if' ignored
autoheader: `main/php_config.h.in' is created

---

Heres the error of configure :-

./configure: line 88207: syntax error near unexpected token `6]))'
./configure: line 88207: `echo \ 6]))],'




I fixed up the configure script and installed php.  I found that the
errors where only for outputting messages to me, which I cared not
about.

HEre is the output of the core dump :-

#0  0x28412740 in execute (op_array=0x28478090)
at /home/admin/cvs/php4/Zend/zend_execute.c:318
#1  0x283d8d03 in sslow (m=0x284647bc, start=0x0,
stop=0xbfbff844 tø¿¿\022ÿ=(\f\020\032\b\203, startst=675107865,
stopst=675694524) at /usr/include/ctype.h:152
#2  0x28381b08 in zif_proc_open (ht=675694524,
return_value=0x28477ee0,
this_ptr=0xbfbff874, return_value_used=67583)
at /home/admin/cvs/php4/ext/standard/exec.c:939
#3  0x283e0efb in php_ini_displayer (ini_entry=0x81a100c,
module_number=131)
at /home/admin/cvs/php4/main/php_ini.c:112
#4  0x283dff12 in php_checkuid (
filename=0x1953 Address 0x1953 out of bounds,
fopen_mode=0x83 Address 0x83 out of bounds, mode=675539712)
at /home/admin/cvs/php4/main/safe_mode.c:123
#5  0x283d267e in big2_scanPercent (enc=0x2843eb00,
ptr=0x2843eab8 ted, use the call_user_func variety with the
array($obj, \method\) syntax instead,
end=0x812640c Function registration failed - duplicate name -
apache_lookup_uri, nextTokPtr=0x284523cb)
at /home/admin/cvs/php4/ext/xml/expat/xmltok_impl.c:897
#6  0x283d2d65 in big2_prologTok (enc=0x20,
ptr=0x284523cb
\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005a\005`\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005b\005a\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005c\005b\005F\005F\005F\005F\005F\005F...,
end=0x0, nextTokPtr=0x28452620)
at /home/admin/cvs/php4/ext/xml/expat/xmltok_impl.c:995
#7  0x283fa04e in zend_do_qm_false (result=0x20,
false_value=0x28452620,
qm_token=0x28453e79, colon_token=0x283fc6b6)
at /home/admin/cvs/php4/Zend/zend_compile.c:2355
#8  0x283fc7a6 in zend_strip ()
at /home/admin/cvs/php4/Zend/zend_highlight.c:240
#9  0x283fc8a7 in zend_llist_prepend_element (l=0x28464660,
element=0x284647bc)
at /home/admin/cvs/php4/Zend/zend_llist.c:56
#10 0x283fc69d in zend_strip () at /usr/include/stdio.h:363
#11 0x28413c15 in execute (op_array=0x80e0018)
at /home/admin/cvs/php4/Zend/zend_execute.c:71
#12 0x2841301d in execute (op_array=0x80e0018)
at /home/admin/cvs/php4/Zend/zend_execute.c:72
#13 0x8097ec1 in ap_run_post_config (pconf=0x80e0018, plog=0x8118018,
ptemp=0x811e018, s=0x80e3428) at config.c:129
#14 0x809c47c in main (argc=3, argv=0xbfbffbd8) at main.c:634
#15 0x8065301 in _start ()


Previous Comments:


[2002-09-19 20:30:23] [EMAIL PROTECTED]

Yes, --enable-debug should be used. But please get a fresh
snapshot, there have been couple of fixes just recently.




[2002-09-19 06:42:34] [EMAIL PROTECTED]

I just noticed, I forgot to compile with the --enable-debug, does that
matter, is the info supplied sufficient?  Ill do it again if needs be.



[2002-09-19 06:40:40] [EMAIL PROTECTED]

at /home/admin/cvs/b/php4/sapi/apache2filter/sapi_apache2.c:126
#1  0x283d79b3 in sapi_send_headers ()
at /home/admin/cvs/b/php4/main/SAPI.c:696
#2  0x283819a8 in php_header ()

#19496 [Opn]: Apache 2.40 Core Dump

[neil . doody]

 ID:   19496
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Apache2 related
 Operating System: FreeBSD 4.7-PRERELEASE #2
 PHP Version:  4CVS-2002-09-19
 New Comment:

Can you tell me this ?


Why is this :-

/home/admin/cvs/php4/ext/standard/exec.c

Being called ?

The latest install comes from the directory /home/admin/cvs/c/php4
[this is the source directory]

Surely it should never try to have any referrence to the file
/home/admin/cvs/php4/ext/standard/exec.c ?  Plus once it is installed
it shoulndt be calling to the source any more any how ?


Previous Comments:


[2002-09-20 04:13:28] [EMAIL PROTECTED]

Okay,I got the latest version and I enabled the debugging.

[LATEST CORE DUMP DEBUG AT THE BOTTOM]

Firstly can I say that this newer version is worse in that configure
fails.

HEres some of the errors when running buildconf :-



buildconf: automake version 1.6.3 (ok)
buildconf: libtool version 1.4.1 (ok)
rebuilding configure
ext/yaz/config.m4:32: /usr/local/bin/gm4: Warning: Excess arguments to
built-in `m4_if' ignored
configure:88216: error: possibly undefined macro: AS_ESCAPE
configure:88217: error: possibly undefined macro: m4_warn
configure:88219: error: possibly undefined macro: _AS_ECHO
rebuilding acconfig.h
rebuilding main/php_config.h.in

ext/yaz/config.m4:32: /usr/local/bin/gm4: Warning: Excess arguments to
built-in `m4_if' ignored
autoheader: `main/php_config.h.in' is created

---

Heres the error of configure :-

./configure: line 88207: syntax error near unexpected token `6]))'
./configure: line 88207: `echo \ 6]))],'




I fixed up the configure script and installed php.  I found that the
errors where only for outputting messages to me, which I cared not
about.

HEre is the output of the core dump :-

#0  0x28412740 in execute (op_array=0x28478090)
at /home/admin/cvs/php4/Zend/zend_execute.c:318
#1  0x283d8d03 in sslow (m=0x284647bc, start=0x0,
stop=0xbfbff844 tø¿¿\022ÿ=(\f\020\032\b\203, startst=675107865,
stopst=675694524) at /usr/include/ctype.h:152
#2  0x28381b08 in zif_proc_open (ht=675694524,
return_value=0x28477ee0,
this_ptr=0xbfbff874, return_value_used=67583)
at /home/admin/cvs/php4/ext/standard/exec.c:939
#3  0x283e0efb in php_ini_displayer (ini_entry=0x81a100c,
module_number=131)
at /home/admin/cvs/php4/main/php_ini.c:112
#4  0x283dff12 in php_checkuid (
filename=0x1953 Address 0x1953 out of bounds,
fopen_mode=0x83 Address 0x83 out of bounds, mode=675539712)
at /home/admin/cvs/php4/main/safe_mode.c:123
#5  0x283d267e in big2_scanPercent (enc=0x2843eb00,
ptr=0x2843eab8 ted, use the call_user_func variety with the
array($obj, \method\) syntax instead,
end=0x812640c Function registration failed - duplicate name -
apache_lookup_uri, nextTokPtr=0x284523cb)
at /home/admin/cvs/php4/ext/xml/expat/xmltok_impl.c:897
#6  0x283d2d65 in big2_prologTok (enc=0x20,
ptr=0x284523cb
\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005a\005`\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005b\005a\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005c\005b\005F\005F\005F\005F\005F\005F...,
end=0x0, nextTokPtr=0x28452620)
at /home/admin/cvs/php4/ext/xml/expat/xmltok_impl.c:995
#7  0x283fa04e in zend_do_qm_false (result=0x20,
false_value=0x28452620,
qm_token=0x28453e79, colon_token=0x283fc6b6)
at /home/admin/cvs/php4/Zend/zend_compile.c:2355
#8  0x283fc7a6 in zend_strip ()
at /home/admin/cvs/php4/Zend/zend_highlight.c:240
#9  0x283fc8a7 in zend_llist_prepend_element (l=0x28464660,
element=0x284647bc)
at /home/admin/cvs/php4/Zend/zend_llist.c:56
#10 0x283fc69d in zend_strip () at /usr/include/stdio.h:363
#11 0x28413c15 in execute (op_array=0x80e0018)
at /home/admin/cvs/php4/Zend/zend_execute.c:71
#12 0x2841301d in execute (op_array=0x80e0018)
at /home/admin/cvs/php4/Zend/zend_execute.c:72
#13 0x8097ec1 in ap_run_post_config (pconf=0x80e0018, plog=0x8118018,
ptemp=0x811e018, s=0x80e3428) at config.c:129
#14 0x809c47c in main (argc=3, argv=0xbfbffbd8) at main.c:634
#15 0x8065301 in _start ()



[2002-09-19 20:30:23] [EMAIL PROTECTED]

Yes, --enable-debug should be used. But please get a fresh
snapshot, there have been couple of fixes just recently.

#19496 [Opn]: Apache 2.40 Core Dump

[neil . doody]

 ID:   19496
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Apache2 related
 Operating System: FreeBSD 4.7-PRERELEASE #2
 PHP Version:  4CVS-2002-09-19
 New Comment:

Just to keep you informed, I just deleted my apache build and source,
recompiled it from fresh and got the latest cvs again [the configure
script now works at least] and rebuilt that too.

Total clean install and same core dump.


Previous Comments:


[2002-09-20 12:35:52] [EMAIL PROTECTED]

Can you tell me this ?


Why is this :-

/home/admin/cvs/php4/ext/standard/exec.c

Being called ?

The latest install comes from the directory /home/admin/cvs/c/php4
[this is the source directory]

Surely it should never try to have any referrence to the file
/home/admin/cvs/php4/ext/standard/exec.c ?  Plus once it is installed
it shoulndt be calling to the source any more any how ?



[2002-09-20 04:13:28] [EMAIL PROTECTED]

Okay,I got the latest version and I enabled the debugging.

[LATEST CORE DUMP DEBUG AT THE BOTTOM]

Firstly can I say that this newer version is worse in that configure
fails.

HEres some of the errors when running buildconf :-



buildconf: automake version 1.6.3 (ok)
buildconf: libtool version 1.4.1 (ok)
rebuilding configure
ext/yaz/config.m4:32: /usr/local/bin/gm4: Warning: Excess arguments to
built-in `m4_if' ignored
configure:88216: error: possibly undefined macro: AS_ESCAPE
configure:88217: error: possibly undefined macro: m4_warn
configure:88219: error: possibly undefined macro: _AS_ECHO
rebuilding acconfig.h
rebuilding main/php_config.h.in

ext/yaz/config.m4:32: /usr/local/bin/gm4: Warning: Excess arguments to
built-in `m4_if' ignored
autoheader: `main/php_config.h.in' is created

---

Heres the error of configure :-

./configure: line 88207: syntax error near unexpected token `6]))'
./configure: line 88207: `echo \ 6]))],'




I fixed up the configure script and installed php.  I found that the
errors where only for outputting messages to me, which I cared not
about.

HEre is the output of the core dump :-

#0  0x28412740 in execute (op_array=0x28478090)
at /home/admin/cvs/php4/Zend/zend_execute.c:318
#1  0x283d8d03 in sslow (m=0x284647bc, start=0x0,
stop=0xbfbff844 tø¿¿\022ÿ=(\f\020\032\b\203, startst=675107865,
stopst=675694524) at /usr/include/ctype.h:152
#2  0x28381b08 in zif_proc_open (ht=675694524,
return_value=0x28477ee0,
this_ptr=0xbfbff874, return_value_used=67583)
at /home/admin/cvs/php4/ext/standard/exec.c:939
#3  0x283e0efb in php_ini_displayer (ini_entry=0x81a100c,
module_number=131)
at /home/admin/cvs/php4/main/php_ini.c:112
#4  0x283dff12 in php_checkuid (
filename=0x1953 Address 0x1953 out of bounds,
fopen_mode=0x83 Address 0x83 out of bounds, mode=675539712)
at /home/admin/cvs/php4/main/safe_mode.c:123
#5  0x283d267e in big2_scanPercent (enc=0x2843eb00,
ptr=0x2843eab8 ted, use the call_user_func variety with the
array($obj, \method\) syntax instead,
end=0x812640c Function registration failed - duplicate name -
apache_lookup_uri, nextTokPtr=0x284523cb)
at /home/admin/cvs/php4/ext/xml/expat/xmltok_impl.c:897
#6  0x283d2d65 in big2_prologTok (enc=0x20,
ptr=0x284523cb
\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005a\005`\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005b\005a\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005F\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005P\005c\005b\005F\005F\005F\005F\005F\005F...,
end=0x0, nextTokPtr=0x28452620)
at /home/admin/cvs/php4/ext/xml/expat/xmltok_impl.c:995
#7  0x283fa04e in zend_do_qm_false (result=0x20,
false_value=0x28452620,
qm_token=0x28453e79, colon_token=0x283fc6b6)
at /home/admin/cvs/php4/Zend/zend_compile.c:2355
#8  0x283fc7a6 in zend_strip ()
at /home/admin/cvs/php4/Zend/zend_highlight.c:240
#9  0x283fc8a7 in zend_llist_prepend_element (l=0x28464660,
element=0x284647bc)
at /home/admin/cvs/php4/Zend/zend_llist.c:56
#10 0x283fc69d in zend_strip () at /usr/include/stdio.h:363
#11 0x28413c15 in execute (op_array=0x80e0018)
at /home/admin/cvs/php4/Zend/zend_execute.c:71
#12 0x2841301d in execute (op_array=0x80e0018)
at /home/admin/cvs/php4/Zend/zend_execute.c:72
#13 0x8097ec1 in ap_run_post_config (pconf=0x80e0018, plog=0x8118018,
ptemp=0x811e018, s=0x80e3428) at config.c:129
#14 0x809c47c in main (argc=3, argv=0xbfbffbd8) at 

#19496 [NEW]: Apache 2.40 Core Dump

[neil . doody]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.7-PRERELEASE #2
PHP version:  4CVS-2002-09-19
PHP Bug Type: Reproducible crash
Bug description:  Apache 2.40 Core Dump

Sep 19 12:02:12 admin /kernel: pid 86191 (httpd), uid 0: exited on signal
11 (core dumped)

I am getting a core dump from apache 2.40 when using the latest CVS,
lookily I have a backup of the CVS I was laready using.

This old CVS works fine, I have reinstalled/uninstalled many times and
eery time ocre dump with the latest CVS.

Both configure lines are identical in the installs.  Which was :-

./configure --with-mysql --with-apxs2=/usr/local/apache/bin/apxs

I noticed the message of supplying the path to pth on the latest CVS, so I
tried this also :-

./configure --with-mysql --with-apxs2=/usr/local/apache/bin/apxs
--with-tsrm-pth=/usr/local/bin/pth-config

The current working CVS I have is dated 2002-09-06.
-- 
Edit bug report at http://bugs.php.net/?id=19496edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19496r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19496r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19496r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19496r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19496r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19496r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19496r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19496r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19496r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19496r=globals

#19496 [Fbk-Opn]: Apache 2.40 Core Dump

[neil . doody]

 ID:   19496
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: FreeBSD 4.7-PRERELEASE #2
 PHP Version:  4CVS-2002-09-19
 New Comment:

at /home/admin/cvs/b/php4/sapi/apache2filter/sapi_apache2.c:126
#1  0x283d79b3 in sapi_send_headers ()
at /home/admin/cvs/b/php4/main/SAPI.c:696
#2  0x283819a8 in php_header ()
at /home/admin/cvs/b/php4/ext/standard/head.c:62
#3  0x283dfbab in php_ub_body_write (
str=0x81a100c br /\nbWarning/b:  Function registration
failed - duplicate name - apache_lookup_uri in bUnknown/b on line
b0/bbr /\n,
str_length=131) at /home/admin/cvs/b/php4/main/output.c:686
#4  0x283debc2 in php_body_write (
str=0x81a100c br /\nbWarning/b:  Function registration
failed - duplicate name - apache_lookup_uri in bUnknown/b on line
b0/bbr /\n,
str_length=131) at /home/admin/cvs/b/php4/main/output.c:104
#5  0x283d135a in php_printf (
format=0x2843d700 br /\nb%s/b:  %s in b%s/b on line
b%d/bbr /\n) at /home/admin/cvs/b/php4/main/main.c:388
#6  0x283d1a41 in php_error_cb (type=32, error_filename=0x2845104b
Unknown,
error_lineno=0,
format=0x284512a0 Function registration failed - duplicate name -
%s,
args=0xbfbff994
Ù*E(³?(\2343F(@2F(@2F(é(=(\2343F(À0F((4\016\b%\017\(Ù*E( ) at
/home/admin/cvs/b/php4/main/main.c:609
#7  0x283f8cd6 in zend_error (type=32,
format=0x284512a0 Function registration failed - duplicate name -
%s)
at /home/admin/cvs/b/php4/Zend/zend.c:710
#8  0x283fb42e in zend_register_functions (functions=0x28463200,
function_table=0x0, type=1) at
/home/admin/cvs/b/php4/Zend/zend_API.c:1060
#9  0x283fb52f in zend_register_module (module=0x28463240)
at /home/admin/cvs/b/php4/Zend/zend_API.c:1103
#10 0x283fb325 in zend_startup_module (module=0x28463240)
at /home/admin/cvs/b/php4/Zend/zend_API.c:1014
#11 0x2841289d in php_apache_register_module ()
at /home/admin/cvs/b/php4/sapi/apache2filter/php_functions.c:172
#12 0x28411ca5 in php_apache_server_startup (pconf=0x80e0018,
plog=0x8118018,
ptemp=0x811e018, s=0x80e3428)
at /home/admin/cvs/b/php4/sapi/apache2filter/sapi_apache2.c:505
#13 0x8097ec1 in ap_run_post_config (pconf=0x80e0018, plog=0x8118018,
ptemp=0x811e018, s=0x80e3428) at config.c:129
#14 0x809c47c in main (argc=3, argv=0xbfbffbd8) at main.c:634
#15 0x8065301 in _start ()


Previous Comments:


[2002-09-19 06:21:21] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.





[2002-09-19 06:12:37] [EMAIL PROTECTED]

Sep 19 12:02:12 admin /kernel: pid 86191 (httpd), uid 0: exited on
signal 11 (core dumped)

I am getting a core dump from apache 2.40 when using the latest CVS,
lookily I have a backup of the CVS I was laready using.

This old CVS works fine, I have reinstalled/uninstalled many times and
eery time ocre dump with the latest CVS.

Both configure lines are identical in the installs.  Which was :-

./configure --with-mysql --with-apxs2=/usr/local/apache/bin/apxs

I noticed the message of supplying the path to pth on the latest CVS,
so I tried this also :-

./configure --with-mysql --with-apxs2=/usr/local/apache/bin/apxs
--with-tsrm-pth=/usr/local/bin/pth-config

The current working CVS I have is dated 2002-09-06.




-- 
Edit this bug report at http://bugs.php.net/?id=19496edit=1

#19496 [Opn]: Apache 2.40 Core Dump

[neil . doody]

 ID:   19496
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Apache2 related
 Operating System: FreeBSD 4.7-PRERELEASE #2
 PHP Version:  4CVS-2002-09-19
 New Comment:

I just noticed, I forgot to compile with the --enable-debug, does that
matter, is the info supplied sufficient?  Ill do it again if needs be.


Previous Comments:


[2002-09-19 06:40:40] [EMAIL PROTECTED]

at /home/admin/cvs/b/php4/sapi/apache2filter/sapi_apache2.c:126
#1  0x283d79b3 in sapi_send_headers ()
at /home/admin/cvs/b/php4/main/SAPI.c:696
#2  0x283819a8 in php_header ()
at /home/admin/cvs/b/php4/ext/standard/head.c:62
#3  0x283dfbab in php_ub_body_write (
str=0x81a100c br /\nbWarning/b:  Function registration
failed - duplicate name - apache_lookup_uri in bUnknown/b on line
b0/bbr /\n,
str_length=131) at /home/admin/cvs/b/php4/main/output.c:686
#4  0x283debc2 in php_body_write (
str=0x81a100c br /\nbWarning/b:  Function registration
failed - duplicate name - apache_lookup_uri in bUnknown/b on line
b0/bbr /\n,
str_length=131) at /home/admin/cvs/b/php4/main/output.c:104
#5  0x283d135a in php_printf (
format=0x2843d700 br /\nb%s/b:  %s in b%s/b on line
b%d/bbr /\n) at /home/admin/cvs/b/php4/main/main.c:388
#6  0x283d1a41 in php_error_cb (type=32, error_filename=0x2845104b
Unknown,
error_lineno=0,
format=0x284512a0 Function registration failed - duplicate name -
%s,
args=0xbfbff994
Ù*E(³?(\2343F(@2F(@2F(é(=(\2343F(À0F((4\016\b%\017\(Ù*E( ) at
/home/admin/cvs/b/php4/main/main.c:609
#7  0x283f8cd6 in zend_error (type=32,
format=0x284512a0 Function registration failed - duplicate name -
%s)
at /home/admin/cvs/b/php4/Zend/zend.c:710
#8  0x283fb42e in zend_register_functions (functions=0x28463200,
function_table=0x0, type=1) at
/home/admin/cvs/b/php4/Zend/zend_API.c:1060
#9  0x283fb52f in zend_register_module (module=0x28463240)
at /home/admin/cvs/b/php4/Zend/zend_API.c:1103
#10 0x283fb325 in zend_startup_module (module=0x28463240)
at /home/admin/cvs/b/php4/Zend/zend_API.c:1014
#11 0x2841289d in php_apache_register_module ()
at /home/admin/cvs/b/php4/sapi/apache2filter/php_functions.c:172
#12 0x28411ca5 in php_apache_server_startup (pconf=0x80e0018,
plog=0x8118018,
ptemp=0x811e018, s=0x80e3428)
at /home/admin/cvs/b/php4/sapi/apache2filter/sapi_apache2.c:505
#13 0x8097ec1 in ap_run_post_config (pconf=0x80e0018, plog=0x8118018,
ptemp=0x811e018, s=0x80e3428) at config.c:129
#14 0x809c47c in main (argc=3, argv=0xbfbffbd8) at main.c:634
#15 0x8065301 in _start ()



[2002-09-19 06:21:21] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.





[2002-09-19 06:12:37] [EMAIL PROTECTED]

Sep 19 12:02:12 admin /kernel: pid 86191 (httpd), uid 0: exited on
signal 11 (core dumped)

I am getting a core dump from apache 2.40 when using the latest CVS,
lookily I have a backup of the CVS I was laready using.

This old CVS works fine, I have reinstalled/uninstalled many times and
eery time ocre dump with the latest CVS.

Both configure lines are identical in the installs.  Which was :-

./configure --with-mysql --with-apxs2=/usr/local/apache/bin/apxs

I noticed the message of supplying the path to pth on the latest CVS,
so I tried this also :-

./configure --with-mysql --with-apxs2=/usr/local/apache/bin/apxs
--with-tsrm-pth=/usr/local/bin/pth-config

The current working CVS I have is dated 2002-09-06.




-- 
Edit this bug report at http://bugs.php.net/?id=19496edit=1

#17265 [Com]: function connection_xxxx() and ignore_user_abort don't work

[neil . doody]

 ID:   17265
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Scripting Engine problem
 Operating System: FreeBSD4.5
 PHP Version:  4.1.2
 Assigned To:  zeev
 New Comment:

Ive been updating my version of PHP every week in the hope that this
problem is fixed.

alas, it still does not work.

Has anyone any feedback on this bug, when it may be fixed?


Previous Comments:


[2002-09-05 15:56:57] [EMAIL PROTECTED]

Another one for Zeev to fix.. :)




[2002-09-05 13:42:59] [EMAIL PROTECTED]

This bug is trivially reproduceable with the following code fragment:

while (1) {
sleep(3);

$status = connection_status();
syslog(1, connection status is $status);
$status = connection_aborted();
syslog(1, connection aborted is $status);
}   

It happens consistently using php4.1.2 compiled under OpenBSD 2.8.

If you watch the error log, the connection_status() always returns 0,
whether or not the stop button has been pressed.  Similarly,
connection_aborted() always returns 0.



[2002-06-07 20:53:02] [EMAIL PROTECTED]

the functions do work if you hve a sleep() with more then one second
everything below don't work.

some one should fix that bug



[2002-05-16 00:48:22] [EMAIL PROTECTED]

when client disconnected or hit 'Stop' button. 
1.these 2 functions alway return 0;
connection_status();
connection_aborted();

2.and alway ignore 'STOP' button when
ignore_user_abort(true);  or
ignore_user_abort(false);





-- 
Edit this bug report at http://bugs.php.net/?id=17265edit=1