[PHP-DEV] PHP 4.0 Bug #9644 Updated: File Upload eats all RAM and swap space

[gerard]

ID: 9644
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Reproduceable crash
Description: File Upload eats all RAM and swap space

I have compiled the CVS snapshot, with the same configure options as before, and the 
problem still exists.  Have not compiled it with APC this time.

I have copied php.ini-dist to /usr/local/lib/php.ini



Previous Comments:
---

[2001-03-09 19:49:25] [EMAIL PROTECTED]
1. There is an entry for APC in your php.ini.. have you
tried this without APC? 

2. Please try the latest CVS snapshot from http://snaps.php.net/

--Jani


---

[2001-03-09 01:10:31] [EMAIL PROTECTED]
Hi!

I'm using PHP to create a file upload script for a website.  When a user uploads a 
large file (>1Mb) my server always starts to use all the available RAM(I have 160Mb 
installed), and also uses up all the swap space(256Mb).  This happens for any upload 
script written in PHP, even scripts that work on other servers.  I can upload files to 
scripts written in PERL, without a problem.  To resolve this problem, my only option 
is to completely kill apache with 'apachectl stop' and then start it back 'apachectl 
start'

Server software:
Apache 1.3.19 (also happened while I was running 1.3.17)
PHP 4.0.4pl1
Linux 2.4.1 (originally slackware 7.1 distro)

Server specs:
Intel Pentium 133Mhz
160Mb RAM
10Gb HDD

Here is the script that I'm using:
Trying something?";
} else {
if ($userfile_size) {
$target = $xdir.'/'.$userfile_name;
if (!copy ($userfile,$target)) {
echo 'Error copying file! Please try again!Press the back button in your 
browser!';
} else {
header ("Location: 
http://mouthoff.magestudios.net/admin/filemanager/?path=".urlencode($path));
exit;
}
} else {
?>

Upload this file: 






I'm a PHP newbie, so please excuse any bad coding =)

Here's a copy of php.ini:
[PHP]

;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior.  In order for PHP to
; read it, it must be named 'php.ini'.  PHP looks for it in the current
; working directory, in the path designated by the environment variable
; PHPRC, and in the path that was defined in compile time (in that order).
; Under Windows, the compile-time path is the Windows directory.  The
; path in which the php.ini file is looked for can be overriden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple.  Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an expression
; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and parentheses:
; | bitwise OR
; & bitwise AND
; ~ bitwise NOT
; ! boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after the equal
; sign, or by using the None keyword:
;
;   foo =   ; sets foo to an empty string
;   foo = none  ; sets foo to an empty string
;   foo = "none"; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a dynamically
; loaded extension (either a PHP extension or a Zend extension), you may only
; use these constants *after* the line that loads the extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these lines,
; the builtin defaults will be identical).



; Language Options ;


engine  =   On  ; Enable the PHP scripting language engine 
under Apache
short_open_tag  =   On  ; allow the  tags are recognized.
asp_tags=   Off ; allow ASP-style <% %> tags
precision   =   14  ; number of significant digits displayed in 
floating point numbers
y2k_compliance  =   Off ; whether to be year 2000 compliant (will cause 
problems with non y2k compliant browsers)
output_buffering= Off   ; Output buffering allows you to send header lines 
(including cookies)
 

[PHP-DEV] PHP 4.0 Bug #8790 Updated: set global in function

[koyama]

ID: 8790
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Description: set global in function

Sorry, it's my mistake.
reset() is required.

Previous Comments:
---

[2001-01-18 13:03:35] [EMAIL PROTECTED]
If set global variables as global in function,
first time works fine, but second wrong.
===
n";
}
a();
a();
a();
?>
===
It displays
===
hoge: hoge
hoge:
hoge:
===



---


Full Bug description available at: http://bugs.php.net/?id=8790


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9365 Updated: Problem with muiti-byte char code set (serious)

[yohgaki]

ID: 9365
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Description: Problem with muiti-byte char code set (serious)

I forgot comment that it does not happen with simple scripts that have the same logic. 
So trying to make a script that causes this problem is just a waste of your time.

I'll test some more, so please wait feedback.

Previous Comments:
---

[2001-03-09 23:14:11] [EMAIL PROTECTED]
It seems it is related to reference.

The registration is done in a function and if there are error the function returns 
array contains error messages. It can be relatively large, so I returned reference. I 
get rid of the reference, then it start working as it should.

i.e. 
function ®ister() <= script executed from the beginning.
function register() <= works as it should.

Hope this info helps.


---

[2001-03-09 23:03:45] [EMAIL PROTECTED]
I tested with 

Newer Japanese Charset Handling module.
=> the same result.

Without these modules
=> the same result.

I was compiled in these Japanese char handling modules in php. I didn't compile these 
modules in php, but I compile these modules as individual *.so file. The same result.

If I use plain ASCII HTML file for include(). It works. But not with HTML contains 
EUC.
I'll upgrade my glibc see if it fixes. (Please wait for feedback)

FYI:
Code that causes this. I've tested with require()/include_once()/require_once(), the 
same result.
Reminder - Include()/require() works fine except on this file.

--
// Show Registration complete html
//die('DIED BEFORE INCLUDE'); // Dies as it should
//header('Location: http://www/'); // Just for testing
//include('regist_finished.ihtml'); // HTML file contains EUC. Script executed again 
from the beginning!! Can't even die at the beginning of the file.
//include('test3.php'); // ASCII char only. Works as expected.
include('cancel.ihtml'); // Another HTML file contains EUC. Script executed again from 
the beginning!! Can't even die at the beginning of the file.
die('DIED AFTER INCLUDE'); // DO NOT DIE, as it should.




---

[2001-03-09 22:52:46] [EMAIL PROTECTED]
I tested with 

Newer Japanese Charset Handling module.
=> the same result.

Without these modules
=> the same result.

I was compiled in these Japanese char handling modules in php. I didn't compile these 
modules in php, but I compile these modules as individual *.so file. The same result.

If I use plain ASCII HTML file for include(). It works. But not with HTML contains 
EUC.
I'll upgrade my glibc see if it fixes. (Please wait for feedback)

FYI:
Code that causes this. I've tested with require()/include_once()/require_once(), the 
same result.
Reminder - Include()/require() works fine except on this file.

--
// Show Registration complete html
//die('DIED BEFORE INCLUDE'); // Dies as it should
//header('Location: http://www/'); // Just for testing
//include('regist_finished.ihtml'); // HTML file contains EUC. Script executed again 
from the beginning!! Can't even die at the beginning of the file.
//include('test3.php'); // ASCII char only. Works as expected.
include('cancel.ihtml'); // Another HTML file contains EUC. Script executed again from 
the beginning!! Can't even die at the beginning of the file.
die('DIED AFTER INCLUDE'); // DO NOT DIE, as it should.




---

[2001-03-08 07:11:18] [EMAIL PROTECTED]
I thought I put some code, but there is not
Anyway, I found the line causes "goto" like behaviour. It was the line to include HTML 
file to show users.
(Note: I still have code that alway do that, I tried to make it simple. So far no 
luck, if I make it simple, it starts working as expected I will try again after I 
upgrade my glibc to see if it fixes the problem)

I've tried to stop script execution as follows.

die('Die before include'); // Works as expected
include('some.html');
die('Die after include); // This will never happen

Inside some.html

at the beginning of the file.

My code has many include/require like this. This only happens on the script, but not 
others. Other scripts work fine. All I can tell is something happens when the file is 
included. Although, the file can be included w/o problems from other scripts.

I'll post follow up. Because I didn't test the script after I upgraded Japanese 
Charactor handling module. It might be gone. (I hope)

---

[2001-03-08 05:41:04] [EMAIL PROTECTED]
Could you please provide a short code demonstrating the problem?

-

[PHP-DEV] PHP 4.0 Bug #9365 Updated: Problem with muiti-byte char code set (serious)

[yohgaki]

ID: 9365
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Description: Problem with muiti-byte char code set (serious)

It seems it is related to reference.

The registration is done in a function and if there are error the function returns 
array contains error messages. It can be relatively large, so I returned reference. I 
get rid of the reference, then it start working as it should.

i.e. 
function ®ister() <= script executed from the beginning.
function register() <= works as it should.

Hope this info helps.


Previous Comments:
---

[2001-03-09 23:03:45] [EMAIL PROTECTED]
I tested with 

Newer Japanese Charset Handling module.
=> the same result.

Without these modules
=> the same result.

I was compiled in these Japanese char handling modules in php. I didn't compile these 
modules in php, but I compile these modules as individual *.so file. The same result.

If I use plain ASCII HTML file for include(). It works. But not with HTML contains 
EUC.
I'll upgrade my glibc see if it fixes. (Please wait for feedback)

FYI:
Code that causes this. I've tested with require()/include_once()/require_once(), the 
same result.
Reminder - Include()/require() works fine except on this file.

--
// Show Registration complete html
//die('DIED BEFORE INCLUDE'); // Dies as it should
//header('Location: http://www/'); // Just for testing
//include('regist_finished.ihtml'); // HTML file contains EUC. Script executed again 
from the beginning!! Can't even die at the beginning of the file.
//include('test3.php'); // ASCII char only. Works as expected.
include('cancel.ihtml'); // Another HTML file contains EUC. Script executed again from 
the beginning!! Can't even die at the beginning of the file.
die('DIED AFTER INCLUDE'); // DO NOT DIE, as it should.




---

[2001-03-09 22:52:46] [EMAIL PROTECTED]
I tested with 

Newer Japanese Charset Handling module.
=> the same result.

Without these modules
=> the same result.

I was compiled in these Japanese char handling modules in php. I didn't compile these 
modules in php, but I compile these modules as individual *.so file. The same result.

If I use plain ASCII HTML file for include(). It works. But not with HTML contains 
EUC.
I'll upgrade my glibc see if it fixes. (Please wait for feedback)

FYI:
Code that causes this. I've tested with require()/include_once()/require_once(), the 
same result.
Reminder - Include()/require() works fine except on this file.

--
// Show Registration complete html
//die('DIED BEFORE INCLUDE'); // Dies as it should
//header('Location: http://www/'); // Just for testing
//include('regist_finished.ihtml'); // HTML file contains EUC. Script executed again 
from the beginning!! Can't even die at the beginning of the file.
//include('test3.php'); // ASCII char only. Works as expected.
include('cancel.ihtml'); // Another HTML file contains EUC. Script executed again from 
the beginning!! Can't even die at the beginning of the file.
die('DIED AFTER INCLUDE'); // DO NOT DIE, as it should.




---

[2001-03-08 07:11:18] [EMAIL PROTECTED]
I thought I put some code, but there is not
Anyway, I found the line causes "goto" like behaviour. It was the line to include HTML 
file to show users.
(Note: I still have code that alway do that, I tried to make it simple. So far no 
luck, if I make it simple, it starts working as expected I will try again after I 
upgrade my glibc to see if it fixes the problem)

I've tried to stop script execution as follows.

die('Die before include'); // Works as expected
include('some.html');
die('Die after include); // This will never happen

Inside some.html

at the beginning of the file.

My code has many include/require like this. This only happens on the script, but not 
others. Other scripts work fine. All I can tell is something happens when the file is 
included. Although, the file can be included w/o problems from other scripts.

I'll post follow up. Because I didn't test the script after I upgraded Japanese 
Charactor handling module. It might be gone. (I hope)

---

[2001-03-08 05:41:04] [EMAIL PROTECTED]
Could you please provide a short code demonstrating the problem?

---

[2001-02-21 04:07:58] [EMAIL PROTECTED]
PHP4.0.4pl1 possibly has unsafe code for 8 bit char codesets. If it is the case, any 
user, that uses charactor code from 128 to 255, may experience strange/unexpected PHP 
behavior. (Another possiblity is bugs in glibc)

NOTE: It is very difficult to determi

[PHP-DEV] PHP 4.0 Bug #9365 Updated: Problem with muiti-byte char code set (serious)

[yohgaki]

ID: 9365
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Description: Problem with muiti-byte char code set (serious)

I tested with 

Newer Japanese Charset Handling module.
=> the same result.

Without these modules
=> the same result.

I was compiled in these Japanese char handling modules in php. I didn't compile these 
modules in php, but I compile these modules as individual *.so file. The same result.

If I use plain ASCII HTML file for include(). It works. But not with HTML contains 
EUC.
I'll upgrade my glibc see if it fixes. (Please wait for feedback)

FYI:
Code that causes this. I've tested with require()/include_once()/require_once(), the 
same result.
Reminder - Include()/require() works fine except on this file.

--
// Show Registration complete html
//die('DIED BEFORE INCLUDE'); // Dies as it should
//header('Location: http://www/'); // Just for testing
//include('regist_finished.ihtml'); // HTML file contains EUC. Script executed again 
from the beginning!! Can't even die at the beginning of the file.
//include('test3.php'); // ASCII char only. Works as expected.
include('cancel.ihtml'); // Another HTML file contains EUC. Script executed again from 
the beginning!! Can't even die at the beginning of the file.
die('DIED AFTER INCLUDE'); // DO NOT DIE, as it should.




Previous Comments:
---

[2001-03-09 22:52:46] [EMAIL PROTECTED]
I tested with 

Newer Japanese Charset Handling module.
=> the same result.

Without these modules
=> the same result.

I was compiled in these Japanese char handling modules in php. I didn't compile these 
modules in php, but I compile these modules as individual *.so file. The same result.

If I use plain ASCII HTML file for include(). It works. But not with HTML contains 
EUC.
I'll upgrade my glibc see if it fixes. (Please wait for feedback)

FYI:
Code that causes this. I've tested with require()/include_once()/require_once(), the 
same result.
Reminder - Include()/require() works fine except on this file.

--
// Show Registration complete html
//die('DIED BEFORE INCLUDE'); // Dies as it should
//header('Location: http://www/'); // Just for testing
//include('regist_finished.ihtml'); // HTML file contains EUC. Script executed again 
from the beginning!! Can't even die at the beginning of the file.
//include('test3.php'); // ASCII char only. Works as expected.
include('cancel.ihtml'); // Another HTML file contains EUC. Script executed again from 
the beginning!! Can't even die at the beginning of the file.
die('DIED AFTER INCLUDE'); // DO NOT DIE, as it should.




---

[2001-03-08 07:11:18] [EMAIL PROTECTED]
I thought I put some code, but there is not
Anyway, I found the line causes "goto" like behaviour. It was the line to include HTML 
file to show users.
(Note: I still have code that alway do that, I tried to make it simple. So far no 
luck, if I make it simple, it starts working as expected I will try again after I 
upgrade my glibc to see if it fixes the problem)

I've tried to stop script execution as follows.

die('Die before include'); // Works as expected
include('some.html');
die('Die after include); // This will never happen

Inside some.html

at the beginning of the file.

My code has many include/require like this. This only happens on the script, but not 
others. Other scripts work fine. All I can tell is something happens when the file is 
included. Although, the file can be included w/o problems from other scripts.

I'll post follow up. Because I didn't test the script after I upgraded Japanese 
Charactor handling module. It might be gone. (I hope)

---

[2001-03-08 05:41:04] [EMAIL PROTECTED]
Could you please provide a short code demonstrating the problem?

---

[2001-02-21 04:07:58] [EMAIL PROTECTED]
PHP4.0.4pl1 possibly has unsafe code for 8 bit char codesets. If it is the case, any 
user, that uses charactor code from 128 to 255, may experience strange/unexpected PHP 
behavior. (Another possiblity is bugs in glibc)

NOTE: It is very difficult to determine in what condtion program does wrong. When 
condition meets PHP does following behavior ALWAYS. (I don't figure out exact 
condition yet. i.e. what combination/location of multi-byte charset causes this 
behavior.) In most cases, I don't have this kind of problem at all. Therefore, I can't 
reproduce this problem with simple script, so I don't put them in here.

Anyway, it seems PHP4.0.4pl1 does this:

PHP4 behavior: Script is executed TWICE and included file is not processed
1) PHP parse script and start executing.

[PHP-DEV] PHP 4.0 Bug #9365 Updated: Problem with muiti-byte char code set (serious)

[yohgaki]

ID: 9365
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Description: Problem with muiti-byte char code set (serious)

I tested with 

Newer Japanese Charset Handling module.
=> the same result.

Without these modules
=> the same result.

I was compiled in these Japanese char handling modules in php. I didn't compile these 
modules in php, but I compile these modules as individual *.so file. The same result.

If I use plain ASCII HTML file for include(). It works. But not with HTML contains 
EUC.
I'll upgrade my glibc see if it fixes. (Please wait for feedback)

FYI:
Code that causes this. I've tested with require()/include_once()/require_once(), the 
same result.
Reminder - Include()/require() works fine except on this file.

--
// Show Registration complete html
//die('DIED BEFORE INCLUDE'); // Dies as it should
//header('Location: http://www/'); // Just for testing
//include('regist_finished.ihtml'); // HTML file contains EUC. Script executed again 
from the beginning!! Can't even die at the beginning of the file.
//include('test3.php'); // ASCII char only. Works as expected.
include('cancel.ihtml'); // Another HTML file contains EUC. Script executed again from 
the beginning!! Can't even die at the beginning of the file.
die('DIED AFTER INCLUDE'); // DO NOT DIE, as it should.




Previous Comments:
---

[2001-03-08 07:11:18] [EMAIL PROTECTED]
I thought I put some code, but there is not
Anyway, I found the line causes "goto" like behaviour. It was the line to include HTML 
file to show users.
(Note: I still have code that alway do that, I tried to make it simple. So far no 
luck, if I make it simple, it starts working as expected I will try again after I 
upgrade my glibc to see if it fixes the problem)

I've tried to stop script execution as follows.

die('Die before include'); // Works as expected
include('some.html');
die('Die after include); // This will never happen

Inside some.html

at the beginning of the file.

My code has many include/require like this. This only happens on the script, but not 
others. Other scripts work fine. All I can tell is something happens when the file is 
included. Although, the file can be included w/o problems from other scripts.

I'll post follow up. Because I didn't test the script after I upgraded Japanese 
Charactor handling module. It might be gone. (I hope)

---

[2001-03-08 05:41:04] [EMAIL PROTECTED]
Could you please provide a short code demonstrating the problem?

---

[2001-02-21 04:07:58] [EMAIL PROTECTED]
PHP4.0.4pl1 possibly has unsafe code for 8 bit char codesets. If it is the case, any 
user, that uses charactor code from 128 to 255, may experience strange/unexpected PHP 
behavior. (Another possiblity is bugs in glibc)

NOTE: It is very difficult to determine in what condtion program does wrong. When 
condition meets PHP does following behavior ALWAYS. (I don't figure out exact 
condition yet. i.e. what combination/location of multi-byte charset causes this 
behavior.) In most cases, I don't have this kind of problem at all. Therefore, I can't 
reproduce this problem with simple script, so I don't put them in here.

Anyway, it seems PHP4.0.4pl1 does this:

PHP4 behavior: Script is executed TWICE and included file is not processed
1) PHP parse script and start executing.
   - My script check username data in db, if there is the same username, return error. 
If not, insert new username into db.
2) PHP calls function to register new user.
2) PHP execute code to insert data into db in the function. if user can be added. PHP 
possibly encounters 8bit char unclean code some where near include()and RESTART script 
execution from the beginning.
   - The script written to include() HTML file for successful user registration.

PHP inserts new username into db at 1st execution, then it finds the same username in 
db and return error for 2nd execution. 
If I put die('died here') BEFORE include(), PHP stops execution and outputs 'died 
here'. but not AFTER include(). PHP does not stop execution inside of included file, 
too. 
I was using 'ob_gzhandler', disabling it does not make any difference.

This happened when user registration check/insert was done in function defined in 
other included file that included at the top of script. 
PHP does not log any errors when this happens. (E_ALL)

PHP4 behavior: Script does not process included file and outputs default HTML as if I 
didn't print any outputs.
(It is rewrite for the code I explained)
1) PHP parse script and start executing.
 - This script does not use function calls in contrast to previous one.
2) PHP possibly encounters 8bit char unclean code some w

[PHP-DEV] PHP 4.0 Bug #9620 Updated: new operator does not behave correctly

[sniper]

ID: 9620
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Closed
Bug Type: Scripting Engine problem
Assigned To: 
Comments:



Previous Comments:
---

[2001-03-08 08:27:45] [EMAIL PROTECTED]
I submitted this bug previous and was told that this is how the new operator is 
supposed to work. I submit to you that in every other instance this makes sense, but 
for self referencing constructs, especially with the new operator, the fact that =new 
is not interpreted as =&new does not make sense whatsoever because why would I want to 
assign a copy of the object I just created, especially if that object opens files? Is 
there EVER a situation where I want to assign ANYTHING other than the object I just 
created???

Thank you.

- Response follows --

Yes, when you do a $obj = new Foo(), the object is copied.
Use =& if you want reference.

Previous Comments:
---

[2001-02-27 09:16:56] [EMAIL PROTECTED]
$objectlist=array();
class MyClass
{
  function MyClass()
  {
global $objectlist;
// Save the reference for later use
$objectList[]=&$this;
  }
};

// the object referred to by $myobject is NOT in the array
$myobject = new MyClass();
// $myobject2 exists in the array
$myobject2 =& new MyClass();

It appears that there is an object being copied when returning from the
constructor. What am I doing wrong?

I'm not supposed to return anything from the constuctor.



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9620&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #6546 Updated: Header Problem

[sniper]

ID: 6546
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Closed
Bug Type: Scripting Engine problem
Assigned To: 
Comments:



Previous Comments:
---

[2000-09-05 00:27:32] [EMAIL PROTECTED]
When sending a header after including another file (if the other file does not write 
anything directly), you will get a header problem even though no headers were actually 
sent. The connect.php only connects to the database. Nothing else.

CODE:

http://www.domain.com/data/$row[Type]/$row[FileName]");
end;
} else {
$error = "File Not Found";
}
?>


Warning: Cannot add header information - headers already sent by (output started at 
include/connect.php:8) in /usr/home/a01/html/densetsu/downloads.php on line 9

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6546&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #6131 Updated: str_pad does not accept optional fourth parameter

[sniper]

ID: 6131
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Closed
Bug Type: Documentation problem
Assigned To: 
Comments:



Previous Comments:
---

[2000-08-12 17:47:26] [EMAIL PROTECTED]
str_pad does not accept optional fourth parameter. Adding STR_PAD_LEFT or any fourth 
parameter causes 
Warning: Wrong parameter count for str_pad() error

Example script:
$emailpass=str_pad($emailpass, 12, " ", STR_PAD_LEFT); 



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6131&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #5900 Updated: Apache(apxs w/ php) fails to start

[sniper]

ID: 5900
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:



Previous Comments:
---

[2000-08-01 16:47:39] [EMAIL PROTECTED]
apache fails to start - no core dump
when php is built as a static module, things work fine,
or if no mysql, esoob and ldap, but with apxs, things work.

Platform: Redhat 6.2( Linux 2.2.14-6.1.1)
  Dell PowerEdge 2400

apache config:
   CFLAGS="-g -O" ./configure --prefix=/usr/local/apache 
--enable-module=most --enable-shared=max

php config:
./configure --with-apxs=/usr/local/apache/bin/apxs 
 --with-mysql=/usr 
 --with-esoob=/usr/local/easysoft/oob/client 
 --enable-debug --enable-trans-sid --enable-track-vars

back trace:

[root@begot bin]# gdb /usr/local/apache/bin/httpd
GNU gdb 19991004
Copyright 1998 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-redhat-linux"...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
Cannot access memory at address 0x40445b14
(gdb) bt
#0  0x4000af21 in _dl_debug_state () at dl-debug.c:56
#1  0x40180156 in _dl_close (map=0x80a4770) at dl-close.c:195
#2  0x4009e430 in dlclose_doit (handle=0x80a4770) at dlclose.c:26
#3  0x4000ac3b in _dl_catch_error (errstring=0x400a0080, 
operate=0x4009e418 , args=0x80a4770) at dl-error.c:141
#4  0x4009e8b9 in _dlerror_run (operate=0x4009e418 , 
args=0x80a4770) at dlerror.c:125
#5  0x4009e3fe in dlclose (handle=0x80a4770) at dlclose.c:32
#6  0x80644f3 in ap_os_dso_unload (handle=0x80a4770) at os.c:133
#7  0x804efcc in unload_module (modi=0x809462c) at mod_so.c:181
#8  0x80501f7 in run_cleanups (c=0x80db914) at alloc.c:1706
#9  0x804f3b9 in ap_clear_pool (a=0x809435c) at alloc.c:531
#10 0x8059eb1 in standalone_main (argc=2, argv=0xbd24) at http_main.c:4611
#11 0x805a57f in main (argc=2, argv=0xbd24) at http_main.c:4978



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=5900&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #5211 Updated: "my_init.c", line 102: undefined struct/union member: ru_maxrss

[sniper]

ID: 5211
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Closed
Bug Type: Compile Failure
Assigned To: 
Comments:



Previous Comments:
---

[2000-08-20 04:05:18] [EMAIL PROTECTED]
Does this problem still persist with more recent version of php (from CVS or 
http://snaps.php.net) ??

--Jani

---

[2000-06-24 01:22:55] [EMAIL PROTECTED]
This is a correction to Bug # 5210.  My email address and password are evidently not 
enough to allow me to edit my earlier bug report.  Sorry about the seeming duplicate.


Re: my fix in bug report 5210

Uh, no.  That will break on the BS2000.  It suppresses the compiler error on the 
Sequent for the wrong reason, and leaves open the same problem in microtime.c.

After the patch diff from bug report 5210 is applied, line 98 in my_init.c should read

#if !defined(_OSD_POSIX) && !defined(_SEQUENT_)

instead of #ifdef _OSD_POSIX

Then, a similar change is needed in microtime.c, where line 117 should become

#if !defined(_OSD_POSIX) && !defined(_SEQUENT_)

as well, instead of #ifndef _OSD_POSIX

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=5211&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] iconv patch...

[Rui Hirokawa]

On 09 Mar 2001 18:31:07 +0100
Ondrej Sury <[EMAIL PROTECTED]> wrote:

> 
> I think that UTF-8 is better choice as default encoding ;-) And because I
> couldn't compile this module, I have added php_iconv_init_globals and put
> it in ZEND_INIT_MODULE_GLOBALS.  (I have inspired by mysql module, so this
> shouldn't be neccessary correct.)

I personaly agree with your choice because I am using multibyte encoding (japanese) as 
my native language.
But some other modules like ext/xml are using ISO-8859-1 as default encoding now.
You can easily change these encoding settings using php.ini as follows,

[iconv]
iconv.internal_encoding = "UTF-8"
iconv.output_encoding = "UTF-8"

The iconv.input_encoding encoding has no meaning now.
I have a plan to add encoding translation capability between input encoding and 
internal encoding in http input (POST/GET/Cookie) parser.

-- 
--
Rui Hirokawa <[EMAIL PROTECTED]>
maintainer of japanese PHP manual <[EMAIL PROTECTED]>

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #5185 Updated: Mail() function doesn't work properly in win32 version...

[sniper]

ID: 5185
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Closed
Bug Type: Mail related
Assigned To: 
Comments:



Previous Comments:
---

[2000-06-22 05:07:58] [EMAIL PROTECTED]
Mail() function doesn't work properly in win32 version when the smtp server is 
installed on the localhost. It just connects to the server and does nothing - seems 
that it is waiting for something.



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=5185&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: PHP 4.0 Bug #8647 Updated: php.exe exception: access violation address: 0x1008e6a1 on or after file()

[Peter]

Some feedback:
I tried to get the binaries from http://www.php4win.de/ working but ran
in to problems that prevented me getting as far as testing the XML part.

I then ran in to problems switching PHP from CGI to module on an NT
machine. I updated the machine from Apache 1.3.14 to 1.3.19 and
everything worked.

The error with PHP module and Apache began when you switched to the new
format Win32 install in PHP 4.0.4pl1. The error was something about a
missing entry point and was similar to the error reported in error id
#8990.

By the time I had all that working, I had used some PHP text and array
code to read the XML file without using the XML functions.

I am writing the PHP code for a customer that will not install things
from development sites. The customer always waits for RPMs. I will now
have to stay back at the same PHP level as the customer.

Perhaps I can dive in to the leading edge again after this project.

See you at ApacheCon.

Peter

Bug Database wrote:
> 
> ID: 8647
> Updated by: sniper
> Reported By: [EMAIL PROTECTED]
> Old-Status: Feedback
> Status: Closed
> Bug Type: Reproduceable crash
> Assigned To:
> Comments:
> 
> No feedback.
> 
> --Jani
> 
> Previous Comments:
> ---
> 
> [2001-01-24 19:32:06] [EMAIL PROTECTED]
> This (XML related) bug should be fixed in CVS already. Please try the binaries
> 
> found at http://www.php4win.de/
> 
> --Jani
> 
> ---
> 
> [2001-01-11 15:06:51] [EMAIL PROTECTED]
> can you please append some *short* reproducing code?
> 
> i tested file() with a file greater than 100k and it didn't crash.
> 
> ---
> 
> [2001-01-10 21:05:56] [EMAIL PROTECTED]
> Loading array via file(). File is 4Mb of text. Bang, PHP died.
> 
> I increased PHP memory from 8 MB to 20 Mb but did not fix it. I cut the file down to 
>about 10Kb but that did not fix it. When I comment out the line containing file(), 
>that removes the problem.
> 
> I thought it might not be file(), it might be any part of the code that uses the 
>array so I commented out file() and inserted statements that manually load the array 
>with data. The script ran to completion using the manual array.
> 
> gdb backtrace is gobbledygook to me. I am reading your documentation page to see if 
>any of it is relevant to Windows environment. If your page helps me change my php 
>setup to produce additional diagnostics, I will add them to this report.
> 
> Apache is the latest Apache 1.14 or something from about 3 weeks ago. PHP is PHP 
>4.0.4 from the large download file. NT 4.0 SP6a running without a hitch for 6 months. 
>The code I am working on was working in the middle of last year on a PHP3 downloaded 
>in the middle of last year.
> 
> ---
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=8647&edit=2

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9106 Updated: Floating Point and Arithmetic Exception crashes

[sniper]

ID: 9106
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:

This is fixed in CVS. Try latest CVS snapshot from http://snaps.php.net/

--Jani


Previous Comments:
---

[2001-02-05 17:13:48] [EMAIL PROTECTED]
the change helps, but today i managed another FPE.
so there's something else to be fixed here.

---

[2001-02-05 04:02:51] [EMAIL PROTECTED]
I have suffered from 

/kernel: pid 69000 (httpd), uid 99: exited on signal 8

repeatedly in any php script whose guts wind up calling
rand(). The fix is supposedly fpsetmask(0) instead of
the current code in zend.c, but this would only work
for me if I set apache's MaxRequestsPerChild to one.

As might be expected, this is because the fix, if placed
in zend_startup, is effective ONLY for
the first request served from that httpd (in DSO mode. CGI obviously would not care). 
If you place
the fpsetmask(0) call at the beginning of zend_activate_modules, subsequent requests 
will benefit
and the signal 8 crashes cease.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9106&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8885 Updated: Child processes hang on exit

[sniper]

ID: 8885
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Reproduceable crash
Assigned To: 
Comments:

Does upgrading mod_ssl & openssl help?

--Jani


Previous Comments:
---

[2001-01-27 15:41:07] [EMAIL PROTECTED]
More info...  If I don't compile ttf into gd, it doesn't crash...

---

[2001-01-24 10:54:07] [EMAIL PROTECTED]
Child (or the main) processes hang whenever they try to exit.

This will happen when
maxrequestsperchild is reached (I'm assuming) and a child tries to die naturally
a child process is killed manually
the main process can't bind to port/etc

Here's a ps to see what it looks like

USER   PID %CPU %MEM   VSZ  RSS  TT  STAT STARTED   TIME COMMAND
www443   14066  5.6  0.3  6220  988  ??  R 8:00AM0:06.52 /var/www443/bin/httpd
www443   14067  5.3  0.3  6216 1000  ??  R 8:00AM0:07.20 /var/www443/bin/httpd
www443   14063  5.4  0.3  6220 1000  ??  R 8:00AM0:07.17 /var/www443/bin/httpd
www443   14065  5.4  0.3  6212  980  ??  R 8:00AM0:06.63 /var/www443/bin/httpd
www443   14064  5.5  0.3  6216 1004  ??  R 8:00AM0:07.57 /var/www443/bin/httpd
www443   19823  5.9  0.2  6032  608  ??  R 8:26AM9:31.91 /var/www443/bin/httpd
root 14027  0.0  0.1  6032  404  ??  Ss8:00AM0:00.18 /var/www443/bin/httpd
www443   14322  0.0  0.2  6208  724  ??  S 8:01AM0:00.22 /var/www443/bin/httpd
www443   14346  0.0  0.2  6208  736  ??  S 8:01AM0:00.23 /var/www443/bin/httpd
www443   19726  0.0  0.2  6212  744  ??  S 8:25AM0:00.17 /var/www443/bin/httpd
www443   19732  0.0  0.2  6212  732  ??  S 8:25AM0:00.14 /var/www443/bin/httpd
www443   19733  0.0  0.2  6212  724  ??  S 8:25AM0:00.09 /var/www443/bin/httpd

as you can see, the top 5 processes are hung.  A sigkill is the only way to kill them.

Attaching to one of the hung processes with gdb gives the backtrace listed at the
bottom of this report.


We can only produce this problem with the following configuration:

(Apache 1.3.12 or 1.3.14)
./configure --prefix=$prefix --with-port=$port --enable-module=most 
 --enable-module=rewrite --enable-module=status --with-layout=Apache 
 --sysconfdir=$prefix/conf --enable-module=so

(mod_ssl 2.6.5-1.3.12 or x.x.x-1.3.14)
./configure --with-apache=../apache_1.3.12 --prefix=/var/www443 
--with-ssl=/usr/local/ssl

(php 4.0.1 - 4.0.4pl1)
./configure  --with-mysql --with-xml --with-gd=/usr/local 
 --with-apxs=/var/www443/bin/apxs --enable-track-vars --enable-bcmath 
 --enable-ftp --with-jpeg-dir=/usr/local/lib --with-ttf

If we leave out PHP or mod_ssl, the problem goes away.
Also, with older versions of BSDi, this problem does not occure. (using the same 
configuration as above)



Attaching to program `/var/www443/bin/httpd', process 19823
Reading symbols from /shlib/libdl.so...done.
Reading symbols from /shlib/libgcc.so.1...done.
Reading symbols from /shlib/libc.so.1...done.
Reading symbols from /shlib/ld-bsdi.so...done.
Reading symbols from /var/www443/libexec/libphp4.so...done.
Reading symbols from /usr/local/lib/libttf.so.2...done.
Reading symbols from /shlib/libm.so.0.0...done.
0x481a5a54 in __deregister_frame_info ()
(gdb) bt
#0  0x481a5a54 in __deregister_frame_info ()
#1  0x8069e7a in __do_global_dtors_aux ()
#2  0x8163fa4 in _fini ()
#3  0x48248028 in exit ()
#4  0x80c3e1f in clean_child_exit (code=0) at http_main.c:517
#5  0x80c6ac2 in child_main (child_num_arg=10) at http_main.c:4057
#6  0x80c6f8c in make_child (s=0x81ad034, slot=10, now=980349966) at http_main.c:4435
#7  0x80c7305 in perform_idle_server_maintenance () at http_main.c:4599
#8  0x80c77f5 in standalone_main (argc=1, argv=0x8047ec4) at http_main.c:4831
#9  0x80c7dc3 in main (argc=1, argv=0x8047ec4) at http_main.c:5092
#10 0x8069e37 in __start ()
(gdb) quit


# /var/www443/bin/httpd -l
Compiled-in modules:
  http_core.c
  mod_vhost_alias.c
  mod_env.c
  mod_define.c
  mod_log_config.c
  mod_mime_magic.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_info.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_speling.c
  mod_userdir.c
  mod_alias.c
  mod_rewrite.c
  mod_access.c
  mod_auth.c
  mod_auth_anon.c
  mod_auth_dbm.c
  mod_digest.c
  mod_proxy.c
  mod_cern_meta.c
  mod_expires.c
  mod_headers.c
  mod_usertrack.c
  mod_unique_id.c
  mod_so.c
  mod_setenvif.c
  mod_ssl.c
  mod_frontpage.c

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8885&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addition

[PHP-DEV] PHP 4.0 Bug #8837 Updated: Compilation gives error after successfull configure with gw, t1

[sniper]

ID: 8837
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Install and Config
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2001-01-26 13:28:22] [EMAIL PROTECTED]
Without the error message itself I have to guess here..
You propably have some old gd-library remains somewhere
in your system. Try adding the base dir of libgd.a (or .so)
into --with-gd, ie. --with-gd=/usr if the library is in
/usr/lib/

Then delete config.cache, configure, make clean, make,
make install.

--Jani

---

[2001-01-22 08:47:24] [EMAIL PROTECTED]
With programs and versions :

T1-1.0.1/  
apache_1.3.14/  
gd-1.8.3/  
jpeg-6b/  
libpng-1.0.8/  
mod_ssl-2.7.1-1.3.14/  
openssl-0.9.6/  
php-4.0.3pl1/  
xpm-3.4k/
we ran configure succesfull parameters:

--with-with-mysql --with-xml --with-apche=../apache_1.3.14/ --enable-track-vars 
--with-gd --with-t1lib=../T1-1.0.1 --with-jpeg-dir --with-imap  
--with-xpm-dir=../xpm-3.4k 

we got this error message after make ran:


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8837&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8840 Updated: configure php w/FdfTk.hith --with-fdftk option

[sniper]

ID: 8840
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Install and Config
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2001-01-26 13:33:01] [EMAIL PROTECTED]
Is the /usr/local/include/FdfTk.h readable by 
the user with which you are trying to configure?
ie. does the file have read permissions?

And have you checked the config.log if there 
is something else failing?

--Jani


---

[2001-01-22 10:45:36] [EMAIL PROTECTED]
I trie to install php 4.04 with fdftk.
I got libfdftk.so and from adobe web site and i put it in :
   /usr/local/lib
  /usr/local/include

and i used this command line 

sh configure sh ./configure --with-apxs=/usr/bin/apxs  
--with-imap=/usr/local/lib/imap 
--with-pgsql=/opt/pgsql 
--with-pdflib --with-jpeg-dir --with-png-dir
--with-tiff-dir
--with-zlib
--with-fdftk=/usr/local 
--with-ldap=/usr/local

or 
sh ./configure --with-apxs=/usr/bin/apxs  
--with-imap=/usr/local/lib/imap 
--with-pgsql=/opt/pgsql 
--with-pdflib --with-jpeg-dir --with-png-dir
--with-tiff-dir
--with-zlib
--with-fdftk=/usr/local/lib 
--with-ldap=/usr/local

each time i had this error message

configure: error: Please reinstall the fdftk distribution
 
Thanks

Regards
  

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8840&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8353 Updated: foreach modify array pointer

[sniper]

ID: 8353
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Arrays related
Assigned To: 
Comments:

no feedback.


Previous Comments:
---

[2001-01-05 22:52:10] [EMAIL PROTECTED]
I get 121 for both cases. Please try the latest snapshot from http://snaps.php.net/

--Jani

---

[2000-12-21 09:44:03] [EMAIL PROTECTED]
try 1.:

$var[] = "1";
$var[] = "2";

foreach($var as $test)
{
echo $test;
}
reset($var); 
echo current($var);

output -> 12

then try:
$var[] = "1";
$var[] = "2";

//reset($var);
foreach($var as $test)
{
echo $test;
current($var);
}
echo current($var);

output -> 121

this should be the output of the first script too?
Greetings lunepi

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8353&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8362 Updated: php_oci8.dll wont load.

[sniper]

ID: 8362
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Dynamic loading
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2001-01-08 16:58:08] [EMAIL PROTECTED]
does the directory really contain php_ori8.dll, or is it a typo? maybe this is just a 
php.ini / actual filename mismatch.

---

[2000-12-21 14:00:49] [EMAIL PROTECTED]
When trying to load the php_oci8.dll module it gives the next message:
Unable to load dynamic library 'C:/php4/extensions/php_ori8.dll' 

It´s not the extension_dir, becouse i´m able to load other extensions, and i have even 
tried to change the name of the dll but it doesn´t work.

I think there must be some problem with the dll.

Thankyou in advance.  PHP is great!



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8362&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8375 Updated: Undefined Reference

[sniper]

ID: 8375
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Install and Config
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2001-01-04 13:11:21] [EMAIL PROTECTED]
What was the full configure line used?
Did you follow the instructions in INSTALL file?
Try doing 'make clean ; make depend' after configure.

--Jani

---

[2000-12-22 07:29:51] [EMAIL PROTECTED]
I configured PHP with-pfpro=(correct signio lib directory). Make and Make Install 
worked fine.

I switched over to apache, and remade it. When it got to pfpro, I got this:

modules/php4/libphp4.a(pfpro.o): In function `php_rshutdown_pfpro':
/usr/local/etc/php-4.0.4/ext/pfpro/pfpro.c(.text+0x58): undefined reference to `
PNCleanup'
modules/php4/libphp4.a(pfpro.o): In function `php_info_pfpro':
/usr/local/etc/php-4.0.4/ext/pfpro/pfpro.c(.text+0x87): undefined reference to `
PNVersion'
modules/php4/libphp4.a(pfpro.o): In function `php_if_pfpro_version':
/usr/local/etc/php-4.0.4/ext/pfpro/pfpro.c(.text+0xc9): undefined reference to `
PNVersion'
modules/php4/libphp4.a(pfpro.o): In function `php_if_pfpro_init':
/usr/local/etc/php-4.0.4/ext/pfpro/pfpro.c(.text+0x115): undefined reference to
`PNInit'
modules/php4/libphp4.a(pfpro.o): In function `php_if_pfpro_cleanup':
/usr/local/etc/php-4.0.4/ext/pfpro/pfpro.c(.text+0x149): undefined reference to
`PNCleanup'
modules/php4/libphp4.a(pfpro.o): In function `php_if_pfpro_process_raw':
/usr/local/etc/php-4.0.4/ext/pfpro/pfpro.c(.text+0x80b): undefined reference to
`PNInit'
/usr/local/etc/php-4.0.4/ext/pfpro/pfpro.c(.text+0x862): undefined reference to
`ProcessPNTransaction'
modules/php4/libphp4.a(pfpro.o): In function `php_if_pfpro_process':
/usr/local/etc/php-4.0.4/ext/pfpro/pfpro.c(.text+0x127c): undefined reference to
 `PNInit'
/usr/local/etc/php-4.0.4/ext/pfpro/pfpro.c(.text+0x12ce): undefined reference to
 `ProcessPNTransaction'
*** Error code 1

Stop in /usr/local/etc/apache_1.3.14/src.
*** Error code 1

Stop in /usr/local/etc/apache_1.3.14.
*** Error code 1

Stop in /usr/local/etc/apache_1.3.14.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8375&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8383 Updated: array_unique() causes core dump

[sniper]

ID: 8383
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:



Previous Comments:
---

[2000-12-22 17:38:57] [EMAIL PROTECTED]
array_unique() can cause php to core dump.  i haven't quite figured out the exact 
situation though.

this works:

array_unique(array("socket", "37", "99", "3d"));

this does not:

array_unique(array("socket", "370", "99", "3d"));


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8383&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8401 Updated: imap_header

[sniper]

ID: 8401
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: IMAP related
Assigned To: 
Comments:

No feedback.
Should be fixed. Try with 4.0.4pl1 and imap-2000 c-client.


--Jani


Previous Comments:
---

[2001-01-02 10:09:44] [EMAIL PROTECTED]
Please try PHP 4.0.4 to check if this is fixed already.

--Jani


---

[2000-12-24 09:13:59] [EMAIL PROTECTED]
Imap version 4.1

imap_header($imap_link, $msg_no);
does not work with some letters.

Warning:  No body information available in /homedir/somefile.php on line 
250

exsemple of letter:
Received: (qmail 30260 invoked from network); 9 Sep 2000 08:34:30 -
Received: from gc-227.intevo.com (HELO andre.intevo.com) ([EMAIL PROTECTED])
  by some.server.lt with SMTP; 9 Sep 2000 08:34:30 -
X-tracker: I1-3000-15-19-2066352-A61007
Content-Transfer-Encoding: binary
Content-Type: multipart/alternative; boundary="_--=_96837028189360"
Date: Thu, 7 Sep 2000 23:44:41 UT
To: [EMAIL PROTECTED]
From: deltathree <[EMAIL PROTECTED]>
Reply-To: deltathree <[EMAIL PROTECTED]>
Subject: News from deltathree

This is a multi-part message in MIME format.

--_--=_96837028189360
Content-Disposition: inline
Content-Length: 259
Content-Transfer-Encoding: binary
Content-Type: text/plain

body of letter
--_--=_96837028189360--

Why the functions not working ?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8401&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8404 Updated: Crash with libmcrypt-2.4.7-shared

[sniper]

ID: 8404
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Reproduceable crash
Assigned To: 
Comments:

DOes this happen with latest CVS snapshot from http://snaps.php.net/ ?? And what were 
the configure lines?

--Jani


Previous Comments:
---

[2001-01-07 19:12:33] [EMAIL PROTECTED]
Please add the configure lines for both PHP and Mcrypt into this bug report.

--Jani

---

[2000-12-24 11:49:20] [EMAIL PROTECTED]
With libmcrypt-2.4.7 (shared)

test.php


(gdb) bt
#0  0x4000af20 in _dl_debug_state () at ripemd.c:401
#1  0x4000ac3b in _dl_catch_error () at ripemd.c:401
#2  0x407bfd3d in _dl_open (file=0x8328350 "/usr/local/lib/libmcrypt/wake.so", 
mode=257, caller=0xbfffd774)
at dl-open.c:232
#3  0x4003faa7 in dlopen_doit (a=0xbfffd888) at dlopenold.c:45
#4  0x4000ac3b in _dl_catch_error () at ripemd.c:401
#5  0x4003f8b9 in _dlerror_run (operate=0x4003fa7c , args=0xbfffd888) at 
dlerror.c:125
#6  0x4003fa6b in __dlopen_nocheck (file=0x8328350 "/usr/local/lib/libmcrypt/wake.so", 
mode=257)
at dlopenold.c:61
#7  0x40094ba3 in sys_dl_open (handle=0x83282a0, filename=0x8328350 
"/usr/local/lib/libmcrypt/wake.so")
at ltdl.c:266
#8  0x400951a5 in tryall_dlopen (handle=0xbfffda04, filename=0x8328350 
"/usr/local/lib/libmcrypt/wake.so")
at ltdl.c:943
#9  0x40095307 in find_module (handle=0xbfffda04, dir=0x8322e40 
"/usr/local/lib/libmcrypt/", 
libdir=0x8327de0 "/usr/local/lib/libmcrypt", dlname=0x8328280 "wake.so", 
old_name=0x8328290 "wake.a", 
installed=1) at ltdl.c:986
#10 0x400961d4 in lt_dlopen (filename=0x8326f0b "wake.la") at ltdl.c:1340
#11 0x400964fc in lt_dlopenext (filename=0x8326f0b "wake.la") at ltdl.c:1423
#12 0x4009176f in mcrypt_module_close () at mcrypt_modules.c:48
#13 0x40090e9f in mcrypt_free_p () at mcrypt_extra.c:211
#14 0x40090b37 in mcrypt_list_algorithms (libdir=0x0, size=0xbfffe334) at 
mcrypt_extra.c:100
#15 0x80a0f7a in php_info_mcrypt (zend_module=0x82de1e0) at mcrypt.c:351
#16 0x80da71e in _display_module_info (module=0x82de1e0, arg=0xbfffe3e4) at info.c:50
#17 0x811dca9 in zend_hash_apply_with_argument (ht=0x82b9bc0, apply_func=0x80da6ec 
<_display_module_info>, 
argument=0xbfffe3e4) at zend_hash.c:711
#18 0x80d9b40 in php_print_info (flag=-1) at info.c:256
#19 0x80da2b9 in php_if_phpinfo (ht=0, return_value=0x832567c, this_ptr=0x0, 
return_value_used=0) at info.c:464
#20 0x8149b65 in execute (op_array=0x83255f4) at ./zend_execute.c:1519
#21 0x81188fb in zend_execute_scripts (type=8, file_count=3) at zend.c:729
#22 0x80914db in php_execute_script (primary_file=0xb6b4) at main.c:1221
#23 0x8127211 in apache_php_module_main (r=0x831feac, display_source_mode=0) at 
sapi_apache.c:89
#24 0x808eb53 in send_php () at ripemd.c:401
#25 0x808ee32 in send_parsed_php () at ripemd.c:401
#26 0x8156165 in ap_invoke_handler () at ripemd.c:401
#27 0x81673dc in process_request_internal () at ripemd.c:401
#28 0x8167789 in ap_process_request () at ripemd.c:401

With libmcrypt-2.4.7-static - Working.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8404&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8405 Updated: header() doesn't seem to have effect

[sniper]

ID: 8405
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Apache related
Assigned To: 
Comments:

No feedback.


Previous Comments:
---

[2000-12-28 09:04:17] [EMAIL PROTECTED]
1. Upgrade to php4.0.4
2. Check your php.ini as it seems you have
enabled the session.auto_start, in which case
you might want to use something else than 'nocache' in session.cache_limiter 
directive.

--Jani

---

[2000-12-24 11:55:24] [EMAIL PROTECTED]
When I do :

$date_expire = gmdate("D, d M Y H:i:s", (time() + 60*60*24*2))  . " GMT";
header ("Expires: " . $date_expire ); 
   //the client-browser SHOULD CACHE IT!
header ("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); 

I always get as following:
[siva@localhost siva]$ curl -I http://localhost.localdomain/utqa4/utqa.php
HTTP/1.1 200 OK
Date: Sun, 24 Dec 2000 16:45:32 GMT
Server: Apache-AdvancedExtranetServer/1.3.14 (Linux-Mandrake/2mdk) PHP/4.0.3pl1
X-Powered-By: PHP/4.0.3pl1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Last-Modified: Sun, 24 Dec 2000 16:45:32 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=1f4ffbfbd2118f0f1c827a4c4adea8ae; path=/
Connection: close
Content-Type: text/html  


Note that 
1) the HTTP header Cache-Control specifies no-cache, contrariwise to what I specified 
in the header() function. 
2) Last-Modified header too is wrong
Is it buggy? What should I do?

APACHE ver 1.3.14
PHP version 4.0.3pl1
 './configure' '--enable-trans-sid' '--with-pgsql' '--with-apxs' '--with-mycrypt

==
Thanks, happy parties!
Siva

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8405&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8410 Updated: php4 & newest 2.0a9 apache "misalignment"

[sniper]

ID: 8410
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Compile Failure
Assigned To: 
Comments:

no feedback.


Previous Comments:
---

[2001-01-11 11:49:57] [EMAIL PROTECTED]
Could you please try the latest CVS snapshot from http://snaps.php.net/ as this should 
be fixed.

--Jani

---

[2000-12-24 21:15:59] [EMAIL PROTECTED]
when compiling with apache 2.0a9 two things have to be changed in php's source and 
makefile so that php will compile as apxs2 module

a) in makefile an include dir to apache_dir/include/apr-util has to be added - 
otherwise ap_hooks.h and ap_bucktes.h won't be found
b) in sapi/apache2filter/php_functions.c in line 49 in the call to 
ap_sub_req_lookup_uri there has to be added a third argument to the function - NULL 
obviously. :)

after this two changes everything compiles OK, but
when starting apache it report an fatal error saying "unresolved symbol: uncompress" 
regarding libphp4.so. with this one i cannot handle

Marcin Galczynski

---

[2000-12-24 20:21:03] [EMAIL PROTECTED]
Due to changes in apache 2.0a9 two things have to
be changed in php's source and makefile so that php will
compile as apxs2 module

a) in makefile an include dir to apache_dir/include/apr-util has to be added - 
otherwise ap_hooks.h and ap_bucktes.h won't be found

b) in sapi/apache2filter/php_functions.c in line 49 
  in the call to ap_sub_req_lookup_uri there has to be added
a third argument to the function - NULL obviously. :)

after this two changes everything compiles OK and even works.

good luck

Marcin Galczynski

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8410&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8416 Updated: Unable to load dynamic library

[sniper]

ID: 8416
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: IIS related
Assigned To: 
Comments:

No feedback.


Previous Comments:
---

[2001-01-05 12:14:41] [EMAIL PROTECTED]
are you sure they are stored there?
additionally make sure that there's no other php.ini hanging around in your system 
which causes the error.

---

[2000-12-25 09:08:23] [EMAIL PROTECTED]
Installating bugs 
Platform: windows 2000 (professional) + IIS 5.0
version: Win32 Binaries PHP 4.0.4 - 19 December 2000, 
From: http://www.php.net/downloads.php, 2000/12/25
Remark: 3.79 Mb CGI binary and ISAPI module included, MySQL support built-in, many 
extensions included, packaged as zip

Maybe: the / after "extension_dir" yet not change to Win32 style...

Unable to load dynamic library 'c:phpextentions/php_db.dll'- ...
Unable to load dynamic library 'c:phpextentions/php_gd.dll'- ...
Unable to load dynamic library 'c:phpextentions/php_ldap.dll'- ...
Unable to load dynamic library 'c:phpextentions/php_mhash.dll'- ...
Unable to load dynamic library 'c:phpextentions/php_mssql70.dll'- ...
Unable to load dynamic library 'c:phpextentions/php_pdf.dll'- ...
Unable to load dynamic library 'c:phpextentions/php_pgsql.dll'- ...
Unable to load dynamic library 'c:phpextentions/php_zlib.dll'- ...

My php.ini:
...
extension_dir   =   c:phpextentions
...
;extension=php_cpdf.dll
;extension=php_cybercash.dll
 extension=php_db.dll
;extension=php_dbase.dll
;extension=php_domxml.dll
;extension=php_dotnet.dll
;extension=php_exif.dll
;extension=php_fdf.dll
 extension=php_gd.dll
;extension=php_gettext.dll
;extension=php_ifx.dll
;extension=php_imap.dll
;extension=php_interbase.dll
;extension=php_java.dll
 extension=php_ldap.dll
 extension=php_mhash.dll
;extension=php_mssql65.dll
 extension=php_mssql70.dll
;extension=php_oci8.dll
;extension=php_oracle.dll
 extension=php_pdf.dll
 extension=php_pgsql.dll
;extension=php_sablot.dll
;extension=php_swf.dll
;extension=php_sybase_ct.dll
 extension=php_zlib.dll


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8416&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8420 Updated: configure --with-mcrypt may fail to detect mcrypt

[sniper]

ID: 8420
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Compile Failure
Assigned To: 
Comments:

No feedback.


Previous Comments:
---

[2000-12-28 08:53:13] [EMAIL PROTECTED]
Please reduce the configure options to the minimum
which still makes the detect fail.

--Jani


---

[2000-12-26 02:44:25] [EMAIL PROTECTED]
I recently made a build with a number of options enabled. With my full configure line, 
the mcrypt library detection would fail ("error: Sorry" after the two version checks)
./configure --with-apxs=/usr/sbin/apxs --with-mysql --with-imap=../imap-2000a/ 
--with-pdflib --with-bz2 --with-openssl --with-mm --with-pspell --enable-bcmath 
--with-curl --with-dom --enable-ftp --with-gd --enable-gd-imgstrttf --with-jpeg-dir 
--with-gettext --with-java --with-ldap --with-mcrypt --with-mhash --with-pgsql 
--enable-shmop --enable-sockets --with-swf=/home/chris/libswf-0.99/ --enable-sysvsem 
--enable-sysvshm --with-zlib --enable-inline-optimization --enable-memory-limit 
--enable-shared
fails. If I did a bare ./configure --with-mcrypt, the library would be detected. I 
could then re-run the full script, as the mcrypt detection was cached.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8420&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8429 Updated: erealloc() problem

[sniper]

ID: 8429
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Class/Object related
Assigned To: 
Comments:

No feedback. 

Previous Comments:
---

[2001-02-04 13:07:40] [EMAIL PROTECTED]
Please include a gdb backtrace of the crash into this bug report.
Instructions can be found here:
http://bugs.php.net/bugs-generating-backtrace.php

Also, please include a SHORT script which can (without
any DB's or such) used to reproduce the crash.

--Jani


---

[2001-01-08 14:01:29] [EMAIL PROTECTED]
Could you produce minimal PHP code that reproduces the
problem? 1000 lines of DB-dependant application is pretty
hard to investigate. Also, do you have some non-standard PHP
modules in your application?

---

[2000-12-26 13:52:18] [EMAIL PROTECTED]
Under Linux, memory appears to be corrupted after Alarm object newed/ or call to 
DisplayObject function.  This is part of a large/complex script, around 1000 lines.

  Using BODY debugger, variables having weird stuff in them.  It is like the memory 
manager gets hosed.  I would be willing to give entire script/database configuration 
set to anyone.  The application is GPL'd.  I've got a sample database for MySQL that 
configures and loads as follows:
mysql walking TestActionArray+++
Function==CheckTestActionResult(0,0) file /home/httpd/html/mom/momact.c line 
203
Key 0 not used
Function==CheckTestActionResult(Object,2) file /home/httpd/html/mom/momact.c 
line 203
key 2 for object Object
---
For Object 'ActionResult ($ARValue)':
---
new action result!
Creating New Alarm Info Object
$Alarm was NOT set
---
For Object 'ActionResult':
---
FATAL:  erealloc():  Unable to allocate 1699901065 bytes   
88


(browser)
http://127.0.0.1/mom/mom.php


System is running 128 meg on linux.

  The objects's variables having weird stuff in them is shown in this printout:


printout of web page:
99

->defining debug in file /home/httpd/html/mom/mom.c at line 242

Function==MonitorMachines file /home/httpd/html/mom/momact.c line 334
walking MonitoredMachineArray

Function==RunTestAction(0, 0): file /home/httpd/html/mom/momact.c line 139

Function==RunTestAction(Object, 1): file /home/httpd/html/mom/momact.c line 139

Function==RunAction(2,1) file /home/httpd/html/mom/momact.c line 71
Running PHP Command String
$ExecString="echo 'Sendmail is being Tested
';return(SUCCESS);"
Sendmail is being Tested
$Result="1"
$TestActionResult["2"]=RunAction($ActionID,$MMKey)
$ActionID = 2
---
For Object 'TesActionResult':
ServiceID -> 1
MonitoredMachineID -> 1
Result -> 1
---
+++
walking TestActionArray
+++

Function==CheckTestActionResult(0,0) file /home/httpd/html/mom/momact.c line 201
Key 0 not used

Function==CheckTestActionResult(Object,2) file /home/httpd/html/mom/momact.c line 201
key 2 for object Object 
---
For Object 'ActionResult ($ARValue)':
ServiceID -> 1
MonitoredMachineID -> 1
Result -> 1
---
new action result!
Creating New Alarm Info Object
$Alarm was NOT set
---
For Object 'ActionResult':
ServiceID -> 1
MonitoredMachineID -> ActionResult
Result -> 1
---
$ServiceID=1, $MachineID=D?  d[
ExitNow called from 264 in file /home/httpd/html/mom/momact.c

@@
function DisplayObject(&$Obj,$Name)// crash occurs even when obj //copied by not using 
& in front of $Obj parameter description
{
   echo "---n"; 
   echo "For Object '$Name':n";
   
   while ( list($key,$value) = each($Obj) )
  {  
  if (gettype($key) == "string")
 echo "$key -> $valuen";
  }  
   echo "---n"; 
} 


function CheckTestActionResult($ARValue,$ARKey)
{
   global $MySQLConfig; // the mysql configurationinfo
   global $AlarmType;
   global $StatusType;
   global $Service;
   global $Alarm;
   global $LastActionResult;
   global $LastAlarm; 
   global $TestActionResult;

  if (defined("DEBUG"))
 print("Function==CheckTestActionResult($ARValue,$ARKey) file ".__FILE__." 
line ".__LINE__."n"); 
  
  if ($ARKey == 0)
   {
   if (defined("DEBUG"))
  echo "Key 0 not usedn";
   return;
   }
  else
   if (defined("DEBUG"))
  echo "key $ARKey for object

[PHP-DEV] PHP 4.0 Bug #8450 Updated: Warning: Supplied argument is not a valid InterBase result resource

[sniper]

ID: 8450
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: InterBase related
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2000-12-28 05:26:46] [EMAIL PROTECTED]
Please provide more information, such as php configure line,
small reproducing piece of code.

---

[2000-12-28 04:02:33] [EMAIL PROTECTED]
I got the problem only when i use ibase_query with a Select sql command, i use the 
linux Super Server of Interbase 6.0 and the las Apache Version 1.3.14 with DSO and PHP 
4.0.4.

Thanks in advance 



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8450&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8451 Updated: undefined struct tm

[sniper]

ID: 8451
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Assigned To: 
Comments:

Have you tried the latest CVS ?


Previous Comments:
---

[2000-12-28 10:02:41] [EMAIL PROTECTED]
Try loading the php4ts.dsw workspace instead and build the thread safe versions of 
things. That should work ok. Let us know how you get on.

Question to any dev who knows about this stuff: is the non ts build now obsolete (ie 
the php4.dsw), and if so, should it be removed from the source?

---

[2000-12-28 08:59:59] [EMAIL PROTECTED]
When I try to build the php4dll project, it fails in main.c.

It is tripping over the include of win32/time.h.  I would strongly recommend changing 
the names of any php custom modules to include a prefix of 'php_'.  

My workaround involved doing just that.  So far, the only two that I changed were 
time.h and signal.h.  I think the MS environment may behave a little strange compared 
to UNIX ;-)  

Also, I found the php3 build process to be very smooth, definitely a sign of maturity. 
 The php4 process is still a little rough.

There is another omission with compiling of one of the parser modules, I will submit 
that as another bug.

I'm using version 6.0 sp3, enterprise edition.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8451&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8461 Updated: ftp_put() some files will be sent, some files won't

[sniper]

ID: 8461
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: FTP related
Assigned To: 
Comments:

no feedback.


Previous Comments:
---

[2001-01-24 04:05:38] [EMAIL PROTECTED]
Possible reasons:

1. The script timeouts. 
Solution: set_time_limit(0)

2. There is a file with same name as the target and it
has read-only permissions.

3. The local file is not readable by the user with which
the web server is running.

--Jani


---

[2000-12-28 12:12:14] [EMAIL PROTECTED]
the target is, to send all files in a specific directory to an ftp-account.
PHP-Version 4.04
Server IIs (windows NT)


the source:

//## start code ###
if($fazftpport){
$fazftpid   = ftp_connect($fazftphost, $fazftpport);   
 // <-- works !!
} else {
$fazftpid   = ftp_connect($fazftphost);
// <-- works !!
}
if(!ftp_login($fazftpid, $fazftpuser, $fazftppwd)){
 // <-- works !!
die("Fehler beim LogIn (FTP-Server: " . $fazftphost . ")");
} else {
 if(!ftp_chdir($fazftpid, $fazftpdir)){
   // <-- works !!
die("ChangeDirectory nicht erfolgreich (" . $fazftpdir . ")");
} else {
print "FTP-Zugang geöffnet und Verzeichnis gewechselt";
}
$filecount = 1;
$fopendir = opendir($fazausgabepfad);   // Verzeichnisbaum lesen
if($fopendir <= 0){
print "Start-Verzeichnis konnte nicht geöffnet werden";
} else {
print "Start-Verzeichnis geöffnet";
while($filezwischen = readdir($fopendir)){
if($filezwischen != "." && $filezwischen != ".."){
print "Startdatei : " . $filezwischen . " / ";
$zieldatei = $filezwischen;
print "Zieldatei : " . $zieldatei . "";

// Here is the problem !!!
// all files are .htm-files, so ascii is ok

if(ftp_put($fazftpid, $zieldatei, $filezwischen, 
FTP_ASCII)){   

// some files will be sent !
// but most files won't
// all files are set to the same permissions

print "Datei " . $filezwischen .  " 
erfolgreich übertragen";
} else {
print "Fehler ! Datei " . $filezwischen .  " konnte nicht 
übertragen werden";
}
}
}

}

}
if(!ftp_quit($fazftpid)){ // <-- works !!
die("Fehler beim Schließen des FTP-Connects (FTP-Server: " . $fazftphost . " / 
FTP-ID: " . $fazftpid . ")");
}
print "FTP-Zugang geschlossen";
// ### end code ###

comment:
all variables are given and OK.
some files will be sent, some files won't.
we did not figure out, why files are not sent, becouse, when i copy a sendable file 
and try it again, the new file will not be sent.




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8461&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8485 Updated: while loading libphp4.so -> undefined symbol: SSL_CTX_set_tmp_rsa_callback

[sniper]

ID: 8485
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Install and Config
Assigned To: 
Comments:

No feedback, considered fixed.


Previous Comments:
---

[2001-01-04 13:35:15] [EMAIL PROTECTED]
Try adding --with-imap-ssl=/path/to/openssl/install/dir
into your configure line. 

--Jani

---

[2000-12-29 17:39:48] [EMAIL PROTECTED]
Apache  1.3.14

./configure --prefix=/usr --with-apxs --enable-track-vars --with-mysql --with-imap 
--enable-magic-quotes  --enable-calendar --with-kerberos

compiles with no problems and then when starting apache

 Cannot load /home/httpd/modules/libphp4.so into server: undefined symbol: 
SSL_CTX_set_tmp_rsa_callback

The system is RedHat 7.0 using  egcs-2.91.66





---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8485&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8507 Updated: Can't connect to MySQL 3.22.32

[sniper]

ID: 8507
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: MySQL related
Assigned To: 
Comments:

No feedback. Old PHP version.



Previous Comments:
---

[2001-01-02 08:51:43] [EMAIL PROTECTED]
I assume that mysqld is running?
Try reconfigure php to use the installed mysql instead
of the bundled client library.

1. Delete config.cache
2. Use --with-mysql=/path/to/mysql/install/dir
3. 'make clean ; make depend ; make ; make install'

Please report back whether this works for you or not.

--Jani

---

[2000-12-31 22:24:38] [EMAIL PROTECTED]
I own a Cobalt Raq4 preinstalled with PHP Version 4.0.1pl2 and Chilisoft ASP. 
Chilisoft ASP will only work with Mysql 3.22.32. I am unable to connect to my 
databases using PHP 4.0.1 in MySQL 3.22.32.   phpinfo(); returns Mysql Client API 
version 3.23.10-alpha. The script I am using is as follows




I have filled in all of the correct parameters and I got the following message. The 
script is cut from the page and the error message line matches up with the actual 
page.

Warning: MySQL Connection Failed: Can't connect to local MySQL server through socket
   '/tmp/mysql.sock' (111) in /home/sites/site2/web/info.php on line 5
Couldn't connect to server.

Is this a bug or is there a way to make PHP  4.0.1pl2 connect to Mysql 3.22.32.

Any help would be greatly appreciated

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8507&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8525 Updated: fileupload bug

[sniper]

ID: 8525
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Filesystem function related
Assigned To: 
Comments:

No feedback.


Previous Comments:
---

[2001-01-04 05:08:53] [EMAIL PROTECTED]
Do you use PHP as CGI or module? IIRC you can't use stripslashes($bild) in the module 
version on Win32.
Instead you have to access directly to $bild.

-Martin

---

[2001-01-02 15:18:04] [EMAIL PROTECTED]
I have problems with fileupload with the new version (4.04).
With the old version ( 3.x) all worked fine.

Look at this:
$id=5;
$smallpic = stripslashes($bild);
  if ((file_Exists($smallpic)) AND (!($smallpic=="")))
  {
   $fp = fopen($smallpic,  "r");
   $datei = fread($fp, filesize($smallpic));
   fclose($fp);
   $smallname = $id."bild.jpg";
   $fp = fopen("$bildpfad$smallname", "w+");
   fwrite($fp, "$datei");
   fclose($fp);
  } else $smallname="";

Normally, in $smallname should be the correct filename
from the uploaded pic - but it's empty. It's empty, 
because the file does not exists.
In $smallname I have something like
"c:tempphp9005.TMP"- but I think this is incorrect.

Well - with the old version (3.x) it worked fine.




 





---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8525&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8541 Updated: Fieldtype doesn't work with PHP

[sniper]

ID: 8541
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: MSSQL related
Assigned To: 
Comments:



Previous Comments:
---

[2001-01-03 15:07:59] [EMAIL PROTECTED]
I use:

PHP 4.04 ISAPI-Mode
SQL Server 2000
and ODBC.

Here the message:

FATAL: emalloc(): Unable to allocate 1073741824 bytes 

The problem seems (for me) to be the field NTEXT.
I changed the fields of type NTEXT to TEXT and it worked.

I first posted this problem on www.experts-exchange.com.
James Moore (PHP QA Team) asked me to post the problem here.

So, how I said: After I changed all the database-fields of type NTEXT to TEXT, it 
worked perfect for me!

Hope I could help.

Bye.
Yasmeen


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8541&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8551 Updated: mssql70.dll problem

[sniper]

ID: 8551
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Install and Config
Assigned To: 
Comments:

No feedback.


Previous Comments:
---

[2001-01-04 11:58:40] [EMAIL PROTECTED]
please check php4ts.dll as well. If php.exe or php4isapi.dll is loaded you will not be 
able to overwrite php4ts.dll.

---

[2001-01-04 10:40:41] [EMAIL PROTECTED]
Downloaded php4.04 and installed in c:php directory over a working copy of 4.02

Try to do a mssql_connect and get

'The procedure entry point php_unregister_ini_entries could not be located in the 
dynamic link library php4ts.dll.'

dll is dated as 20th Dec 2000, 11:01 same as php.exe and is present in c:php only

Press ok on this box and get...

'Unable to load dynamic library './php_mssql70.dll' - The specified procedure could 
not be found.'

Then get on page:

X-Powered-By: PHP/4.0.4 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: 
no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache 
Content-type: text/html 
Fatal error: Call to undefined function: mssql_connect() in...


I hope that this is enough info to go on.  If I back out to v4.0.2 then everything 
works ok again, but I want to use the file upload stuff in the new version which is 
why I want to upgrade.

Cheers,

David Clark.




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8551&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8557 Updated: apache fails to start after compiling PHP - "can't load libphp4.so"

[sniper]

ID: 8557
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Reproduceable crash
Assigned To: 
Comments:

Did the fix in #4630 help?

--Jani


Previous Comments:
---

[2001-01-07 19:08:05] [EMAIL PROTECTED]
Please try the workaround found in bug report #4630.

--Jani

---

[2001-01-04 17:11:12] [EMAIL PROTECTED]
Configured PHP 4.0.4 on AIX 4.3.3 using IBM C for AIX v.5 
Apache 1.3.9 in /usr/local/etc/apache

Installed via the following:
export CC='cc -Dinline= -ma'
./configure --with-apxs=/usr/local/etc/apache/bin/apxs --with-mysql=/usr/local 
--with-gd=/usr/local --with-ttf  --with-informix
make; make install

everything appears to run fine (with the exception of some small errors about 
unrecognized suffixes), but when I start apache, I get:

[root@p140 php-4.0.4]# /usr/local/etc/apache/bin/apachectl start
Syntax error on line 208 of /usr/local/etc/apache/conf/httpd.conf:
Cannot load /usr/local/etc/apache/libexec/libphp4.so into server: dlopen: 
/usr/local/etc/apache/libexec/libphp4.so: No such file or directory 
/usr/local/etc/apache/bin/apachectl start: httpd could not be started

If I run configure with ONLY the --with-apxs and --with-mysql options, it compiles and 
installs, and apache runs fine.  If I remove --with-informix, same thing.  If I remove 
the --with-gd and related, same thing.

I've set INFORMIXDIR appropriately, and have the informix SDK installed (I've built 
this module successfully in Linux).

I've installed the gd,zlib,libjpeg,and freetype from bull.de, and manually built them 
as well.  No difference.

Apache modules installed:

[root@p140 local]# /usr/local/etc/apache/bin/httpd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_access.c
  mod_auth.c
  mod_so.c
  mod_setenvif.c



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8557&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8561 Updated: memory leak

[sniper]

ID: 8561
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: OCI8 related
Assigned To: 
Comments:

No feedback, should be fixed in CVS.

--Jani


Previous Comments:
---

[2001-01-06 20:34:35] [EMAIL PROTECTED]
Please try the patch in #8573.

--Jani


---

[2001-01-05 04:04:42] [EMAIL PROTECTED]
I dunno whether it's the php memory management's problem, the phplib's problem, or my 
coding's problem. Apparently, I'm facing a memory leak's problem that has no solution 
at all until now. Please help if someone faced the same situation before. 

When I run follow script using OCI8 function, this script use a lot of system memory. 
when a large number of user access this script, the httpd is running extremely wierd 
exactly heap size. The memory usage is kept on increasing without stopping. 

Environment : Oracle8.1.5

script :


command for checking memory : 
pmap -x 26749(pid)

other command for checking memory : 
ps -ef -o pid -o vsz -o rss -o fname -o args | grep httpd | sort

before running above script  : 
26749 10704 4168 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
26752 10704 1808 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
26753 10704 1784 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
26754 10704 1784 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
26755 10704 1784 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
26756 10704 1784 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd

after running above script  :
26749 10704 4168 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
26752 10888 6360 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
26753 10888 6360 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
26754 10888 6360 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
26755 10704 1808 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
26756 10704 1784 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd
28154 10712 1792 libhttpd /H2K/HiTEL2000/webservice/apache/bin/httpd






---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8561&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8709 Updated: endless loop trying to chdir

[sniper]

ID: 8709
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Apache related
Assigned To: 
Comments:

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

--Jani


Previous Comments:
---

[2001-01-15 11:41:32] [EMAIL PROTECTED]
it seems to be related to output buffering.

The script page.html had a ob_start() line and I have 
commented it out and it seems to have stopped 
happening.


Hope this helps

---

[2001-01-15 08:24:44] [EMAIL PROTECTED]
I have several Apache processes that get stuck taking 
all the CPU they can.

A truss -p pid the stuck process shows that apache is 
performing a chdir("/page.html") system call (all html 
files are parsed)
the result is 'Err#2 ENOENT'

This is quite enoying since it makes the machine 
eventualy crash with loads of up to 100.

The file is present, but is located on 
'/export/web/host.domain.com/www/page.html'

I use Apache 1.3.12 with a compiled in PHP module 
and the Zend optimizer for 4.0.3pl1

PHP configure line 
'./configure' '--with-apache=/usr/src/apache2' 
'--with-sybase-ct=/usr/local/freetds' 
'--with-mysql=/usr/local/mysql' 
'--with-zlib-dir=/usr/local/lib' '--enable-debug=no' 
'--enable-track-vars=yes' '--disable-short-tags' 
'--with-xml' '--enable-ftp' '--with-gd=/usr/src/gd-1.8.3' 
'--with-jpeg-dir=/usr/src/jpeg-6b' '--with-mcrypt' 
'--with-pdflib=/usr/local/lib'



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8709&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8630 Updated: impossible to write and read thai language in an oracle database

[sniper]

ID: 8630
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: OCI8 related
Assigned To: 
Comments:

No feedback. If problem still exists with latest CVS snapshot and when those 
environment vars are set, reopen.

--Jani


Previous Comments:
---

[2001-01-11 12:07:40] [EMAIL PROTECTED]
Did you setup all the relevant environment variables
before starting Apache?

Check the manual:
http://www.php.net/manual/ref.oci8.php

--Jani 


---

[2001-01-10 07:05:56] [EMAIL PROTECTED]
I actually front to a major problem using PHP (4.0.2) to insert Thai characters into 
an Oracle 

database. The mail is a little bit long but try to explain many things.

I am using Oracle under Linux RH 6.2 Kernel 2.2.17 recompiled for oracle and Apache 
1.3.12.
A lot of people seems to have the same problem (when they want to insert arabic or 
japanese 

characters) using the same configuration (cf. PHP sites mailing lists / forum).

The problem doesn't seems to be a configuration problem. Oracle is correctly 
configured (I mean 

Thai character set -as oracle told me- and env. variables...) and insertion rules are 
conform to 

Oracle doc. However, all tests have been also made with the UTF-8 character set.

Regarding the tests I have done and information I have gotten from various 
programmers, Oracle 

can definitely store Thai.
Php can display web pages with Thai language (the basic test is to input Thai from a 
html form 

and generate a new web page with what has been input before).

BUT, there is one thing that I don't completly understand:
*) When I sniff the incoming and outgoing information going through the linux 
oracle+web server, 

I can see that the incoming information (posted from a browser) is:
'S Q L = & T H A I = % E 6 % E 4 % D 3 % B E % D 0 % D 1 % D 5 & S u b = S u b m i t'
So this is Hexa. representing ascii code greather than 128 (equiv to 230,228,211... in 
decimal) 

which is Thai characters.

*)If I ask Php to generate a new page with the Thai sentence I have input before, php 
send back 

the ASCII DECIMAL code:
' b r > . s q l : I N S E R T   I N T O   S C O T T . T H A I 2   ( C O L )   V A 
L U E S ( N 

' . . . . . . . ' ) < b r > . s t a t e m e n t   e x e c u t e d < b r >'
NOTE: The dot '.' represent ascii decimal code greather than 127. So a conversion has 
been done 

within php but it works.

*) What is stored in the database is the received ASCII code (230,228,211...) LESS 128 


(102,100,83..). So in oracle, I have a non thai sentence.

The main question is:
Which entity modify the ascii code? Php? Oracle? Apache? all of them will receive this 
mail.

Of course, a solution is to add 128 when you retrieve characters from the database but 
first, 

it's dirty and second, thai sentence can contain numbers ;-)...

I really hope someone can help.
I thank you all in advance,

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8630&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8632 Updated: Error Message

[sniper]

ID: 8632
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Unknown/Other Function
Assigned To: 
Comments:

No feedback.

--Jani


Previous Comments:
---

[2001-01-12 06:00:36] [EMAIL PROTECTED]
is this really the shortest possible script? wouldn't something shorter reproduce the 
bug too? it's quite lengthy, and the easier you make it for developers to locate the 
bug, the sooner it'll get fixed. 

---

[2001-01-10 08:27:12] [EMAIL PROTECTED]
IIS 5 

---

[2001-01-10 08:26:20] [EMAIL PROTECTED]
its only with the ISAPI !!

---

[2001-01-10 08:03:00] [EMAIL PROTECTED]
please, provide the shortest possible script reproducing the behavior. 
is it CGI version of PHP or SAPI version?
also, what web server do you use? 

---

[2001-01-10 07:48:39] [EMAIL PROTECTED]
This Error Message is displayed:

PHP has encountered an Access Violation at 011A527B

Script:


  You should have received a copy of the GNU Public
  License along with this package; if not, write to the
  Free Software Foundation, Inc., 59 Temple Place - Suite 330,
  Boston, MA 02111-1307, USA.

*/

require("./config/owl.php");
require("./config/html.php");
require("./lib/owl.lib");
require("./lib/security.lib");
include("./lib/header.inc");

if(!$parent) $parent = "1";
if(!$expand) $expand = "0";
if(!$order) $order = "name";

if(check_auth($parent, "folder_view", $userid) != "1") {
print($lang_nofolderaccess);
exit;
}

if ($expand == 1) {
print("ttn");
} else {
print("ttn");
}

// **FM**
print("ttt" . $lang_currentdir . "");
print("ttt" . gen_navbar($parent) . "");
//print("ttt" . gen_navbar($parent) . "");

if ($expand == 1) {
print("ttn");
} else {
print("ttn");
}

if ($expand==1) print("");
if ($expand==0) print("");

print("
$lang_addfolder ");
print("
$lang_addfile  ");
if($expand==1) {
print("owl_root_url/locale/$default->owl_lang/graphics/btn_collapse_view.gif'
ttBORDER=0>");
} else {
print("tttowl_root_url/locale/$default->owl_lang/graphics/btn_expand_view.gif'
ttBORDER=0>  n");
}

print("$lang_logout");

if ($expand == 1) {
print("ttt
$lang_title
$lang_file

$lang_size

$lang_postedby

$lang_modified

$lang_actions");
} else {
print("ttt
$lang_title
$lang_file
$lang_size");
}

$sql = new Owl_DB;
if ($order == "creatorid") {
$sql->query("select * from $default->owl_folders_table where parent = 
'$parent' order by $order");
} else {
$sql->query("select * from $default->owl_folders_table where parent = 
'$parent' order by name");
}

while($sql->next_record()) {
print("
" . $sql->f("name") . "
");
if($expand == 1) {
print("
t 


 ");
} else {
print("");
}
}

$sql = new Owl_DB;
$sql->query("select * from $default->owl_files_table where parent = '$parent' order by 
$order");

while($sql->next_record()) {
print("");

$iconfiles = array("html","htm","gif","jpg","bmp","zip","tar","gz");
$choped = split(".", $sql->f("filename"));
$pos = count($choped);
$ext = $choped[$pos-1];
if (preg_grep("/$ext/",$iconfiles)) {
print("");
} else {
print(" ");
}
print($sql->f("name")."".$sql->f("filename")."".gen_filesize($sql->f("size"))."");


if($expand ==1) {

print("".fid_to_creator($sql->f("id"))."".$sql->f("modified")."");

print("
t 





");
$imgfiles = array("jpg","gif");
if (preg_grep("/$ext/", $imgfiles)) {
print("");
}
print("");
} else {
print("");
}
}

print("");

include("./lib/footer.inc");

?>


<-- php.ini --->

[PHP]

;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior.  In order for PHP to
; read it, it must be named 'php.ini'.  PHP looks for it in the current
; working dire

[PHP-DEV] PHP 4.0 Bug #8639 Updated: fopen always return true in some case

[sniper]

ID: 8639
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Unknown/Other Function
Assigned To: 
Comments:

No feedback.

--Jani


Previous Comments:
---

[2001-01-14 06:48:52] [EMAIL PROTECTED]
I've made some changes, fixed a bug and added more detailed
error reporting. Could you try the latest code, either from CVS
or snaps.php.net? I'm interested in the contents of
$http_response_header and any error messages you get.


---

[2001-01-10 15:15:52] [EMAIL PROTECTED]
The problem could be that fopen() currently doesn't support HTTP
redirects. Could you try to do

var_dump($http_response_header);

right after the fopen() call? If the header is a redirect, try to do
fopen() with the new location. If not we'll have to investigate further.
It would be useful to know what $http_response_header contains
anyway.

Stig


---

[2001-01-10 10:49:00] [EMAIL PROTECTED]
It seems that :
$test=@fopen("http://$url/$urlphotos/".$reference."-1.jpg","r");
# (with all vars correct)
always return true (at least with 4.0.4) ?!
Is it because it's a picture ?
Didn't test it with an html file though ...


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8639&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8647 Updated: php.exe exception: access violation address: 0x1008e6a1 on or after file()

[sniper]

ID: 8647
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:

No feedback.

--Jani


Previous Comments:
---

[2001-01-24 19:32:06] [EMAIL PROTECTED]
This (XML related) bug should be fixed in CVS already. Please try the binaries
found at http://www.php4win.de/

--Jani

---

[2001-01-11 15:06:51] [EMAIL PROTECTED]
can you please append some *short* reproducing code?
i tested file() with a file greater than 100k and it didn't crash.

---

[2001-01-10 21:05:56] [EMAIL PROTECTED]
Loading array via file(). File is 4Mb of text. Bang, PHP died.

I increased PHP memory from 8 MB to 20 Mb but did not fix it. I cut the file down to 
about 10Kb but that did not fix it. When I comment out the line containing file(), 
that removes the problem.

I thought it might not be file(), it might be any part of the code that uses the array 
so I commented out file() and inserted statements that manually load the array with 
data. The script ran to completion using the manual array.

gdb backtrace is gobbledygook to me. I am reading your documentation page to see if 
any of it is relevant to Windows environment. If your page helps me change my php 
setup to produce additional diagnostics, I will add them to this report.

Apache is the latest Apache 1.14 or something from about 3 weeks ago. PHP is PHP 4.0.4 
from the large download file. NT 4.0 SP6a running without a hitch for 6 months. The 
code I am working on was working in the middle of last year on a PHP3 downloaded in 
the middle of last year.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8647&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8654 Updated: Servlet.init() for servlet php threw exception

[sniper]

ID: 8654
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Other web server
Assigned To: 
Comments:

No feedback.

--Jani


Previous Comments:
---

[2001-01-11 11:58:53] [EMAIL PROTECTED]
Is libphp4.so installed in your java.library.path? If it isn't, it's throwing the 
exception because it can't find your PHP module. Try putting the library into 
jdk1.3/jre/lib/libphp4.so or any other place where Java knows to look for it and it 
should work.

---

[2001-01-11 10:08:58] [EMAIL PROTECTED]
ENV: Tomcat-4.0-b1,Linux,jdk1.3,PHP 4.0.4. 
This error happens when i access any *.php files.

A Servlet Exception Has Occurred
Exception Report:
javax.servlet.ServletException: Servlet.init() for servlet php threw exception 
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:774)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:227)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:897)
at java.lang.Thread.run(Thread.java:484)

Root Cause:
java.lang.UnsatisfiedLinkError: no php4 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1312)
at java.lang.Runtime.loadLibrary0(Runtime.java:749)
at java.lang.System.loadLibrary(System.java:820)
at net.php.reflect.loadLibrary(reflect.java:34)
at net.php.reflect.(reflect.java:29)
at net.php.servlet.init(servlet.java:131)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:755)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:227)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at 
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
at 
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:897)
at java.lang.Thread.run(Thread.java:484)

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8654&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8668 Updated: Mysql_connect Error!

[sniper]

ID: 8668
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Bogus
Bug Type: MySQL related
Assigned To: 
Comments:

Try latest CVS snapshot. http://snaps.php.net/
(no feedback, not even nearly enough info, bogus)

--Jani


Previous Comments:
---

[2001-01-12 06:14:36] [EMAIL PROTECTED]
The actual error would be great to have in this report..

--Jani

---

[2001-01-12 02:51:22] [EMAIL PROTECTED]
If Mysql use gb2312 charset,Mysql_connect display error:


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8668&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8708 Updated: special chars insertion into oracle / NLS_LANG ?

[sniper]

ID: 8708
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: OCI8 related
Assigned To: 
Comments:

Also try PHP 4.0.4pl1 if setting the environment vars 
doesn't help.

Closed due missing feedback.

--Jani


Previous Comments:
---

[2001-01-15 07:28:31] [EMAIL PROTECTED]
You should set the environment variables in the shell before starting Apache NOT with 
PHP's putenv(). 

--Jani

---

[2001-01-15 07:20:35] [EMAIL PROTECTED]
hi !

this our very painful problem...

we've been able to use php4.O.0 with Oracle 8i and use OCI functions to insert and 
retrieve datas in Our TAbles..

We can't do it no more, as special chars are transformed badly on insert... maybe 
since we installed PHP 4.01 pl2.

Apache config as been checked as well as Oracle.

with php 4.0.0 the virtual host was configured with an special NLS_LANG env. var set 
to the WE8DEC value... wich seems to be very specific and not so usual...

this value is still registerd but can't resolve the problem.

any other script (perl) from anyother source than our web server (www.wappup.com) is 
able to insert proper datas... but our php scripts can't.

we tried to set an environnement variable with php special functions, but it changed 
nothing.

we're in contact with Oracle support but i'm afraid they won't help us...

is there anyone in your brillant team who will send us a solution ???

thanks for all and patience in uncrypting myvery poor english

cusoon("jl barranger");



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8708&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8725 Updated: Fun with putenv

[sniper]

ID: 8725
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Apache related
Assigned To: 
Comments:

User feedback:
--
The latest snapshot made no difference. The behavior I 
describe persists. It's always the third execution of the 
script (second page reload) that produces the failure. By 
the way, at that point not only "exec" stops working, but 
"system" and "passthru" as well. It appears that "putenv" is
the cause, since removing it from the script remedies the 
problem (after apache restart there is).

It's quite possible that the problem is unique to my 
environment:

SCO Opendesktop 5.05
Apache/1.3.14 with mod_php4

but that doesn't make the situation any easier.

Couple of more points:

-- the same script works fine when executed on the shell level
-- every time phtml script fails, the following message is left in access_log: ": is 
not an identifier".

If this matter is of any interest to the developers, I'll be 
more than happy to investigate (with proper guidance :-)) 
further.

Thanks.

-mk


Previous Comments:
---

[2001-01-15 18:04:25] [EMAIL PROTECTED]
I tried your script in my system (Linux) and with the latest CVS of PHP 4 
and it works just fine. Could you try the latest snapshot from http://snaps.php.net/
to verify if this is fixed or if it is your system that causes this.

--Jani

---

[2001-01-15 15:53:11] [EMAIL PROTECTED]
[this is a re-sent of my message, I accidentally inserted php config options in
the wrong place of  my previous message]

Apache: 1.3.14 (with mod_php4 among other)

test.phtml:
");
 print("2: $two[0] ($ret)");
?>

Browser shows:
1: one
2: two (0)

After hitting Reload, browser shows:
1: one
2: two (0)

After hitting Reload again, browser shows:
1: one
Warning: Undefined index: 0 in /u/local/apache/htdocs/test.phtml on line 6
2: (1)

After "apachectl restart"  the above repeats...

Config options:
configure  --with-gd=/usr/local/gd --with-mysql --with-jpeg-dir=/tmp/jpeg-6b
 --with-apache=../apache_1.3.14


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8725&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9664 Updated: Unable to make , related to bug 8468 i think

[yavo]

ID: 9664
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Sockets related
Description: Unable to make , related to bug 8468 i think

No but it's my understanding that this (SOlaris Workishop CC) is a commersial product 
which you have to buy from solaris. I'm right.

-- yavor

Previous Comments:
---

[2001-03-09 20:47:37] [EMAIL PROTECTED]
Ok I'really hate to be a nag, but just finished compiling the latest cvs snapshot, 
it's still the same error. I wonder if im missing a library. Which libs does the 
socket extention use.

BTW Thanks for your so imadiate response.

-- yavo

---

[2001-03-09 20:24:07] [EMAIL PROTECTED]
You're not missing any libraries..FYI: The sockets extension is still EXPERIMENTAL, 
ie. it's not very stable yet. 
This is yet another bug in it. Have you tried compiling it with the Solaris Workshop 
CC ???

--Jani


---

[2001-03-09 20:16:31] [EMAIL PROTECTED]
Ok I'really hate to be a nag, but just finished compiling the latest cvs snapshot, 
it's still the same error. I wonder if im missing a library. Which libs does the 
socket extention use.

BTW Thanks for your so imadiate response.

-- yavo

---

[2001-03-09 20:10:58] [EMAIL PROTECTED]
Yes, you should try with the whole CVS snapshot and 
not try to replace any files from it in PHP 4.0.4.

--Jani


---

[2001-03-09 19:29:22] [EMAIL PROTECTED]
Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=9664


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8778 Updated: Cannot load libphp4.so

[sniper]

ID: 8778
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Apache related
Assigned To: 
Comments:

Is this problem still valid? Have you tried latest CVS snapshot from 
http://snaps.php.net/ ?

--Jani


Previous Comments:
---

[2001-01-18 12:44:53] [EMAIL PROTECTED]
What does ldd say about libphp4.so?
ie.

# ldd /usr/local/apache/libexec/libphp4.so


--Jani

---

[2001-01-18 06:15:33] [EMAIL PROTECTED]
I did the compilation with : 
./configure --with-mysql=/usr/local --with-apxs=/usr/local/apache/bin/apxs 
--with-jpeg-dir --with-gd

and, when I try to start apache, I receive the error:

nvagent3:[/AIX_SOFT/php-4.0.4pl1] # apachectl start
   
Syntax error on line 208 of /usr/local/apache/conf/httpd.conf: 
   
Cannot load /usr/local/apache/libexec/libphp4.so into server: No such file or 
directory   
/usr/local/apache/bin/apachectl start: httpd could not be started  
   

But the file is present.

nvagent3:[/AIX_SOFT/php-4.0.4pl1] # ls -l /usr/local/apache/libexec/libphp4.so 
   
-rwxr-xr-x   1 root system   2118557 Jan 18 10:26 
/usr/local/apache/libexec/libphp4.so


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8778&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #7972 Updated: Segmentation fault

[sniper]

ID: 7972
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:

No feedback.


Previous Comments:
---

[2000-12-28 08:15:34] [EMAIL PROTECTED]
Does this happen with PHP 4.0.4? 
And if it does, please provide a gdb backtrace 
of the crash (remember to configre with --enable-debug first!)

--Jani

---

[2000-11-25 16:16:31] [EMAIL PROTECTED]
When post form in to php script 





... skip ...







---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7972&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #7984 Updated: Apparent memory access problem after object assignment causes PWS to crash

[sniper]

ID: 7984
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:

No feedback.


Previous Comments:
---

[2001-01-08 13:57:52] [EMAIL PROTECTED]
please, provide the shortest possible script reproducing the error.

---

[2000-11-26 21:21:42] [EMAIL PROTECTED]
  This is a _very_ complex script that heavily uses objects.  The first few lines
are the web page printout.  The next lines are the function that crashes the system.
It uses mysql and PWS on win98. ( It will later be used on linux.  It is GPL, and is
a distributive monitoring system.) PWS crashes consistently at this point, and must be 
restarted.
every few times, the win98 machine must be rebooted.

  the array_walk function is being called:

  array_walk($TestActionResult,"CheckTestActionResult");

  The object definitions are:

   class MySQLPollConfig 
  {
  var $configured; // if TRUE, this is configured   
  var $MySQLConnect; 
  var $poll_rate; 
  var $MySQLConnectCount;
  function MySQLPollConfig()
 {
 $this->configured = FALSE;
 $this->poll_rate = FALSE;
 $this->MySQLConnect = 0;
 $this->MySQLConnectCount = 0;
 }
  };

   class AlarmInfoClass
  {
   var $HistoryID; // the ID in the History table
   var $AlarmState;// the alarm id found
   var $Status;// the current status ID of the alarm
   var $Type; // type, either Success or Fail
   var $MachineID; // the machine that the alarm belongs to
   var $New; // if TRUE, this was just updated with new info
   var $ID;  // if in the database, this ID is non-zero
   var $ServiceID; // the id of the service involved
   function AlarmInfoClass()
 {// make sure all variables exist
 $this->HistoryID=0;
 $this->AlarmState=0;
 $this->Status=0;
 $this->Type=0;
 $this->MachineID=0;
 $this->New=FALSE;
 $this->ID=0;
 $this->ServiceID=0;
 }
   };

   class ActionResultClass
  {
  var $ServiceID;
  var $MonitoredMachineID;
  var $Result;  
  function ActionResultClass()
 {
 $this->ServiceID=0;
 $this->MonitoredMachineID=0;
 $this->Result = 0;
 }
  };

-
the web page output.
--
   
MoM execution test page  
 MoM  



  

 
GetServiceInfo: No value for $MMValue->FKServiceID
GetTestActionInfo(0,0,Resource id #2): No value for FKServiceID
Error in Database!! No Service Entries scanned!
->defining debug in file mom.c at line 226
Function==MonitorMachines file momact.c line 323
walking MonitoredMachineArray
Function==RunTestAction(0, 0): file momact.c line 139
RunTestAction: No value for $MMValue->FKServiceID in file momact.c, line 146
Function==RunTestAction(Object, 2): file momact.c line 139
Function==RunAction(4,2) file momact.c line 71
Running PHP Command String
$ExecString="echo "Test Sendmail!n";  return(SUCCESS);"
Test Sendmail!
$Result="1"
$TestActionResult["4"]=RunAction($ActionID,$MMKey)$ActionID = 4
---
For Object 'TesActionResult':
ServiceID -> 1
MonitoredMachineID -> 2
Result -> 1
---
walking TestActionArray
Function==CheckTestActionResult(0,0) file momact.c line 198
Key 0 not used
Function==CheckTestActionResult(Object,4) file momact.c line 198
key 4 for object Object
---
For Object 'ActionResult ($ARValue)':
ServiceID -> 1
MonitoredMachineID -> 2
Result -> 1
---
new action result!
$Alarm was NOT set
---
For Object 'ActionResult':
ServiceID -> 1


''
web page ended at last line before blank line




function CheckTestActionResult($ARValue,$ARKey)
{
   global $MySQLConfig; // the mysql configurationinfo
   global $AlarmType;
   global $StatusType;
   global $Service;
   global $Alarm;
   global $LastActionResult;
   global $LastAlarm; 
   global $TestActionResult;

  if (defined("DEBUG"))
 print("Function==CheckTestActionResult($ARValue,$ARKey) file ".__FILE__." 
line ".__LINE__."n"); 
  
  if ($ARKey == 0)
   {
   if (defined("DEBUG"))
  echo "Key 0 not usedn";
   return;
   }
  else
   if (defined("DEBUG"))
  echo "key $ARKey for object $ARValuen";


  if (defined("DEBUG"))
   DisplayObject($ARValue,"ActionResult ($ARValue)");
  
   
  $DoWork = FALSE;


   
  if (!isset($LastActionResult["$AR

[PHP-DEV] PHP 4.0 Bug #8067 Updated: OCI8 and Apache bug with: exec, system, passthru and backticks

[sniper]

ID: 8067
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Program Execution
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2001-03-09 20:56:46] [EMAIL PROTECTED]
No feedback, not enough info, closed.

--Jani

---

[2000-12-21 19:25:50] [EMAIL PROTECTED]
btw. What was the configure line you used to configure php ??

--Jani

---

[2000-12-20 19:05:01] [EMAIL PROTECTED]
Could you please try PHP 4.0.4 to check if this happens with it too.
I'm using it and I have oci8 enabled, and e.g. exec() works just fine.

--Jani

---

[2000-12-19 18:58:52] [EMAIL PROTECTED]
When you have the module for OCI 8 installed (preappended) the functions do not work. 

When the module is not install, then the functions do work.

To see the problem you have to have libclntsh.so loaded at the time apache starts, and 
then try running any of the program execution functions.

They did not work for me, under this conditions. 

---

[2000-12-15 20:33:31] [EMAIL PROTECTED]
What do you mean by 'preappended to apache' ??
These functions work just fine for me.

--Jani

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8067&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8067 Updated: OCI8 and Apache bug with: exec, system, passthru and backticks

[sniper]

ID: 8067
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Program Execution
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2000-12-21 19:25:50] [EMAIL PROTECTED]
btw. What was the configure line you used to configure php ??

--Jani

---

[2000-12-20 19:05:01] [EMAIL PROTECTED]
Could you please try PHP 4.0.4 to check if this happens with it too.
I'm using it and I have oci8 enabled, and e.g. exec() works just fine.

--Jani

---

[2000-12-19 18:58:52] [EMAIL PROTECTED]
When you have the module for OCI 8 installed (preappended) the functions do not work. 

When the module is not install, then the functions do work.

To see the problem you have to have libclntsh.so loaded at the time apache starts, and 
then try running any of the program execution functions.

They did not work for me, under this conditions. 

---

[2000-12-15 20:33:31] [EMAIL PROTECTED]
What do you mean by 'preappended to apache' ??
These functions work just fine for me.

--Jani

---

[2000-11-30 21:59:15] [EMAIL PROTECTED]
The functions that perform program executions, do not work when libclntsh.so is 
preappended to apache, and Oracle and Apache will not run without that library as 
everyone know. 





---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8067&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8082 Updated: cgi error with php.exe

[sniper]

ID: 8082
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: IIS related
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2001-01-12 13:02:44] [EMAIL PROTECTED]
could you please provide a short but complete script that produces this behavior?
also, please read http://bugs.php.net/bugs-dos-and-donts.php

---

[2000-12-02 21:35:18] [EMAIL PROTECTED]
i get this message in irregular intervals. its not a bug in the script cause when i 
refresh the site, all is ok. i think that php crashes while executing the script but i 
have no possibility to find the reason why.

Error:

CGI Error
The specified CGI application misbehaved by not returning a
complete set of
HTTP headers. The headers it did return are:

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8082&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8091 Updated: Segfaulting apache with passthru

[sniper]

ID: 8091
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:

No feedback.


Previous Comments:
---

[2001-01-07 18:54:25] [EMAIL PROTECTED]
Does this happen with latest snapshot from http://snaps.php.net/ ??

--Jani

---

[2000-12-04 05:50:49] [EMAIL PROTECTED]
Hi

I have a script which displays executes 15 times passthru to include the output of a 
perlscript.

passthru("perl scripts/calc.pl $file");

The apache child that executes this dies with a segfault

I use debian unstable with the latest version of php4

Jacob



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8091&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8105 Updated: session_register drops inner object

[sniper]

ID: 8105
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Session related
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2000-12-30 19:26:06] [EMAIL PROTECTED]
Have you tried PHP 4.0.4? Does this work when using it?

--Jani

---

[2000-12-05 07:41:32] [EMAIL PROTECTED]
Could you please try latest snapshot from 
http://snaps.php.net/ ??

--Jani

---

[2000-12-04 17:19:40] [EMAIL PROTECTED]
When I have an object that I register to a session, it first describes the variable 
name, then the name of the class from which it was instantiated, and finally the 
property names and values for any of that objects properties.

A problem  exists when you try to register an object which has a different one nested 
within it.  In this case, no mention of the inner object is registered, and the next 
time you attempt to call it, you get an error message of trying to call a method of a 
undeclared object.

Ex:
=
file class.test.php
fname=$fname;
$this->lname=$lname;
}

function x() {
return $this->inner->get_name($this->fname,$this->lname);
}
}
?>
=
file test1.html:




=
file test2.html:

fname."";
echo "LAST_NAME: ".$testClass->lname."";
echo "FULL_NAME: ".$testClass->x()."";
?>




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8105&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8131 Updated: Access Violation with php4isapi

[sniper]

ID: 8131
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2001-01-06 03:55:47] [EMAIL PROTECTED]
Provide a short script causing the crash.

---

[2000-12-05 22:11:09] [EMAIL PROTECTED]
PHP has encountered an Access Violation at 040B3609

I get that screen when I use the url

http://fidome.warnerstreet.net/php4isapi.dll

the isapi module is loaded as a handler

php4isapi is in my document root

I know the documentation says the plug-in is buggy.  I was hoping there was some way 
to run it that way anyway.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8131&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8153 Updated: ora-12154 problem

[sniper]

ID: 8153
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: OCI8 related
Assigned To: 
Comments:

No feedback.


Previous Comments:
---

[2001-01-30 04:46:26] [EMAIL PROTECTED]
Have you set the required environment vars mentioned
at http://www.php.net/oci8 ??

--Jani


---

[2000-12-07 04:46:42] [EMAIL PROTECTED]
Warning: _oci_open_server: Error while trying to retrieve text for error ORA-12154 in 
/home/httpd/html/webcalendar/includes/php-dbi.inc on line 51
Error connecting to database:

 Unknown error

this my error my tnsnames.ora function well 
i have a client oracle 8.0.5, php 4.0.3, apache but nothing gone 
i can access to my database by sqlplus but never with my phpcode why??
id o everything u tell me but this doesn't work at all
 

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8153&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8154 Updated: failed to compile

[sniper]

ID: 8154
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Compile Failure
Assigned To: 
Comments:

No feedback, considered fixed.



Previous Comments:
---

[2000-12-18 11:07:51] [EMAIL PROTECTED]
Does this happen with latest snapshot from http://snaps.php.net/ ??

--Jani

---

[2000-12-07 05:24:43] [EMAIL PROTECTED]
configure:
  ./configure (only the apache was included)

OS:
  AIX 4.3

Used:
  C for AIX Compiler, Version 5

Message when trying to start make:

zend_extensions.c
"zend_extensions.c", line 50.16: 1506-068 (S) Operation between types "void*" and 
"int" is not allow
ed.
make: The error code from the last command is 1.



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8154&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8158 Updated: unable to find math.h when doing a make

[sniper]

ID: 8158
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Install and Config
Assigned To: 
Comments:

No feedback.


Previous Comments:
---

[2001-01-04 13:09:43] [EMAIL PROTECTED]
What was the configure line used? 
Have you tried PHP 4.0.4?
And I think this is more like problem with your system 
than with PHP.

--Jani

---

[2000-12-11 13:31:44] [EMAIL PROTECTED]
Okay, I downloaded and configured the php-4.200012080445 build, and got the same 
error. It looks like it's related to how the OS and gcc compiler is set up (I'm still 
trying to bring myself up to speed on Solaris :) )?  I'm configuring the package via 
./configure --with-mysql --with-apxs (trying to create dynamic module for apache) - do 
I need to specify the location of the math.h file?



---

[2000-12-11 11:20:28] [EMAIL PROTECTED]
Okay, I downloaded and configured the php-4.200012080445 build, and got the same 
error. It looks like it's related to how the OS and gcc compiler is set up (I'm still 
trying to bring myself up to speed on Solaris :) )?  I'm configuring the package via 
./configure --with-mysql --with-apxs (trying to create dynamic module for apache) - do 
I need to specify the location of the math.h file?



---

[2000-12-07 18:59:43] [EMAIL PROTECTED]
Please try latest snapshot from http://snaps.php.net/
And if it still doesn't work, please add your configure line into this bug report too.

--Jani

---

[2000-12-07 09:32:53] [EMAIL PROTECTED]
When trying to do a make after compiling, I get the following error message :
Making all in Zend
make[1]: Entering directory `/temp/php-4.0.3pl1/Zend'
/bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..   -D
_POSIX_PTHREAD_SEMANTICS -DXML_BYTE_ORDER=21  -g -O2 -c zend-scanner.c
In file included from ../math.h:5,
 from ../php_config.h:1692,
 from zend_config.h:1,
 from zend.h:43,
 from zend-scanner.c:2620:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95/include/math.h:5: math.h: No such 
file or directory
make[1]: *** [zend-scanner.lo] Error 1
make[1]: Leaving directory `/temp/php-4.0.3pl1/Zend'
make: *** [all-recursive] Error 1

So then I created a soft link to this file in /usr/include/, and get the following :

Making all in Zend
make[1]: Entering directory `/temp/php-4.0.3pl1/Zend'
/bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..   -D
_POSIX_PTHREAD_SEMANTICS -DXML_BYTE_ORDER=21  -g -O2 -c zend-scanner.c
In file included from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95/include/m
ath.h:5,
 from ../math.h:5,
 from ../php_config.h:1692,
 from zend_config.h:1,
 from zend.h:43,
 from zend-scanner.c:2620:
/usr/include/math.h:5: No include path in which to find math.h
make[1]: *** [zend-scanner.lo] Error 1
make[1]: Leaving directory `/temp/php-4.0.3pl1/Zend'
make: *** [all-recursive] Error 1

   Which looks like it can't find the math.h file in the gcc-lib/include directory - 
but the file is in the directory where it is looking?

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8158&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8175 Updated: reproducable core with everything:

[sniper]

ID: 8175
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:

No feedback.

Previous Comments:
---

[2000-12-15 10:04:34] [EMAIL PROTECTED]
Please try the latest RC from http://www.php.net/distributions/

to see if this happens with it too.

--Jani

---

[2000-12-11 22:12:51] [EMAIL PROTECTED]
I tried
php-4.0.4RC4
but I'm not able to build it correctly:-(
Actually it builds but when I try to run apacheit reports a missing symbol:-(

marcow@jena:~/usr/apache-1>bin/httpd -t
Syntax error on line 239 of /export/home/marcow/usr/apache-1/conf/httpd.conf:
Cannot load /export/home/marcow/usr/apache-1/libexec/libphp4.so into server: ld.so.1: 
bin/httpd: fatal: relocation error: file 
/export/home/marcow/usr/apache-1/libexec/libphp4.so: symbol php_if_stat64: referenced 
symbol not found

Since I could not find this symbol in any *.[hc] files I tried the following:
marcow@jena:apache/php-4.0.4RC4>for i in `find . -name '*.o' -o -name '*.lo'` 
> do
> nm $i | fgrep php_if_stat64 && echo $i
> done
 U php_if_stat64
./ext/standard/basic_functions.lo

I don't know how this symbol ends up there.

Thanks,
-- Marco

---

[2000-12-11 20:12:28] [EMAIL PROTECTED]
It means that the next release most propably will work too.
You can get the latest release candidate for PHP4.0.4 from here:

http://www.php.net/distributions/php-4.0.4RC4.tar.gz

It might be a good thing to try that too...just to be sure that 
it really works for you too. But if it doesn't or this bug exists also
in PHP 4.0.4, please reopen this bug report. 

--Jani


---

[2000-12-11 13:47:19] [EMAIL PROTECTED]
Ok,
the latest snapshot works:
php4-200012110945

But I still leave this bug open because I don't know yet what's the
difference. I basically don't want to drag the dev tree every day:-(

Thanks for your fast response.
-- Marco

---

[2000-12-11 10:57:34] [EMAIL PROTECTED]
Please try the latest snapshot from http://snaps.php.net/
I have used php within same system and apache
without any problems. Compiled with same version of gcc.

If you still get this crash with the latest snapshot,
please include a gdb backtrace of it. Remember to configure
php with --enable-debug to get useful backtrace.

--Jani


---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8175&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8190 Updated: Crash on parse error

[sniper]

ID: 8190
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:

No feedback.

--Jani


Previous Comments:
---

[2000-12-15 09:59:39] [EMAIL PROTECTED]
I can not reproduce this with latest CVs.
Try updating CVS.

--Jani

---

[2000-12-10 21:44:20] [EMAIL PROTECTED]
httpd will die if there's a parse error in the code. An example is a missing 
semi-colon. Here is what happens when its run inside GDB:

(gdb) run
Starting program: /www/bin/httpd -X
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols 
found)...
Program received signal SIGSEGV, Segmentation fault.
0x182dce05 in _zval_ptr_dtor () at zend_execute_API.c:102
102 return(ce->type != ZEND_INTERNAL_CLASS);

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8190&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8192 Updated: CRASH ON IISXX AND PHP4 AND MYSQL 3.23.XX

[sniper]

ID: 8192
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Reproduceable crash
Assigned To: 
Comments:

No feedback. 

--Jani


Previous Comments:
---

[2001-01-09 15:03:10] [EMAIL PROTECTED]
does this still happen with 4.0.4?

can you provide a short script reproducing the behavior? what do mean by 'THE SERVER 
MYSQL SHUTDOWN
IMMEDIATELY'? the MySQL server stops upon a query from PHP?

---

[2000-12-11 09:29:16] [EMAIL PROTECTED]
ON NT OR WIN 2000 WITH IIS4 OR IIS5 ON THE SAME SERVER WHERE THERE ARE:
IIS
PHP 4 RELEASE (I TRY 4.0 --> 4.02)
AND MYSQL (I TRY 3.23.22 --> 3.23.29)

WHEN PHP CALL MYSQL DATA (WITH NATIVE MYSQL FUNCTION) THE SERVER MYSQL SHUTDOWN 
IMMEDIATELY. 
NO ERROR ARE VISIBLE
I TRY ON SEVERAL SERVER (WITH NT4 AND MYSQL --- WITH WIN2000 AND MYSQL). THIS PROBLEM 
STARTED WITH RELEASE 3.23.XX. (NOTE THAT WITH REL 3.22.XX IT WORKS)
I CAN'T UNDESTAND WHY IIS AND PHP AND MYSQL ON TEH SAME SERVER DON'T WORK WELL WHILE 
IF YOU INSTALL THE SAME RELEASE OF MYSQL ON A LINUX PLATFORM IT WORKS.
NOTE THAT MYSQL WORKS WERY WELL VIA ODBC WITH ACCESS AND HAVE NO PROBLEMS.

THANKS A LOT.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8192&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8200 Updated: /usr/local/libexec/apache/libphp4.so: Undefined symbol "rfc822_parse_msg"

[sniper]

ID: 8200
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Bogus
Bug Type: Apache related
Assigned To: 
Comments:

Not enough info.


Previous Comments:
---

[2000-12-15 09:29:50] [EMAIL PROTECTED]
And what was the c-client version?

--Jani

---

[2000-12-12 05:08:22] [EMAIL PROTECTED]
What was your configure line for PHP?

---

[2000-12-11 18:47:23] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8200&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8232 Updated: 12154 oci_open_server

[sniper]

ID: 8232
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: OCI8 related
Assigned To: 
Comments:

No feedback.

--Jani


Previous Comments:
---

[2001-01-30 04:47:19] [EMAIL PROTECTED]
Try setting the required environment vars mentioned
at http://www.php.net/oci8

--Jani


---

[2000-12-13 10:25:25] [EMAIL PROTECTED]
i have windows2000 server, iis5.0, oracle client 8.0.5 and php 4.0.3pl1
i have oci8 and oracle installed 
i can access to oracle by sqlplus and sqlnet

tnsnames.ora is ok
sqlnet.ora is ok
when i do phpinfo() , coi8, oracle installed


but i have this error
Warning: _oci_open_server: ORA-12154: TNS:l'adresse symbolique n'a pas pu être résolue 
in includes/php-dbi.inc on line 50
Error connecting to database:

 Unknown error

thanx for your help because i don't know why i may do now?


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8232&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: Jeroen van Wolffelaar
Email: [EMAIL PROTECTED]
ID: jeroen
Purpose: update phpdoc - language/types/, mainly \'array\'

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8234 Updated: Unable to resolve DL_UNLOAD (dlclose)

[sniper]

ID: 8234
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Compile Failure
Assigned To: 
Comments:

No feedback. Considered fixed.

--Jani


Previous Comments:
---

[2001-01-02 09:01:19] [EMAIL PROTECTED]
Please try PHP 4.0.4 as this should be fixed.

--Jani

---

[2000-12-13 10:30:23] [EMAIL PROTECTED]
On HP-UX 11.0, I use gcc for linking with Apache 1.3.14.  Our application needs to be 
compiled to run on both 64 bit and 32 bit machines.  When I run make for php, I get an 
error that DL_UNLOAD cannot be resolved.  Having gone through some HP investigation, 
that symbol (actually dlcose is what DL_UNLOAD is defined as), I found that it is only 
located in a 64-bit libdl.sl library.  I cannot use that.

So, is there a -- option I can specify to not have the dl routines be used?  Is there 
some 32 bit solution here that I am missing?  The trouble seems to stem from the 
ext/java/java.c module and perhaps the Zend module.

Here is the link statement with apache:
gcc  -DHPUX11 -DMOD_SSL=207101 -I/home/mraine/apache/php-4.0.3pl1 
-I/home/mraine/apache/php-4.0.3pl1/main 
-I/home/mraine/apache/php-4.0.3pl1/main 
-I/home/mraine/apache/php-4.0.3pl1/Zend 
-I/home/mraine/apache/php-4.0.3pl1/Zend 
-I/home/mraine/apache/php-4.0.3pl1/TSRM 
-I/home/mraine/apache/php-4.0.3pl1/TSRM 
-I/home/mraine/apache/php-4.0.3pl1 -DEAPI -DUSE_EXPAT 
-I./lib/expat-lite -DNO_DL_NEEDED -DNO_IDEA 
`./apaci` -L/usr/local/ssl/lib   
-o httpd buildmark.o modules.o 
modules/extra/libextra.a modules/proxy/libproxy.a 
modules/ssl/libssl.a modules/php4/libphp4.a 
modules/standard/libstandard.a main/libmain.a 
./os/unix/libos.a ap/libap.a  lib/expat-lite/libexpat.a 
/home/mraine/apache/libcbinfsql.a -L/informix/runtm/lib 
-L/informix/runtm/lib/esql 
-L/home/mraine/apache/php-4.0.3pl1/ext/informix  
-L/informix/runtm/lib -L/informix/runtm/lib/esql 
-L/home/mraine/apache/php-4.0.3pl1/ext/informix 
-Lmodules/php4 -L../modules/php4 -L../../modules/php4 
-lmodphp4  -lpam  -lm -lcrypt -lnsl  -lixsql -lixasf 
-lixgen -lixos -lixgls -lnsl_s -lV3 -lcl -lsec 
-lphp_ifx -lixglx   -lm -lpthread  -ldbm -lssl -lcrypto 

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8234&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8235 Updated: session_id parameter doesn't work

[sniper]

ID: 8235
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Session related
Assigned To: 
Comments:

No feedback.

--Jani


Previous Comments:
---

[2000-12-15 08:54:32] [EMAIL PROTECTED]
What did you expect to happen here?
Ie. WHAT doesn't work??

--Jani

---

[2000-12-13 12:38:46] [EMAIL PROTECTED]
session_id parameter doesn't work

session_id($thatOne);

does NOTHING!!!

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8235&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8238 Updated: crypt() fails

[sniper]

ID: 8238
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Configuration Issues
Assigned To: 
Comments:

This should be fixed in CVS.

--Jani


Previous Comments:
---

[2001-01-05 22:47:25] [EMAIL PROTECTED]
Why do you need to set those before configure? Why not adding the correct
install dirs for the different --with-options ? And I don't see any --with-openssl
in you configure line..

--Jani

---

[2000-12-13 14:11:14] [EMAIL PROTECTED]
When php is linked with openssl (specifically the -lcrypto library) crypt() fails to 
use the MD5 (12char $1$...$ salts) algorith and is only able to return DES crypted 
strings.

The configure command used to build php is:

PROG_SENDMAIL=/usr/local/sbin/sendmail 
CPPFLAGS="-I/usr/local/devel/gd/include 
  -I/usr/local/security/openssl/include 
  -I/usr/local/devel/zlib/include 
  -I/usr/local/devel/libpng/include 
  -I/usr/local/devel/gdbm/include" 
LIBS="-L/usr/local/devel/gd/lib 
  -L/usr/local/security/openssl/lib 
  -L/usr/local/devel/zlib/lib 
  -L/usr/local/devel/libpng/lib 
  -L/usr/local/devel/gdbm/lib 
  -L/usr/local/support/flex/lib" 
  ./configure 
--prefix=/usr/local/services/apache-1.3.14 
--with-config-file-path=/usr/local/services/apache-1.3.14/conf 
--with-apache=../apache-1.3.14 
--with-gnu-ld 
--with-exec-dir=/usr/local/services/apache-1.3.14/exec 
--with-mysql=/usr/local/services/mysql 
--with-imap=/usr/local/devel/c-client 
--with-gdbm=/usr/local/devel/gdbm 
--with-zlib=/usr/local/devel/zlib 
--with-gd=/usr/local/devel/gd 
--with-jpeg-dir=/usr/local/devel/jpeg 
--with-png-dir=/usr/local/devel/libpng 
--with-zlib-dir=/usr/local/devel/zlib 
--with-gettext=/usr/local/devel/gettext 
--with-ldap=/usr/local/services/openldap 
--with-imap-ssl 
--enable-sockets 
--enable-ftp 
--enable-trans-sid 
--enable-track-vars 
--enable-url-includes

Removing -L.../openssl/lib and -I.../openssl/include allows for MD5 crypted strings.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8238&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9664 Updated: Unable to make , related to bug 8468 i think

[yavo]

ID: 9664
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Sockets related
Description: Unable to make , related to bug 8468 i think

Ok I'really hate to be a nag, but just finished compiling the latest cvs snapshot, 
it's still the same error. I wonder if im missing a library. Which libs does the 
socket extention use.

BTW Thanks for your so imadiate response.

-- yavo

Previous Comments:
---

[2001-03-09 20:24:07] [EMAIL PROTECTED]
You're not missing any libraries..FYI: The sockets extension is still EXPERIMENTAL, 
ie. it's not very stable yet. 
This is yet another bug in it. Have you tried compiling it with the Solaris Workshop 
CC ???

--Jani


---

[2001-03-09 20:16:31] [EMAIL PROTECTED]
Ok I'really hate to be a nag, but just finished compiling the latest cvs snapshot, 
it's still the same error. I wonder if im missing a library. Which libs does the 
socket extention use.

BTW Thanks for your so imadiate response.

-- yavo

---

[2001-03-09 20:10:58] [EMAIL PROTECTED]
Yes, you should try with the whole CVS snapshot and 
not try to replace any files from it in PHP 4.0.4.

--Jani


---

[2001-03-09 19:29:22] [EMAIL PROTECTED]
Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

---

[2001-03-09 19:28:59] [EMAIL PROTECTED]
Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=9664


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8264 Updated: checkdnsrr and getmxrr always return true

[sniper]

ID: 8264
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Network Functions
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2000-12-15 08:21:13] [EMAIL PROTECTED]
I can not reproduce this with latest CVS.
Could you please try it: http://snaps.php.net/
And if it doesn't work either, please include
a short script which can be used to reproduce this.

--Jani

---

[2000-12-14 18:02:54] [EMAIL PROTECTED]
Using te function on http://www.php.net/manual/function.checkdnsrr.php

I try to check an email: [EMAIL PROTECTED]

Now whatever strange kind of domain I try, the getmxrr always returns true! The same 
goes for checkdnsrr.

Fanky



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8264&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8273 Updated: Can't submit a form with 50 tag

[sniper]

ID: 8273
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: HTTP related
Assigned To: 
Comments:

This is fixed.

--Jani


Previous Comments:
---

[2000-12-15 11:15:49] [EMAIL PROTECTED]
Please try the latest RC of PHP4.0.4
from http://www.php.net/distributions/ as someone
(in #7218) reported this should be fixed already.

--Jani

---

[2000-12-15 11:07:50] [EMAIL PROTECTED]
Have you tried with less than 50 ? Does it work then?
And I assume you did put different names for them?
ie. like this :

where X is number between 1-50 ?

--Jani

---

[2000-12-15 04:54:23] [EMAIL PROTECTED]
When submitting a form (post / enctype multipart/fom-data),
with 50 file input tags,
i obtain this warning message :


Warning: File Upload Mime headers garbled ptr: [ in Unknown on line 0


any ideas ?


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8273&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8278 Updated: libmain.al(main.lo) in archive is not object

[sniper]

ID: 8278
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Compile Failure
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2000-12-18 08:24:33] [EMAIL PROTECTED]
Try doing this:

1. delete config.cache
2. reconfigure 
3. # make clean ; make depend ; make

--Jani

---

[2000-12-15 10:54:30] [EMAIL PROTECTED]
Configuration executed as follows:
  ./configure --enable-track-vars 
  --enable-trans-sid 
  --with-mysql 
  --disable-debug 
  --with-apxs 
  --enable-versioning

It configures ok, but when make is executed this error is given:

main/.libs/libmain.al: object main/.libs/libmain.al(main.lo)
in archive is not object
collect2: ld returned 1 exit status
make[1]: ***[libphp4.la] Error 1
make[1]: Leaving directory `/.../php-4.0.3pl1´
make: ***[all-recursive] Error 1

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8278&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8280 Updated: Segmentation violation

[sniper]

ID: 8280
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Unknown/Other Function
Assigned To: 
Comments:

No feedback.


--Jani

Previous Comments:
---

[2001-01-13 13:42:33] [EMAIL PROTECTED]
have you tried that with socket support enabled? did it help?

---

[2000-12-29 03:22:18] [EMAIL PROTECTED]
I tried to make the same with a class with a constructor and the problem was the same.

Maybe, it's because I didn't enable the socket support when I configured my apache 
with php4 with support to Java?

---

[2000-12-28 13:35:13] [EMAIL PROTECTED]
I'm not sure but I think new Java("name") is designed to invoke a constructor (not a 
standalone class that contains a main() function).

---

[2000-12-15 11:14:12] [EMAIL PROTECTED]
hi guys,

I have a problem when i try to call a java class from PHP code.

The problem is the following:
I have a weblogic server that server me EJB, I try to call
an EJB from this weblogic server that is in another machine, but always that I try to 
call the function "", that is necessary to call EJB.

The source of the java client code is:

/
/
package test;

import javax.ejb.*;
import javax.naming.*;
import java.util.*;

public class TestProxyPHPClient
{
public static void main(String[] args)
{
if (args != null && args.length > 0) {
for (int i = 0; i < args.length; i++) {
switch(i) {
case 0:
url = args[i];
break;
case 1:
user = args[i];
break;
case 2:
password = args[i];
break;
default:
}
}
}

try {
Context ctx = getInitialContext();
TestProxyPHPHome home = (TestProxyPHPHome) 
ctx.lookup("TestProxyPHP");
TestProxyPHP the_ejb = home.create();
//System.out.println("the_ejb = " + the_ejb.toString());

// to do: call business methods
System.out.println(the_ejb.getHello());

the_ejb.remove();
}
catch (Exception e) {
e.printStackTrace();
}
}

public static Context getInitialContext()
throws NamingException
{
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, 
"weblogic.jndi.TengahInitialContextFactory");
p.put(Context.PROVIDER_URL, url);

if (user != null) {
p.put(Context.SECURITY_PRINCIPAL, user);
if (password == null)
password = "";
p.put(Context.SECURITY_CREDENTIALS, password);
}
return new InitialContext(p);
}

public String getHello() throws Exception
{
  String result;
Context ctx = getInitialContext();
test.TestProxyPHPHome home = (test.TestProxyPHPHome) 
ctx.lookup("TestProxyPHP");
test.TestProxyPHP the_ejb = home.create();
//System.out.println("the_ejb = " + the_ejb.toString());

// to do: call business methods
result = the_ejb.getHello();
the_ejb.remove();
return result;

  //throw new Exception();
  //return "Hola";
}

static String url = "t3://192.168.7.20:7601";
static String user = null;
static String password = null;

}

/
/


The apache server give me this error in the error_log:





SIGSEGV   11*  segmentation violation
si_signo [11]: SIGSEGV   11*  segmentation violation
si_errno [0]: Success
si_code [0]: SI_USER [pid: 0, uid: 0]
stackpointer=0xbfffd564

[PHP-DEV] PHP 4.0 Bug #8304 Updated: Lost data when write in file

[sniper]

ID: 8304
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Session related
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2000-12-18 08:22:13] [EMAIL PROTECTED]
Could you please try the PHP 4.0.4RC6 from 

http://www.php.net/distributions/ 

to see if this happens with it too..

--Jani

---

[2000-12-17 12:37:37] [EMAIL PROTECTED]
Sometimes happens a problem when the PHP saves variables into session file. When this 
occurs, I lost all data for my session.. the session file became with 0 bytes.. the 
message error is:
Warning: open(../sessao/sess_fmattos, O_RDWR) failed: m (13) in 
betaclientshomeportuguesemsed.php on line 4

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8304&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8316 Updated: cannot set short_open_tags to off

[sniper]

ID: 8316
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Configuration Issues
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2000-12-18 17:22:59] [EMAIL PROTECTED]
Try this instead (in php.ini):

short_open_tag = Off

And are you sure the php.ini file gets read??
The configure option is not yet used anywhere so that won't help.

--Jani

---

[2000-12-18 14:38:53] [EMAIL PROTECTED]
I simply cannot turn off "short_open_tags" I have tried several different ways in the 
config file

short_open_tags = off
short_open_tags = Off
short_open_tags = No
short_open_tags = 0

and also compiling with

--disable-short-tags

it still processes with short open tags on. This is quite disabling if you are working 
with XML documents (XHTML 1.0)

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8316&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8327 Updated: Son of Defect 4155: X-Powered-By and Content-Type bogus headers resurfacing

[sniper]

ID: 8327
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Install and Config
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani

Previous Comments:
---

[2001-01-04 13:37:37] [EMAIL PROTECTED]
Have you tried PHP 4.0.4 ? Does this happen with it?

--Jani

---

[2000-12-19 21:52:27] [EMAIL PROTECTED]
Win2K/Apache 1.3.14/PHP 4.0.1pl1/MySQL 3.23.28-gamma

Problem: The Content-Type and (optional) X-Powered-By headers are preceded by a blank 
line, causing the browser to believe them part of the document rather than headers.  
This appears to be tied to the old bug where this behavior was tied to whether the 
MySQL module was being loaded; now that MySQL support is compiled in by default (at 
least on the Win32 binaries), the defect is always exercised.

Examle input source:


Testing


Testing!n" );
phpinfo();
?>



Output for example:

Content-type: text/html


Testing



Testing!






---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8327&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8347 Updated: /usr/local/apache/bin/apachectl start: httpd could not be started

[sniper]

ID: 8347
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Apache related
Assigned To: 
Comments:

No feedback, not enough info, closed.

--Jani


Previous Comments:
---

[2000-12-21 05:47:49] [EMAIL PROTECTED]
Does it give any error messages? What about error_log?
Could you try using --enable-debug=yes and recompile
and generate a gdb backtrace and it here. 
Have you tried leaving --enable-memory-limit out?

--Jani

---

[2000-12-21 02:05:56] [EMAIL PROTECTED]
/usr/local/apache/bin/apachectl start: httpd could not be started, and generates a 
"core".

Version of my Sybase ASE is 11.9.2.

Configuration likes following:

./configure 
--with-apache=../apache_1.3.14 
--with-mysql 
--with-sybase-ct=/opt/sybase 
--enable-track-vars 
--enable-debug=no 
--enable-memory-limit=yes

[Sybase-CT]
sybct.allow_persistent  =   On  ; allow or prevent persistent li
nk
sybct.max_persistent=   -1  ; maximum number of persistent l
inks. -1 means no limit
sybct.max_links =   -1  ; maximum number of link
sybct.min_server_severity   =   12  ; minimum server message severit
y to display
sybct.min_client_severity   =   10  ; minimum client message severit
y to display

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8347&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: static call bugs?

[André Langhorst]

> Right, and they weren't static functions either (this feature was 
> designed for calling parent/grandparent/etc methods).  The way it's 
> designed is completely intentional.

ok. this makes sense now :)

andré

-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9664 Updated: Unable to make , related to bug 8468 i think

[sniper]

ID: 9664
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Sockets related
Assigned To: 
Comments:

You're not missing any libraries..FYI: The sockets extension is still EXPERIMENTAL, 
ie. it's not very stable yet. 
This is yet another bug in it. Have you tried compiling it with the Solaris Workshop 
CC ???

--Jani


Previous Comments:
---

[2001-03-09 20:16:31] [EMAIL PROTECTED]
Ok I'really hate to be a nag, but just finished compiling the latest cvs snapshot, 
it's still the same error. I wonder if im missing a library. Which libs does the 
socket extention use.

BTW Thanks for your so imadiate response.

-- yavo

---

[2001-03-09 20:10:58] [EMAIL PROTECTED]
Yes, you should try with the whole CVS snapshot and 
not try to replace any files from it in PHP 4.0.4.

--Jani


---

[2001-03-09 19:29:22] [EMAIL PROTECTED]
Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

---

[2001-03-09 19:28:59] [EMAIL PROTECTED]
Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

---

[2001-03-09 18:46:22] [EMAIL PROTECTED]
Please try the latest CVS snapshot from http://snaps.php.net/ as there have been some 
fixes for this.

--Jani


---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9664&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9664 Updated: Unable to make , related to bug 8468 i think

[yavo]

ID: 9664
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Sockets related
Description: Unable to make , related to bug 8468 i think

Ok I'really hate to be a nag, but just finished compiling the latest cvs snapshot, 
it's still the same error. I wonder if im missing a library. Which libs does the 
socket extention use.

BTW Thanks for your so imadiate response.

-- yavo

Previous Comments:
---

[2001-03-09 20:10:58] [EMAIL PROTECTED]
Yes, you should try with the whole CVS snapshot and 
not try to replace any files from it in PHP 4.0.4.

--Jani


---

[2001-03-09 19:29:22] [EMAIL PROTECTED]
Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

---

[2001-03-09 19:28:59] [EMAIL PROTECTED]
Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

---

[2001-03-09 18:46:22] [EMAIL PROTECTED]
Please try the latest CVS snapshot from http://snaps.php.net/ as there have been some 
fixes for this.

--Jani


---

[2001-03-09 16:24:19] [EMAIL PROTECTED]
My enviroment
 Solaris 8
 Gnu gcc
 
 compile options ./configure --enable-sockets


This bug occured to some one and he asked me to look in to it. I tried it on another 
machine same enviroment and got the same problem. A search revealed a similar ( i 
think ) bug with id 8468 .

This is the dump of the error.


Making all in sockets
gcc  -I. -I/people/yavo/work/php-4.0.4/ext/sockets -I/people/yavo/work/php-4.0.4/main 
-I/people/yavo/work/php-4.0.4 -I/people/yavo/work/php-4.0.4/Zend 
-I/people/yavo/work/php-4.0.4/ext/mysql/libmysql 
-I/people/yavo/work/php-4.0.4/ext/xml/expat/xmltok 
-I/people/yavo/work/php-4.0.4/ext/xml/expat/xmlparse 
-I/people/yavo/work/php-4.0.4/TSRM  -D_POSIX_PTHREAD_SEMANTICS -DXML_BYTE_ORDER=12 -g 
-O2  -c sockets.c && touch sockets.lo
sockets.c:118: `php_if___xnet_listen' undeclared here (not in a function)
sockets.c:118: initializer element is not constant
sockets.c:118: (near initialization for `sockets_functions[10].handler')
sockets.c:139: `php_if___xnet_socket' undeclared here (not in a function)
sockets.c:139: initializer element is not constant
sockets.c:139: (near initialization for `sockets_functions[16].handler')
sockets.c:140: `php_if___xnet_connect' undeclared here (not in a function)
sockets.c:140: initializer element is not constant
sockets.c:140: (near initialization for `sockets_functions[17].handler')
sockets.c:142: `php_if___xnet_bind' undeclared here (not in a function)
sockets.c:142: initializer element is not constant
sockets.c:142: (near initialization for `sockets_functions[19].handler')
sockets.c:146: `php_if___xnet_sendto' undeclared here (not in a function)
sockets.c:146: initializer element is not constant
sockets.c:146: (near initialization for `sockets_functions[23].handler')
sockets.c:153: `php_if___xnet_recvmsg' undeclared here (not in a function)
sockets.c:153: initializer element is not constant
sockets.c:153: (near initialization for `sockets_functions[30].handler')
sockets.c:154: `php_if___xnet_sendmsg' undeclared here (not in a function)
sockets.c:154: initializer element is not constant
sockets.c:154: (near initialization for `sockets_functions[31].handler')
sockets.c:157: `php_if___xnet_getsockopt' undeclared here (not in a function)
sockets.c:157: initializer element is not constant
sockets.c:157: (near initialization for `sockets_functions[34].handler')
sockets.c:159: `php_if___xnet_socketpair' undeclared here (not in a function)
sockets.c:159: initializer element is not constant
sockets.c:159: (near initialization for `sockets_functions[36].handler')
*** Error code 1
make: Fatal error: Command failed for target `sockets.lo'
Current working directory /people/yavo/work/php-4.0.4/ext/sockets
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /people/yavo/work/php-4.0.4/ext/sockets
*** Error code 1
make: Fatal error: Command f

[PHP-DEV] PHP 4.0 Bug #9664 Updated: Unable to make , related to bug 8468 i think

[sniper]

ID: 9664
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Sockets related
Assigned To: 
Comments:

Yes, you should try with the whole CVS snapshot and 
not try to replace any files from it in PHP 4.0.4.

--Jani


Previous Comments:
---

[2001-03-09 19:29:22] [EMAIL PROTECTED]
Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

---

[2001-03-09 19:28:59] [EMAIL PROTECTED]
Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

---

[2001-03-09 18:46:22] [EMAIL PROTECTED]
Please try the latest CVS snapshot from http://snaps.php.net/ as there have been some 
fixes for this.

--Jani


---

[2001-03-09 16:24:19] [EMAIL PROTECTED]
My enviroment
 Solaris 8
 Gnu gcc
 
 compile options ./configure --enable-sockets


This bug occured to some one and he asked me to look in to it. I tried it on another 
machine same enviroment and got the same problem. A search revealed a similar ( i 
think ) bug with id 8468 .

This is the dump of the error.


Making all in sockets
gcc  -I. -I/people/yavo/work/php-4.0.4/ext/sockets -I/people/yavo/work/php-4.0.4/main 
-I/people/yavo/work/php-4.0.4 -I/people/yavo/work/php-4.0.4/Zend 
-I/people/yavo/work/php-4.0.4/ext/mysql/libmysql 
-I/people/yavo/work/php-4.0.4/ext/xml/expat/xmltok 
-I/people/yavo/work/php-4.0.4/ext/xml/expat/xmlparse 
-I/people/yavo/work/php-4.0.4/TSRM  -D_POSIX_PTHREAD_SEMANTICS -DXML_BYTE_ORDER=12 -g 
-O2  -c sockets.c && touch sockets.lo
sockets.c:118: `php_if___xnet_listen' undeclared here (not in a function)
sockets.c:118: initializer element is not constant
sockets.c:118: (near initialization for `sockets_functions[10].handler')
sockets.c:139: `php_if___xnet_socket' undeclared here (not in a function)
sockets.c:139: initializer element is not constant
sockets.c:139: (near initialization for `sockets_functions[16].handler')
sockets.c:140: `php_if___xnet_connect' undeclared here (not in a function)
sockets.c:140: initializer element is not constant
sockets.c:140: (near initialization for `sockets_functions[17].handler')
sockets.c:142: `php_if___xnet_bind' undeclared here (not in a function)
sockets.c:142: initializer element is not constant
sockets.c:142: (near initialization for `sockets_functions[19].handler')
sockets.c:146: `php_if___xnet_sendto' undeclared here (not in a function)
sockets.c:146: initializer element is not constant
sockets.c:146: (near initialization for `sockets_functions[23].handler')
sockets.c:153: `php_if___xnet_recvmsg' undeclared here (not in a function)
sockets.c:153: initializer element is not constant
sockets.c:153: (near initialization for `sockets_functions[30].handler')
sockets.c:154: `php_if___xnet_sendmsg' undeclared here (not in a function)
sockets.c:154: initializer element is not constant
sockets.c:154: (near initialization for `sockets_functions[31].handler')
sockets.c:157: `php_if___xnet_getsockopt' undeclared here (not in a function)
sockets.c:157: initializer element is not constant
sockets.c:157: (near initialization for `sockets_functions[34].handler')
sockets.c:159: `php_if___xnet_socketpair' undeclared here (not in a function)
sockets.c:159: initializer element is not constant
sockets.c:159: (near initialization for `sockets_functions[36].handler')
*** Error code 1
make: Fatal error: Command failed for target `sockets.lo'
Current working directory /people/yavo/work/php-4.0.4/ext/sockets
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /people/yavo/work/php-4.0.4/ext/sockets
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /people/yavo/work/php-4.0.4/ext
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
[yavo@crayxmp php-4.0.4]$ 

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/

Re: [PHP-DEV] Re: static call bugs?

[Zeev Suraski]

At 02:30 10/3/2001, André Langhorst wrote:
>>There are no static functions in PHP. This syntax is used to call a 
>>method of the parent. It can be used to call other methods and thus have
>
>parent::foo();
>If you remember, it has been implemented *after* 
>[classname]::[functionname]() ...

Right, and they weren't static functions either (this feature was designed 
for calling parent/grandparent/etc methods).  The way it's designed is 
completely intentional.

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: Niklas Fondberg
Email: [EMAIL PROTECTED]
ID: nfondberg
Purpose: developer

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: static call bugs?

[Andi Gutmans]

At 01:48 AM 3/10/2001 +0100, André Langhorst wrote:
>>I still don't understand what the problem is? What should be documented 
>>is the right way to use these calls.
>
>problem 1 : how do I call the "::" operator and how do I call what it does 
>if it is no static call.

It does:
a) Calls an ancestor's method which can rely on $this
b) Another classes method (unrelated) which shouldn't rely on $this


>problem 2 : the "bug" with incorrect $this I mentioned, it is at least 
>unexcpected and should be documented (that you can't rely on $this using 
>"::" ) but since no one likes undefined behaviour it would be fine to see 
>it fixed - my opinion is that using "::" $this should never be set to 
>anything...

Every language implementation including C/C++ has undefined/unexpected 
behavior when you use constructs in ways they aren't meant/documented for. 
There is nothing to fix here like there's nothing to fix in gcc. It happens 
that $this is meant to propogate with a :: call because it is meant to work 
in case 1) above.



>>PEAR relies on the $this being correct even when you call a method which 
>>is not in the current class or in one of its parent classes?
>
>no, it simply uses "::" that is an undocumented feature

:: should be documented in the way I mentioned above.


>>Where can I see the documentation? (Any chance you can send it here to 
>>save me the time? :).
>>We just need to be sure we don't document things which aren't necessarily 
>>supposed to work.
>
>http://toye.php.net/~andre/html/keyword.newref.html

I'll try and read through this tomorrow.

Andi


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: static call bugs?

[André Langhorst]

> I still don't understand what the problem is? What should be documented 
> is the right way to use these calls.

problem 1 : how do I call the "::" operator and how do I call what it 
does if it is no static call.

problem 2 : the "bug" with incorrect $this I mentioned, it is at least 
unexcpected and should be documented (that you can't rely on $this using 
"::" ) but since no one likes undefined behaviour it would be fine to 
see it fixed - my opinion is that using "::" $this should never be set 
to anything...


> PEAR relies on the $this being correct even when you call a method which 
> is not in the current class or in one of its parent classes?

no, it simply uses "::" that is an undocumented feature

> Where can I see the documentation? (Any chance you can send it here to 
> save me the time? :).
> We just need to be sure we don't document things which aren't 
> necessarily supposed to work.

http://toye.php.net/~andre/html/keyword.newref.html

andré

-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9644 Updated: File Upload eats all RAM and swap space

[sniper]

ID: 9644
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Reproduceable crash
Assigned To: 
Comments:

1. There is an entry for APC in your php.ini.. have you
tried this without APC? 

2. Please try the latest CVS snapshot from http://snaps.php.net/

--Jani


Previous Comments:
---

[2001-03-09 01:10:31] [EMAIL PROTECTED]
Hi!

I'm using PHP to create a file upload script for a website.  When a user uploads a 
large file (>1Mb) my server always starts to use all the available RAM(I have 160Mb 
installed), and also uses up all the swap space(256Mb).  This happens for any upload 
script written in PHP, even scripts that work on other servers.  I can upload files to 
scripts written in PERL, without a problem.  To resolve this problem, my only option 
is to completely kill apache with 'apachectl stop' and then start it back 'apachectl 
start'

Server software:
Apache 1.3.19 (also happened while I was running 1.3.17)
PHP 4.0.4pl1
Linux 2.4.1 (originally slackware 7.1 distro)

Server specs:
Intel Pentium 133Mhz
160Mb RAM
10Gb HDD

Here is the script that I'm using:
Trying something?";
} else {
if ($userfile_size) {
$target = $xdir.'/'.$userfile_name;
if (!copy ($userfile,$target)) {
echo 'Error copying file! Please try again!Press the back button in your 
browser!';
} else {
header ("Location: 
http://mouthoff.magestudios.net/admin/filemanager/?path=".urlencode($path));
exit;
}
} else {
?>

Upload this file: 






I'm a PHP newbie, so please excuse any bad coding =)

Here's a copy of php.ini:
[PHP]

;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior.  In order for PHP to
; read it, it must be named 'php.ini'.  PHP looks for it in the current
; working directory, in the path designated by the environment variable
; PHPRC, and in the path that was defined in compile time (in that order).
; Under Windows, the compile-time path is the Windows directory.  The
; path in which the php.ini file is looked for can be overriden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple.  Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an expression
; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and parentheses:
; | bitwise OR
; & bitwise AND
; ~ bitwise NOT
; ! boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after the equal
; sign, or by using the None keyword:
;
;   foo =   ; sets foo to an empty string
;   foo = none  ; sets foo to an empty string
;   foo = "none"; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a dynamically
; loaded extension (either a PHP extension or a Zend extension), you may only
; use these constants *after* the line that loads the extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these lines,
; the builtin defaults will be identical).



; Language Options ;


engine  =   On  ; Enable the PHP scripting language engine 
under Apache
short_open_tag  =   On  ; allow the  tags are recognized.
asp_tags=   Off ; allow ASP-style <% %> tags
precision   =   14  ; number of significant digits displayed in 
floating point numbers
y2k_compliance  =   Off ; whether to be year 2000 compliant (will cause 
problems with non y2k compliant browsers)
output_buffering= Off   ; Output buffering allows you to send header lines 
(including cookies)
; even after you send body 
content, in the price of slowing PHP's
; output layer a bit.
; You can enable output 
buffering by in runtime by calling the output
   

Re: [PHP-DEV] static call bugs?

[André Langhorst]

> I don't understand the question. Can you rephrase?

I simply wanted to know what you had in mind, where could it be useful...


andré

-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] static call bugs?

[Andi Gutmans]

If you have:

class foo
{
 function blahblah()
 {

 }
}

class foobar extends foo
{
}

class bar extends foobar
{
 function hey()
 {
 foo::blahblah(); <-- You want $this to be correct in 
foo::blahblah.
 }

}

Andi

At 01:32 AM 3/10/2001 +0100, André Langhorst wrote:

>>Is that bad? Could come in useful, especially when calling parent
>>classes.
>
>wow, what a quick response :)
>could you elaborate (I guess you do not have parent:: in your mind writing 
>from parent classes)?
>
>andré
>
>
>
>
>
>--
>· André Langhorstt: +49 331 5811560 ·
>· [EMAIL PROTECTED]  m: +49 173 9558736 ·
>* PHP Quality Assurance  http://qa.php.net  *
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] static call bugs?

[Andrei Zmievski]

On Sat, 10 Mar 2001, André Langhorst wrote:
> could you elaborate (I guess you do not have parent:: in your mind 
> writing from parent classes)?

I don't understand the question. Can you rephrase?

-Andrei

Any sufficiently advanced bug is
indistinguishable from a feature.
-- Rich Kulawiec

--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: static call bugs?

[Andi Gutmans]

At 01:30 AM 3/10/2001 +0100, André Langhorst wrote:
>>There are no static functions in PHP. This syntax is used to call a 
>>method of the parent. It can be used to call other methods and thus have
>
>parent::foo();
>If you remember, it has been implemented *after* 
>[classname]::[functionname]() ...

I still don't understand what the problem is? What should be documented is 
the right way to use these calls.



>>the wrong $this but I wouldn't document it.
>
>can't this be fixed, otherwise if I start documenting :: (however you want 
>to call it), I cannot leave it out and since PEAR uses it heavily it has 
>to be documented

PEAR relies on the $this being correct even when you call a method which is 
not in the current class or in one of its parent classes?


>>In general, I think it's a bad idea to document undocumented features 
>>because some of them aren't meant for people to use. The behavior might 
>>change in the future.
>
>it's just three features "references inside constructor" (already 
>commited), :: (the magical operator ;) ) and php_ticks

Where can I see the documentation? (Any chance you can send it here to save 
me the time? :).
We just need to be sure we don't document things which aren't necessarily 
supposed to work.

Andi


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] static call bugs?

[André Langhorst]

> Is that bad? Could come in useful, especially when calling parent
> classes.

wow, what a quick response :)
could you elaborate (I guess you do not have parent:: in your mind 
writing from parent classes)?

andré





-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: static call bugs?

[André Langhorst]

> There are no static functions in PHP. This syntax is used to call a 
> method of the parent. It can be used to call other methods and thus have 

parent::foo();
If you remember, it has been implemented *after* 
[classname]::[functionname]() ...


> the wrong $this but I wouldn't document it.

can't this be fixed, otherwise if I start documenting :: (however you 
want to call it), I cannot leave it out and since PEAR uses it heavily 
it has to be documented


> In general, I think it's a bad idea to document undocumented features 
> because some of them aren't meant for people to use. The behavior might 
> change in the future.

it's just three features "references inside constructor" (already 
commited), :: (the magical operator ;) ) and php_ticks

andré




-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9664 Updated: Unable to make , related to bug 8468 i think

[yavo]

ID: 9664
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Sockets related
Description: Unable to make , related to bug 8468 i think

Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

Previous Comments:
---

[2001-03-09 19:28:59] [EMAIL PROTECTED]
Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

---

[2001-03-09 18:46:22] [EMAIL PROTECTED]
Please try the latest CVS snapshot from http://snaps.php.net/ as there have been some 
fixes for this.

--Jani


---

[2001-03-09 16:24:19] [EMAIL PROTECTED]
My enviroment
 Solaris 8
 Gnu gcc
 
 compile options ./configure --enable-sockets


This bug occured to some one and he asked me to look in to it. I tried it on another 
machine same enviroment and got the same problem. A search revealed a similar ( i 
think ) bug with id 8468 .

This is the dump of the error.


Making all in sockets
gcc  -I. -I/people/yavo/work/php-4.0.4/ext/sockets -I/people/yavo/work/php-4.0.4/main 
-I/people/yavo/work/php-4.0.4 -I/people/yavo/work/php-4.0.4/Zend 
-I/people/yavo/work/php-4.0.4/ext/mysql/libmysql 
-I/people/yavo/work/php-4.0.4/ext/xml/expat/xmltok 
-I/people/yavo/work/php-4.0.4/ext/xml/expat/xmlparse 
-I/people/yavo/work/php-4.0.4/TSRM  -D_POSIX_PTHREAD_SEMANTICS -DXML_BYTE_ORDER=12 -g 
-O2  -c sockets.c && touch sockets.lo
sockets.c:118: `php_if___xnet_listen' undeclared here (not in a function)
sockets.c:118: initializer element is not constant
sockets.c:118: (near initialization for `sockets_functions[10].handler')
sockets.c:139: `php_if___xnet_socket' undeclared here (not in a function)
sockets.c:139: initializer element is not constant
sockets.c:139: (near initialization for `sockets_functions[16].handler')
sockets.c:140: `php_if___xnet_connect' undeclared here (not in a function)
sockets.c:140: initializer element is not constant
sockets.c:140: (near initialization for `sockets_functions[17].handler')
sockets.c:142: `php_if___xnet_bind' undeclared here (not in a function)
sockets.c:142: initializer element is not constant
sockets.c:142: (near initialization for `sockets_functions[19].handler')
sockets.c:146: `php_if___xnet_sendto' undeclared here (not in a function)
sockets.c:146: initializer element is not constant
sockets.c:146: (near initialization for `sockets_functions[23].handler')
sockets.c:153: `php_if___xnet_recvmsg' undeclared here (not in a function)
sockets.c:153: initializer element is not constant
sockets.c:153: (near initialization for `sockets_functions[30].handler')
sockets.c:154: `php_if___xnet_sendmsg' undeclared here (not in a function)
sockets.c:154: initializer element is not constant
sockets.c:154: (near initialization for `sockets_functions[31].handler')
sockets.c:157: `php_if___xnet_getsockopt' undeclared here (not in a function)
sockets.c:157: initializer element is not constant
sockets.c:157: (near initialization for `sockets_functions[34].handler')
sockets.c:159: `php_if___xnet_socketpair' undeclared here (not in a function)
sockets.c:159: initializer element is not constant
sockets.c:159: (near initialization for `sockets_functions[36].handler')
*** Error code 1
make: Fatal error: Command failed for target `sockets.lo'
Current working directory /people/yavo/work/php-4.0.4/ext/sockets
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /people/yavo/work/php-4.0.4/ext/sockets
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /people/yavo/work/php-4.0.4/ext
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
[yavo@crayxmp php-4.0.4]$ 

---


Full Bug description available at: http://bugs.php.net/?id=9664


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9664 Updated: Unable to make , related to bug 8468 i think

[yavo]

ID: 9664
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Sockets related
Description: Unable to make , related to bug 8468 i think

Hi Jani,

Prior to submiting this bug I tried two things first I applied the pathch in bug 8468, 
next I got the latest cvs snapshot as of 5-6 hours before this post and replased all 
files in the ext/sockets dir with the files from the snapshot. As this is clearly a 
socket extention problem I didn't replace any other files. Do you thinkit would make 
any sence to replace any other files.

-- yavo

Previous Comments:
---

[2001-03-09 18:46:22] [EMAIL PROTECTED]
Please try the latest CVS snapshot from http://snaps.php.net/ as there have been some 
fixes for this.

--Jani


---

[2001-03-09 16:24:19] [EMAIL PROTECTED]
My enviroment
 Solaris 8
 Gnu gcc
 
 compile options ./configure --enable-sockets


This bug occured to some one and he asked me to look in to it. I tried it on another 
machine same enviroment and got the same problem. A search revealed a similar ( i 
think ) bug with id 8468 .

This is the dump of the error.


Making all in sockets
gcc  -I. -I/people/yavo/work/php-4.0.4/ext/sockets -I/people/yavo/work/php-4.0.4/main 
-I/people/yavo/work/php-4.0.4 -I/people/yavo/work/php-4.0.4/Zend 
-I/people/yavo/work/php-4.0.4/ext/mysql/libmysql 
-I/people/yavo/work/php-4.0.4/ext/xml/expat/xmltok 
-I/people/yavo/work/php-4.0.4/ext/xml/expat/xmlparse 
-I/people/yavo/work/php-4.0.4/TSRM  -D_POSIX_PTHREAD_SEMANTICS -DXML_BYTE_ORDER=12 -g 
-O2  -c sockets.c && touch sockets.lo
sockets.c:118: `php_if___xnet_listen' undeclared here (not in a function)
sockets.c:118: initializer element is not constant
sockets.c:118: (near initialization for `sockets_functions[10].handler')
sockets.c:139: `php_if___xnet_socket' undeclared here (not in a function)
sockets.c:139: initializer element is not constant
sockets.c:139: (near initialization for `sockets_functions[16].handler')
sockets.c:140: `php_if___xnet_connect' undeclared here (not in a function)
sockets.c:140: initializer element is not constant
sockets.c:140: (near initialization for `sockets_functions[17].handler')
sockets.c:142: `php_if___xnet_bind' undeclared here (not in a function)
sockets.c:142: initializer element is not constant
sockets.c:142: (near initialization for `sockets_functions[19].handler')
sockets.c:146: `php_if___xnet_sendto' undeclared here (not in a function)
sockets.c:146: initializer element is not constant
sockets.c:146: (near initialization for `sockets_functions[23].handler')
sockets.c:153: `php_if___xnet_recvmsg' undeclared here (not in a function)
sockets.c:153: initializer element is not constant
sockets.c:153: (near initialization for `sockets_functions[30].handler')
sockets.c:154: `php_if___xnet_sendmsg' undeclared here (not in a function)
sockets.c:154: initializer element is not constant
sockets.c:154: (near initialization for `sockets_functions[31].handler')
sockets.c:157: `php_if___xnet_getsockopt' undeclared here (not in a function)
sockets.c:157: initializer element is not constant
sockets.c:157: (near initialization for `sockets_functions[34].handler')
sockets.c:159: `php_if___xnet_socketpair' undeclared here (not in a function)
sockets.c:159: initializer element is not constant
sockets.c:159: (near initialization for `sockets_functions[36].handler')
*** Error code 1
make: Fatal error: Command failed for target `sockets.lo'
Current working directory /people/yavo/work/php-4.0.4/ext/sockets
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /people/yavo/work/php-4.0.4/ext/sockets
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /people/yavo/work/php-4.0.4/ext
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
[yavo@crayxmp php-4.0.4]$ 

---


Full Bug description available at: http://bugs.php.net/?id=9664


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9665: .netrc sought only in /root

[torben]

From: [EMAIL PROTECTED]
Operating system: Mandrake 7.0
PHP version:  4.0.4pl1
PHP Bug Type: cURL related
Bug description:  .netrc sought only in /root

cURL works fine in general, but when told to search for a .netrc file, searches
only in /root and not in the httpd user's actual home directory (/home/www).

i.e., the following only works if .netrc is in /root:

ftp://www.work.loc';

if (!$curld = curl_init()) {
echo "Could not initialize cURL session.\n";
exit;
}

curl_setopt($curld, CURLOPT_NETRC, true);
curl_setopt($curld, CURLOPT_URL, $url);
curl_exec($curld);
echo curl_errno($curld);
?>



-- 
Edit Bug report at: http://bugs.php.net/?id=9665&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: static call bugs?

[Andi Gutmans]

At 12:56 AM 3/10/2001 +0100, André Langhorst wrote:
>Hi,
>
>1) I am currently completing the php documentation to cover all 
>undocumented features and I have noticed that using a static method call 
>to the same class from on instanciated object exhibits the presence of the 
>instance within the static call

There are no static functions in PHP. This syntax is used to call a method 
of the parent. It can be used to call other methods and thus have the wrong 
$this but I wouldn't document it.
In general, I think it's a bad idea to document undocumented features 
because some of them aren't meant for people to use. The behavior might 
change in the future.
Best if you make a list of the things you want to document and we'll tell 
you if they are a side-effect, a feature for backwards compatibility but 
people shouldn't use it anymore or valid behavior.


>2) If you uncomment the marked line, you will get an error without any 
>reason...

I'll look at this tomorrow. Don't have time right now.

Andi


>I guess these are bugs, aren't they?
>class foo {
>
> function moo()  {
> // $this->boo=2; // try to remove the comments
> print '$this is ';
> if (!isset($this)) {
> print 'not set';
> foo::zoo();
> } else {
> print 'set';
> $this->zoo();
> foo::zoo();
> }
>
> }
> function zoo()  {
> print ''.'I have been called '.(!isset($this) ? 
> 'statically':'via $this->zoo()');
> var_dump($this);
> }
>
>}
>$s=new foo();
>$s->moo();
>?>foo::moo();
>?>
>
>andré
>
>
>--
>· André Langhorstt: +49 331 5811560 ·
>· [EMAIL PROTECTED]  m: +49 173 9558736 ·
>* PHP Quality Assurance  http://qa.php.net  *


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] static call bugs?

[Andrei Zmievski]

On Sat, 10 Mar 2001, André Langhorst wrote:
> Hi,
> 
> 1) I am currently completing the php documentation to cover all 
> undocumented features and I have noticed that using a static method call 
> to the same class from on instanciated object exhibits the presence of 
> the instance within the static call

Is that bad? Could come in useful, especially when calling parent
classes.

-Andrei

Linux is like living in a teepee.
No Windows, no Gates, Apache in house.
- Usenet signature

--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] static call bugs?

[André Langhorst]

Hi,

1) I am currently completing the php documentation to cover all 
undocumented features and I have noticed that using a static method call 
to the same class from on instanciated object exhibits the presence of 
the instance within the static call

2) If you uncomment the marked line, you will get an error without any 
reason...

I guess these are bugs, aren't they?
boo=2; // try to remove the comments
 print '$this is ';
 if (!isset($this)) {
 print 'not set';
 foo::zoo();
 } else {
 print 'set';
 $this->zoo();
 foo::zoo();
 }

 }
 function zoo()  {
 print ''.'I have been called '.(!isset($this) ? 
'statically':'via $this->zoo()');
 var_dump($this);
 }

}
$s=new foo();
$s->moo();
?>

andré


-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]