Bug #16012 Updated: IIS + PHP + MSSQL Sessions not working right..

[sander]

 ID:   16012
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: Windows .NET Build 3604
 PHP Version:  4.1.1
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".





Previous Comments:


[2002-03-12 01:12:25] [EMAIL PROTECTED]

When I look in the temp directory of the windows server I get ( minus
the admin):

 !user|!password| 

and on my linux server:

 user|s:6:"---";password2|s:6:"-";admins|s:1:"1"; 

the lines used were:
session_register('user');
session_register('password');




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

Bug #16013: max execution time reached with slow connection

[franck]

From: [EMAIL PROTECTED]
Operating system: linux+windows
PHP version:  4.1.2
PHP Bug Type: *Web Server problem
Bug description:  max execution time reached with slow connection

I'm not sure about the php version number as I experience the problem on
other people servers from Fiji like www.hp.com

When accessing a php page on a web server, if the link is of poor
bandwidth then the max execution time can be reached stopping the download
of the page.

To test the problem, you have to be in poor network conditions, which is
sometime difficult to achieve. 

Ideally the max execution time should be independent of the flow of data
from the web server to the client. This bug seems similar to the max
execution time of ASP in IIS where a client had 240seconds to download a
page. The solution was to enable page buffering, where the page is first
created internally then send to the client.

On php, it does not seem to be exactly similar as 30 second, default
setting, would stop most of the download of pages.

This will put php at odd with accessibility issues for developing
countries.
-- 
Edit bug report at http://bugs.php.net/?id=16013&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16013&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16013&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16013&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16013&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16013&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16013&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16013&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16013&r=submittedtwice

Bug #14564 Updated: Trusted Connections Not Supported

[g . sollis]

 ID:   14564
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Windows NT 4/SQL Server 7
 PHP Version:  4.1.0
 New Comment:

This would be great, as i too think it is a potential security risk to
have usernames and passwords in the source-code. But instead of keeping
it in MS-SQL functions i suggest it is also available for ODBC
connections.

Just another small suggestion i thought of; maybe it's a good idea to
implement a second (form of) 
[dbtype]_connect() function, which will accept something like an ODBC
Connection String. This way it would be possible to either use the
following:
1. DSN connection with specified user & password
2. DSN connection with trusted connection to db-server
3. DSN-less connection with connection string

The only way it is available now is by using the COM functionality.
Which is OK if you want to go that way, but that does mean rewriting a
lot of code if there is no db-abstraction layer in use.


Previous Comments:


[2001-12-17 11:27:14] [EMAIL PROTECTED]

Making this a feature request



[2001-12-17 11:12:07] [EMAIL PROTECTED]

I consider the inclusion of database usernames and passwords in scripts
to be a security risk.

In a Windows environment it is possible to access SQL Server via a
trusted connection.  This uses the context of the current logged in
user.

Furthermore it is possible to configure IIS and presumably Apache to
use a particular user account to service requests.

It is therefore possible (for example under ASP) to open a database
connection without specifying a username or password in the script
because the context of the current user account has permission to
access the SQL Server.

I would be happy if this functionality could be implmented in the MS
SQL Server extension.




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

Bug #16015: Online Documentation Differs in languages

[ronnie]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.1.2
PHP Bug Type: Documentation problem
Bug description:  Online Documentation Differs in languages

I have found a difference in two PHP manuals which both are online at...

http://nl.php.net/manual/nl/language.variables.predefined.php
http://nl.php.net/manual/en/language.variables.predefined.php

De Dutch page contains information about superglobals and the english page
about Apache Variables.
-- 
Edit bug report at http://bugs.php.net/?id=16015&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16015&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16015&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16015&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16015&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16015&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16015&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16015&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16015&r=submittedtwice

Bug #16015 Updated: Online Documentation Differs in languages

[torben]

 ID:  16015
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
-Status:  Open
+Status:  Bogus
 Bug Type:Documentation problem
 PHP Version: 4.1.2
 New Comment:

The Dutch manual appears to be in the middle of updating,
and got that part of the Dutch version done before it did
the English. Changes to the manual can take a while to 
propagate.


Torben


Previous Comments:


[2002-03-12 05:35:45] [EMAIL PROTECTED]

I have found a difference in two PHP manuals which both are online
at...

http://nl.php.net/manual/nl/language.variables.predefined.php
http://nl.php.net/manual/en/language.variables.predefined.php

De Dutch page contains information about superglobals and the english
page about Apache Variables.




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

Bug #16013 Updated: max execution time reached with slow connection

[sniper]

 ID:   16013
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *Web Server problem
 Operating System: linux+windows
 PHP Version:  4.1.2
 New Comment:

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php


Previous Comments:


[2002-03-12 04:57:57] [EMAIL PROTECTED]

I'm not sure about the php version number as I experience the problem
on other people servers from Fiji like www.hp.com

When accessing a php page on a web server, if the link is of poor
bandwidth then the max execution time can be reached stopping the
download of the page.

To test the problem, you have to be in poor network conditions, which
is sometime difficult to achieve. 

Ideally the max execution time should be independent of the flow of
data from the web server to the client. This bug seems similar to the
max execution time of ASP in IIS where a client had 240seconds to
download a page. The solution was to enable page buffering, where the
page is first created internally then send to the client.

On php, it does not seem to be exactly similar as 30 second, default
setting, would stop most of the download of pages.

This will put php at odd with accessibility issues for developing
countries.




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

Bug #15771 Updated: cannot pass value to image field by ado

[darkwings]

 ID:   15771
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Suspended
 Bug Type: COM related
 Operating System: windows
 PHP Version:  4.0.6
 New Comment:

i think it is not necessary to rewrite,just use a function
like binarywrite() in asp(Active Server Page),
int binarywrite ($variant,$source)
return the length copied.


Previous Comments:


[2002-03-11 13:04:50] [EMAIL PROTECTED]

hmm, this is a bit difficult because strings become usually translated
into unicode which is usually a good thing(tm) but unfortunatelly not
in this case.
as i'm actually rewriting the whole thing for php5/ZE2 i don't think
that i'll address this yet.

harald

ps: don't use ado, it's slw :)



[2002-02-27 21:29:09] [EMAIL PROTECTED]

Since PHP can support COM and I usually use php in windows,
I try to use database like mssql through ado.
All things work properly but the image datatype of mysql cannot be set 
correctly.
I use it just like this
Open("Provider=sqloledb;Data Source=ndht;Initial
Catalog=printers;User Id=printers;Password=printers;");
$fp=fopen("5.gif","r") or die ("file opening error");
$content = fread ($fp, filesize ("5.gif"));
fclose ($fp);
echo filesize ("5.gif");
$rec=new COM("ADODB.recordset");
$rec->open("select * from sav",$dbconn);
$rec->addnew();
$rec->fields["datas"]->AppendChunk($content);
$rec->update();
$rec->close();
$rec=null;
$dbconn->close();
$dbconn=null;
?>

I think that windows use two type text for strings and binary for the
8bit chars, but in php string are both of
these.
So when trans the data to mssql,the variables be string of
window first, and the information were lost.




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

Bug #16013 Updated: max execution time reached with slow connection

[franck]

 ID:   16013
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: *Web Server problem
 Operating System: linux+windows
 PHP Version:  4.1.2
 New Comment:

This is not a support question. I know how to increase the max support
time.

There is definitively a problem with php over slow link which make the
product as bad as MS IIS for difficult environment. I'd like a
developer to look into the matter and provide a sensible answer to this
problem where php is dependent on the connection speedIt shouldn't
be...


Previous Comments:


[2002-03-12 06:14:19] [EMAIL PROTECTED]

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php



[2002-03-12 04:57:57] [EMAIL PROTECTED]

I'm not sure about the php version number as I experience the problem
on other people servers from Fiji like www.hp.com

When accessing a php page on a web server, if the link is of poor
bandwidth then the max execution time can be reached stopping the
download of the page.

To test the problem, you have to be in poor network conditions, which
is sometime difficult to achieve. 

Ideally the max execution time should be independent of the flow of
data from the web server to the client. This bug seems similar to the
max execution time of ASP in IIS where a client had 240seconds to
download a page. The solution was to enable page buffering, where the
page is first created internally then send to the client.

On php, it does not seem to be exactly similar as 30 second, default
setting, would stop most of the download of pages.

This will put php at odd with accessibility issues for developing
countries.




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

Bug #15887 Updated: vulnerability? security hole?

[imajes]

 ID:   15887
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Apache related
 Operating System: windows 2000
 PHP Version:  4.1.2
 New Comment:

released.


Previous Comments:


[2002-03-05 15:48:46] [EMAIL PROTECTED]

This has been fixed and will be released shortly with the new version
of php under windows.



[2002-03-05 15:41:02] [EMAIL PROTECTED]

hi!
I just happened to see on a web page and tried that when one writes
'http://myaddress/php/php.exe?anyfile', he can see what's in this file.
And this way, one can also upload some files and hack the system. 
What do you think? Is this 'php.exe' a security hole, and what's the
use of it if I dont use it at all? I searched your web site, but
couldn't find an answer for that. Could you please give me a sufficient
explanation about the capabilities of this 'php.exe' file?
Thanks in advance!
smurfie




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

Bug #16016: Unable to load dynamic library

[jesus951]

From: [EMAIL PROTECTED]
Operating system: W2K
PHP version:  4.0.5
PHP Bug Type: InterBase related
Bug description:  Unable to load dynamic library

I have read a lot about this bug around all the bug, but noone of the
solutions given 
have soved the problem in my case. That makes me thing the bug remains.

I copied some of the next text from another user whon I agree with.


After uncommenting the "extension=php_interbase.dll" line in php.ini,
php shows the following error in a dialog box:

Unable to load dynamic library
'c:\php\extensions\php_interbase.dll'

This happens:

  - To php_interbase.dll but not with php_imap.dll and others.

  - No matter PHP is running as CGI or ISAPI module

  - A user (http://marc.theaimsgroup.com/?l=php-db&m=97812982300192&w=2)
has reported success by putting PHP_INTERBASE.DLL in the SYSTEM32
folder. But I haven't.

  - Another user (http://bugs.php.net/bug.php?id=13188) has reported
success too by 
copying all the DLLs from the \php\dlls directory to c:\winnt\system32.
But again I 
haven't.

  - I've seen it happen in two computers: two of them running Win2000
Server and the other two running Win NT.

What is strange about this bug is that I've installed PHP with this
module in my computer once in the past and it worked...

This bug has compromised the use of PHP in one of my company's project.(in
my case
 I have several webs that have stopped working) I am really worry about
it.

Thanks in advance.
Jesús.



-- 
Edit bug report at http://bugs.php.net/?id=16016&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16016&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16016&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16016&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16016&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16016&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16016&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16016&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16016&r=submittedtwice

Bug #16018: PHP crashing (Backtrace included)

[matt]

From: [EMAIL PROTECTED]
Operating system: RH linux7.2
PHP version:  4.1.2
PHP Bug Type: Reproducible crash
Bug description:  PHP crashing (Backtrace included)

config.nice
'./configure' \
'--with-apxs=/www/bin/apxs' \
'--with-mysql' \
'--with-pgsql=/usr/local/pgsql' \
'--without-pear' \
'--with-gd' \
'--enable-wddx' \
'--with-xmlrpc' \
'--with-curl' \
'--enable-debug' \
"$@"

backtrace:

#0  0x40540d89 in execute (op_array=0x81bb53c) at ./zend_execute.c:1815
#1  0x4053fe02 in execute (op_array=0x8237a40) at ./zend_execute.c:1630
#2  0x4053fe02 in execute (op_array=0x81947cc) at ./zend_execute.c:1630
#3  0x4054e574 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at zend.c:814
#4  0x4055bfa1 in php_execute_script (primary_file=0xb600) at
main.c:1307
#5  0x40558082 in apache_php_module_main (r=0x8186b24,
display_source_mode=0) at sapi_apache.c:90
#6  0x40558b65 in send_php (r=0x8186b24, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#7  0x40558bba in send_parsed_php (r=0x8186b24) at mod_php4.c:590
#8  0x808bded in ap_invoke_handler ()
#9  0x80a0fab in process_request_internal ()
#10 0x80a100c in ap_process_request ()
#11 0x8098051 in child_main ()
#12 0x8098220 in make_child ()
#13 0x8098390 in startup_children ()
#14 0x8098a09 in standalone_main ()
#15 0x80992a3 in main ()
#16 0x4016db65 in __libc_start_main (main=0x8098ee0 , argc=2,
ubp_av=0xbb14, init=0x8054a30 <_init>, 
fini=0x80d132c <_fini>, rtld_fini=0x4000df24 <_dl_fini>,
stack_end=0xbb0c) at ../sysdeps/generic/libc-start.c:111

Only happens under POST and then a Header("location: ...") as far as i
cant tell

-- 
Edit bug report at http://bugs.php.net/?id=16018&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16018&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16018&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16018&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16018&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16018&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16018&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16018&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16018&r=submittedtwice

Bug #16019: Installtion problem

[samuel-barz]

From: [EMAIL PROTECTED]
Operating system: Win98
PHP version:  4.1.2
PHP Bug Type: *General Issues
Bug description:  Installtion problem

when starting the "php-4.1.2-installer.exe" i get the message: "Could not
initialize installtion. File size expected=941579, size returned=586464."

what's the problem here?
-- 
Edit bug report at http://bugs.php.net/?id=16019&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16019&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16019&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16019&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16019&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16019&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16019&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16019&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16019&r=submittedtwice

Bug #15499 Updated: Apache crashes with Segmentation fault

[mranner]

 ID:   15499
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OCI8 related
 Operating System: Linux
 PHP Version:  4.1.1
 New Comment:

We need urgent support on this case!
What can we do to accellerate the necessary steps?

Sincerly,

Mike


Previous Comments:


[2002-02-20 12:37:51] [EMAIL PROTECTED]

We use Oracle 8.1.7

this described bug is completely reproduceable.

We store in our App the session-data in a db-table in a CLOB. Maybe
there is a problem with the LOB-Handling of the OCI8-Module.

I hope this bug will be edited soon, because we have real problems with
our customers.

We can also give root-access via ssh to our server for debugging.



[2002-02-13 09:55:04] [EMAIL PROTECTED]

We see this same problem on Redhat 6.2 kernel version 2.2.19-6.3.  We
are using version 8.1.6.2 of the oracle client libraries with php 4.0.6
and php 4.1.1.



[2002-02-11 07:09:29] [EMAIL PROTECTED]

We run many sites with php4 and oracle.
On every site we have seen that Apache child processes crash after
about 10 to 20 requests.
We use different Linux Versions (RedHat 7.1, SuSe Linux 7.1, 7.3) and
also different php-Versions (php4.0.6, php4.1.1).
All these sites use Oracle as Database (oci8-Module).
We run other sites with PHP but without Oracle-Module and these sites
run stable.
We tried also PHP on W2K with IIS with the ISAPI Module with
Oci8-Support and we have the same effect, after 10 to 20 requests, the
Server stops serving PHP-Sites, ...
... this seems to be a bug in the oci8-Module of php.

below ldd of http and a gdb backtrace.
phpinfo can be requested from this url:
http://sqp.sft.jawa.at/test.php

ldd httpd
libdl.so.2 => /lib/libdl.so.2 (0x40027000)
libm.so.6 => /lib/libm.so.6 (0x4002a000)
libldap.so.1 => /usr/lib/libldap.so.1 (0x40048000)
liblber.so.1 => /usr/lib/liblber.so.1 (0x4005d000)
libgd.so => /usr/local/lib/libgd.so (0x40062000)
libt1.so.1 => /usr/local/lib/libt1.so.1 (0x4009d000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x400e)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40116000)
libz.so.1 => /usr/local/lib/libz.so.1 (0x40142000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40151000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4017)
libresolv.so.2 => /lib/libresolv.so.2 (0x4019e000)
libnsl.so.1 => /lib/libnsl.so.1 (0x401af000)
libclntsh.so.8.0 => /opt/oracle/OraHome1/lib/libclntsh.so.8.0
(0x401c5000)
libc.so.6 => /lib/libc.so.6 (0x4077b000)
libwtc8.so => /opt/oracle/OraHome1/lib/libwtc8.so (0x4088f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40891000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)

gdb output:

pluto:/usr/local/apache/bin # gdb httpd
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-suse-linux"...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
[New Thread 1024 (LWP 7211)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 7211)]
0x8159933 in zend_hash_index_find (ht=0x822ca44, h=11,
pData=0xbfffea98)
at zend_hash.c:935
935 if ((p->h == h) && (p->nKeyLength == 0)) {
(gdb) bt
#0  0x8159933 in zend_hash_index_find (ht=0x822ca44, h=11,
pData=0xbfffea98)
at zend_hash.c:935
#1  0x815a54b in _zend_list_delete (id=11) at zend_list.c:53
#2  0x80aa637 in _oci_column_hash_dtor (data=0x8f0db04) at oci8.c:727
#3  0x815894a in zend_hash_destroy (ht=0x87db67c) at zend_hash.c:541
#4  0x80aa7f8 in _oci_stmt_list_dtor (rsrc=0x87db4b4) at oci8.c:771
#5  0x815a838 in list_entry_destructor (ptr=0x87db4b4) at
zend_list.c:177
#6  0x815aa67 in zend_destroy_rsrc_list (ht=0x822ca44) at
zend_list.c:248
#7  0x8148f97 in shutdown_executor () at zend_execute_API.c:196
#8  0x8152d84 in zend_deactivate () at zend.c:600
#9  0x806d71f in php_request_shutdown (dummy=0x0) at main.c:735
#10 0x815f596 in apache_php_module_main (r=0x828fe44,
display_source_mode=0)
at sapi_apache.c:96
#11 0x806ac3e in send_php ()
#12 0x806aca6 in send_parsed_php ()
#13 0x8184509 in ap_invoke_handler ()
#14 0x8199f6f in process_request_internal ()
#15 0x8199fe2 in ap_process_request ()
#16 0x8190b96 in child_main ()
#17 0x8190d55 in make_child ()
#18 0x8190ed6 in startup_children ()
#19 0x819157d in standalone_main 

Bug #15499 Updated: Apache crashes with Segmentation fault

[sander]

 ID:   15499
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OCI8 related
 Operating System: Linux
 PHP Version:  4.1.1
 New Comment:

You can try to fix it yourself...
If you've fixed it, please post a diff here or send it to
[EMAIL PROTECTED]


Previous Comments:


[2002-03-12 08:16:08] [EMAIL PROTECTED]

We need urgent support on this case!
What can we do to accellerate the necessary steps?

Sincerly,

Mike



[2002-02-20 12:37:51] [EMAIL PROTECTED]

We use Oracle 8.1.7

this described bug is completely reproduceable.

We store in our App the session-data in a db-table in a CLOB. Maybe
there is a problem with the LOB-Handling of the OCI8-Module.

I hope this bug will be edited soon, because we have real problems with
our customers.

We can also give root-access via ssh to our server for debugging.



[2002-02-13 09:55:04] [EMAIL PROTECTED]

We see this same problem on Redhat 6.2 kernel version 2.2.19-6.3.  We
are using version 8.1.6.2 of the oracle client libraries with php 4.0.6
and php 4.1.1.



[2002-02-11 07:09:29] [EMAIL PROTECTED]

We run many sites with php4 and oracle.
On every site we have seen that Apache child processes crash after
about 10 to 20 requests.
We use different Linux Versions (RedHat 7.1, SuSe Linux 7.1, 7.3) and
also different php-Versions (php4.0.6, php4.1.1).
All these sites use Oracle as Database (oci8-Module).
We run other sites with PHP but without Oracle-Module and these sites
run stable.
We tried also PHP on W2K with IIS with the ISAPI Module with
Oci8-Support and we have the same effect, after 10 to 20 requests, the
Server stops serving PHP-Sites, ...
... this seems to be a bug in the oci8-Module of php.

below ldd of http and a gdb backtrace.
phpinfo can be requested from this url:
http://sqp.sft.jawa.at/test.php

ldd httpd
libdl.so.2 => /lib/libdl.so.2 (0x40027000)
libm.so.6 => /lib/libm.so.6 (0x4002a000)
libldap.so.1 => /usr/lib/libldap.so.1 (0x40048000)
liblber.so.1 => /usr/lib/liblber.so.1 (0x4005d000)
libgd.so => /usr/local/lib/libgd.so (0x40062000)
libt1.so.1 => /usr/local/lib/libt1.so.1 (0x4009d000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x400e)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40116000)
libz.so.1 => /usr/local/lib/libz.so.1 (0x40142000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40151000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4017)
libresolv.so.2 => /lib/libresolv.so.2 (0x4019e000)
libnsl.so.1 => /lib/libnsl.so.1 (0x401af000)
libclntsh.so.8.0 => /opt/oracle/OraHome1/lib/libclntsh.so.8.0
(0x401c5000)
libc.so.6 => /lib/libc.so.6 (0x4077b000)
libwtc8.so => /opt/oracle/OraHome1/lib/libwtc8.so (0x4088f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40891000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)

gdb output:

pluto:/usr/local/apache/bin # gdb httpd
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-suse-linux"...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
[New Thread 1024 (LWP 7211)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 7211)]
0x8159933 in zend_hash_index_find (ht=0x822ca44, h=11,
pData=0xbfffea98)
at zend_hash.c:935
935 if ((p->h == h) && (p->nKeyLength == 0)) {
(gdb) bt
#0  0x8159933 in zend_hash_index_find (ht=0x822ca44, h=11,
pData=0xbfffea98)
at zend_hash.c:935
#1  0x815a54b in _zend_list_delete (id=11) at zend_list.c:53
#2  0x80aa637 in _oci_column_hash_dtor (data=0x8f0db04) at oci8.c:727
#3  0x815894a in zend_hash_destroy (ht=0x87db67c) at zend_hash.c:541
#4  0x80aa7f8 in _oci_stmt_list_dtor (rsrc=0x87db4b4) at oci8.c:771
#5  0x815a838 in list_entry_destructor (ptr=0x87db4b4) at
zend_list.c:177
#6  0x815aa67 in zend_destroy_rsrc_list (ht=0x822ca44) at
zend_list.c:248
#7  0x8148f97 in shutdown_executor () at zend_execute_API.c:196
#8  0x8152d84 in zend_deactivate () at zend.c:600
#9  0x806d71f in php_request_shutdown (dummy=0x0) at main.c:735
#10 0x815f596 in apache_php_module_main (r=0x828fe44,
display_source_mode=0)
at sapi_apache.c:96
#11 0x806ac3e in send_php ()
#12 0x806aca6 in send_parsed_php ()
#13 0x8184509 in ap_invoke_handle

Bug #15499 Updated: Apache crashes with Segmentation fault

[derick]

 ID:   15499
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Linux
 PHP Version:  4.1.1
 New Comment:

Can you possible try a snapshot from snaps.php.net?

Derick


Previous Comments:


[2002-03-12 08:24:46] [EMAIL PROTECTED]

You can try to fix it yourself...
If you've fixed it, please post a diff here or send it to
[EMAIL PROTECTED]



[2002-03-12 08:16:08] [EMAIL PROTECTED]

We need urgent support on this case!
What can we do to accellerate the necessary steps?

Sincerly,

Mike



[2002-02-20 12:37:51] [EMAIL PROTECTED]

We use Oracle 8.1.7

this described bug is completely reproduceable.

We store in our App the session-data in a db-table in a CLOB. Maybe
there is a problem with the LOB-Handling of the OCI8-Module.

I hope this bug will be edited soon, because we have real problems with
our customers.

We can also give root-access via ssh to our server for debugging.



[2002-02-13 09:55:04] [EMAIL PROTECTED]

We see this same problem on Redhat 6.2 kernel version 2.2.19-6.3.  We
are using version 8.1.6.2 of the oracle client libraries with php 4.0.6
and php 4.1.1.



[2002-02-11 07:09:29] [EMAIL PROTECTED]

We run many sites with php4 and oracle.
On every site we have seen that Apache child processes crash after
about 10 to 20 requests.
We use different Linux Versions (RedHat 7.1, SuSe Linux 7.1, 7.3) and
also different php-Versions (php4.0.6, php4.1.1).
All these sites use Oracle as Database (oci8-Module).
We run other sites with PHP but without Oracle-Module and these sites
run stable.
We tried also PHP on W2K with IIS with the ISAPI Module with
Oci8-Support and we have the same effect, after 10 to 20 requests, the
Server stops serving PHP-Sites, ...
... this seems to be a bug in the oci8-Module of php.

below ldd of http and a gdb backtrace.
phpinfo can be requested from this url:
http://sqp.sft.jawa.at/test.php

ldd httpd
libdl.so.2 => /lib/libdl.so.2 (0x40027000)
libm.so.6 => /lib/libm.so.6 (0x4002a000)
libldap.so.1 => /usr/lib/libldap.so.1 (0x40048000)
liblber.so.1 => /usr/lib/liblber.so.1 (0x4005d000)
libgd.so => /usr/local/lib/libgd.so (0x40062000)
libt1.so.1 => /usr/local/lib/libt1.so.1 (0x4009d000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x400e)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40116000)
libz.so.1 => /usr/local/lib/libz.so.1 (0x40142000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40151000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4017)
libresolv.so.2 => /lib/libresolv.so.2 (0x4019e000)
libnsl.so.1 => /lib/libnsl.so.1 (0x401af000)
libclntsh.so.8.0 => /opt/oracle/OraHome1/lib/libclntsh.so.8.0
(0x401c5000)
libc.so.6 => /lib/libc.so.6 (0x4077b000)
libwtc8.so => /opt/oracle/OraHome1/lib/libwtc8.so (0x4088f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40891000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)

gdb output:

pluto:/usr/local/apache/bin # gdb httpd
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-suse-linux"...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
[New Thread 1024 (LWP 7211)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 7211)]
0x8159933 in zend_hash_index_find (ht=0x822ca44, h=11,
pData=0xbfffea98)
at zend_hash.c:935
935 if ((p->h == h) && (p->nKeyLength == 0)) {
(gdb) bt
#0  0x8159933 in zend_hash_index_find (ht=0x822ca44, h=11,
pData=0xbfffea98)
at zend_hash.c:935
#1  0x815a54b in _zend_list_delete (id=11) at zend_list.c:53
#2  0x80aa637 in _oci_column_hash_dtor (data=0x8f0db04) at oci8.c:727
#3  0x815894a in zend_hash_destroy (ht=0x87db67c) at zend_hash.c:541
#4  0x80aa7f8 in _oci_stmt_list_dtor (rsrc=0x87db4b4) at oci8.c:771
#5  0x815a838 in list_entry_destructor (ptr=0x87db4b4) at
zend_list.c:177
#6  0x815aa67 in zend_destroy_rsrc_list (ht=0x822ca44) at
zend_list.c:248
#7  0x8148f97 in shutdown_executor () at zend_execute_API.c:196
#8  0x8152d84 in zend_deactivate () at zend.c:600
#9  0x806d71f in php_request_shutdown (dummy=0x0) at main.c:73

Bug #16018 Updated: PHP crashing (Backtrace included)

[sniper]

 ID:   16018
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: RH linux7.2
 PHP Version:  4.1.2
 New Comment:

Please add some short example script which can be used
to  reproduce this. And also, try with the latest CVS
snapshot from http://snaps.php.net/ 

--Jani



Previous Comments:


[2002-03-12 07:52:36] [EMAIL PROTECTED]

config.nice
'./configure' \
'--with-apxs=/www/bin/apxs' \
'--with-mysql' \
'--with-pgsql=/usr/local/pgsql' \
'--without-pear' \
'--with-gd' \
'--enable-wddx' \
'--with-xmlrpc' \
'--with-curl' \
'--enable-debug' \
"$@"

backtrace:

#0  0x40540d89 in execute (op_array=0x81bb53c) at
./zend_execute.c:1815
#1  0x4053fe02 in execute (op_array=0x8237a40) at
./zend_execute.c:1630
#2  0x4053fe02 in execute (op_array=0x81947cc) at
./zend_execute.c:1630
#3  0x4054e574 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at zend.c:814
#4  0x4055bfa1 in php_execute_script (primary_file=0xb600) at
main.c:1307
#5  0x40558082 in apache_php_module_main (r=0x8186b24,
display_source_mode=0) at sapi_apache.c:90
#6  0x40558b65 in send_php (r=0x8186b24, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#7  0x40558bba in send_parsed_php (r=0x8186b24) at mod_php4.c:590
#8  0x808bded in ap_invoke_handler ()
#9  0x80a0fab in process_request_internal ()
#10 0x80a100c in ap_process_request ()
#11 0x8098051 in child_main ()
#12 0x8098220 in make_child ()
#13 0x8098390 in startup_children ()
#14 0x8098a09 in standalone_main ()
#15 0x80992a3 in main ()
#16 0x4016db65 in __libc_start_main (main=0x8098ee0 , argc=2,
ubp_av=0xbb14, init=0x8054a30 <_init>, 
fini=0x80d132c <_fini>, rtld_fini=0x4000df24 <_dl_fini>,
stack_end=0xbb0c) at ../sysdeps/generic/libc-start.c:111

Only happens under POST and then a Header("location: ...") as far as i
cant tell





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

Bug #15499 Updated: Apache crashes with Segmentation fault

[mbretter]

 ID:   15499
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: OCI8 related
 Operating System: Linux
 PHP Version:  4.1.1
 New Comment:

I already tried the latest version from cvs
/* $Id: oci8.c,v 1.168 2002/02/10 12:41:52 thies Exp $ */
and 
/* $Id: php_oci8.h,v 1.23 2002/02/10 12:41:52 thies Exp $ */

with the same effect


Previous Comments:


[2002-03-12 08:25:19] [EMAIL PROTECTED]

Can you possible try a snapshot from snaps.php.net?

Derick



[2002-03-12 08:24:46] [EMAIL PROTECTED]

You can try to fix it yourself...
If you've fixed it, please post a diff here or send it to
[EMAIL PROTECTED]



[2002-03-12 08:16:08] [EMAIL PROTECTED]

We need urgent support on this case!
What can we do to accellerate the necessary steps?

Sincerly,

Mike



[2002-02-20 12:37:51] [EMAIL PROTECTED]

We use Oracle 8.1.7

this described bug is completely reproduceable.

We store in our App the session-data in a db-table in a CLOB. Maybe
there is a problem with the LOB-Handling of the OCI8-Module.

I hope this bug will be edited soon, because we have real problems with
our customers.

We can also give root-access via ssh to our server for debugging.



[2002-02-13 09:55:04] [EMAIL PROTECTED]

We see this same problem on Redhat 6.2 kernel version 2.2.19-6.3.  We
are using version 8.1.6.2 of the oracle client libraries with php 4.0.6
and php 4.1.1.



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/15499

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

Bug #15944 Updated: imap_sort Error

[sander]

 ID:   15944
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Analyzed
 Bug Type: Documentation problem
 Operating System: Windows XP
 PHP Version:  4.1.1
 New Comment:

Fixed that sentence, but the rest of the functions might need notes
about the availability on POP/NNTP servers.


Previous Comments:


[2002-03-08 03:26:36] [EMAIL PROTECTED]

This is documentation problem. When you use pop3
it doesn't have all the capabilities as imap has.
Search & sorting are one of the missing ones, AFAIK.

On this page: 
http://www.php.net/manual/en/function.imap-open.php

Is a faulty line which confuses (at least me :)

"This function can also be used to open streams to POP3 and NNTP
servers, but some functions and features are not available on IMAP
servers. "

It should be saying "..features are only available on IMAP.."

--Jani




[2002-03-07 21:09:38] [EMAIL PROTECTED]



// if u run it on Windows. U will see the error message "ERROR PHP.EXE"
and "Gate ERROR"!!

/*
My System 
Windows XP, IIS 5.1, Expoler 6.0, PHP 4.1.1
*/




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

Bug #14939 Updated: Warning: gzinflate: buffer error in /usr/local/apache/elca_rmg/class.FTemplateE

[sr]

 ID:   14939
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: Zlib Related
 Operating System: Apache
 PHP Version:  4.1.1
 Assigned To:  sr
 New Comment:

Should be fixed in latest cvs version.


Previous Comments:


[2002-03-07 17:24:45] [EMAIL PROTECTED]

Does the attached patch help?

--- /home/sr/cvs/php/php4/ext/zlib/zlib.c   Thu Mar  7 16:38:26
2002
+++ ext/zlib/zlib.c Thu Mar  7 23:15:48 2002
@@ -967,7 +967,7 @@
if(! s2) { if(s1) efree(s1); RETURN_FALSE; }
 
stream.next_in = (Bytef*) Z_STRVAL_PP(data);
-   stream.avail_in = (uInt) Z_STRLEN_PP(data);
+   stream.avail_in = (uInt) Z_STRLEN_PP(data) + 1; /*
there is room for \0 */
 
stream.next_out = s2;
stream.avail_out = (uInt) length;

(If there are broken line breaks and you can't apply it, change the
line stream.avail_in = (uInt) Z_STRLEN_PP(data) to ...(data)+1 in the
gzinflate function).

Please report if it works (and if it doesn't break other things). This
seems to be a rather strange thing in the zlib library ...




[2002-03-07 08:06:33] [EMAIL PROTECTED]

Does this script work if you don't provide a compression level?


-- robin



[2002-01-08 21:04:16] [EMAIL PROTECTED]

Receive the following error with only 15 consecutive characters
entered.

Warning: gzinflate: buffer error in
/usr/local/apache/elca_rmg/class.FTemplateExt.php on line 153

What follows is the code updating the SQL files:

$gzsize = strlen($description) + 4;  // added 4 more than req'd
$gzcompress = gzdeflate ($description,6);
$gzcompress = addslashes($gzcompress);  //Reqd for SQL updates

$query = "UPDATE htmlcontent SET record_nbr = \"$record_nbr\",
gzcompress = \"$gzcompress\", gzsize = $gzsize WHERE record_nbr =
\"$record_nbr\"";
  }
general_update($errno,$errmsg,$rowsaffected, $result, $s_synod_id,
$query);   // UPDATE the record

***
Next I attempt to read the record back and unzip gzcompress
Note that $description consists of 20 'a' characters.  Any repetitive
char will do and only 15 to 20 are req'd
***

$query = "SELECT * FROM htmlcontent WHERE record_nbr =
\"$record_nbr\"";
   
general_read($errno, $errmsg,$numrows, $result_html, $s_synod_id,
$query);
   
if  ($numrows > 0) {
if ($row_html = mysql_fetch_array ($result_html)) {
 $content = stripslashes($row_html["gzcompress"]);
 if (strlen($content) > 0) {
**Error occurs on the following instruction*
$new = gzinflate($content,$row_html["gzsize"]);





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

Bug #16018 Updated: PHP crashing (Backtrace included)

[matt]

 ID:   16018
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: RH linux7.2
 PHP Version:  4.1.2
 New Comment:

Currently downloading the latest snap, this BT was from 4.1.2.

I cant make a little script, as far I can tell it's borking on a
Header("Location: ");


Previous Comments:


[2002-03-12 08:29:10] [EMAIL PROTECTED]

Please add some short example script which can be used
to  reproduce this. And also, try with the latest CVS
snapshot from http://snaps.php.net/ 

--Jani




[2002-03-12 07:52:36] [EMAIL PROTECTED]

config.nice
'./configure' \
'--with-apxs=/www/bin/apxs' \
'--with-mysql' \
'--with-pgsql=/usr/local/pgsql' \
'--without-pear' \
'--with-gd' \
'--enable-wddx' \
'--with-xmlrpc' \
'--with-curl' \
'--enable-debug' \
"$@"

backtrace:

#0  0x40540d89 in execute (op_array=0x81bb53c) at
./zend_execute.c:1815
#1  0x4053fe02 in execute (op_array=0x8237a40) at
./zend_execute.c:1630
#2  0x4053fe02 in execute (op_array=0x81947cc) at
./zend_execute.c:1630
#3  0x4054e574 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at zend.c:814
#4  0x4055bfa1 in php_execute_script (primary_file=0xb600) at
main.c:1307
#5  0x40558082 in apache_php_module_main (r=0x8186b24,
display_source_mode=0) at sapi_apache.c:90
#6  0x40558b65 in send_php (r=0x8186b24, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#7  0x40558bba in send_parsed_php (r=0x8186b24) at mod_php4.c:590
#8  0x808bded in ap_invoke_handler ()
#9  0x80a0fab in process_request_internal ()
#10 0x80a100c in ap_process_request ()
#11 0x8098051 in child_main ()
#12 0x8098220 in make_child ()
#13 0x8098390 in startup_children ()
#14 0x8098a09 in standalone_main ()
#15 0x80992a3 in main ()
#16 0x4016db65 in __libc_start_main (main=0x8098ee0 , argc=2,
ubp_av=0xbb14, init=0x8054a30 <_init>, 
fini=0x80d132c <_fini>, rtld_fini=0x4000df24 <_dl_fini>,
stack_end=0xbb0c) at ../sysdeps/generic/libc-start.c:111

Only happens under POST and then a Header("location: ...") as far as i
cant tell





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

Bug #16020: long2ip Returns Incorrect Results

[lee]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.4-STABLE i386
PHP version:  4.1.2
PHP Bug Type: Unknown/Other Function
Bug description:  long2ip Returns Incorrect Results

I have found some problems where long2ip (and I would presume ip2long by
the same token) seems to return an IP address offset by one.  I'm not sure
if it is the implmentation of inet_ntoa on the platform I am using or
something else.

Even if this is a problem with a particular version of a library on my
machine, maybe it might be worth using a method other than inet_ntoa for
ease of platform independance?

Perhaps something along there lines  ?


struct inet4addr {
  unsigned int a:8;
  unsigned int b:8;
  unsigned int c:8;
  unsigned int d:8;
};

typedef union {
  unsigned int inet4dec;
  struct inet4addr inet4oct;
} inet4oct;
  
  blah.inet4dec = ;
  printf("%i.%i.%i.%i\n", blah.inet4oct.a,
blah.inet4oct.b,blah.inet4oct.c,blah.inet4oct.d);


 
-- 
Edit bug report at http://bugs.php.net/?id=16020&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16020&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16020&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16020&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16020&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16020&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16020&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16020&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16020&r=submittedtwice

Bug #15499 Updated: Apache crashes with Segmentation fault

[mbretter]

 ID:   15499
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OCI8 related
 Operating System: Linux
 PHP Version:  4.1.1
 New Comment:

We will pay for the support if the bug can be fixed from  one of the
php-developers.

I think the maintainer of this module will find the bug more quickly.


Previous Comments:


[2002-03-12 08:30:00] [EMAIL PROTECTED]

I already tried the latest version from cvs
/* $Id: oci8.c,v 1.168 2002/02/10 12:41:52 thies Exp $ */
and 
/* $Id: php_oci8.h,v 1.23 2002/02/10 12:41:52 thies Exp $ */

with the same effect



[2002-03-12 08:25:19] [EMAIL PROTECTED]

Can you possible try a snapshot from snaps.php.net?

Derick



[2002-03-12 08:24:46] [EMAIL PROTECTED]

You can try to fix it yourself...
If you've fixed it, please post a diff here or send it to
[EMAIL PROTECTED]



[2002-03-12 08:16:08] [EMAIL PROTECTED]

We need urgent support on this case!
What can we do to accellerate the necessary steps?

Sincerly,

Mike



[2002-02-20 12:37:51] [EMAIL PROTECTED]

We use Oracle 8.1.7

this described bug is completely reproduceable.

We store in our App the session-data in a db-table in a CLOB. Maybe
there is a problem with the LOB-Handling of the OCI8-Module.

I hope this bug will be edited soon, because we have real problems with
our customers.

We can also give root-access via ssh to our server for debugging.



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/15499

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

Bug #15930 Updated: gzencode can't have a level

[sr]

 ID:   15930
 Updated by:   [EMAIL PROTECTED]
-Summary:  gzencode can't have a level
 Reported By:  [EMAIL PROTECTED]
-Status:   Analyzed
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: windows 2000
 PHP Version:  4.1.1
 Assigned To:  sr
 New Comment:

Fixed in latest cvs.


Previous Comments:


[2002-03-07 13:04:09] [EMAIL PROTECTED]

Well, I prefer the fonctionnality in documentation
or something like : gzencode($data[,$level[,$mode]])

It would be much easy to use, than make a gzip by hand with header,crc,
...

in "User Contributed Notes" two another persons report this problem. We
can perhaps ask them.



[2002-03-07 12:42:03] [EMAIL PROTECTED]

Z_DEFAULT_COMPRESSION is a constant of the zlib include file, so you
could change it only with a recompile of php.

As a workaround maybe you can use gzdeflate() or gzcompress(), there
the second parameter is the compression level. But then you have to
manually add the gzip headers (and maybe the CRC) if you need them.



[2002-03-07 11:41:43] [EMAIL PROTECTED]

YES, I use it. before I use gzopen($fic,"wb9"); with a temporary file
the compression was better than gzencode.
For passing information from serveur to client, the size of data is
very important. I prefer spending 20 ms for much compression than 30
sec more for download.
but if it is possible to change the Z_DEFAULT_COMPRESSION,
it's ok I always use the same (maxi) compression.



[2002-03-07 10:50:54] [EMAIL PROTECTED]

That's an error in the documentation.

The optional second parameter doesn't set the compression level, it
does set the compression mode, i.e. you can use FORCE_GZIP or
FORCE_DEFLATE in order to use gzip/deflate compression. The compression
level is always the default Z_DEFAULT_COMPRESSION.

If nobody objects (does anybody use this parameter?) I'll fix the
documentation ...




[2002-03-07 07:37:05] [EMAIL PROTECTED]

";
$gzdata = gzencode($data,9);
echo strlen($gzdata),":bad always 10";
?>




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

Bug #15908 Updated: failed to compile with iconv

[winfried]

 ID:   15908
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: FreeBSD 4.5-RELEASE
 PHP Version:  4.1.2
 New Comment:

[15:01] mizantrop:~/tmp/php(13)# tail -n 2 config.log 
configure:28872: checking for ICAP support
configure:29268: checking for iconv support

EOF here. Tried the today's snapshot.


Previous Comments:


[2002-03-08 13:28:11] [EMAIL PROTECTED]

Check what config.log has about it.

--Jani




[2002-03-08 11:47:06] [EMAIL PROTECTED]

I tried the latest snapshot:

http://snaps.php.net/php4-200203080600.tar.bz2

But the configure simply fails on iconv:

(..)
checking for iconv support... yes
configure: error: Please reinstall the iconv library.

Oink?



[2002-03-07 14:33:32] [EMAIL PROTECTED]

Could you please try the latest CVS snapshot from
http://snaps.php.net/ ? 




[2002-03-07 11:01:41] [EMAIL PROTECTED]

I tried the patch specified in:

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

but it fails at:

Making all in main
cc -I. -I/usr/ports/www/mod_php4/work/php-4.1.2/main
-I/usr/ports/www/mod_php4/work/php-4.1.2/main
-I/usr/ports/www/mod_php4/work/php-4.1.2
-I/usr/ports/www/mod_php4/work/php-4.1.2/Zend
-I/usr/local/include/freetype2/freetype -I/usr/local/include/gd
-I/usr/local/include -I/usr/local/include/mysql
-I/usr/local/include/pspell 
-I/usr/ports/www/mod_php4/work/php-4.1.2/TSRM -march=i686 -O6
-I/usr/local/include -I/usr/local/include/pgsql  -c
internal_functions.c && touch internal_functions.lo
internal_functions.c:69: `iconv_module_entry' undeclared here (not in a
function)
internal_functions.c:69: initializer element is not constant
internal_functions.c:69: (near initialization for
`php_builtin_extensions[15]')
*** Error code 1



[2002-03-06 12:58:42] [EMAIL PROTECTED]

I tried to compile latest PHP 4.1.2 on my system.
I need the iconv extension, but I get the following
error in linking:

/bin/sh /usr/ports/www/mod_php4/work/php-4.1.2/libtool --silent
--mode=link cc -I. -I/usr/ports/www/mod_php4/work/php-4.1.2/
-I/usr/ports/www/mod_php4/work/php-4.1.2/main
-I/usr/ports/www/mod_php4/work/php-4.1.2
-I/usr/ports/www/mod_php4/work/php-4.1.2/Zend
-I/usr/local/include/freetype2/freetype -I/usr/local/include/gd
-I/usr/local/include -I/usr/local/include/mysql
-I/usr/local/include/pspell 
-I/usr/ports/www/mod_php4/work/php-4.1.2/TSRM -march=i686 -O6
-I/usr/local/include -I/usr/local/include/pgsql   -o php
-export-dynamic stub.lo libphp4.la 
./.libs/libphp4.a(internal_functions.o)(.data+0x3c): undefined
reference to `iconv_module_entry'
*** Error code 1

I'm making the PHP binary standalone, right from ports. Some info about
the system: iconv-2.0, Sablot-0.81, expat-1.95.2. I had a similar
problem on other system, making an Apache PHP module; with PHP 4.0.6 I
had no
problems with that (on FreeBSD 4.4-RELEASE/STABLE).

Here's my configure line:
--with-config-file-path=/usr/local/etc/php.standalone --disable-pear
--enable-discard-path --with-readline=/usr --enable-force-cgi-redirect
--enable-versioning --with-system-regex --disable-debug
--enable-track-vars --without-gd --without-mysql --with-gd=/usr/local
--with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local
--with-png-dir=/usr/local --with-zlib --with-mcrypt=/usr/local
--with-mhash=/usr/local --with-mysql=/usr/local --with-pgsql=/usr/local
--with-xml --with-expat-dir=/usr/local --enable-xslt --with-xslt-sablot
--with-expat-dir=/usr/local --with-iconv=/usr/local
--with-pspell=/usr/local --enable-mbregex --enable-mbstring
--enable-sockets --enable-trans-sid --with-iconv=/usr/local
--prefix=/usr/local i386-portbld-freebsd4.5





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

Bug #16020 Updated: long2ip Returns Incorrect Results

[sander]

 ID:   16020
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Unknown/Other Function
 Operating System: FreeBSD 4.4-STABLE i386
 PHP Version:  4.1.2
 New Comment:

Can you provide a simple sample script with data that shows the
problem?


Previous Comments:


[2002-03-12 08:47:38] [EMAIL PROTECTED]

I have found some problems where long2ip (and I would presume ip2long
by the same token) seems to return an IP address offset by one.  I'm
not sure if it is the implmentation of inet_ntoa on the platform I am
using or something else.

Even if this is a problem with a particular version of a library on my
machine, maybe it might be worth using a method other than inet_ntoa
for ease of platform independance?

Perhaps something along there lines  ?


struct inet4addr {
  unsigned int a:8;
  unsigned int b:8;
  unsigned int c:8;
  unsigned int d:8;
};

typedef union {
  unsigned int inet4dec;
  struct inet4addr inet4oct;
} inet4oct;
  
  blah.inet4dec = ;
  printf("%i.%i.%i.%i\n", blah.inet4oct.a,
blah.inet4oct.b,blah.inet4oct.c,blah.inet4oct.d);


 




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

Bug #16020 Updated: long2ip Returns Incorrect Results

[lee]

 ID:   16020
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Unknown/Other Function
 Operating System: FreeBSD 4.4-STABLE i386
 PHP Version:  4.1.2
 New Comment:

Sorry, I missed out a bit:

inet4oct blah;

;)


Previous Comments:


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

Can you provide a simple sample script with data that shows the
problem?



[2002-03-12 08:47:38] [EMAIL PROTECTED]

I have found some problems where long2ip (and I would presume ip2long
by the same token) seems to return an IP address offset by one.  I'm
not sure if it is the implmentation of inet_ntoa on the platform I am
using or something else.

Even if this is a problem with a particular version of a library on my
machine, maybe it might be worth using a method other than inet_ntoa
for ease of platform independance?

Perhaps something along there lines  ?


struct inet4addr {
  unsigned int a:8;
  unsigned int b:8;
  unsigned int c:8;
  unsigned int d:8;
};

typedef union {
  unsigned int inet4dec;
  struct inet4addr inet4oct;
} inet4oct;
  
  blah.inet4dec = ;
  printf("%i.%i.%i.%i\n", blah.inet4oct.a,
blah.inet4oct.b,blah.inet4oct.c,blah.inet4oct.d);


 




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

Bug #16002 Updated: imagecreatetruecolor not recognizing create version of GD library

[md5ander]

 ID:   16002
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GD related
 Operating System: Red Hat Linux
 PHP Version:  4.1.2
 New Comment:

i got the same errors with the precomiled win32 version of php 4.1.2.

Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in
c:\www\scripts\cddb_appl\crop.php on line 46

Is there a fault in the config file (i.e. should
php.ini:extension=php_gd.dll read php_gd2.dll?) or what?


Previous Comments:


[2002-03-11 15:55:29] [EMAIL PROTECTED]

I rent my server from a virtual host so I do not have much control over
the server.  This might not be a bug but a error in them compiling it
but it should be reported just in case.

I had a script that was working that used imagecreatetruecolor with a
older version of PHP, I think it was two versions back.
Anyway, my server updated to php 4.1.2 and it 2.01 of GD and after that
my script would only return this error.


Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in
/home/member/public_html/website/admin/imgfunctions.php on line 39

As I said it is a virtual server but phpinfo produced this,

 './configure' '--with-mysql' '--with-apache=../apache_1.3.23'
'--enable-track-vars' '--with-gd=/usr/gd-2.0.1' '--with-jpeg-dir=/usr'
'--with-png-dir=/usr/local/lib' '--with-zlib-dir=/usr/local/include'

This might not be a bug but an error in my server compiling the latest
version of PHP.

Please email me at [EMAIL PROTECTED] if an error is obvious that you can
see that I can't and I will contact my host and see if that is the
problem and then this bug report can be closed.






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

Bug #16002 Updated: imagecreatetruecolor not recognizing create version of GD library

[dlaur]

 ID:   16002
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GD related
 Operating System: Red Hat Linux
 PHP Version:  4.1.2
 New Comment:

Here is an update from my server.
Sorry guys that I do not have my own server but this is all I can do to
track this down.
I am working on getting my own server up locally to test this but
haven't had luck yet.

Here is the comments from my server host.

We have been attempting to correct this problem today by re-compiling
PHP and GD, but to no avail at this point.  For some unknown reason the
GD test programs won't even work because of the gdImageCreateTrueColor
problems (yet GD compiles fine).


Previous Comments:


[2002-03-12 09:50:11] [EMAIL PROTECTED]

i got the same errors with the precomiled win32 version of php 4.1.2.

Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in
c:\www\scripts\cddb_appl\crop.php on line 46

Is there a fault in the config file (i.e. should
php.ini:extension=php_gd.dll read php_gd2.dll?) or what?



[2002-03-11 15:55:29] [EMAIL PROTECTED]

I rent my server from a virtual host so I do not have much control over
the server.  This might not be a bug but a error in them compiling it
but it should be reported just in case.

I had a script that was working that used imagecreatetruecolor with a
older version of PHP, I think it was two versions back.
Anyway, my server updated to php 4.1.2 and it 2.01 of GD and after that
my script would only return this error.


Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in
/home/member/public_html/website/admin/imgfunctions.php on line 39

As I said it is a virtual server but phpinfo produced this,

 './configure' '--with-mysql' '--with-apache=../apache_1.3.23'
'--enable-track-vars' '--with-gd=/usr/gd-2.0.1' '--with-jpeg-dir=/usr'
'--with-png-dir=/usr/local/lib' '--with-zlib-dir=/usr/local/include'

This might not be a bug but an error in my server compiling the latest
version of PHP.

Please email me at [EMAIL PROTECTED] if an error is obvious that you can
see that I can't and I will contact my host and see if that is the
problem and then this bug report can be closed.






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

Bug #16020 Updated: long2ip Returns Incorrect Results

[lee]

 ID:   16020
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Unknown/Other Function
 Operating System: FreeBSD 4.4-STABLE i386
 PHP Version:  4.1.2
 New Comment:

I've done a little more digging to see why the problem occured.  I'm
not 100% sure if it is a problem with php, or misuse of php really. 
However it might be worth adding in something to make this work.

My script was getting the decimal address as a string, an integer.  The
following example should illustrate it.

";

$moo = 167772161;
echo long2ip($moo);

?>


As a side thing you also need to add the following to get larger
numbers to work when using strings:

if ($moo > 0) $moo += pow(2,32);


Previous Comments:


[2002-03-12 09:04:56] [EMAIL PROTECTED]

Sorry, I missed out a bit:

inet4oct blah;

;)



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

Can you provide a simple sample script with data that shows the
problem?



[2002-03-12 08:47:38] [EMAIL PROTECTED]

I have found some problems where long2ip (and I would presume ip2long
by the same token) seems to return an IP address offset by one.  I'm
not sure if it is the implmentation of inet_ntoa on the platform I am
using or something else.

Even if this is a problem with a particular version of a library on my
machine, maybe it might be worth using a method other than inet_ntoa
for ease of platform independance?

Perhaps something along there lines  ?


struct inet4addr {
  unsigned int a:8;
  unsigned int b:8;
  unsigned int c:8;
  unsigned int d:8;
};

typedef union {
  unsigned int inet4dec;
  struct inet4addr inet4oct;
} inet4oct;
  
  blah.inet4dec = ;
  printf("%i.%i.%i.%i\n", blah.inet4oct.a,
blah.inet4oct.b,blah.inet4oct.c,blah.inet4oct.d);


 




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

Bug #16021: imap_bodystruct call generates signal (via abort())

[reinke]

From: [EMAIL PROTECTED]
Operating system: Linux (RedHat 6.2)
PHP version:  4.1.2
PHP Bug Type: Reproducible crash
Bug description:  imap_bodystruct call generates signal (via abort()) 

While this may have been used incorrectly causing a problem (don't know
since I've not been able to get it to work properly),
Consider the following steps:
a) Create a message with two attachments (in this case .doc files)
b) Mail the message to an account.
c) Read the email (in this case, with Netscape) and forward the
message as an attachment to an account from where you will
access it via PHP.
d) Now try to read and process the file.
The problem comes in dealin with the multipart/mixed portion that
represents the original message that is now an attachment.
When the call imap_bodystruct($stream, $msgno, $partno) is
invoked, where $partno can actually be any value at all (tested values
from
0 to 5), each case causes the Apache process handling the request to
croak.

The configure line from phpinfo() reads
'./configure' '--with-apache=../apache_1.3.23' '--enable-debug=no'
'--prefix=/usr/local/apache' '--with-zlib'
'--with-imap=/home/thomas/imap-4.7c' '--with-mcrypt' '--with-mhash'
'--with-pgsql' '--with-gd=/home/thomas/gd1.2'

The apache error log shows a single line
[Tue Mar 12 00:09:13 2002] [notice] child pid 10813 exit signal Aborted
(6)

-- 
Edit bug report at http://bugs.php.net/?id=16021&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16021&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16021&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16021&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16021&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16021&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16021&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16021&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16021&r=submittedtwice

Bug #16002 Updated: imagecreatetruecolor not recognizing create version of GD library

[dlaur]

 ID:   16002
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GD related
 Operating System: Red Hat Linux
-PHP Version:  4.1.2
+PHP Version:  4.1.1
 New Comment:

Duplicated the error on a new dedicated server account that I have.

This one is running version 4.1.1.

Same error:
Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in
/www/apache/htdocs/starsguitars/admin/imgfunctions.php on line 39

Here is the configuration

 './configure' '--with-apxs=/www/apache/bin/apxs'
'--with-config-file-path=/usr/local/apache/conf/'
'--with-mysql=/usr/local/mysql' '--enable-debug=no'
'--enable-track-vars' '--enable-magic-quotes' '--enable-ftp'
'--with-gd' '--with-jpeg-dir=/usr' '--with-png-dir=/usr/lib'
'--with-pear' '--with-curl' '--with-zlib-dir=/usr/lib' '--with-ttf'
'--enable-gd-native-ttf' '--with-xml' '--with-openssl'


Previous Comments:


[2002-03-12 10:02:47] [EMAIL PROTECTED]

Here is an update from my server.
Sorry guys that I do not have my own server but this is all I can do to
track this down.
I am working on getting my own server up locally to test this but
haven't had luck yet.

Here is the comments from my server host.

We have been attempting to correct this problem today by re-compiling
PHP and GD, but to no avail at this point.  For some unknown reason the
GD test programs won't even work because of the gdImageCreateTrueColor
problems (yet GD compiles fine).



[2002-03-12 09:50:11] [EMAIL PROTECTED]

i got the same errors with the precomiled win32 version of php 4.1.2.

Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in
c:\www\scripts\cddb_appl\crop.php on line 46

Is there a fault in the config file (i.e. should
php.ini:extension=php_gd.dll read php_gd2.dll?) or what?



[2002-03-11 15:55:29] [EMAIL PROTECTED]

I rent my server from a virtual host so I do not have much control over
the server.  This might not be a bug but a error in them compiling it
but it should be reported just in case.

I had a script that was working that used imagecreatetruecolor with a
older version of PHP, I think it was two versions back.
Anyway, my server updated to php 4.1.2 and it 2.01 of GD and after that
my script would only return this error.


Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in
/home/member/public_html/website/admin/imgfunctions.php on line 39

As I said it is a virtual server but phpinfo produced this,

 './configure' '--with-mysql' '--with-apache=../apache_1.3.23'
'--enable-track-vars' '--with-gd=/usr/gd-2.0.1' '--with-jpeg-dir=/usr'
'--with-png-dir=/usr/local/lib' '--with-zlib-dir=/usr/local/include'

This might not be a bug but an error in my server compiling the latest
version of PHP.

Please email me at [EMAIL PROTECTED] if an error is obvious that you can
see that I can't and I will contact my host and see if that is the
problem and then this bug report can be closed.






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

Bug #11021 Updated: apache crash when mail with linked files over 2 ko

[sadara]

 ID:   11021
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Duplicate
 Bug Type: Mail related
 Operating System: windows 98 SE
 PHP Version:  4.0.5
 Assigned To:  hholzgra
 New Comment:

Same result:

"APACHE caused an invalid page fault in
module MSVCRT.DLL at 017f:780035d7."

Windows 98SE
Apache 1.3.20
PHP 4.1.0

Code:



big.txt is a 15k csv file.

Identical code with identical attachment runs fine under FreeBSD
3.0/Apache 1.3.6/PHP 4.0.1pl2


Previous Comments:


[2001-06-22 18:32:06] [EMAIL PROTECTED]

see #11165



[2001-05-22 12:21:37] [EMAIL PROTECTED]

I work with apache 1.3.19, with php 4.0.5 downloaded here

I can't send any linked files with mail() when they are over about 2
ko...


no error log


apache crash :
Ce programme va être arrété car il a effectué une opération non
conforme (this program will be stopped because it made a non-conform
error)
APACHE a causé une défaillance de page dans
 le module MSVCRT.DLL à 0167:78004c96.

APACHE a causé une défaillance de page dans
 le module PHP4TS.DLL à 0167:00bee5ea.

APACHE a causé une défaillance de page dans
 le module PHP4TS.DLL à 0167:00c1d86d.


the code :
*
*

class Email 
{ 
//---Global Variables 
var $mailTo= "";// array of
To addresses 
var $mailFrom= "";// from
address 
var $mailSubject= "";// email
subject 
var $mailText= "";// plain text
message 
var $mailAttachments= "";// array of
attachments 

/*#Fonction rajoutée , le
constructeur###*/
function EMail($mailTo, $mailFrom, $mailSubject, $mailText,
$mailAttachments) {
$this->mailTo = $mailTo;
$this->mailFrom = $mailFrom;
$this->mailSubject = $mailSubject;
$this->mailText = $mailText;
$this->mailAttachments = $mailAttachments;
}




/***

Function:setTo($inAddress) 
Description:sets the email To address 
Arguments:$inAddress as string 
separate multiple values with comma 
Returns:true if set 
***/

function setTo($inAddress){ 
//--split addresses at commas 
$addressArray = explode(",",$inAddress); 
//--loop through each address and exit on error 
for($i=0;$icheckEmail($addressArray[$i])==false) return
false; 
} 
//--all values are OK so implode array into string 
$this->mailTo = implode($addressArray,","); 
return true; 
} 
/***

Function:setFrom($inAddress) 
Description:sets the email FROM address 
Arguments:$inAddress as string (takes single email address)

Returns:true if set 
***/

function setFrom($inAddress){ 
if($this->checkEmail($inAddress)){ 
$this->mailFrom = $inAddress; 
return true; 
} 
return false; 
} 
/***

Function:setSubject($inSubject) 
Description:sets the email subject 
Arguments:$inSubject as string 
Returns:true if set 
***/

function setSubject($inSubject){ 
if(strlen(trim($inSubject)) > 0){ 
$this->mailSubject = ereg_replace("\n","",$inSubject); 
return true; 
} 
return false; 
} 
/***

Function:setText($inText) 
Description:sets the email text 
Arguments:$inText as string 
Returns:true if set 
***/

function setText($inText){ 
if(strlen(trim($inText)) > 0){ 
$this->mailText = $inText; 
return true; 
} 
return false; 
} 
/***

Function:setAttachments($inAttachments) 
Description:stores the Attachment string 
Arguments:$inAttachme

Bug #16022: php 4.1.2 windows binary zip

[matled]

From: [EMAIL PROTECTED]
Operating system: windows
PHP version:  4.1.2
PHP Bug Type: Apache related
Bug description:  php 4.1.2 windows binary zip

The windows binary zip file apache module dll shows version 4.1.3-dev when
starting apache. Tt doesn't start at all if a php.ini is in %SystemRoot%.
If it is loaded every php file just shows an error as:
Warning: Failed opening '/path/to/foo.php' for inclusion
(include_path='c:\php4\pear') in Unknown on line 0
-- 
Edit bug report at http://bugs.php.net/?id=16022&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16022&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16022&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16022&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16022&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16022&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16022&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16022&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16022&r=submittedtwice

Bug #16023: php4apache.dll 4.1.2 for Windows misreporting its version via phpinfo()

[fseesink]

From: [EMAIL PROTECTED]
Operating system: Windows 2000 SP2 w/ all updates
PHP version:  4.1.2
PHP Bug Type: Apache related
Bug description:  php4apache.dll 4.1.2 for Windows misreporting its version via 
phpinfo()

Quick note:  this is a minor issue, but thought it best to report it since
others may be confused when they do the traditional 
script to test their setup.

I have been running Apache for Windows v1.3.23 with PHP v4.1.1 (Apache
module) as a service.  All works well, with \WINNT\PHP.INI configured, PHP
located in "\PHP".

* Downloaded PHP v4.1.2 for Windows today (12Mar2002)...the .ZIP file.
* Decompressed the .ZIP file.
* Noted differences in php.ini-recommended vs. my current php.ini file
(copied the cgi.* entries to my php.ini file, etc.).
* Once ready, renamed my current "\PHP" directory to "\PHP v4.1.1", then
renamed the decompressed directory from "\php-4.1.2-Win32" to "\PHP". 
Effectively swapped PHP 4.1.2 into place.
* Shutdown Apache service, then started it again.
* In webbrowser, loaded a php file containing




* Loading this webpage shows "PHP Version 4.1.1", NOT "PHP Version 4.1.2"
as one might expect.
* Using GRC.COM's ID Serve program, I get the following response:  
   "Server: Apache/1.3.23 (Win32) PHP/4.1.3-dev"
* Using NetCraft.com's "What's that site running?" feature, I get the
following response:  
   "Apache/1.3.23 (Win32) PHP/4.1.3-dev on Windows 2000"

In a nutshell, it appears that the Apache for Windows PHP SAPI module is
listing itself as both v4.1.1 and v4.1.3-dev, but NOT v4.1.2.  Again,
minor issue.  But thought you should be aware, in case many people start
contacting you about this.

P.S.  From the Command Prompt, if I enter 'php -v' in the \PHP directory,
the CGI version accurately reports "4.1.2", so this issue may only involve
the Apache SAPI module.  I can't speak for any of the other SAPI modules.

-- 
Edit bug report at http://bugs.php.net/?id=16023&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16023&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16023&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16023&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16023&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16023&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16023&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16023&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16023&r=submittedtwice

Bug #16023 Updated: php4apache.dll 4.1.2 for Windows misreporting its version via phpinfo()

[sander]

 ID:   16023
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Apache related
 Operating System: Windows 2000 SP2 w/ all updates
 PHP Version:  4.1.2
 New Comment:

Works fine for me. Maybe your browser (or a proxy) cached the page. Try
shift-F5. 


Previous Comments:


[2002-03-12 13:22:20] [EMAIL PROTECTED]

Quick note:  this is a minor issue, but thought it best to report it
since others may be confused when they do the traditional  script to test their setup.

I have been running Apache for Windows v1.3.23 with PHP v4.1.1 (Apache
module) as a service.  All works well, with \WINNT\PHP.INI configured,
PHP located in "\PHP".

* Downloaded PHP v4.1.2 for Windows today (12Mar2002)...the .ZIP file.
* Decompressed the .ZIP file.
* Noted differences in php.ini-recommended vs. my current php.ini file
(copied the cgi.* entries to my php.ini file, etc.).
* Once ready, renamed my current "\PHP" directory to "\PHP v4.1.1",
then renamed the decompressed directory from "\php-4.1.2-Win32" to
"\PHP".  Effectively swapped PHP 4.1.2 into place.
* Shutdown Apache service, then started it again.
* In webbrowser, loaded a php file containing




* Loading this webpage shows "PHP Version 4.1.1", NOT "PHP Version
4.1.2" as one might expect.
* Using GRC.COM's ID Serve program, I get the following response:  
   "Server: Apache/1.3.23 (Win32) PHP/4.1.3-dev"
* Using NetCraft.com's "What's that site running?" feature, I get the
following response:  
   "Apache/1.3.23 (Win32) PHP/4.1.3-dev on Windows 2000"

In a nutshell, it appears that the Apache for Windows PHP SAPI module
is listing itself as both v4.1.1 and v4.1.3-dev, but NOT v4.1.2. 
Again, minor issue.  But thought you should be aware, in case many
people start contacting you about this.

P.S.  From the Command Prompt, if I enter 'php -v' in the \PHP
directory, the CGI version accurately reports "4.1.2", so this issue
may only involve the Apache SAPI module.  I can't speak for any of the
other SAPI modules.





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

Bug #14688 Updated: session_register() doesn't register

[colin]

 ID:   14688
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: Session related
 Operating System: linux 2.2
 PHP Version:  4.1.0
 New Comment:

I notice this too under 4.1.2.  unset($var) doesn't unregister $var
from the session

FWIW, this is with Linux 2.4.6-pre6, and I'm using the default files
for session storage.

- Colin


Previous Comments:


[2002-02-02 06:38:08] [EMAIL PROTECTED]

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



[2002-01-11 18:31:26] [EMAIL PROTECTED]

Clarification. 
Which save handler are you using files or user?



[2001-12-25 14:20:57] [EMAIL PROTECTED]

This bug is in 4.1.1 aswell



[2001-12-25 07:44:24] [EMAIL PROTECTED]

Both servers got register_globals = On.
On the 4.1.0 server i run with a php.ini that originates from the 4.0.5
release.

--niklas



[2001-12-25 06:00:24] [EMAIL PROTECTED]

What is your register_globals setting?

Derick



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/14688

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

Bug #15419 Updated: ibase_close problem

[haystd]

 ID:   15419
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: InterBase related
 Operating System: linux red hat
 PHP Version:  4.1.1
 New Comment:

I can reproduce this as well. All is fine if the ibase_close call is
removed. It is a "Segmentation Fault" according to the Apache
error_log. (Could this be related to BUG 15940?) Here is the debugging
info:

Program received signal SIGSEGV, Segmentation fault.
0x4019c07c in memcpy () from /lib/i686/libc.so.6

#0  0x4019c07c in memcpy () from /lib/i686/libc.so.6
#1  0x0018 in ?? ()
#2  0x4003e564 in gds__msg_format () from /opt/interbase/lib/libgds.so
#3  0x4003e1c8 in gds__interprete () from /opt/interbase/lib/libgds.so
#4  0x40038ab3 in isc_interprete () from /opt/interbase/lib/libgds.so
#5  0x0808315a in _php_ibase_error () at interbase.c:268
#6  0x08083477 in _php_ibase_free_result (rsrc=0x82151a4) at
interbase.c:388
#7  0x081214f7 in list_entry_destructor (ptr=0x82151a4) at
zend_list.c:177
#8  0x0811f775 in zend_hash_del_key_or_index (ht=0x81c8e64, arKey=0x0,
nKeyLength=0, h=2, flag=1) at zend_hash.c:512
#9  0x08121281 in _zend_list_delete (id=2) at zend_list.c:56
#10 0x0811906d in _zval_dtor (zvalue=0x8215164,
__zend_filename=0x8191cdc "zend_execute_API.c", __zend_lineno=274)
at zend_variables.c:64
#11 0x08110e4a in _zval_ptr_dtor (zval_ptr=0x8215910,
__zend_filename=0x81925b3 "zend_variables.c", __zend_lineno=192)
at zend_execute_API.c:274
#12 0x0811939f in _zval_ptr_dtor_wrapper (zval_ptr=0x8215910)
at zend_variables.c:192
#13 0x0811f895 in zend_hash_destroy (ht=0x81c8d48) at zend_hash.c:541
#14 0x08110b4a in shutdown_executor () at zend_execute_API.c:173
#15 0x0811a1aa in zend_deactivate () at zend.c:600
#16 0x0807acdc in php_request_shutdown (dummy=0x0) at main.c:735
#17 0x08125c5a in apache_php_module_main (r=0x820859c,
display_source_mode=0)
at sapi_apache.c:96
#18 0x0807843c in send_php ()
#19 0x08078495 in send_parsed_php ()
#20 0x081471e3 in ap_invoke_handler ()
#21 0x0815b3c3 in process_request_internal ()
#22 0x0815b424 in ap_process_request ()
#23 0x0815288d in child_main ()
#24 0x08152a38 in make_child ()
#25 0x08152bac in startup_children ()
#26 0x08153224 in standalone_main ()
#27 0x08153a77 in main ()
#28 0x4012f627 in __libc_start_main (main=0x81536e0 , argc=2,
ubp_av=0xbb94, init=0x8060014 <_init>, fini=0x8169c00 <_fini>,
rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbb8c)
at ../sysdeps/generic/libc-start.c:129

PHP configured with:
./configure --without-mysql --with-apache=../apache_1.3.22/
--enable-track-vars --with-interbase=/opt/interbase --enable-debug

Apache configured with:
./configure --prefix=/usr/local/apache
--activate-module=src/modules/php4/libphp4.a

Firebase version: FirebirdSS-1.0.0.681-0.RC2
OS: RedHat 7.2 (Intel) 
Kernel: 2.4.17 (from kernel.org no patches)
Libc: 2.2.4
GCC: 2.96 2731 (Red Hat Linux 7.1 2.96-98)
PHP: 4.1.2


Previous Comments:


[2002-03-08 00:00:05] [EMAIL PROTECTED]

No feedback was provided for this bug for over a month, 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".



[2002-02-14 06:52:06] [EMAIL PROTECTED]

We experienced this same bug. I tested it in RH 7.2 with IB 6.
We run the same script from command line and got: Segmentation fault

when I comment ibase_close($db) out the script works fine.



[2002-02-07 03:17:27] [EMAIL PROTECTED]

Can look up in your apache log if you get a segfault or some similar
crash, and if so can you please provide a backtrace
(http://bugs.php.net/?id=15419&edit=1) ?



[2002-02-07 02:55:13] [EMAIL PROTECTED]



'./configure' '--prefix=/usr/local/php4.1.1/' '--enable-track-vars'
'--enable-trans-sid' '--with-mysql' '--disable-debug'
'--with-apxs=/usr/local/apache-local/bin/apxs' '--enable-shmop'
'--enable-xml' '--enable-sockets' '--with-gd'
'--with-interbase=/opt/interbase/'

Any command after ibase_close doesn't execute and apache returns 404
return code 






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

Bug #16023 Updated: php4apache.dll 4.1.2 for Windows misreporting its version via phpinfo()

[fseesink]

 ID:   16023
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Apache related
 Operating System: Windows 2000 SP2 w/ all updates
 PHP Version:  4.1.2
 New Comment:

Nope, that didn't do it.  Tried flushing browser caches, used a
different browser, etc.  Always the same.  Then it hit me:  I'm running
PHP Apache SAPI module, which requires the php4ts.dll file in
%SYSTEMROOT%\SYSTEM32\.  I had that file from v4.1.1 there.  Did not
think to replace it.

Copied v4.1.2 php4ts.dll into %SYSTEMROOT%\SYSTEM32, shutdown/restarted
Apache, and voila!

Thanks for the reminder.  Consider this issue dead.

Question:  What is the "preferred" location for php4ts.dll?  Is it
better to simply keep it in the same directory with php4apache.dll
(e.g., \PHP\SAPI\), or is it best to copy it to %SYSTEMROOT%\SYSTEM32? 
Is there really any difference, or is it purely personal preference?


Previous Comments:


[2002-03-12 13:42:24] [EMAIL PROTECTED]

Works fine for me. Maybe your browser (or a proxy) cached the page. Try
shift-F5. 



[2002-03-12 13:22:20] [EMAIL PROTECTED]

Quick note:  this is a minor issue, but thought it best to report it
since others may be confused when they do the traditional  script to test their setup.

I have been running Apache for Windows v1.3.23 with PHP v4.1.1 (Apache
module) as a service.  All works well, with \WINNT\PHP.INI configured,
PHP located in "\PHP".

* Downloaded PHP v4.1.2 for Windows today (12Mar2002)...the .ZIP file.
* Decompressed the .ZIP file.
* Noted differences in php.ini-recommended vs. my current php.ini file
(copied the cgi.* entries to my php.ini file, etc.).
* Once ready, renamed my current "\PHP" directory to "\PHP v4.1.1",
then renamed the decompressed directory from "\php-4.1.2-Win32" to
"\PHP".  Effectively swapped PHP 4.1.2 into place.
* Shutdown Apache service, then started it again.
* In webbrowser, loaded a php file containing




* Loading this webpage shows "PHP Version 4.1.1", NOT "PHP Version
4.1.2" as one might expect.
* Using GRC.COM's ID Serve program, I get the following response:  
   "Server: Apache/1.3.23 (Win32) PHP/4.1.3-dev"
* Using NetCraft.com's "What's that site running?" feature, I get the
following response:  
   "Apache/1.3.23 (Win32) PHP/4.1.3-dev on Windows 2000"

In a nutshell, it appears that the Apache for Windows PHP SAPI module
is listing itself as both v4.1.1 and v4.1.3-dev, but NOT v4.1.2. 
Again, minor issue.  But thought you should be aware, in case many
people start contacting you about this.

P.S.  From the Command Prompt, if I enter 'php -v' in the \PHP
directory, the CGI version accurately reports "4.1.2", so this issue
may only involve the Apache SAPI module.  I can't speak for any of the
other SAPI modules.





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

Bug #6960 Updated: Cannot find/load truetype font

[enemybuster]

 ID:   6960
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: GD related
 Operating System: Win 2000
 PHP Version:  4.0.2
 New Comment:

There it is again...

I'm using mod_php4.1.2 on SuSE Linux with freetype2 and a patched
version of gd 2.0.1b to allow gif support.

I, expieriencing the same problem. If the $font-parameter of the
ImageTTFText is a relative path, I get the error message "Could not
find/open font". It used to work fine with the old version of gd. So
this might be an gd issue...

Anyway, a work-around is quite simple: Just do a realpath($font) and it
will work (at least it does for me).

Felix


Previous Comments:


[2001-07-27 13:06:24] [EMAIL PROTECTED]

And this should be fixed (again) in CVS now.

--Jani




[2001-07-23 19:45:04] [EMAIL PROTECTED]

Bug has reappeared in 4.0.6 when i downloaded the zip version of PHP.



[2000-10-18 07:51:17] [EMAIL PROTECTED]

fixed in cvs



[2000-09-30 10:25:15] [EMAIL PROTECTED]

the file adventure.ttf is in the same dir as the script --Dan



[2000-09-30 10:23:46] [EMAIL PROTECTED]

I ran the PHP Easy installer for windows and get this error on my win2k
system.  The behavior exists on NT4 as well.  It seems to run OK on
Linux though.

PHP OUTPUT---

Warning:  Could not find/open font in
c:\inetpub\wwwroot\freeways\test\gd2.php3 on line 5

Warning:  Could not find/open font in
c:\inetpub\wwwroot\freeways\test\gd2.php3 on line 15

Warning:  Could not find/open font in
c:\inetpub\wwwroot\freeways\test\gd2.php3 on line 16
‰PNG


IHDR

ýÑÞ_  PLTE,m¯°ØõpŠ>IDATxœíÁ1
 õOm
 >
Ð
õQJýIEND®B`‚
Warning:  Unknown list entry type in request shutdown (15605704)
in c:\inetpub\wwwroot\freeways\test\gd2.php3 on line
18

MY CODE---








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

Bug #8744 Updated: call to header() causes CGI error

[sabram]

 ID:   8744
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: IIS related
 Operating System: Windows 2000
 PHP Version:  4.1.1
 New Comment:

Hi All,

I also have this problem and it is definately related to MSSQL because
I also used the same code with a MySQL database and the error doesn't
exist.

Thanks,

Steve


Previous Comments:


[2002-02-16 05:20:10] [EMAIL PROTECTED]

This problem also occurs when using apache, and a real url as opposed
to a relative url (ie, having the php.exe engine exposed in the
docroot).

I cannot determine if it's the same cause, but it's definitely the same
symptom.

if this could get fixed, it'd fix a big security hole we have now.

james.



[2002-02-16 05:15:00] [EMAIL PROTECTED]

Reopening.



[2002-02-15 18:24:04] [EMAIL PROTECTED]

I have tried 4.1.1 with win2k and the bug still exists.



[2002-02-02 06:39:14] [EMAIL PROTECTED]

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



[2002-01-12 06:55:40] [EMAIL PROTECTED]

How does this work on 4.1.1?



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/8744

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

Bug #15568 Updated: ImageTTFText doesn't work in 4.1.1

[matt]

 ID:   15568
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: GD related
 Operating System: Linux
 PHP Version:  4.1.1
 New Comment:

Tried with PHP 4.1.2 on Win2K/Apache - still doesn't work - still
getting those funny characters as the error message I noted earlier on.


Previous Comments:


[2002-02-27 12:15:45] [EMAIL PROTECTED]

Tried with PHP 4.1.2. It still doesn't work.



[2002-02-24 19:12:57] [EMAIL PROTECTED]

I have come across the same issue on Win2K running PHP4.1.1.
The code worked in 4.0.6 though.

The error message I am getting (if I comment out the ImagePNG line) is
a strange one:
Warning: ˜óO in (file) on line 6

Those funny characters (if you can see them) are what PHP outputs -
they seem to be fairly random though - sometimes I get different funny
characters.



[2002-02-21 17:25:15] [EMAIL PROTECTED]

Remove the header line and take a look at the output. You will probably
see the error now 



[2002-02-15 09:50:55] [EMAIL PROTECTED]

No errors. Just a black square.



[2002-02-15 09:37:36] [EMAIL PROTECTED]

What error message do you get when running this
code?



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/15568

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

Bug #16024: Bug in configure script: apxs call CFLAGS

[brad]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.1.2
PHP Bug Type: Compile Failure
Bug description:  Bug in configure script: apxs call CFLAGS

On line 3094 in file 'configure' the line
 $APXS -q CFLAGS >/dev/null 2>&1

should read 

 $APXS -q $CFLAGS >/dev/null 2>&1


-- 
Edit bug report at http://bugs.php.net/?id=16024&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16024&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16024&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16024&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16024&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16024&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16024&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16024&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16024&r=submittedtwice

Bug #16024 Updated: Bug in configure script: apxs call CFLAGS

[markonen]

 ID:   16024
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Linux
 PHP Version:  4.1.2
 New Comment:

No it shouldn't. CFLAGS is a parameter apxs accepts.


Previous Comments:


[2002-03-12 16:42:22] [EMAIL PROTECTED]

On line 3094 in file 'configure' the line
 $APXS -q CFLAGS >/dev/null 2>&1

should read 

 $APXS -q $CFLAGS >/dev/null 2>&1






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

Bug #16025: segmentation fault on mail() function

[matrix]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.19 / Trustix 1.5
PHP version:  4.0.6
PHP Bug Type: Mail related
Bug description:  segmentation fault on mail() function

When using the mail() function, the mail is sent out correctly but there
isn't any output of the page. There isn't even a html header sent out. The
following message is in the error logfile:

[notice] child pid 30567 exit signal Segmentation fault (11)

Problem happend on a standard installation of Trustix 1.5 (Linux 2.2.19)
with Apache/1.3.20 (Release 10320100; API Version 19990320) mailer is
Postfix.

PHP Configure:
'./configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs'
'--with-config-file-path=/etc/httpd' '--with-regex=system'
'--with-exec-dir=/usr/bin' '--enable-safe-mode' '--enable-debugger'
'--enable-magic-quotes' '--enable-track-vars' '--enable-memory-limit'
'--enable-ftp' '--disable-debug' '--disable-rpath' '--with-bz2'
'--with-gmp' '--with-zlib=/usr' '--with-imap-ssl'
'--with-imap=static,/usr' '--with-ldap=shared,/usr'
'--with-mysql=shared,/usr' '--with-pgsql=shared,/usr'
'--with-openssl=shared,/usr'
-- 
Edit bug report at http://bugs.php.net/?id=16025&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16025&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16025&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16025&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16025&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16025&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16025&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16025&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16025&r=submittedtwice

Bug #16025 Updated: segmentation fault on mail() function

[jimw]

 ID:   16025
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Mail related
 Operating System: Linux 2.2.19 / Trustix 1.5
 PHP Version:  4.0.6
 New Comment:

To properly diagnose this bug, 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".


Previous Comments:


[2002-03-12 17:11:59] [EMAIL PROTECTED]

When using the mail() function, the mail is sent out correctly but
there isn't any output of the page. There isn't even a html header sent
out. The following message is in the error logfile:

[notice] child pid 30567 exit signal Segmentation fault (11)

Problem happend on a standard installation of Trustix 1.5 (Linux
2.2.19) with Apache/1.3.20 (Release 10320100; API Version 19990320)
mailer is Postfix.

PHP Configure:
'./configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs'
'--with-config-file-path=/etc/httpd' '--with-regex=system'
'--with-exec-dir=/usr/bin' '--enable-safe-mode' '--enable-debugger'
'--enable-magic-quotes' '--enable-track-vars' '--enable-memory-limit'
'--enable-ftp' '--disable-debug' '--disable-rpath' '--with-bz2'
'--with-gmp' '--with-zlib=/usr' '--with-imap-ssl'
'--with-imap=static,/usr' '--with-ldap=shared,/usr'
'--with-mysql=shared,/usr' '--with-pgsql=shared,/usr'
'--with-openssl=shared,/usr'




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

Bug #16026: Segmentation fault in zend_alloc.c

[loverde]

From: [EMAIL PROTECTED]
Operating system: RH 7.2
PHP version:  4.1.2
PHP Bug Type: Reproducible crash
Bug description:  Segmentation fault in zend_alloc.c

I had a problem trying to migrate a SourceForge installation from PHP 4.0.6
to 4.1.2.  It appears to be related to something in the postgres
integration (opening two connections to the same database).  The
workaround was to just turn sys_db_use_replication to false (which it
probably should have been set to originally anyway..)  

But here is the script that failed (about as small as I could make it). 
Note that there were other areas of code that I had commented out that
would produce the same problem.  In particular one really strange section
where commenting out the "global" line from a function eliminated the seg
fault.  However, this is the script I narrowed down to a single CGI file.

 BEGIN SCRIPT 
#!/home/system/pkg/sourceforge.net/php/4.1.2/bin/php -q

 END SCRIPT 




PHP was built with the following options:
../configure \
--prefix=$PKG/php/4.1.2 \
--with-pgsql=$PKG/postgres/7.1.2 \
--enable-track-vars \
--enable-discard-path \
--with-config-file-path=$PKG/apache/conf \
--with-ldap=$PKG/openldap/2.0.11 \
--with-gd=$PKG/gd/1.8.4 \
--with-png-dir=$PKG/libpng/1.0.12 \
--with-jpeg-dir=$PKG/jpeg/6b \
--with-t1lib=$PKG/t1lib/1.2 \
--with-zlib=$PKG/zlib/1.1.3 \
--with-curl=$PKG/curl/7.9 \
--with-mcrypt=$PKG/libmcrypt/2.4.15 \
--enable-rule=EAPI \
--with-debug


And here is the backtrace:
#0  0x402dcdf0 in chunk_free (ar_ptr=0x40385f00, p=0x81eee18) at
malloc.c:3131
hd = 1077436944
sz = 3912
idx = 1077436216
next = 0x81efd60
nextsz = 1077436216
prevsz = 1077436944
bck = 0x40386170
fwd = 0x81efd60
islr = 0
sz = 3912
next = 0x81efd60
bck = 0x40386170
islr = 0
#1  0x402dcd59 in __libc_free (mem=0x81efd20) at malloc.c:3054
mem = (void *) 0x81efd60
ar_ptr = (arena *) 0x40385f00
p = 0x81efd18
#2  0x080f5025 in shutdown_memory_manager (silent=0, clean_cache=0)
at ../../Zend/zend_alloc.c:485
ptr = (zend_mem_header *) 0x40385f00
p = (zend_mem_header *) 0x20
t = (zend_mem_header *) 0x81efd60
fci = 11292
i = 7
j = 32
fast_cache_list_entry = (zend_fast_cache_list_entry *) 0x40386210
next_fast_cache_list_entry = (zend_fast_cache_list_entry *) 0x20
#3  0x08069ae3 in php_request_shutdown (dummy=0x0)
at
/home/system/src/sourceforge.net/sourceforge.net-binaries-needed-software
/php-4.1.2/main/main.c:742
orig_bailout = {{__jmpbuf = {1077443044, 135978484, -1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484, -1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484, -1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484, -1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484, -1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {0, 1073834432, 1073834432,
-40736468,
  571, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0,
3221220736,
0, 2, 1076368789, 0, 1073781889, 0, 1076368789, 0, 1562,
1076303630,
1077443044, 1076232668, 1075046400, 22, 1077137904, 17,
1077443044,
3221220664, 1077138054, 136241152, 0, 1074067016, 1077137986, 0,
1077443044, 3221220696, 1077443044, 4096, 136237056,
3221220696
orig_bailout_set = 0 '\000'
#4  0x08068b7f in main (argc=3, argv=0xb2ec)
at
/home/system/src/sourceforge.net/sourceforge.net-binaries-needed-software
/php-4.1.2/sapi/cgi/cgi_main.c:776
orig_bailout = {{__jmpbuf = {0, 0, 0, 0, 0, 0}, __mask_was_saved =
0,
__saved_mask = {__val = {0 
exit_status = 0
cgi = 0
c = 1077436944
i = 135978328
len = 136248672
file_handle = {type = 2 '\002', filename = 0x81eff5c "./bar.php",
  opened_path = 0x81f00ec "SYS_DB_PRIMARY", handle = {fd = 136249200,
fp = 0x81eff70}, free_filename = 0 '\000'}
retval

Bug #16021 Updated: imap_bodystruct call generates signal (via abort())

[sniper]

 ID:   16021
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux (RedHat 6.2)
 PHP Version:  4.1.2
 New Comment:

Try first using the latest c-client. 4.7c is really old
and the new ones have lot of bug fixes..



Previous Comments:


[2002-03-12 10:43:27] [EMAIL PROTECTED]

While this may have been used incorrectly causing a problem (don't
know
since I've not been able to get it to work properly),
Consider the following steps:
a) Create a message with two attachments (in this case .doc files)
b) Mail the message to an account.
c) Read the email (in this case, with Netscape) and forward the
message as an attachment to an account from where you will
access it via PHP.
d) Now try to read and process the file.
The problem comes in dealin with the multipart/mixed portion that
represents the original message that is now an attachment.
When the call imap_bodystruct($stream, $msgno, $partno) is
invoked, where $partno can actually be any value at all (tested values
from
0 to 5), each case causes the Apache process handling the request to
croak.

The configure line from phpinfo() reads
'./configure' '--with-apache=../apache_1.3.23' '--enable-debug=no'
'--prefix=/usr/local/apache' '--with-zlib'
'--with-imap=/home/thomas/imap-4.7c' '--with-mcrypt' '--with-mhash'
'--with-pgsql' '--with-gd=/home/thomas/gd1.2'

The apache error log shows a single line
[Tue Mar 12 00:09:13 2002] [notice] child pid 10813 exit signal Aborted
(6)





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

Bug #16022 Updated: php 4.1.2 windows binary zip

[sniper]

 ID:   16022
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Apache related
 Operating System: windows
 PHP Version:  4.1.2
 New Comment:

Your include path setting is wrong.
Make it 'include_path=".;c:\php4\pear"'.



Previous Comments:


[2002-03-12 13:04:17] [EMAIL PROTECTED]

The windows binary zip file apache module dll shows version 4.1.3-dev
when starting apache. Tt doesn't start at all if a php.ini is in
%SystemRoot%. If it is loaded every php file just shows an error as:
Warning: Failed opening '/path/to/foo.php' for inclusion
(include_path='c:\php4\pear') in Unknown on line 0




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

Bug #16027: decoding of GET-parameter %D0%27 fails

[schmidt]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.1.2
PHP Bug Type: *General Issues
Bug description:  decoding of GET-parameter %D0%27 fails

After decoding a GET-request containing %D0%27 an extraneous \ is inserted
between the two characters. This may easily reproduced by calling a
PHP-page containing phpinfo(), calling it with ?request=%D027 ad taking a
look at the "PHP Variables" section.

_GET["request"] Ð\' 
_SERVER["REQUEST_METHOD"] GET 
_SERVER["QUERY_STRING"] request=%D0%27 
_SERVER["REQUEST_URI"] /bla.php?request=%D0%27

For your convenience I've added some more lines from the output:

_SERVER["SERVER_SOFTWARE"] Apache/1.3.23 (Unix) mod_ssl/2.8.7
OpenSSL/0.9.6b PHP/4.1.2 

Configure Command './configure' '--with-pgsql'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-xml' '--without-mysql'
'--enable-sysvshm' '--enable-sysvsm'
'--with-config-file-path=/usr/local/apache' '--enable-track-vars'
'--enable-force-cgi-redirect' '--with-gettext'
'--enable-inline-optimization'

I've seen the bug the first time with PHP 4.0.6,then checked against PHP
4.1.2.

-- 
Edit bug report at http://bugs.php.net/?id=16027&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16027&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16027&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16027&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16027&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16027&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16027&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16027&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16027&r=submittedtwice

Bug #16027 Updated: decoding of GET-parameter %D0%27 fails

[sniper]

 ID:   16027
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  4.1.2
 New Comment:

Check your php.ini..you have 'magic_quotes_gpc=On' there. Turn it off
and you won't see the slash.
Not a bug but expected behaviour.

--Jani



Previous Comments:


[2002-03-12 18:28:08] [EMAIL PROTECTED]

After decoding a GET-request containing %D0%27 an extraneous \ is
inserted between the two characters. This may easily reproduced by
calling a PHP-page containing phpinfo(), calling it with ?request=%D027
ad taking a look at the "PHP Variables" section.

_GET["request"] Ð\' 
_SERVER["REQUEST_METHOD"] GET 
_SERVER["QUERY_STRING"] request=%D0%27 
_SERVER["REQUEST_URI"] /bla.php?request=%D0%27

For your convenience I've added some more lines from the output:

_SERVER["SERVER_SOFTWARE"] Apache/1.3.23 (Unix) mod_ssl/2.8.7
OpenSSL/0.9.6b PHP/4.1.2 

Configure Command './configure' '--with-pgsql'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-xml' '--without-mysql'
'--enable-sysvshm' '--enable-sysvsm'
'--with-config-file-path=/usr/local/apache' '--enable-track-vars'
'--enable-force-cgi-redirect' '--with-gettext'
'--enable-inline-optimization'

I've seen the bug the first time with PHP 4.0.6,then checked against
PHP 4.1.2.





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

Bug #16010 Updated: phpinfo manual page bad grammar

[alindeman]

 ID:   16010
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Documentation problem
 Operating System: n/a
 PHP Version:  4.1.2
 New Comment:

And also, to answer your question, yes this is correct place to submit
bugs for PHP and the docs.  Please 
feel free to submit any others errors you find as a bug like you did in
this case.



Previous Comments:


[2002-03-11 22:12:02] [EMAIL PROTECTED]

This bug has been fixed in CVS.





[2002-03-11 22:07:32] [EMAIL PROTECTED]

on http://www.php.net/manual/en/function.phpinfo.php, in the "phpinfo()
options" table:

Loaded modules and there respective settings.

should be:

Loaded modules and their respective settings.

(is this the right place to report this sort of error?)

S







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

Bug #16028: mysql_fetch_array() fails to index array correctly

[mjm]

From: [EMAIL PROTECTED]
Operating system: GNU/Linux 2.4 (intel)
PHP version:  4.1.2
PHP Bug Type: MySQL related
Bug description:  mysql_fetch_array() fails to index array correctly

After some frustration, I performed the following SELECT query (column
names have been changed):

$result = mysql_query("SELECT tbl1.colA, tbl2.colB, tbl2.colC FROM tbl1
LEFT JOIN tbl2 ON tbl1.colD = tbl2.colD WHERE tbl1.colE = "myvalue" ORDER
BY tbl1.colF DESC, tbl2.colC ASC, tbl2.colD ASC", $handle);

I executed the following statements:

$row = mysql_fetch_array($result);
print_r(array_keys($row));

The output looked like this:

Array ( [0] => 0 [1] => 1 [2] => colB [3] => 2 [4] => colC )

This doesn't make any sense. When you SELECT from a LEFT JOIN it would
make sense for you to be able to access the array like this (IMHO):

$row["tbl2.colB"], $row["tbl2.colC"], etc...


since two columns in the select could have the same name but different
values.
-- 
Edit bug report at http://bugs.php.net/?id=16028&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16028&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16028&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16028&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16028&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16028&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16028&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16028&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16028&r=submittedtwice

Bug #16028 Updated: mysql_fetch_array() indexing on joins

[mjm]

 ID:   16028
 Updated by:   [EMAIL PROTECTED]
-Summary:  mysql_fetch_array() fails to index array correctly
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: GNU/Linux 2.4 (intel)
 PHP Version:  4.1.2
 New Comment:

Oops, did query on bad table.


Previous Comments:


[2002-03-12 19:23:02] [EMAIL PROTECTED]

After some frustration, I performed the following SELECT query (column
names have been changed):

$result = mysql_query("SELECT tbl1.colA, tbl2.colB, tbl2.colC FROM tbl1
LEFT JOIN tbl2 ON tbl1.colD = tbl2.colD WHERE tbl1.colE = "myvalue"
ORDER BY tbl1.colF DESC, tbl2.colC ASC, tbl2.colD ASC", $handle);

I executed the following statements:

$row = mysql_fetch_array($result);
print_r(array_keys($row));

The output looked like this:

Array ( [0] => 0 [1] => 1 [2] => colB [3] => 2 [4] => colC )

This doesn't make any sense. When you SELECT from a LEFT JOIN it would
make sense for you to be able to access the array like this (IMHO):

$row["tbl2.colB"], $row["tbl2.colC"], etc...


since two columns in the select could have the same name but different
values.




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

Bug #16028 Updated: mysql_fetch_array() fails to index array correctly

[mjm]

 ID:   16028
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Closed
 Bug Type: MySQL related
 Operating System: GNU/Linux 2.4 (intel)
 PHP Version:  4.1.2
 New Comment:

Closing bug.


Previous Comments:


[2002-03-12 19:38:25] [EMAIL PROTECTED]

Oops, did query on bad table.



[2002-03-12 19:23:02] [EMAIL PROTECTED]

After some frustration, I performed the following SELECT query (column
names have been changed):

$result = mysql_query("SELECT tbl1.colA, tbl2.colB, tbl2.colC FROM tbl1
LEFT JOIN tbl2 ON tbl1.colD = tbl2.colD WHERE tbl1.colE = "myvalue"
ORDER BY tbl1.colF DESC, tbl2.colC ASC, tbl2.colD ASC", $handle);

I executed the following statements:

$row = mysql_fetch_array($result);
print_r(array_keys($row));

The output looked like this:

Array ( [0] => 0 [1] => 1 [2] => colB [3] => 2 [4] => colC )

This doesn't make any sense. When you SELECT from a LEFT JOIN it would
make sense for you to be able to access the array like this (IMHO):

$row["tbl2.colB"], $row["tbl2.colC"], etc...


since two columns in the select could have the same name but different
values.




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

Bug #16029: Feature Request on mysql_fetch_array()

[mjm]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4 (intel)
PHP version:  4.1.2
PHP Bug Type: MySQL related
Bug description:  Feature Request on mysql_fetch_array()

When you SELECT two columns from different tables with the same column name
in a JOIN, you cannot use column names is associative array keys. It would
be really nice when you did something like this:
---
$result = mysql_query("SELECT tbl1.colA, tbl2.colA FROM tbl1 LEFT JOIN
tbl2 ON tbl1.colB = tbl2.colB");
$row = mysql_fetch_array($result);
---
if you could then do something like this:
---
$mydata1 = $row["tbl1.colA"];
$mydata1 = $row["tbl2.colA"];
---
With the current behavior, you may only access the second array element
with its numerical index.


-- 
Edit bug report at http://bugs.php.net/?id=16029&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16029&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16029&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16029&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16029&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16029&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16029&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16029&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16029&r=submittedtwice

Bug #16026 Updated: Segmentation fault in zend_alloc.c

[yohgaki]

 ID:   16026
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: RH 7.2
 PHP Version:  4.1.2
 New Comment:

Your script is not complete.  db_query() is not defined. (and missing
";")
Please submit short and complete script. Thank you.


Previous Comments:


[2002-03-12 18:05:15] [EMAIL PROTECTED]

I had a problem trying to migrate a SourceForge installation from PHP
4.0.6 to 4.1.2.  It appears to be related to something in the postgres
integration (opening two connections to the same database).  The
workaround was to just turn sys_db_use_replication to false (which it
probably should have been set to originally anyway..)  

But here is the script that failed (about as small as I could make it).
 Note that there were other areas of code that I had commented out that
would produce the same problem.  In particular one really strange
section where commenting out the "global" line from a function
eliminated the seg fault.  However, this is the script I narrowed down
to a single CGI file.

 BEGIN SCRIPT 
#!/home/system/pkg/sourceforge.net/php/4.1.2/bin/php -q

 END SCRIPT 




PHP was built with the following options:
../configure \
--prefix=$PKG/php/4.1.2 \
--with-pgsql=$PKG/postgres/7.1.2 \
--enable-track-vars \
--enable-discard-path \
--with-config-file-path=$PKG/apache/conf \
--with-ldap=$PKG/openldap/2.0.11 \
--with-gd=$PKG/gd/1.8.4 \
--with-png-dir=$PKG/libpng/1.0.12 \
--with-jpeg-dir=$PKG/jpeg/6b \
--with-t1lib=$PKG/t1lib/1.2 \
--with-zlib=$PKG/zlib/1.1.3 \
--with-curl=$PKG/curl/7.9 \
--with-mcrypt=$PKG/libmcrypt/2.4.15 \
--enable-rule=EAPI \
--with-debug


And here is the backtrace:
#0  0x402dcdf0 in chunk_free (ar_ptr=0x40385f00, p=0x81eee18) at
malloc.c:3131
hd = 1077436944
sz = 3912
idx = 1077436216
next = 0x81efd60
nextsz = 1077436216
prevsz = 1077436944
bck = 0x40386170
fwd = 0x81efd60
islr = 0
sz = 3912
next = 0x81efd60
bck = 0x40386170
islr = 0
#1  0x402dcd59 in __libc_free (mem=0x81efd20) at malloc.c:3054
mem = (void *) 0x81efd60
ar_ptr = (arena *) 0x40385f00
p = 0x81efd18
#2  0x080f5025 in shutdown_memory_manager (silent=0, clean_cache=0)
at ../../Zend/zend_alloc.c:485
ptr = (zend_mem_header *) 0x40385f00
p = (zend_mem_header *) 0x20
t = (zend_mem_header *) 0x81efd60
fci = 11292
i = 7
j = 32
fast_cache_list_entry = (zend_fast_cache_list_entry *)
0x40386210
next_fast_cache_list_entry = (zend_fast_cache_list_entry *)
0x20
#3  0x08069ae3 in php_request_shutdown (dummy=0x0)
at
/home/system/src/sourceforge.net/sourceforge.net-binaries-needed-software
/php-4.1.2/main/main.c:742
orig_bailout = {{__jmpbuf = {1077443044, 135978484,
-1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484,
-1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484,
-1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484,
-1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484,
-1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {0, 1073834432, 1073834432,
-40736468,
  571, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0,
3221220736,
0, 2, 1076368789, 0, 1073781889, 0, 1076368789, 0, 1562,
1076303630,
1077443044, 1076232668, 1075046400, 22, 1077137904, 17,
1077443044,
3221220664, 1077138054, 136241152, 0, 1074067016, 1077137986,
0,
1077443044, 3221220696, 1077443044, 4096, 136237056,
3221220696
orig_bailout_set = 0 '\000'
#4  0x08068b7f in main (argc=3, argv=0xb2ec)
at
/home/system/src/sourceforge.net/sourceforge.net-binaries-needed-software
/php-4.1.2/sapi/cgi/cgi_main.c:776
orig_bailout = {{__jmpbuf = {0, 0, 0, 0, 0, 0},
__mask_was_saved = 0,
__saved_mask

Bug #13913 Updated: Empty strings on "nlist" and "rawlist"

[ryan]

 ID:   13913
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: FTP related
 Operating System: Windows XP final
 PHP Version:  4.0.6
 New Comment:

I'm seeing this exact same bug using PHP 4.1.1 on Windows 2000 Advanced
Server with IIS 5.0. This is a major showstopper for me -- I *really*
need FTP functionality, and now I'm screwed.


Previous Comments:


[2002-03-01 03:58:26] [EMAIL PROTECTED]

I have been trying the same with Windows 2000 Server IIS 5.0 and the
result is the same, an empty array, i can not make a for(){} or
foreach(){} or something similar because the matrix is always empty,
the passive mode doesn´t change anything.

All ftp functions works correctly except ftp_nlist() and ftp_rawlist()
why?

I hope something can help me please.Thx.



[2001-11-08 15:17:29] [EMAIL PROTECTED]

Update:

I just validated my FTP's logs and found out that:
- The user logs in correctly
- The passive request arrived and was set correctly
- There was no list command anywhere to be found

It's just not arriving.. (?)



[2001-11-08 02:13:45] [EMAIL PROTECTED]

After adding the following code after the connection and before the
listings, 

// Initiate passive mode
if (ftp_pasv($conn_id, true))
{ echo "Initiated passive mode"; }
else { echo "Could not initiated passive mode"; }

The result stays the exact same..

What i forgot to mention: i can switch directorys etc. so
the connection seems to work, but the "LIST" command never reaches the
ftp server (checked).



[2001-11-07 17:04:08] [EMAIL PROTECTED]

You're probably trying to get a listing in active mode, and being
rejected.  Set the connection to passive mode with ftp_pasv() before
you try to get the listing.



[2001-11-02 17:55:32] [EMAIL PROTECTED]

Thank you for hearing me :)

The problem is that whatever i try there is no data in any nlist or
rawlist command i issue on my ftp server.

I started out with IIS 5.1 (standard winXP) and ended with bulletproof
FTP 1.25, both not giving any listings..

Some sample code:

--

$dir=ftp_pwd($conn_id); 

$rawlist = ftp_rawlist($conn_id,$dir);
$nlist = ftp_nlist($conn_id,$dir);
 
if ($rawlist) { echo "Spawned value for nlist was ".$nlist; }
else { echo "empty as usual.."; }
if ($rawlist) { echo "Spawned value for rawlist was ".$rawlist; }
else { echo "empty as usual.."; }

echo "";

print_r($rawlist);
print_r($nlist);

--

where there:
- was a connection in the 1st place ($conn_id)
- i encountered not a single error message
- i used the "if .. else" to prove my wrong
- i received no data in my string

I have seen various bug reports resembling what i've expierenced but
none of them got answered because they all stopped giving information
which ended in: "can't reproduce the error."

I hope you (the brave volunteer) could help me.. :)

Thanxx





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

Bug #16029 Updated: Feature Request on mysql_fetch_array()

[torben]

 ID:   16029
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: MySQL related
 Operating System: Linux 2.4 (intel)
 PHP Version:  4.1.2
 New Comment:

The data is returned from the server like that. What you can
do is:

'select tbl1.colA as tbl1_colA, tbl2.colA as tbl2_colA. . .'


Torben



Previous Comments:


[2002-03-12 19:55:38] [EMAIL PROTECTED]

When you SELECT two columns from different tables with the same column
name in a JOIN, you cannot use column names is associative array keys.
It would be really nice when you did something like this:
---
$result = mysql_query("SELECT tbl1.colA, tbl2.colA FROM tbl1 LEFT JOIN
tbl2 ON tbl1.colB = tbl2.colB");
$row = mysql_fetch_array($result);
---
if you could then do something like this:
---
$mydata1 = $row["tbl1.colA"];
$mydata1 = $row["tbl2.colA"];
---
With the current behavior, you may only access the second array element
with its numerical index.






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

Bug #16030: Cannot load php_ldap.php extension

[jpmejia]

From: [EMAIL PROTECTED]
Operating system: Windows NT SP 6
PHP version:  4.1.2
PHP Bug Type: Dynamic loading
Bug description:  Cannot load php_ldap.php extension


  The other extensions I use (db, dba, dbase, gd)works properly, but when
I try to put the ldap extension PHP always say: Unable to load dynamic
library 'D:\PHP\php_ldap.php' - The specified procedure could not be
found.

I copied the libsasl.dll to %winnt%\system32 directory but it didn't work.
-- 
Edit bug report at http://bugs.php.net/?id=16030&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16030&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16030&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16030&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16030&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16030&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16030&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16030&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16030&r=submittedtwice

Bug #16030 Updated: Cannot load php_ldap.php extension

[jpmejia]

 ID:   16030
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Dynamic loading
 Operating System: Windows NT SP 6
-PHP Version:  4.1.2
+PHP Version:  4.1.1
 New Comment:

I copied the libsasl.dll to %windir%\system32 directory but it didn't
work.


Previous Comments:


[2002-03-12 20:31:43] [EMAIL PROTECTED]


  The other extensions I use (db, dba, dbase, gd)works properly, but
when I try to put the ldap extension PHP always say: Unable to load
dynamic library 'D:\PHP\php_ldap.php' - The specified procedure could
not be found.

I copied the libsasl.dll to %winnt%\system32 directory but it didn't
work.




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

Bug #14525 Updated: Access Violation at 0528B2F6 using php4isapi.dll on Deerfield WebSite 3.1.11

[mfichtner]

 ID:   14525
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: IIS related
 Operating System: Windows NT 4.0 SP6a
-PHP Version:  4.1.1
+PHP Version:  4.1.0
 New Comment:

It looks like this has been solved in PHP 4.1.2. I do no longer see any
problems under WebSite 3.1.11.


Previous Comments:


[2002-02-02 06:42:47] [EMAIL PROTECTED]

Reopening.



[2002-01-10 08:12:44] [EMAIL PROTECTED]

I am the developer of WebSite. I am available to assist in any way I
can, however my time does not permit my participation on the PHP
development team.

This problem is likely a mis-use of ISAPI that is harmless on IIS but
not on WebSite. One common mistake is to pass junk for the connection
handle hConn in the ECB in calls to ServerSupportFunction(). This
absolutely must be the correct hConn as given by the server when
calling the ISAPI extension. It is actually the transaction context
used throughout WebSite.

I'll be happy to furnish a free copy of WebSite 3.1 to the PHP/ISAPI
developers.



[2002-01-09 21:50:11] [EMAIL PROTECTED]

> Do you use session with files handler?

Nope, this happens whenever a PHP document is accessed -- regardless of
its content. Even a document that only contains  will cause this crash.



[2002-01-09 21:25:50] [EMAIL PROTECTED]

Do you use session with files handler?
Then make sure you use *correct* session.save_path.

Is this the case?



[2002-01-09 21:18:41] [EMAIL PROTECTED]

Same problem with 4.1.1



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/14525

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

Bug #15907 Updated: php 4.1.x error message on trying to load 4.0.x dyn. model broken

[tporter]

 ID:   15907
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Dynamic loading
 Operating System: *
 PHP Version:  4.1.0 and above
 Assigned To:  hholzgra
 New Comment:

I'm getting the exact same thing with PHP 4.1.2 and RedHat Linux 7.2. 
This is very easily seen by executing the php shell binary
(/usr/bin/php) and will also show up in Apaches error log when the
server starts up.  I write cron jobs in php all the time... my mail box
keeps filling up! =(

Also of note... I got a lot of complaints about duplicated imap & mysql
functions until I ran configure --without-mysql and --without-imap (not
good, i need imap support)

here's a sample of those:
PHP Warning:  Function registration failed - duplicate name -
mysql_connect in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
mysql_pconnect in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
mysql_close in Unknown on line 0


PHP Warning:  Function registration failed - duplicate name - imap_open
in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
imap_popen in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
imap_reopen in Unknown on line 0


Previous Comments:


[2002-03-06 12:55:10] [EMAIL PROTECTED]

i get:

PHP Warning: 
U\x89\xe51\xc0\xeb^A\x90\xc9\xc3\x89\xf6U\x89\xe5\x83\xec^TS\xe8:
Unable to initialize module
Module compiled with debug=220, thread-safety=170 module API=677665696
PHP compiled with debug=0, thread-safety=0 module API=20010901
These options need to match 


instead of

PHP Warning:  sixcode :
Unable to initialize module
Module compiled with debug=0, thread-safety=0 module API=20001222
PHP compiled with debug=0, thread-safety=0 module API=20010901
These options need to match 

due to the new fields inserted into structure zend_module_entry

dl.c should be clever enought to look for the previous 
positions of the data fields when encountering malformed
values like "debug=220" or "API=677665696"




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

Bug #16026 Updated: Segmentation fault in zend_alloc.c

[jimw]

 ID:   16026
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: RH 7.2
 PHP Version:  4.1.2
 New Comment:

the script is complete. the db_query() is just from a comment line that
wrapped.


Previous Comments:


[2002-03-12 20:01:41] [EMAIL PROTECTED]

Your script is not complete.  db_query() is not defined. (and missing
";")
Please submit short and complete script. Thank you.



[2002-03-12 18:05:15] [EMAIL PROTECTED]

I had a problem trying to migrate a SourceForge installation from PHP
4.0.6 to 4.1.2.  It appears to be related to something in the postgres
integration (opening two connections to the same database).  The
workaround was to just turn sys_db_use_replication to false (which it
probably should have been set to originally anyway..)  

But here is the script that failed (about as small as I could make it).
 Note that there were other areas of code that I had commented out that
would produce the same problem.  In particular one really strange
section where commenting out the "global" line from a function
eliminated the seg fault.  However, this is the script I narrowed down
to a single CGI file.

 BEGIN SCRIPT 
#!/home/system/pkg/sourceforge.net/php/4.1.2/bin/php -q

 END SCRIPT 




PHP was built with the following options:
../configure \
--prefix=$PKG/php/4.1.2 \
--with-pgsql=$PKG/postgres/7.1.2 \
--enable-track-vars \
--enable-discard-path \
--with-config-file-path=$PKG/apache/conf \
--with-ldap=$PKG/openldap/2.0.11 \
--with-gd=$PKG/gd/1.8.4 \
--with-png-dir=$PKG/libpng/1.0.12 \
--with-jpeg-dir=$PKG/jpeg/6b \
--with-t1lib=$PKG/t1lib/1.2 \
--with-zlib=$PKG/zlib/1.1.3 \
--with-curl=$PKG/curl/7.9 \
--with-mcrypt=$PKG/libmcrypt/2.4.15 \
--enable-rule=EAPI \
--with-debug


And here is the backtrace:
#0  0x402dcdf0 in chunk_free (ar_ptr=0x40385f00, p=0x81eee18) at
malloc.c:3131
hd = 1077436944
sz = 3912
idx = 1077436216
next = 0x81efd60
nextsz = 1077436216
prevsz = 1077436944
bck = 0x40386170
fwd = 0x81efd60
islr = 0
sz = 3912
next = 0x81efd60
bck = 0x40386170
islr = 0
#1  0x402dcd59 in __libc_free (mem=0x81efd20) at malloc.c:3054
mem = (void *) 0x81efd60
ar_ptr = (arena *) 0x40385f00
p = 0x81efd18
#2  0x080f5025 in shutdown_memory_manager (silent=0, clean_cache=0)
at ../../Zend/zend_alloc.c:485
ptr = (zend_mem_header *) 0x40385f00
p = (zend_mem_header *) 0x20
t = (zend_mem_header *) 0x81efd60
fci = 11292
i = 7
j = 32
fast_cache_list_entry = (zend_fast_cache_list_entry *)
0x40386210
next_fast_cache_list_entry = (zend_fast_cache_list_entry *)
0x20
#3  0x08069ae3 in php_request_shutdown (dummy=0x0)
at
/home/system/src/sourceforge.net/sourceforge.net-binaries-needed-software
/php-4.1.2/main/main.c:742
orig_bailout = {{__jmpbuf = {1077443044, 135978484,
-1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484,
-1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484,
-1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484,
-1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {1077443044, 135978484,
-1073745380,
  -1073745288, -1073745632, 134644858}, __mask_was_saved = 0,
__saved_mask = {__val = {0 
orig_bailout_set = 1 '\001'
orig_bailout = {{__jmpbuf = {0, 1073834432, 1073834432,
-40736468,
  571, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0,
3221220736,
0, 2, 1076368789, 0, 1073781889, 0, 1076368789, 0, 1562,
1076303630,
1077443044, 1076232668, 1075046400, 22, 1077137904, 17,
1077443044,
3221220664, 1077138054, 136241152, 0, 1074067016, 1077137986,
0,
1077443044, 3221220696, 1077443044, 4096, 136237056,
3221220696
orig_bailout_set = 0 '\000'
#4  0x08068b7f in main (argc=3, argv=0xb2ec)
at
/home/sys

Bug #15983 Updated: session variables lost between pages

[php]

 ID:   15983
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: Debian/Linux mips platform
 PHP Version:  4.1.2
 New Comment:

I've had the same issue (see bug 15822, which was marked as a
duplicate, though nobody saw fit to tell me what it was a duplicate
of).

Anyone have a work-around?


Previous Comments:


[2002-03-10 09:14:31] [EMAIL PROTECTED]

The session variables are lost between pages.

For example:
session1.php:


session2.php:


The output on page two is the empty string.

A look at the sess_* in /tmp show that it contain the variable and the
value after a request on session1.php.

After a request on session2.php the file is empty.

This error shows up in php 4.1.1 and 4.1.2.

In version 4.0.6 everything works as it is suppose to.

uname --all:
Linux indy01 2.4.16 #1 Sun Dec 16 16:38:44 CET 2001 mips unknown

gcc --version:
2.95.4




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

Bug #15976 Updated: socket_get_status(...) returns nothing

[sean]

 ID:   15976
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Sockets related
 Operating System: Win32 (2000) AND Linux2.2
 PHP Version:  4.1.2
 New Comment:

It's a non-blocking socket, if that helps

S


Previous Comments:


[2002-03-09 17:34:26] [EMAIL PROTECTED]

Also note: This is a listening socket (host / server / whatever) -- ie,
not created with fsockopen; created with socket_create, socket_bind,
socket_listen, socket_accept. There's a note in the manual about this
not working properly, but I didn't see it in the bug DB.



[2002-03-09 17:31:39] [EMAIL PROTECTED]

socket_get_status is supposed to return an associative array, it
_always_ returns null for me. No array, no object, no string
print_r(socket_get_status($verifiedSocketResource)) prints nothing.

I've tried this on two separate 4.1.x installs. The php4win version
(4.1.1) and the Debian Unstable version (4.1.2 -- CGI).





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

Bug #16031: installation

[dnntt]

From: [EMAIL PROTECTED]
Operating system: window XP
PHP version:  4.1.2
PHP Bug Type: PHP options/info functions
Bug description:  installation

In the installation guide, there's part says that copy all .dll files to
c:\winnt\system32 for Windows NT/2000/XP
, but c:\winnt\system32 directory is not existed in windowXP.  The same
problem for the .ini file, there is no c:\winnt40 exist.   Please let me
know where should I copy these files to.
Thanks
mt
-- 
Edit bug report at http://bugs.php.net/?id=16031&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16031&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16031&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16031&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16031&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16031&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16031&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16031&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16031&r=submittedtwice

Bug #15976 Updated: socket_get_status(...) returns nothing

[sean]

 ID:   15976
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Sockets related
 Operating System: Win32 (2000) AND Linux2.2
 PHP Version:  4.1.2
 New Comment:

Alright. So, here's what I've dug up so far:

file: [php]/ext/standard/file.c
line: 968
code: zend_fetch_resource(socket_arg TSRMLS_CC,-1,"Socket
-Handle",NULL,1,php_file_le_socket());

This always line returns false for a valid socket resource (I verified
the resource using `is_resource($sock)` and `get_resource_type($sock)`
for both my listen socket and my message socket.
get_resource_type($sock) returns "Socket".

So, when the next line (969), "ZEND_VERIFY_RESOURCE(what);" is called,
it determines that 'what' is false and calls RETURN_NULL;

I tried screwing with the args in zend_fetch_resource(...), but I don't
know the API well enough (and my C/C++ is more than rusty).

I hope someone takes a look at this soon, I currently have no way of
knowing the status of my sockets (I need to know when a client
disconnects -> eof )

S


Previous Comments:


[2002-03-12 21:00:39] [EMAIL PROTECTED]

It's a non-blocking socket, if that helps

S



[2002-03-09 17:34:26] [EMAIL PROTECTED]

Also note: This is a listening socket (host / server / whatever) -- ie,
not created with fsockopen; created with socket_create, socket_bind,
socket_listen, socket_accept. There's a note in the manual about this
not working properly, but I didn't see it in the bug DB.



[2002-03-09 17:31:39] [EMAIL PROTECTED]

socket_get_status is supposed to return an associative array, it
_always_ returns null for me. No array, no object, no string
print_r(socket_get_status($verifiedSocketResource)) prints nothing.

I've tried this on two separate 4.1.x installs. The php4win version
(4.1.1) and the Debian Unstable version (4.1.2 -- CGI).





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

Bug #15976 Updated: socket_get_status(...) returns nothing

[sean]

 ID:   15976
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Sockets related
 Operating System: Win32 (2000) AND Linux2.2
 PHP Version:  4.1.2
 New Comment:

Oops. Regarding my previous comment:

line 968 reads "what = zend_fetch_resource(socket TSRMLS_CC, -1,
"File-Handle", &type, 1, le_socket);" in CVS, not what I posted
above...

S


Previous Comments:


[2002-03-12 21:44:49] [EMAIL PROTECTED]

Alright. So, here's what I've dug up so far:

file: [php]/ext/standard/file.c
line: 968
code: zend_fetch_resource(socket_arg TSRMLS_CC,-1,"Socket
-Handle",NULL,1,php_file_le_socket());

This always line returns false for a valid socket resource (I verified
the resource using `is_resource($sock)` and `get_resource_type($sock)`
for both my listen socket and my message socket.
get_resource_type($sock) returns "Socket".

So, when the next line (969), "ZEND_VERIFY_RESOURCE(what);" is called,
it determines that 'what' is false and calls RETURN_NULL;

I tried screwing with the args in zend_fetch_resource(...), but I don't
know the API well enough (and my C/C++ is more than rusty).

I hope someone takes a look at this soon, I currently have no way of
knowing the status of my sockets (I need to know when a client
disconnects -> eof )

S



[2002-03-12 21:00:39] [EMAIL PROTECTED]

It's a non-blocking socket, if that helps

S



[2002-03-09 17:34:26] [EMAIL PROTECTED]

Also note: This is a listening socket (host / server / whatever) -- ie,
not created with fsockopen; created with socket_create, socket_bind,
socket_listen, socket_accept. There's a note in the manual about this
not working properly, but I didn't see it in the bug DB.



[2002-03-09 17:31:39] [EMAIL PROTECTED]

socket_get_status is supposed to return an associative array, it
_always_ returns null for me. No array, no object, no string
print_r(socket_get_status($verifiedSocketResource)) prints nothing.

I've tried this on two separate 4.1.x installs. The php4win version
(4.1.1) and the Debian Unstable version (4.1.2 -- CGI).





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

Bug #15595 Updated: imap routines hang when "To" header is too large

[charlesb]

 ID:   15595
 Updated by:   [EMAIL PROTECTED]
-Summary:  imap routines hang when "To" header is too large
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: IMAP related
 Operating System: Solaris-i86
 PHP Version:  4.1.1
 New Comment:

I built php again with imap-2001a's c-client, and the problem still
occurred.

Other suggestions for things I could try?  Thanks, Charles


Previous Comments:


[2002-03-11 21:30:57] [EMAIL PROTECTED]

Try the latest _c-client_ library, not PHP.

As this is most likely not bug in PHP but in the 
c-client library itself.

--Jani




[2002-03-11 20:52:16] [EMAIL PROTECTED]

We upgraded last week to 4.1.2, the problem still occurs.



[2002-03-11 09:37:31] [EMAIL PROTECTED]

First of all you should try with the latest c-client.

--Jani




[2002-03-11 04:47:56] [EMAIL PROTECTED]

Is there anything I can do to help this along?  We've been bitten twice
by this in the last few days.



[2002-02-18 18:09:33] [EMAIL PROTECTED]

An exact script is difficult. (I've spent a day or two trying to pin it
down to a simple routine, not with any great success).

However, it looks like

$h = @imap_header($imp->stream, imap_msgno($imp->stream, $msgnum));

is hanging with a message that has to header of about 4K (again, this
probably violates rfc822, but it shouldn't hang like it does).

$imp->stream is constructed like this (as you'd expect):

$connstr = '{' . $this->server . ':' . $this->port . '}' .
$this->mailbox;
$this->stream = @imap_open($connstr, $this->user, $this->pass);


Thanks.



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/15595

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

Bug #15058 Updated: crash on complex page

[php-bugs]

 ID:   15058
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: Mac OS X 10.1.2 (Build 5P48)
 PHP Version:  4.1.1
 New Comment:

No feedback was provided for this bug for over a month, 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".


Previous Comments:


[2002-01-20 18:15:32] [EMAIL PROTECTED]

i have now rebuilt php with --enable-debug, and i managed 
to get a backtrace. hth...

the configure line is now:

'./configure' '--with-apxs' '--enable-debug'

and the crashlog:

**

Date/Time:  2002-01-21 00:01:44 +0100
OS Version: 10.1.2 (Build 5P48)
Host:   localhost

Command:httpd
PID:1184

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_INVALID_ADDRESS (0x0001) at 0xbff7f910

Thread 0 Crashed:
 #0   0x005247f0 in php_error_cb
 #1   0x004ed84c in zend_error
 #2   0x00508e10 in zend_fetch_dimension_address_inner
 #3   0x004fedcc in zend_fetch_dimension_address
 #4   0x005015e0 in execute
 #5   0x005036c4 in execute
 #6   0x005036c4 in execute
 #7   0x005036c4 in execute
 #8   0x005036c4 in execute
 #9   0x005036c4 in execute
 #10  0x005036c4 in execute
 #11  0x00505c40 in execute
 #12  0x00505c40 in execute
 #13  0x004eddcc in zend_execute_scripts
 #14  0x00526954 in php_execute_script
 #15  0x005232bc in apache_php_module_main
 #16  0x00521d44 in send_php
 #17  0xc5ac in ap_invoke_handler
 #18  0x00016530 in process_request_internal
 #19  0x00016874 in ap_internal_redirect
 #20  0x00136674 in handler_redirect
 #21  0xc5ac in ap_invoke_handler
 #22  0x00016530 in process_request_internal
 #23  0x00016874 in ap_internal_redirect
 #24  0x00136674 in handler_redirect
 #25  0xc5ac in ap_invoke_handler
 #26  0x00016530 in process_request_internal
 #27  0x000165ac in ap_process_request
 #28  0x5d5c in child_main
 #29  0x5f18 in make_child
 #30  0x6084 in startup_children
 #31  0x66a8 in standalone_main
 #32  0x6f64 in main
 #33  0x1e18 in _start
 #34  0x1c48 in start

PPC Thread State:
  srr0: 0x005247f0 srr1: 0x0200f030vrsave: 
0x
   xer: 0x2020   lr: 0x004ed84c  ctr: 0x005247dc   mq: 
0x
r0: 0x24224245   r1: 0xbff80180   r2: 0x00a4c098   r3: 
0x0008
r4: 0x001a4888   r5: 0x009a   r6: 0x005cd76c   r7: 
0xbff80250
r8: 0x009833d8   r9: 0x006105f4  r10: 0x0020ec53  r11: 
0x0020ec53
   r12: 0x005247dc  r13: 0x  r14: 0x  r15: 
0x
   r16: 0x  r17: 0x  r18: 0x  r19: 
0x005cd76c
   r20: 0xbff80250  r21: 0x009a  r22: 0x001a4888  r23: 
0x0003
   r24: 0x0008  r25: 0x  r26: 0x  r27: 
0x0098b2c8
   r28: 0xbff80368  r29: 0x00265b4c  r30: 0xbff80230  r31: 
0x004ed6c4

**

and finally the backtrace:

Program received signal EXC_BAD_ACCESS, Could not access 
memory.
0x005247f0 in php_error_cb (type=10007528, error_filename=
0x3 , error_lineno=1722824, 
format=0x5cd76c "Undefined index:  %s", args=0xbff80210 "") 
at main.c:360
360 main.c: No such file or directory.
in main.c
(gdb) bt
#0  0x005247f0 in php_error_cb (type=10007528, 
error_filename=0x3 , 
error_lineno=1722824, format=0x5cd76c "Undefined index:  
%s", args=0xbff80210 "") at main.c:360
#1  0x00508e10 in zend_fetch_dimension_address_inner (ht=
0x98b3e8, op2=0x265b4c, Ts=0xbff80328, type=0) at ./
zend_execute.c:615
#2  0x004fedcc in zend_fetch_dimension_address (result=
0x265b24, op1=0x265b38, op2=0x265b4c, Ts=0xbff80328, type=
0) at ./zend_execute.c:762
#3  0x005015e0 in execute (op_array=warning: 
ppc_frame_chain_valid: stack frame from 0xbff802f0 to 
0xbff944e0 larger than 65536 bytes; assuming invalid
0x2316c0) at ./zend_execute.c:1262
warning: ppc_frame_chain_valid: stack frame from 0xbff802f0 
to 0xbff944e0 larger than 65536 bytes; assuming invalid
(gdb)



[2002-01-16 01:29:35] [EMAIL PROTECTED]

Hello,

I'm afraid that there can be little done about it, to me it seems a
stack overflow. I guess that it is not possible to dump these files
somewhere to download, so that we can try ourselves.

Note to Yasuo: He didn't compile it himself.

Derick



[2002-01-15 19:42:51] [EMAIL PROTECTED]

Your PHP is not built with --enable-debug option. Could you send
backtrace again?



[2002-01-15 17:11:45] [EMAIL PROTECTED]

when rendering a rather complex page php causes apache to 
crash. th

Bug #16032: program spawned by backticks or shell_exec does not die when user cancels page

[reed]

From: [EMAIL PROTECTED]
Operating system: Debian GNU/Linux (kernel 2.2.16)
PHP version:  4.1.2
PHP Bug Type: Program Execution
Bug description:  program spawned by backticks or shell_exec does not die when user 
cancels page

A process spawned by backticks (backquotes) or with shell_exec() hang
around indefinitely if I cancel the page while it's running. The program
I'm running is a Perl script...
$list = `mp-list 2>&1`;
$list2 = shell_exec("mp-list 2>&1");
$status = shell_exec("mp-add $file 2>&1");
(it's taking too long because of a bug in our networking code -- maybe
this is why its not dying?)

When I do a ps ax (several minutes later) I get a whole bunch of stuff
like:

27030 ?S  0:00 /usr/sbin/apache
27031 ?S  0:00 sh -c mp-list 2>&1
27032 ?R  0:23 /usr/bin/perl /usr/local/bin/mp-list

Happens when I 'cancel' in MS IE 5 and in OmniWeb (Macintosh browsers).

thanks


reed
-- 
Edit bug report at http://bugs.php.net/?id=16032&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16032&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16032&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16032&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16032&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16032&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16032&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16032&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16032&r=submittedtwice

Bug #15830 Updated: configure recognize lib mcrypt 2.4 as 2.2

[joshl-php]

 ID:   15830
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: mcrypt related
 Operating System: RedHat Linux  7.2
 PHP Version:  4.1.2
 New Comment:

PHP 4.1.2 compiles fine, but when I run a test script using libmcrypt
it returns: "libmcrypt is 2.2.x" when I am really using libmcrypt
2.4.22.  Could this be the same problem?


Previous Comments:


[2002-03-02 10:36:53] [EMAIL PROTECTED]

That is really weird, because mcrypt didn't change one single bit. Can
you send me your configure.log (or config.log) (privately please)?

Derick



[2002-03-02 10:34:56] [EMAIL PROTECTED]

configure in php 4.1.2 will recognize libmcrypt 2.4.x (tested with
libmcrypt 2.4.15/16 and 22) as libmcrypt 2.2.x.
This will cause compile to fail due to some missing #define
php 4.1.1 perfectly works instead (tested with the same libmcrypt
versions).





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

Bug #15907 Updated: php 4.1.x error message on trying to load 4.0.x dyn. model broken

[derick]

 ID:   15907
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Dynamic loading
 Operating System: *
 PHP Version:  4.1.0 and above
-Assigned To:  hholzgra
+Assigned To:  derick


Previous Comments:


[2002-03-12 20:39:55] [EMAIL PROTECTED]

I'm getting the exact same thing with PHP 4.1.2 and RedHat Linux 7.2. 
This is very easily seen by executing the php shell binary
(/usr/bin/php) and will also show up in Apaches error log when the
server starts up.  I write cron jobs in php all the time... my mail box
keeps filling up! =(

Also of note... I got a lot of complaints about duplicated imap & mysql
functions until I ran configure --without-mysql and --without-imap (not
good, i need imap support)

here's a sample of those:
PHP Warning:  Function registration failed - duplicate name -
mysql_connect in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
mysql_pconnect in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
mysql_close in Unknown on line 0


PHP Warning:  Function registration failed - duplicate name - imap_open
in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
imap_popen in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
imap_reopen in Unknown on line 0



[2002-03-06 12:55:10] [EMAIL PROTECTED]

i get:

PHP Warning: 
U\x89\xe51\xc0\xeb^A\x90\xc9\xc3\x89\xf6U\x89\xe5\x83\xec^TS\xe8:
Unable to initialize module
Module compiled with debug=220, thread-safety=170 module API=677665696
PHP compiled with debug=0, thread-safety=0 module API=20010901
These options need to match 


instead of

PHP Warning:  sixcode :
Unable to initialize module
Module compiled with debug=0, thread-safety=0 module API=20001222
PHP compiled with debug=0, thread-safety=0 module API=20010901
These options need to match 

due to the new fields inserted into structure zend_module_entry

dl.c should be clever enought to look for the previous 
positions of the data fields when encountering malformed
values like "debug=220" or "API=677665696"




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

Bug #15907 Updated: php 4.1.x error message on trying to load 4.0.x dyn. model broken

[derick]

 ID:   15907
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Dynamic loading
 Operating System: *
 PHP Version:  4.1.0 and above
 Assigned To:  derick


Previous Comments:


[2002-03-12 20:39:55] [EMAIL PROTECTED]

I'm getting the exact same thing with PHP 4.1.2 and RedHat Linux 7.2. 
This is very easily seen by executing the php shell binary
(/usr/bin/php) and will also show up in Apaches error log when the
server starts up.  I write cron jobs in php all the time... my mail box
keeps filling up! =(

Also of note... I got a lot of complaints about duplicated imap & mysql
functions until I ran configure --without-mysql and --without-imap (not
good, i need imap support)

here's a sample of those:
PHP Warning:  Function registration failed - duplicate name -
mysql_connect in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
mysql_pconnect in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
mysql_close in Unknown on line 0


PHP Warning:  Function registration failed - duplicate name - imap_open
in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
imap_popen in Unknown on line 0
PHP Warning:  Function registration failed - duplicate name -
imap_reopen in Unknown on line 0



[2002-03-06 12:55:10] [EMAIL PROTECTED]

i get:

PHP Warning: 
U\x89\xe51\xc0\xeb^A\x90\xc9\xc3\x89\xf6U\x89\xe5\x83\xec^TS\xe8:
Unable to initialize module
Module compiled with debug=220, thread-safety=170 module API=677665696
PHP compiled with debug=0, thread-safety=0 module API=20010901
These options need to match 


instead of

PHP Warning:  sixcode :
Unable to initialize module
Module compiled with debug=0, thread-safety=0 module API=20001222
PHP compiled with debug=0, thread-safety=0 module API=20010901
These options need to match 

due to the new fields inserted into structure zend_module_entry

dl.c should be clever enought to look for the previous 
positions of the data fields when encountering malformed
values like "debug=220" or "API=677665696"




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

Bug #16033: Can't return reference to class member variable from class method.

[gabeb]

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 7.2, BeOS
PHP version:  4.1.2
PHP Bug Type: Class/Object related
Bug description:  Can't return reference to class member variable from class method.

References are screwy when returned from object methods. Witness the 
following (a script to illustrate the trouble): 

- 

class StringList 
{ 
var $strings = array(); 

function &AddString( $a_string ) 
{ 
$this->strings[] = $a_string; 
/* return a reference to newly added item */
return( $this->strings[count($this->strings)-1] ); 
} 
} 

$stringvar = "Hello World" ; 

$x = new StringList; 
$y = &$x->AddString( $stringvar ); 

/* this should change $x->strings[0], but does not! */
$y = "I love PHP!" ; 

/* This should NOT fail, but it does! */ 
assert( $y == $x->strings[0] ); 

- 

One could reasonably infer that because $y is a reference to 
$x->strings[0], modifying $y would also cause $x->strings[0] to be 
modified. 

THIS IS NOT THE CASE. After the call to AddString, $y is a COPY of 
$x->strings[0], which is NOT modified when we change $y's value.

Also, if I were to call AddString as $x->AddString("Some string"),
$x->strings 
is no longer an array and print_r($x->strings) screams *RECURSION*! This
is 
weird, because I am passing in the string using copy, and returning a
reference 
to the added copy.

If this is the correct behavior, I'll eat my hat.

The configure line specified --without-mysql, --without-pear, and my
prefix. 
That's all.
-- 
Edit bug report at http://bugs.php.net/?id=16033&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16033&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16033&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16033&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16033&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16033&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16033&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16033&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16033&r=submittedtwice

Bug #14954 Updated: Warning: Server Error with mail() function

[ras78]

 ID:   14954
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Mail related
 Operating System: Windows 2000
 PHP Version:  4.1.0
 New Comment:

I've got the same problems. Under Win2k SP2 (italian) then mail
function doesn't work. If I config my smtp everything but my localhost
or 127.0.0.1 all works fine. If I use Win2K english this problem
doesn't appear.


Previous Comments:


[2002-01-09 17:56:39] [EMAIL PROTECTED]

While I get a Warning: Server Error in
c:\wwwapache\suddenserv\test_email.php on line 7 when the SMTP = 
mail.pnang.com 
when I change the SMTP =  mail.pnang.comx I get Warning: Failed to
Connect in c:\wwwapache\suddenserv\test_email.php on line 7




[2002-01-09 17:10:07] [EMAIL PROTECTED]

The mail() function doesn't work properly.  
Every so often it does send mail.
I tried putting the php.ini in the c:\php\php.ini instead of the
c:\winnt\php.ini but that didn't help.
I've been at it a while and I've found no solutions on the web yet,
while other people have encountered the same issue.
PHP.INI has a valid SMTP =  mail.pnang.com and sendmail_from =
[EMAIL PROTECTED]

The code
mail("[EMAIL PROTECTED]", "My Subject", "Line 1\nLine 2\nLine 3");
And the birthday one from the manual.
Again the frustrating part is it worked last night. My outlook works
perfectly with the same SMTP.
Thanks,
Jonathan




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