Bug #30471 [Com]: var_export: Nesting level too deep - recursive dependency?

[patrick at infranet dot com]

Edit report at https://bugs.php.net/bug.php?id=30471&edit=1

 ID: 30471
 Comment by: patrick at infranet dot com
 Reported by:none at example dot com
 Summary:var_export: Nesting level too deep - recursive
 dependency?
 Status: Not a bug
 Type:   Bug
 Package:PHP options/info functions
 Operating System:   Linux
 PHP Version:5.0.2
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

Another option would be to have var_export always produce some output and then 
limit the output to some level of recursion (settable by user, but defaulting 
to 
some minimum safe but useful value).


Previous Comments:

[2012-06-27 16:03:00] oxygenus at gmail dot com

var_export should receive a third param with a flag to detect recursivness and 
set 
NULL [or some special value such as an instance of an object of class 
RecursiveError].


[2012-03-28 05:48:38] jodybrabec at gmail dot com

WORKAROUND:
ob_start();
var_dump($GLOBALS);
$dataDump = ob_get_clean();


[2011-03-26 15:21:12] ricki at rocker dot com

I don't believe this is a bug as the purposes of var_dump and var_export are 
entirely different:

var_dump - simply dumps a readable form 
var_export - exports valid PHP! This code is actually usable within an 
application.

var_dump therefore can "manage" the recursive nature of global by simply doing 
the following in the output
&array(15) {
["GLOBALS"]=>
*RECURSION*

var_export on the other hand clearly can't take the same approach to recursion 
if the generated PHP output is to work as intended by the application designer. 
- it can only (and should only) fail.

hope this is useful to someone.


[2010-10-28 20:49:29] hendy at soluvas dot com

This bug is VALID!

The following code works:

var_dump($GLOBALS);

Therefore the dumping algorithm is inconsistent. var_export() should just use 
the same algorithm as var_dump().


[2010-06-27 05:55:26] jdickey at seven-sigma dot com

Derick, I'd suggest that that "expected behavior" itself is a design flaw in 
the 
PHP interpreter. The solutions I can think of right off would be ugly, granted 
(special-case check for global-variable accessor to detect whether it's 
attempting 
to recurse as an effect of debug_backtrace() and, if so, throw an exception 
that 
can then be caught by d_bt); I find it really hard to believe that such a 
heavily-
used software platform with such a large, competent company and community 
behind 
it can't come up with a better solution.

Marking this bug as 'bogus' merely insults your developer customers and 
encourages 
them to go find a real language instead.




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

https://bugs.php.net/bug.php?id=30471


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

Bug #61272 [Com]: ob_start callback get passed empty string

[patrick at procurios dot nl]

Edit report at https://bugs.php.net/bug.php?id=61272&edit=1

 ID: 61272
 Comment by: patrick at procurios dot nl
 Reported by:peacech at gmail dot com
 Summary:ob_start callback get passed empty string
 Status: Not a bug
 Type:   Bug
 Package:Output Control
 Operating System:   Arch 32 bit
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

We are having the same problem and it keeps us from migrating to 5.4. Could you 
please fix it?


Previous Comments:

[2012-03-05 14:43:25] peacech at gmail dot com

Unless ob_start callback specification has changed that for 
ob_clean/ob_end_clean, the output is discarded before calling the callback, 
then this is a bug. And I have scan the PHP 5.4 changelog and couldn't find 
anything mentioning this change.

So let me help by showing where the problem is

In line 1226 of output.c in the distributed PHP 5.4.0 source,

if (flags & PHP_OUTPUT_POP_DISCARD) {
context.op |= PHP_OUTPUT_HANDLER_CLEAN;
orphan->buffer.used = 0;
}
php_output_handler_op(orphan, &context);

orphan->buffer.used should not be set to 0 before calling the callback, 
otherwise the callback will be called with empty buffer.

And likewise in line 300 in php_output_clean

So, no, it isn't about appending $output to $buffer.


[2012-03-05 11:23:43] m...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

You should append $output to $buffer.


[2012-03-04 10:53:53] peacech at gmail dot com

Description:

Running test script below with PHP 5.4 outputs

""

Running test script below with PHP 5.3 outputs

"hello"

Test script:
---
https://bugs.php.net/bug.php?id=61272&edit=1

Req #19621 [Com]: Math needs a "sign()" function

[patrick at ibuildings dot nl]

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

 ID: 19621
 Comment by: patrick at ibuildings dot nl
 Reported by:bill at softky dot com
 Summary:Math needs a "sign()" function
 Status: Closed
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   Mandrake linux
 PHP Version:4.2.0
 Block user comment: N
 Private report: N

 New Comment:

I also searched for a sign() function and ended up here. But I disagree
with Andrey's arguments not to include it into PHP.



Since when is it a policy to *not* include a function, simply because it
does not exist in a number of other languages? Doesn't PHP have its own
'vision'? Secondly, a new function should not break BC.



As Bill stated, it would complement the abs() function and make the Math
list a more complete list, even though it's a simple function. It seems
a better idea to me to add "sign()" then let's say "goto".


Previous Comments:

[2002-10-03 02:32:28] and...@php.net

Quick search showed that there is no well know scripting language that
has such function. C++/C# has this but they are not scripting
languages.

The following code does the same. Also we have to think about
BC(backward compatibility) with older scripts.

function sign($x){

 return (int)((abs($x)-$x)? -1:$x>0);

}



Thank you for you suggestion.




[2002-09-26 13:52:07] bill at softky dot com

The wonderful math-function list is missing a very important and simple
function: sign().  The is the comlpementof abs(), and together with
abs() allows you to separate the magnitude and sign of a number, e.g.
for graphing purposes (it's hard to graph a negative number of pixels,
and displaying money as "$-99" looks dumb). 



It's a one-line function, so I've already written my own, but it really
ought to be built-in. 



Thanks!





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

Req #39863 [Com]: file_exists() silently truncates after a null byte

[patrick at cookie dot monster dot org]

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

 ID: 39863
 Comment by: patrick at cookie dot monster dot org
 Reported by:djcapelis at gmail dot com
 Summary:file_exists() silently truncates after a null byte
 Status: Assigned
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   Linux, MacOSX
 PHP Version:4.4.4, 5.1.5
 Assigned To:pajoye
 Block user comment: N
 Private report: N
 CVE-ID: 2006-7243

 New Comment:

Will this be fixed too in php 5.2.17?


Previous Comments:

[2010-11-18 17:21:15] paj...@php.net

Fixed in PHP_5_3, will be part of 5.3.4.



trunk still needs the fix, it will be done soonish.


[2010-11-18 16:22:24] paj...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=305507
Log: - fix #39863, do not accept paths with NULL in them. See
http://news.php.net/php.internals/50191, trunk will have the patch later
(adding a macro and/or changing (some) APIs. Patch by Rasmus


[2010-06-05 21:45:27] s...@php.net

I've merged the test as ext/standard/tests/file/bug39863.phpt


[2010-06-05 21:44:50] s...@php.net

Automatic comment from SVN on behalf of sixd
Revision: http://svn.php.net/viewvc/?view=revision&revision=300213
Log: New test for file_exists (bug #39863).  It currently xfail's


[2010-05-12 13:25:42] vanderaj at owasp dot org

I've tested this on CentOS 5.0 with a hand built 5.2.11 and Apple's
build of PHP 

5.3.1 on MacOS X 10.6.3, and both have this issue. 



If you don't want to run a phpt, here's some a more readable version of
the 

previous test:









I've included a PHP test script. It's my first phpt, so please be
gentle.




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

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


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

#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache

[patrick dot bueker at triangle-solutions dot de]

 ID:   44994
 Comment by:   patrick dot bueker at triangle-solutions dot de
 Reported By:  dbarrett at vistaprint dot com
 Status:   No Feedback
 Bug Type: Program Execution
 Operating System: win32 only - 2003 Server, 64-bit
 PHP Version:  5.2.6
 Assigned To:  garretts
 New Comment:

I once had the problem too. I had the feeling that it has something to
do with threadsafe or non-threadsafe versions of PHP. I still have the
problem on some installations, others work.


Previous Comments:


[2009-09-01 18:42:09] garre...@php.net

I'm trying to come up with a reproducible test case for this bug.

If anyone has a complete test scenario for this please post it. I
simply can't replicate the effects here.

G



[2009-08-27 01:00:00] php-bugs at lists dot php dot net

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



[2009-08-19 19:06:40] garre...@php.net

Please try using this snapshot:

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

  http://windows.php.net/snapshots/





[2009-08-19 17:26:55] garre...@php.net

I've seen this happen in other languages too.

This happens when the pipe between the parent and child fills up, and
cmd.exe ends up blocking and creates a race condition. (Windows script
host languages trip up on this quickly)

in popen_ex() ( in tsrm_win32.c) the pipe is creates with a 2k buffer:

   if (!str_len || !CreatePipe(&in, &out, &security, 2048L)) {

this should probably be significantly larger. I'd certainly go with at
least 16k or 32k. (hey, it's only memory :D)

as well, the elimination of the unrequired cmd.exe as the immediate
child process would eliminate the possibility that *it's* buffer gets
overwhelmed too. (which solves bug #43327, and I've passed a patch to
Pierre for that.)






[2009-06-08 16:40:15] alex at bartl dot net

Reproducable with PHP 5.2.9-1 on Windows2003 Server with Apache2.2
Workaround with calling session_write_close() before calling exec()
confirmed working

NOT reproducable with PHP 5.2.1 on Windows 2000 Server with IIS5

anyway, seems to be a duplicate of Bug#44942



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

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

#50442 [NEW]: __construct Method Chaining

[michael dot patrick dot mcnally at gmail dot com]

From: michael dot patrick dot mcnally at gmail dot com
Operating system: Windows Vista
PHP version:  5.2.11
PHP Bug Type: Feature/Change Request
Bug description:  __construct Method Chaining

Description:

Method chaining is very impressive when done properly.  For example:

$location = new location();
$location->city('Boston')->state('Massachusetts')->getMap();

In JavaScript, it is possible to chain from the constructor, like this:
new location.city('Boston').state('Massachusetts').getMap();

Where in PHP, the equivalent would be:
new location()->city('Boston')->state('Massachusetts')->getMap();

Is there a reason why the __construct of a class cannot return itself for
method chaining like its' methods?  When I try, I receive a Parse Error.

Thank you!


Reproduce code:
---
---
>From manual page: language.oop5
---


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

#50401 [NEW]: Array Key Data Type Conversion

[michael dot patrick dot mcnally at gmail dot com]

From: michael dot patrick dot mcnally at gmail dot com
Operating system: Windows Vista
PHP version:  5.3.1
PHP Bug Type: Feature/Change Request
Bug description:  Array Key Data Type Conversion

Description:

It is necessary that I check to see if an array key has been set by the
code.  Such as is with this code:

foreach($array as $key => $value){

 if(is_int($key)) echo 'the code assigned a key for this element';

}


How can I achieve this with the following array?:

array('1'=>'Yes','0'=>'No');


PHP converts the '1' into 1 which leaves me no detection for user assigned
keys.  This is bad form.

Reproduce code:
---
---
>From manual page: language.types.array
---



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

#48746 [Com]: Unable to browse directories within Junction Points

[patrick dot boens at latosensu dot be]

 ID:   48746
 Comment by:   patrick dot boens at latosensu dot be
 Reported By:  ddkees at illinois dot edu
 Status:   No Feedback
 Bug Type: Directory function related
 Operating System: win32 only - Windows Server 2003
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

This bug is actually preventing us from using 5.3 at all! We have a
framework that is used for ±60 sites; each of them contains a junction
that points to 1 single instance of the framework.


Previous Comments:


[2009-09-22 01:00:00] php-bugs at lists dot php dot net

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



[2009-09-20 04:12:18] sant9442 at gmail dot com

Hi, 

This is a note for the bug archives.

I just discovered that the bug reported in #49039 which was merged with
this bug entry, can also be reproduced when the web server spawning
PHP-CGI.EXE incorrectly prepares the CGI environment string:

PATH_INFO

The correct "official" (IETF) standard definition is in RFC 3875:

   "The Common Gateway Interface (CGI) Version 1.1":
http://www.ietf.org/rfc/rfc3875 

If PATH_INFO is incorrect, the function sapi_cgi_register_variables()
sapi\cgi\cgi_main.c, which effectively does:

PHP_SELF = SCRIPT_NAME + PATH_INFO

will potentially cause the same "No input file specified" behavior we
saw in bug #49039.  

The original bug #49039 report indicated a script in a sub-folder name
with 3 letters, e.g.;

/public/pwe/test.php

would yield a file not found response.  

It was found if the server-side document root was a junction point, the
no input file error was produced. 

c:\web\HTTP\public\pwe

where C:\WEB\HTTP is a junction, like using SysInternals.com
Junction.EXE utility:

   C:
   CD \WEB
   junction HTTP D:\WEB_SRC\HTTP_REV1.2.3.4

We internally use junctions in this way to test various versions of our
html templates.

Eventually it was determined by paj...@php.net the PHP 5.3 logic for
resolving junctions has some issues to address and that is when I last
left this issue until now.

Recently, in an independent report related to PHP_SELF, we found out
our web server was not creating the environment string PATH_INFO CGI
correctly per RFC 3875.  

This serve issue was just fixed and after seeing how PHP expects
PHP_SELF to be created using PATH_INFO, I was curious if the web server
PATH_INFO fix also fixes #49039.  

Well, indeed it appears that it does fix it, even when the document
root is a junction point.

For the curious, our WEB SERVER first supported real CGI binary
processes, no script maps, for example for a URI with:

   http://example.com/cgi-bin/applet.exe/file.txt?p1=v1

its parts are:

SCRIPT_NAME = "/cgi-bin/applet.exe"
QUERY_STRING= "p1=v1"
PATH_INFO   = "/file.txt"

if for the sake of example, the document root is:

DOCUMENT_ROOT   = "c:\web\http"

then PATH_TRANSLATED is:

PATH_TRANSLATED = "c:\web\http\file.txt"

When script mapping support was added, including support for specific
PHP's SCRIPT_FILENAME environment string, a bug was apparently
introduced for creating PATH_INFO.  So in an valid URI with a PHP script
map:

http://example.com/test.php/file.txt?p1=v2

Our web server correctly created:

DOCUMENT_ROOT= "c:\web\http"
SCRIPT_NAME  = "/test.php"
QUERY_STRING = "p1=v1"
SCRIPT_FILENAME  = "c:\web\http\test.php"
PATH_TRANSLATED  = "c:\web\http\file.txt"

but incorrectly created:

PATH_INFO= "/test.php/file.txt"

So when PHP-CGI started and created PHP_SELF in cgi_main.c

PHP_SELF = SCRIPT_NAME + PATH_INFO

its value was now:

PHP_SELF = "/test.php/test.php/file.txt"

thus the "no input file found" PHP response.

As noted, this as fixed in our web sever, and it appears to resolve
also bug #49039. I am sure inadvertingly the junction point issues were
legit and being (and had been?) addressed, I am just nothing as it
another possible reason caused by a web server not correctly
implementing PATH_INFO per RFC 3875.



[2009-09-14 18:49:29] paj...@php.net

Please try using this snapshot:

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

  http://windows.php.net/snapshots/

The next snapshot (in 1-2h) will have the fix as in the tiny php build
I provided earlier.



[2009-09-14 18:46:57] s...@php.net

Automatic c

#49668 [Fbk->Csd]: httpd2-prefore segfault error 4 mod_php5.so

[patrick dot shanahan at gmail dot com]

 ID:   49668
 User updated by:  patrick dot shanahan at gmail dot com
 Reported By:  patrick dot shanahan at gmail dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: Apache2 related
 Operating System: linux
 PHP Version:  5.3.0
 New Comment:

duplicate of bug #49677
http://bugs.php.net/bug.php?id=49677


Previous Comments:


[2009-09-25 19:43:52] patrick dot shanahan at gmail dot com

--- Comment #13 from Cristian Rodríguez  
2009-09-25 13:38:07   
MDT --- 
not a bug in xcache, bug in PHP, fixing. 

http://bugzilla.novell.com/show_bug.cgi?id=542056



[2009-09-25 19:04:38] patrick dot shanahan at gmail dot com

removed php5-xcache-1.3.0-2.4
enabled apache2 module php5
restarted httpd-prefork

appears all systems go  :^)

prblm apparently in php5-xcache-1.3.0-24

tks,



[2009-09-25 18:23:45] patrick dot shanahan at gmail dot com

yes, it consistently crashes when module php5 is inabled in apache2



[2009-09-25 16:57:19] sjo...@php.net

Can you reproduce the crash?



[2009-09-25 14:00:20] patrick dot shanahan at gmail dot com

last nite was really night before last

expected result s/b: an operable web server



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

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

#49668 [Com]: httpd2-prefore segfault error 4 mod_php5.so

[patrick dot shanahan at gmail dot com]

 ID:   49668
 Comment by:   patrick dot shanahan at gmail dot com
 Reported By:  patrick dot shanahan at gmail dot com
 Status:   Feedback
 Bug Type: Apache2 related
 Operating System: linux
 PHP Version:  5.3.0
 New Comment:

--- Comment #13 from Cristian Rodríguez  
2009-09-25 13:38:07   
MDT --- 
not a bug in xcache, bug in PHP, fixing. 

http://bugzilla.novell.com/show_bug.cgi?id=542056


Previous Comments:


[2009-09-25 19:04:38] patrick dot shanahan at gmail dot com

removed php5-xcache-1.3.0-2.4
enabled apache2 module php5
restarted httpd-prefork

appears all systems go  :^)

prblm apparently in php5-xcache-1.3.0-24

tks,



[2009-09-25 18:23:45] patrick dot shanahan at gmail dot com

yes, it consistently crashes when module php5 is inabled in apache2



[2009-09-25 16:57:19] sjo...@php.net

Can you reproduce the crash?



[2009-09-25 14:00:20] patrick dot shanahan at gmail dot com

last nite was really night before last

expected result s/b: an operable web server



[2009-09-25 13:54:54] patrick dot shanahan at gmail dot com

Description:

Last nite my apache2 server stopped:
  
cat /var/log/apache2/error_log  
  
[Thu Sep 24 00:17:01 2009] [notice] seg fault or similar nasty error
detected in the parent process
   

16:09 wahoo:~ # rcapache2 start 
Starting httpd2 (prefork)  failed  

dmesg: 

[14891.859160] httpd2-prefork[11030]: segfault at 8 ip 7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 
 
google search yields nothing pertinent.


disabling php5 apache2 module allows the server to start   

  
apache2-2.2.13-1.6.x86_64 
apache2-mod_php5-5.3.0-1.2.x86_64 
apache2-prefork-2.2.13-1.6.x86_64  
apache2-worker-2.2.13-1.6.x86_64  
php5-5.3.0-1.2.x86_64  
   

Reproduce code:
---
enable module php5 in apache2
restart/reload apache2

Expected result:

[14891.859160] httpd2-prefork[11030]: segfault at 8 ip
7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 

Actual result:
--
[14891.859160] httpd2-prefork[11030]: segfault at 8 ip
7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 





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

#49668 [Com]: httpd2-prefore segfault error 4 mod_php5.so

[patrick dot shanahan at gmail dot com]

 ID:   49668
 Comment by:   patrick dot shanahan at gmail dot com
 Reported By:  patrick dot shanahan at gmail dot com
 Status:   Feedback
 Bug Type: Apache2 related
 Operating System: linux
 PHP Version:  5.3.0
 New Comment:

removed php5-xcache-1.3.0-2.4
enabled apache2 module php5
restarted httpd-prefork

appears all systems go  :^)

prblm apparently in php5-xcache-1.3.0-24

tks,


Previous Comments:


[2009-09-25 18:23:45] patrick dot shanahan at gmail dot com

yes, it consistently crashes when module php5 is inabled in apache2



[2009-09-25 16:57:19] sjo...@php.net

Can you reproduce the crash?



[2009-09-25 14:00:20] patrick dot shanahan at gmail dot com

last nite was really night before last

expected result s/b: an operable web server



[2009-09-25 13:54:54] patrick dot shanahan at gmail dot com

Description:

Last nite my apache2 server stopped:
  
cat /var/log/apache2/error_log  
  
[Thu Sep 24 00:17:01 2009] [notice] seg fault or similar nasty error
detected in the parent process
   

16:09 wahoo:~ # rcapache2 start 
Starting httpd2 (prefork)  failed  

dmesg: 

[14891.859160] httpd2-prefork[11030]: segfault at 8 ip 7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 
 
google search yields nothing pertinent.


disabling php5 apache2 module allows the server to start   

  
apache2-2.2.13-1.6.x86_64 
apache2-mod_php5-5.3.0-1.2.x86_64 
apache2-prefork-2.2.13-1.6.x86_64  
apache2-worker-2.2.13-1.6.x86_64  
php5-5.3.0-1.2.x86_64  
   

Reproduce code:
---
enable module php5 in apache2
restart/reload apache2

Expected result:

[14891.859160] httpd2-prefork[11030]: segfault at 8 ip
7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 

Actual result:
--
[14891.859160] httpd2-prefork[11030]: segfault at 8 ip
7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 





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

#49668 [Com]: httpd2-prefore segfault error 4 mod_php5.so

[patrick dot shanahan at gmail dot com]

 ID:   49668
 Comment by:   patrick dot shanahan at gmail dot com
 Reported By:  patrick dot shanahan at gmail dot com
 Status:   Feedback
 Bug Type: Apache2 related
 Operating System: linux
 PHP Version:  5.3.0
 New Comment:

yes, it consistently crashes when module php5 is inabled in apache2


Previous Comments:


[2009-09-25 16:57:19] sjo...@php.net

Can you reproduce the crash?



[2009-09-25 14:00:20] patrick dot shanahan at gmail dot com

last nite was really night before last

expected result s/b: an operable web server



[2009-09-25 13:54:54] patrick dot shanahan at gmail dot com

Description:

Last nite my apache2 server stopped:
  
cat /var/log/apache2/error_log  
  
[Thu Sep 24 00:17:01 2009] [notice] seg fault or similar nasty error
detected in the parent process
   

16:09 wahoo:~ # rcapache2 start 
Starting httpd2 (prefork)  failed  

dmesg: 

[14891.859160] httpd2-prefork[11030]: segfault at 8 ip 7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 
 
google search yields nothing pertinent.


disabling php5 apache2 module allows the server to start   

  
apache2-2.2.13-1.6.x86_64 
apache2-mod_php5-5.3.0-1.2.x86_64 
apache2-prefork-2.2.13-1.6.x86_64  
apache2-worker-2.2.13-1.6.x86_64  
php5-5.3.0-1.2.x86_64  
   

Reproduce code:
---
enable module php5 in apache2
restart/reload apache2

Expected result:

[14891.859160] httpd2-prefork[11030]: segfault at 8 ip
7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 

Actual result:
--
[14891.859160] httpd2-prefork[11030]: segfault at 8 ip
7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 





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

#49668 [Com]: httpd2-prefore segfault error 4 mod_php5.so

[patrick dot shanahan at gmail dot com]

 ID:   49668
 Comment by:   patrick dot shanahan at gmail dot com
 Reported By:  patrick dot shanahan at gmail dot com
 Status:   Open
 Bug Type: Apache2 related
 Operating System: linux
 PHP Version:  5.3.0
 New Comment:

last nite was really night before last

expected result s/b: an operable web server


Previous Comments:


[2009-09-25 13:54:54] patrick dot shanahan at gmail dot com

Description:

Last nite my apache2 server stopped:
  
cat /var/log/apache2/error_log  
  
[Thu Sep 24 00:17:01 2009] [notice] seg fault or similar nasty error
detected in the parent process
   

16:09 wahoo:~ # rcapache2 start 
Starting httpd2 (prefork)  failed  

dmesg: 

[14891.859160] httpd2-prefork[11030]: segfault at 8 ip 7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 
 
google search yields nothing pertinent.


disabling php5 apache2 module allows the server to start   

  
apache2-2.2.13-1.6.x86_64 
apache2-mod_php5-5.3.0-1.2.x86_64 
apache2-prefork-2.2.13-1.6.x86_64  
apache2-worker-2.2.13-1.6.x86_64  
php5-5.3.0-1.2.x86_64  
   

Reproduce code:
---
enable module php5 in apache2
restart/reload apache2

Expected result:

[14891.859160] httpd2-prefork[11030]: segfault at 8 ip
7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 

Actual result:
--
[14891.859160] httpd2-prefork[11030]: segfault at 8 ip
7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 





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

#49668 [NEW]: httpd2-prefore segfault error 4 mod_php5.so

[patrick dot shanahan at gmail dot com]

From: patrick dot shanahan at gmail dot com
Operating system: linux
PHP version:  5.3.0
PHP Bug Type: Apache2 related
Bug description:  httpd2-prefore segfault error 4 mod_php5.so

Description:

Last nite my apache2 server stopped:
  
cat /var/log/apache2/error_log  
  
[Thu Sep 24 00:17:01 2009] [notice] seg fault or similar nasty error
detected in the parent process
  
 
16:09 wahoo:~ # rcapache2 start 
Starting httpd2 (prefork)  failed  

dmesg:
 
[14891.859160] httpd2-prefork[11030]: segfault at 8 ip 7f216093c09d sp
7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000]   
   
google search yields nothing pertinent.   
   
  
disabling php5 apache2 module allows the server to start  
   

apache2-2.2.13-1.6.x86_64 
apache2-mod_php5-5.3.0-1.2.x86_64 
apache2-prefork-2.2.13-1.6.x86_64  
apache2-worker-2.2.13-1.6.x86_64  
php5-5.3.0-1.2.x86_64 


Reproduce code:
---
enable module php5 in apache2
restart/reload apache2

Expected result:

[14891.859160] httpd2-prefork[11030]: segfault at 8 ip 7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 

Actual result:
--
[14891.859160] httpd2-prefork[11030]: segfault at 8 ip 7f216093c09d
sp 7fff3e55b648 error 4 in mod_php5.so[7f21606fc000+2a8000] 

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

#48880 [Com]: Random Appearing open_basedir problem

[patrick at patrickpatoray dot com]

 ID:  48880
 Comment by:  patrick at patrickpatoray dot com
 Reported By: brwarner at rogers dot com
 Status:  Open
 Bug Type:Safe Mode/open_basedir
 PHP Version: 5.3.0
 New Comment:

I am having the same problem on Mac OS X 10.5.7.  

Intermittent failures.  It will work after a refresh or two.  Each 
time, it seems to have a slightly 
different allowed path(s).  I've pasted a few example error lines 
below:


Warning: Unknown: open_basedir restriction in effect. 
File(/www/htdocs/common/functions/class.Base.php) is 
not within the allowed path(s): (X-Powered-By: PHP/5.3.0) in Unknown 
on line 0

Warning: Unknown: open_basedir restriction in effect. 
File(/www/htdocs/common/functions/class.Base.php) is 
not within the allowed path(s): (Mozilla/5.0 (Macintosh; U; Intel Mac 
OS X 10_5_7; en-us) AppleWebKit/530.18 
(KHTML, like Gecko) Version/4.0.1 Safari/530.18) in Unknown on line 0

Warning: Unknown: open_basedir restriction in effect. 
File(/www/htdocs/common/functions/class.Base.php) is 
not within the allowed path(s): ( Mac OS X 10_5_7; en-us) 
AppleWebKit/530.19.2 (KHTML, like Gecko) 
Version/4.0.2 Safari/530.19) in Unknown on line 0

Warning: Unknown: open_basedir restriction in effect. 
File(/www/htdocs/common/functions/class.Base.php) is 
not within the allowed path(s): (�O) in Unknown on line 0


I am using Apache 2.2.11 with PHP configured as a module.  Thread 
safety is disabled.

I am setting open_basedir for each virtual host using php_admin_value

The file class.Base.php is included via an auto_prepend line in 
httpd.conf (not on a virtual host basis, but 
for all virtual hosts), which is why it shows "in Unknown on line 0" 
for each error message

As mentioned by brwarner, I have never seen this in any other version 
of PHP until 5.3.0.


Previous Comments:


[2009-07-12 15:05:53] paj...@php.net

not windows specific (given the comments)



[2009-07-12 15:03:03] brwarner at rogers dot com

Yes, they also appear to have ASCII characters outside those of
letters, 
numbers, and symbols. Almost like it is being corrupted.



[2009-07-12 11:09:29] te at powie dot de

We noticed the same problem under Suse Linux + Apache2 + php 5.3.0. 
Warning:

Warning: Unknown: open_basedir restriction in effect.
File(/srv/www/web1/html/cms/mod/gb/index.php) is not within the allowed
path(s): (¶/www/web14/html/) in Unknown on line 0

The displayed allowed paths are random, from other vhosts on the
system!



[2009-07-10 18:27:02] brwarner at rogers dot com

In the httpd file the following line includes the virtual hosts file

# Virtual hosts
Include conf/extra/httpd-vhosts.conf

In that file here is what the virtual host for that specific domain is


ServerName brwarner.co.cc
ServerAlias www.brwarner.co.cc 127.0.0.1
DocumentRoot "C:/www/brwarner.co.cc"
php_admin_value open_basedir 
"C:\www\brwarner.co.cc;C:\svn;C:\Program 
Files\PHP\PEAR;C:\WINDOWS\Temp;C:\djgpp"
php_admin_value short_open_tag "Off"
ErrorLog "C:/www/logs/brwarner_error.log"
ErrorDocument 404 /error404.php


I have several other virtual hosts with look practically idential.

I have never seen this in any other version of PHP besides 5.3.0 and 
not before I upgraded, and I have had these sites working for a while 
so if it was there I probably would have seen it.



[2009-07-10 18:22:00] j...@php.net

Is open_basedir set in httpd.conf or in some .htaccess file?
And does this happen _only_ with PHP 5.3.0 ?



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

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

#48535 [Com]: file_exists returns false if the file path is a symlink

[patrick at procurios dot nl]

 ID:   48535
 Comment by:   patrick at procurios dot nl
 Reported By:  tobias dot burger at rolmail dot net
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: win32 only - Windows Server 2008
 PHP Version:  5.3.0RC3
 Assigned To:  pajoye
 New Comment:

We have the same problem on our Windows Vista developer machines. Links
were made with the tool junction.exe (because the links need to work on
both Windows XP and Windows Vista).

The problem was fixed in Vista when the old links were replaced by new
mklink links.

We haven't tried PHP 5.3 on XP yet.


Previous Comments:


[2009-06-18 08:16:04] tobias dot burger at rolmail dot net

I have a deep folder structure. For example i made a symlink (mklink
/d) from a folder located on drive d: to a folder on drive c:

D:\root\web\wwwtypo35 -> C:\inetpub\wwwtypo35

If I call now realpath() for
"C:\inetpub\wwwtypo35\Packages\Global\FLOW3\Classes\Package\Package.php"
it returns false on the latest snapshot version of PHP. If I try the RC3
release it works and the function returns the full path.

Maybe the bug exists because I made a symlink to a path on another
drive?



[2009-06-17 21:18:35] paj...@php.net

realpath works here (all tests machine) with symlink. Do you have an
example (path used, dir or files?, etc.)



[2009-06-16 06:59:38] tobias dot burger at rolmail dot net

Now it works!

But realpath doesn't work for symlinked pathes anymore (it returns
false).
Tried the RC3 realease again and there it works.
Has it something to do with the actual fix or should I open a new bug
submission?



[2009-06-15 17:02:37] paj...@php.net

Please try using this CVS snapshot:

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

  http://windows.php.net/snapshots/

A fix has been applied to 5.3, please try it



[2009-06-12 10:17:12] paj...@php.net

thanks for the update, I have to figure out what's wrong.



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

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

#45176 [Com]: Create image from ttf file failed

[patrick dot landolt at artack dot ch]

 ID:   45176
 Comment by:   patrick dot landolt at artack dot ch
 Reported By:  heyond at yahoo dot com dot cn
 Status:   Assigned
 Bug Type: GD related
 Operating System: windows 2003
 PHP Version:  5.2.6
 Assigned To:  pajoye
 New Comment:

I also have the same problem with GD on PHP V5.2.6 installed. My font
is a chinese one.


Previous Comments:


[2008-06-05 06:45:11] heyond at yahoo dot com dot cn

The completed script is:
http://www.guomo.com/data/fonts/1.ttf This file
'1.ttf' is normal
$fontfile =
'./data/fonts/174.ttf';//http://www.guomo.com/data/fonts/174.ttf This
file '174.ttf' is abnormal

$width = 30
$height = 40;

$fontsize = 20;
$x = 0;
$y = $fontsize + 10;

$im = imagecreate($wordnum * $width, $height);
$bgcolor = imagecolorallocate($im, hexdec(substr(BG1, 0, 2)),
hexdec(substr(BG1, 2, 2)), hexdec(substr(BG1, 4, 2)));
$fgcolor = imagecolorallocate($im, 0, 0, 0);
imagefill($im, 0, 0, $bgcolor);

imagettftext($im, $fontsize, 0, $x, $y, $fgcolor, $fontfile, $word);
imagejpeg($im);
imagedestroy($im);
exit;

?>



[2008-06-05 06:38:14] heyond at yahoo dot com dot cn

http://www.guomo.com/data/fonts/174.ttf



[2008-06-04 16:23:40] paj...@php.net

"Warning: imagettftext() [function.imagettftext]: Unable to find a
CharMap that I can handle in D:\www\guomo.com\ttf.php on line 33"

Is a pretty clear error message.

Please provide a link to the font you are using a complete script to
reproduce your problem.





[2008-06-04 14:24:08] heyond at yahoo dot com dot cn

Description:

I try to create a font image from ttf file, but I encounted a error :

Warning: imagettftext() [function.imagettftext]: Unable to find a
CharMap that I can handle in D:\www\mvc\ttf2.php on line 49

only few ttf file like this, I guess the freetypes version too lower.

Reproduce code:
---
imagettftext($im, $fontsize, 0, $x, $y, $fgcolor, $fontfile, 'abc');

Expected result:

a binary image.

Actual result:
--
Warning: imagettftext() [function.imagettftext]: Unable to find a
CharMap that I can handle in D:\www\guomo.com\ttf.php on line 33
ÿ?JFIFÿ>CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), default
quality ÿC    $.' ",#(7),01444'9=82<.342ÿC


2!!22ÿ(
J
"

ÿ




ÿ?

}
!1AQa"q2‘?#B±ÁRÑð$3br?
%&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyzƒ„…†‡ˆ‰Š’“”•–—˜™š¢£¤¥¦§¨©ª²³´µ¶·¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕÖ×ØÙÚáâãäåæçèéêñòóôõö÷øù?



ÿ?

w
!1AQaq"2?B‘¡±Á
#3R?br?$4??&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz‚ƒ„…†‡ˆ‰Š’“”•–—˜™š¢£¤¥¦§¨©ª²³´µ¶·¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕÖ×ØÙÚâãäåæçèéêòóôõö÷øùúÿ

?õJ(¢¸Í‚ÿ





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

#44762 [Com]: DOMElement need a innerHTML

[patrick at patricksmith dot org]

 ID:   44762
 Comment by:   patrick at patricksmith dot org
 Reported By:  xwisdom at yahoo dot com
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Windows XP
 PHP Version:  5.2.5
 New Comment:

In the meantime, here's a utility function that you may find helpful:

$innerHTML = '';
$elem = $doc->getElementById($elem_id);

// loop through all childNodes, getting html
$children = $elem->childNodes;
foreach ($children as $child) {
$tmp_doc = new DOMDocument();
$tmp_doc->appendChild($tmp_doc->importNode($child,true));   
$innerHTML .= $tmp_doc->saveHTML();
}


Previous Comments:


[2008-04-17 14:40:05] xwisdom at yahoo dot com

Description:

I would like to request that a innerHTML property (or method) be added
to DOMElement class. This would make it so much easier to retrieve and
set the html or xml content of a node.

Right now we have to use fragments with several lines of to get the job
done. It would be so much better to be able to do it in one line of code
:)










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

#45600 [NEW]: dump_file character conversion

[patrick dot lanove at telenet dot be]

From: patrick dot lanove at telenet dot be
Operating system: Windows XP
PHP version:  4.4.8
PHP Bug Type: DOM XML related
Bug description:  dump_file character conversion

Description:

Might have found a bug in this function.
When the document pased contains special characters like é,è,à...
some level of character conversion is done in the output.

Also, special characters pased as filename are omitted in the outputed
filename.

The string 'ét ' in the reproduction code is converted to unicode
character/CJK Unified Ideographs 9D20 (decimal: 40194).

loaded modules:
php_domxml
php_iconv

Apache version 2.2.3

in some other bugreports, it was said dump_file calls on functions from
libxml12, there is no such file in php's dir.

Reproduce code:
---
$doc = domxml_new_doc('1.0');
$root = $doc->create_element('HTML');
$root = $doc->append_child($root);
$head = $doc->create_element('HEAD');
$head = $root->append_child($head);
$title = $doc->create_element('TITLE');
$title = $head->append_child($title);
$text = $doc->create_text_node('This is yét another title');
$text = $title->append_child($text);

$path = 'some_absolute_path';
$filename = 'bugtést3.xml';
$doc->dump_file($path . '/' . $filename, false, true);

Expected result:

filename: bugtést3.xml


  
This is a title
  


Actual result:
--
filename: bugtst3.xml


  
This is y鴠another title
  


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

#42613 [Csd]: Unable to load Dynamic Link Libraries - installer buggy

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Closed
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 Assigned To:  jmertic
 New Comment:

"Just to clarify again, you don't need to manually adjust the php.ini
file; the installer handles that for you."

I got that, but that's simply not always the case. I appreciate what
you're saying but the problem is that, while there are claims that the
extensions *should* work, they don't. I say they don't, and the answer
continues to be that they *should*. So, erm, how does this resolve the
problem again?

"I bet your script is referencing the mysql_* functions, which require
the the mysql extension. Since you are working with MySQL 5, I'd
recommend moving to the mysqli_* functions; they are mostly identical,
but support some of the newer MySQL 4.1+ features."

Actually no, I was the "mysqli_" functions (well, at least I was
initially). I like using the latest and greatest and this seemed to be
the way to go. But like I said, the mysqli extension simply doesn't
work. So I had to downgrade to mysql to get it running. Again, the
problem is not really entirely solved.

"If you need multibyte support, enable the Multi-Byte String
(mbstring)
extension."

Okay...not included by default with the MySQL extension so I have to
edit the PHP.INI file. Granted it's optional but clearly your first
suggestion to not update the INI file really implies that your web
server will only ever do one thing, and that any time you want to do
something else you need to re-install it. If not, you should be able to
install all the extensions you *think* you may ever need...and we're
right back to step 1!!!

"Any changes to the php.ini file require a restart to the web server."

...right. If I failed to omit this anywhere it's just because it was
getting tedious constantly repeating myself. But yes, I restart my we
server each and every time.

"I'm marking this closed since it sounds like there isn't a PHP error
here, mainly a user configuration error."

Okay, so here's the thing. If I install PHP, I only install exactly
what I need at that exact moment, correct? If need anything else, I 

a) shouldn't touch the INI file because the installer did it for me (so
I'm stuck),
b) Update the INI file by hand and risk enabling a faulty extension
(right back to the very top of this problem), 
c) Re-install PHP and enable the extensions I need now. 

Besides that, it still doesn't answer the fundamental question and
problemif I want functionality "A", which extensions should I be
planning to install way ahead of time to ensure that I can use it.
Furthermore, why do a number of the extensions fail? The basic questions
that this whole thing started with haven't been answered or addressed in
any way. The bug summary "Unable to load Dynamic Link Libraries -
installer buggy" has pretty much been ignored. Maybe it's not an
installer issue but we've managed to get so far off topic...trying to
get one precise installation going...that the original problem has been
forgotten. I'm glad I can partially use MySQL, don't get me wrong, but
how has the original bug been fixed?


Previous Comments:


[2007-11-12 12:56:22] [EMAIL PROTECTED]

Just to clarify again, you don't need to manually adjust the php.ini
file; the installer handles that for you.

I bet your script is referencing the mysql_* functions, which require
the the mysql extension. Since you are working with MySQL 5, I'd
recommend moving to the mysqli_* functions; they are mostly identical,
but support some of the newer MySQL 4.1+ features.

If you need multibyte support, enable the Multi-Byte String (mbstring)
extension.

Any changes to the php.ini file require a restart to the web server.

I'm marking this closed since it sounds like there isn't a PHP error
here, mainly a user configuration error.



[2007-11-05 16:04:44] patrick at baynewmedia dot com

...oh, regarding the mispelling issue; yes, I had initially misspelled
the extension names, a few times. First time I'd forgotten the "php_" at
the front, the next time it was something else. I'll be the first to
admit that that's just dumb on my part, but it's worthwhile to point out
that no errors were reported. I mean 0 errors. The extensions,
justifiably, didn't show up on the info page, but neither did any sort
of error reports that the DLL mentioned doesn't exist (or something to
that effect). Furthermore, I did finally fix my spelling but the resul

#42613 [Asn]: Unable to load Dynamic Link Libraries - installer buggy

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 Assigned To:  jmertic
 New Comment:

...oh, regarding the mispelling issue; yes, I had initially misspelled
the extension names, a few times. First time I'd forgotten the "php_" at
the front, the next time it was something else. I'll be the first to
admit that that's just dumb on my part, but it's worthwhile to point out
that no errors were reported. I mean 0 errors. The extensions,
justifiably, didn't show up on the info page, but neither did any sort
of error reports that the DLL mentioned doesn't exist (or something to
that effect). Furthermore, I did finally fix my spelling but the result
is still the same. If I make alterations by hand, the info page simply
doesn't reflect this. I even tried copying the INI file that was created
with the successful MySQL/i installation (where I enabled it in the
installer). When I tried this again by hand on my XP machine...just open
up the existing INI and dump the contents of the working one in
there...no changes! The phpinfo page does not show any MySQL instances
anywhere. If I uninstall and re-install with the extensions enabled,
however, they're there! And the INI files are, byte for byte, exactly
the same.


Previous Comments:
--------

[2007-11-05 15:51:21] patrick at baynewmedia dot com

*However*, the MySQLi extension didn't work (I'm running PHP5) ...
should've read:

*However*, the MySQLi extension didn't work (I'm running MySQL 5)

----

[2007-11-05 15:50:12] patrick at baynewmedia dot com

"Make sure that you enabled the mysqli extension ( or mysql if you are
connecting to a pre-4.1 server ) in the installation. I have done this
myself and libmysql.dll shows up in the installation directory."

I did this initially by hand. I added the "extension" directive into
the PHP.INI file when installing with no extensions. However, the
extension failed to show up when running php_info(). There was no error
to suggest it was missing or misspelled. Simply, nothing. The only way I
could run the MySQL extension was to specify it when running the
installer. *However*, the MySQLi extension didn't work (I'm running
PHP5). When I tried to run any simple scripts, I was simply told that
the MySQL extension wasn't loaded (no mention of mysqli). So I installed
again with both extensions enabled and the scripts now worked, except
that they warn that the multibyte string extension should also be
present. 

To sum up:
1. Installing the extensions by hand had no--I repeat--no effect. there
were no errors or messages indicating that something was wrong, the
extensions simply didn't show up.

2. Installing with mysqli only doesn't work. I keep getting asked for
the mysql extension instead. I am 100% certain I'm running MySQL 5.

3. Re-installing with both mysqli and mysql allows me to finally
connect *but* I get "missing multibyte string" extension.



[2007-11-05 12:39:12] [EMAIL PROTECTED]

Make sure that you enabled the mysqli extension ( or mysql if you are
connecting to a pre-4.1 server ) in the installation. I have done this
myself and libmysql.dll shows up in the installation directory.

You also don't need to add anything to the php.ini; the installer
enables the extension automatically. Furthermore, the line you added was
incorrect; it should have been:

extension=php_mysqli.dll
-or-
extension=php_mysql.dll




[2007-11-02 18:22:10] patrick at baynewmedia dot com

Okay, so I've cleaned up the php installation on my computer. I did a
full search through my entire system for the existence of "php.ini" just
to ensure that nothing was being left behind. I downloaded the Windows
installer from
http://ca3.php.net/get/php-5.2.4-win32-installer.msi/from/ca.php.net/mirror
and installed it. The default installation has all extensions disabled.
Maybe, I think, I'm being an idiot or losing my mind, so I pull up a
previous package I'd downloaded of 5.2.4. In that one, extensions are
all enabled! Is it possible that some mirrors are getting different
info? I'm using the Canadian one above and that's where I download all
my ZIPs/Installers from. But whatever, looks okay, and now it mimics the
torn-down installation I had previously where I disabled all the "bad"
DLLs.

However, the libmysql.dll file is nowhere to be found so...I grabbed
the ZIP package from
http://ca3.

#42613 [Asn]: Unable to load Dynamic Link Libraries - installer buggy

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 Assigned To:  jmertic
 New Comment:

*However*, the MySQLi extension didn't work (I'm running PHP5) ...
should've read:

*However*, the MySQLi extension didn't work (I'm running MySQL 5)


Previous Comments:
----

[2007-11-05 15:50:12] patrick at baynewmedia dot com

"Make sure that you enabled the mysqli extension ( or mysql if you are
connecting to a pre-4.1 server ) in the installation. I have done this
myself and libmysql.dll shows up in the installation directory."

I did this initially by hand. I added the "extension" directive into
the PHP.INI file when installing with no extensions. However, the
extension failed to show up when running php_info(). There was no error
to suggest it was missing or misspelled. Simply, nothing. The only way I
could run the MySQL extension was to specify it when running the
installer. *However*, the MySQLi extension didn't work (I'm running
PHP5). When I tried to run any simple scripts, I was simply told that
the MySQL extension wasn't loaded (no mention of mysqli). So I installed
again with both extensions enabled and the scripts now worked, except
that they warn that the multibyte string extension should also be
present. 

To sum up:
1. Installing the extensions by hand had no--I repeat--no effect. there
were no errors or messages indicating that something was wrong, the
extensions simply didn't show up.

2. Installing with mysqli only doesn't work. I keep getting asked for
the mysql extension instead. I am 100% certain I'm running MySQL 5.

3. Re-installing with both mysqli and mysql allows me to finally
connect *but* I get "missing multibyte string" extension.



[2007-11-05 12:39:12] [EMAIL PROTECTED]

Make sure that you enabled the mysqli extension ( or mysql if you are
connecting to a pre-4.1 server ) in the installation. I have done this
myself and libmysql.dll shows up in the installation directory.

You also don't need to add anything to the php.ini; the installer
enables the extension automatically. Furthermore, the line you added was
incorrect; it should have been:

extension=php_mysqli.dll
-or-
extension=php_mysql.dll


--------

[2007-11-02 18:22:10] patrick at baynewmedia dot com

Okay, so I've cleaned up the php installation on my computer. I did a
full search through my entire system for the existence of "php.ini" just
to ensure that nothing was being left behind. I downloaded the Windows
installer from
http://ca3.php.net/get/php-5.2.4-win32-installer.msi/from/ca.php.net/mirror
and installed it. The default installation has all extensions disabled.
Maybe, I think, I'm being an idiot or losing my mind, so I pull up a
previous package I'd downloaded of 5.2.4. In that one, extensions are
all enabled! Is it possible that some mirrors are getting different
info? I'm using the Canadian one above and that's where I download all
my ZIPs/Installers from. But whatever, looks okay, and now it mimics the
torn-down installation I had previously where I disabled all the "bad"
DLLs.

However, the libmysql.dll file is nowhere to be found so...I grabbed
the ZIP package from
http://ca3.php.net/get/php-5.2.4-Win32.zip/from/ca.php.net/mirror
copied it (the DLL) to the installation directory I added the extension
directive in the php.ini file:
extension=php_libmysql.dll
(the extension_dir is still "./" -- the default value). Restart my web
server (just to be sure)...and...nothing. "libmysql" (or anything
mentioning mysql) appears nowhere on the phpinfo page. I checked my
MySQL installation...ran the administration tool and it's up and
running. Maybe, I'm thinking, it's because I'm running it on a 64-bit
system so (drivers being not quite up to speed yet), I download the
32-bit version so everything runs virtualized. The 64-bit version gone
and the 32-bit version running, I try it again. Result: no change. The
libmysql.dll file is doing nothing. 

No go. Step 2: Re-install with MySQL (mysqli to be exact-for MySQL 5.0)
support enabled. The INI file is exactly the same as when I updated it
by hand (extension=php_mysqli.dll). The extension now shows up in the
list (so...why was my INI file not being read...even if there was an
error, wouldn't this have been mentioned?). I run my simple PHP script
to connect to the database and it chucks out an error saying that the
MySQL extension isn't loaded. Okay...re-install with *both* mysql

#42613 [Asn]: Unable to load Dynamic Link Libraries - installer buggy

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 Assigned To:  jmertic
 New Comment:

"Make sure that you enabled the mysqli extension ( or mysql if you are
connecting to a pre-4.1 server ) in the installation. I have done this
myself and libmysql.dll shows up in the installation directory."

I did this initially by hand. I added the "extension" directive into
the PHP.INI file when installing with no extensions. However, the
extension failed to show up when running php_info(). There was no error
to suggest it was missing or misspelled. Simply, nothing. The only way I
could run the MySQL extension was to specify it when running the
installer. *However*, the MySQLi extension didn't work (I'm running
PHP5). When I tried to run any simple scripts, I was simply told that
the MySQL extension wasn't loaded (no mention of mysqli). So I installed
again with both extensions enabled and the scripts now worked, except
that they warn that the multibyte string extension should also be
present. 

To sum up:
1. Installing the extensions by hand had no--I repeat--no effect. there
were no errors or messages indicating that something was wrong, the
extensions simply didn't show up.

2. Installing with mysqli only doesn't work. I keep getting asked for
the mysql extension instead. I am 100% certain I'm running MySQL 5.

3. Re-installing with both mysqli and mysql allows me to finally
connect *but* I get "missing multibyte string" extension.


Previous Comments:


[2007-11-05 12:39:12] [EMAIL PROTECTED]

Make sure that you enabled the mysqli extension ( or mysql if you are
connecting to a pre-4.1 server ) in the installation. I have done this
myself and libmysql.dll shows up in the installation directory.

You also don't need to add anything to the php.ini; the installer
enables the extension automatically. Furthermore, the line you added was
incorrect; it should have been:

extension=php_mysqli.dll
-or-
extension=php_mysql.dll


--------

[2007-11-02 18:22:10] patrick at baynewmedia dot com

Okay, so I've cleaned up the php installation on my computer. I did a
full search through my entire system for the existence of "php.ini" just
to ensure that nothing was being left behind. I downloaded the Windows
installer from
http://ca3.php.net/get/php-5.2.4-win32-installer.msi/from/ca.php.net/mirror
and installed it. The default installation has all extensions disabled.
Maybe, I think, I'm being an idiot or losing my mind, so I pull up a
previous package I'd downloaded of 5.2.4. In that one, extensions are
all enabled! Is it possible that some mirrors are getting different
info? I'm using the Canadian one above and that's where I download all
my ZIPs/Installers from. But whatever, looks okay, and now it mimics the
torn-down installation I had previously where I disabled all the "bad"
DLLs.

However, the libmysql.dll file is nowhere to be found so...I grabbed
the ZIP package from
http://ca3.php.net/get/php-5.2.4-Win32.zip/from/ca.php.net/mirror
copied it (the DLL) to the installation directory I added the extension
directive in the php.ini file:
extension=php_libmysql.dll
(the extension_dir is still "./" -- the default value). Restart my web
server (just to be sure)...and...nothing. "libmysql" (or anything
mentioning mysql) appears nowhere on the phpinfo page. I checked my
MySQL installation...ran the administration tool and it's up and
running. Maybe, I'm thinking, it's because I'm running it on a 64-bit
system so (drivers being not quite up to speed yet), I download the
32-bit version so everything runs virtualized. The 64-bit version gone
and the 32-bit version running, I try it again. Result: no change. The
libmysql.dll file is doing nothing. 

No go. Step 2: Re-install with MySQL (mysqli to be exact-for MySQL 5.0)
support enabled. The INI file is exactly the same as when I updated it
by hand (extension=php_mysqli.dll). The extension now shows up in the
list (so...why was my INI file not being read...even if there was an
error, wouldn't this have been mentioned?). I run my simple PHP script
to connect to the database and it chucks out an error saying that the
MySQL extension isn't loaded. Okay...re-install with *both* mysql and
mysqli enabled. Great. Now it's asking me for the multibyte string
extension. I add it to the PHP INI file from my ZIP and, *sigh*, not
there.

Well, this is light years ahead of where I was a month ago so I have to
say thanks for at least getting me this far. I was really going to give
u

#42613 [Asn]: Unable to load Dynamic Link Libraries - installer buggy

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 Assigned To:  jmertic
 New Comment:

Okay, so I've cleaned up the php installation on my computer. I did a
full search through my entire system for the existence of "php.ini" just
to ensure that nothing was being left behind. I downloaded the Windows
installer from
http://ca3.php.net/get/php-5.2.4-win32-installer.msi/from/ca.php.net/mirror
and installed it. The default installation has all extensions disabled.
Maybe, I think, I'm being an idiot or losing my mind, so I pull up a
previous package I'd downloaded of 5.2.4. In that one, extensions are
all enabled! Is it possible that some mirrors are getting different
info? I'm using the Canadian one above and that's where I download all
my ZIPs/Installers from. But whatever, looks okay, and now it mimics the
torn-down installation I had previously where I disabled all the "bad"
DLLs.

However, the libmysql.dll file is nowhere to be found so...I grabbed
the ZIP package from
http://ca3.php.net/get/php-5.2.4-Win32.zip/from/ca.php.net/mirror
copied it (the DLL) to the installation directory I added the extension
directive in the php.ini file:
extension=php_libmysql.dll
(the extension_dir is still "./" -- the default value). Restart my web
server (just to be sure)...and...nothing. "libmysql" (or anything
mentioning mysql) appears nowhere on the phpinfo page. I checked my
MySQL installation...ran the administration tool and it's up and
running. Maybe, I'm thinking, it's because I'm running it on a 64-bit
system so (drivers being not quite up to speed yet), I download the
32-bit version so everything runs virtualized. The 64-bit version gone
and the 32-bit version running, I try it again. Result: no change. The
libmysql.dll file is doing nothing. 

No go. Step 2: Re-install with MySQL (mysqli to be exact-for MySQL 5.0)
support enabled. The INI file is exactly the same as when I updated it
by hand (extension=php_mysqli.dll). The extension now shows up in the
list (so...why was my INI file not being read...even if there was an
error, wouldn't this have been mentioned?). I run my simple PHP script
to connect to the database and it chucks out an error saying that the
MySQL extension isn't loaded. Okay...re-install with *both* mysql and
mysqli enabled. Great. Now it's asking me for the multibyte string
extension. I add it to the PHP INI file from my ZIP and, *sigh*, not
there.

Well, this is light years ahead of where I was a month ago so I have to
say thanks for at least getting me this far. I was really going to give
up. But you can see how I'm slowly sliding down the same slope again.
The PHP.INI file, for some reason, is not being recognized. Or at least,
the changes I added are not being read. The MySQLi extension for MySQL5
does not appear to be the only one required (not sure if it's needed at
all...or what the reason behind this is). 

The thing that keeps bothering me is that I've done this many times
before. These extensions, at least, I'm familiar with and have updated
many times. So when I started running into these problems with the
current installer, it made me call into question what core changes have
been made. I've always had all extensions enabled, and just assumed
everything I would ever need would be there (including any MySQL
stuff)...and it was! It seems now that installations must be exclusive,
rather than inclusive (okay, as long as everyone understands that), and
the problem with the INI file is really beyond me. So...I'm closer...but
still can't get MySQL running fully. I suppose I could disable Multibyte
String support but I would prefer not to as I'm using it in some of my
sequel statements. Being able to load it would likely solve the problem.


Previous Comments:


[2007-11-02 17:13:23] patrick at baynewmedia dot com

Okay. I will try this and get back to you. However, I have re-installed
PHP about 20 times now and the result has been the same so I'm not
overly optimistic.



[2007-11-01 16:10:09] [EMAIL PROTECTED]

The default installer will not install any additional extensions other
than those which PHP is compiled with on Windows, which are:

bcmath
calendar
com_dotnet
ctype
date
dom
filter
ftp
hash
iconv
json
libxml
odbc
pcre
Reflection
session
SimpleXML
SPL
standard
tokenizer
wddx
xml
xmlreader
xmlwriter
zlib

For MySQL development, you'll want to also enable mysqli ( or mysql if
you are working with MySQL 4.0 or lesser ). Otherwise, nothing else
shou

#42613 [Asn]: Unable to load Dynamic Link Libraries - installer buggy

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 Assigned To:  jmertic
 New Comment:

Okay. I will try this and get back to you. However, I have re-installed
PHP about 20 times now and the result has been the same so I'm not
overly optimistic.


Previous Comments:


[2007-11-01 16:10:09] [EMAIL PROTECTED]

The default installer will not install any additional extensions other
than those which PHP is compiled with on Windows, which are:

bcmath
calendar
com_dotnet
ctype
date
dom
filter
ftp
hash
iconv
json
libxml
odbc
pcre
Reflection
session
SimpleXML
SPL
standard
tokenizer
wddx
xml
xmlreader
xmlwriter
zlib

For MySQL development, you'll want to also enable mysqli ( or mysql if
you are working with MySQL 4.0 or lesser ). Otherwise, nothing else
should need enabled.

I would recommend uninstalling PHP, removing the php.ini file left in
the directory, and reinstalling only adding the extension you need.



[2007-10-29 14:55:42] patrick at baynewmedia dot com

[EMAIL PROTECTED]: I'm trying really hard to be civil here. I really
can't explain why you keep reiterating the same things over and over
again when I have very specifically gone into great detail to explain
what's going on.

a) This is an issue both on Windows Vista *AND* Windows XP. I have
tried it on XP Home Edition, Professional, and the Entertainment edition
(whatever that's called). All three fail in exactly the same way. Again,
I'll refer you to the very first paragraph of the bug report...just
scroll all the way up and read it: "This was done on a NEW install of
Windows XP Pro as well
as Vista." 

b) You keep going on about installing extensions that I need only. This
is the fourth time I'm askingwhat extensions do I need?!? I want to
run MySQL but there is NO...I repeat...NO...documentation on extensions
that I should be excluding or including. I can infer, partially, the
extensions I may or may not need. Some are more obvious than others. If
it's a matter of choosing the default installation extensions, well,
they're ALL ENABLED BY DEFAULT! When I install, I hit "next", "next",
"next", "finish". I never choose the extensions, I don't even look at
the file list. So again...which ones do I need, and if I don't need them
all, why are they all enabled by default in the Windows installer? 

I'm really beyond baffled here. I mean, I don't want to be insulting
but I'm on the cusp of hurling out some rather harsh obscenities. I keep
asking the same questions...I keep getting the same responses that fail
to address any of the questions. Please...read again, I mean really
READ, and then respond. This is bordering on ludicrous now :(



[2007-10-29 12:01:36] [EMAIL PROTECTED]

I understand your concern about the problems you've had with the
installer. However, since I am not seeing you issue when using WinXP or
Win2003 ( I unfortuantely don't have a Vista machine to test on, though
others who have have reported back successful results on the whole ).

In reading your very descriptive post, the most likely scenerio you are
encountering comes down to two issues.

- Updating the PATH environment variable and the extension_dir
directive in the php.ini file, which the installer handles properly
setting for you.
- Installing extensions you don't need and/or don't have the supporting
libraries for. This is why I recommend to only install the supporting
libraries you need; many require third party libraries that we do not
ship with the installer for various reasons.

Thank you again for using the PHP Windows Installer and I hope to hear
feedback from you after trying the above things.






[2007-10-24 16:12:47] patrick at baynewmedia dot com

"Please reinstall with ONLY the extensions you need."

I wasn't going to write another follow-up but...are you [EMAIL PROTECTED] 
KIDDING
ME?!? What extensions do I need? How about you tell me! What the hell
have I been asking since day one?!? 
You guys are absolutely brutal. You keep going around like a broken
record; you keep saying the same things and when you can't get to the
bottom of the issue, you hand it off to someone else and they
do...EXACTLY THE SAME THING! 

I'm truly lost for words.



[2007-10-24 16:01:24] patrick at baynewmedia dot com

[EMAIL PROTECTED]: *sigh* Do

#42613 [Asn]: Unable to load Dynamic Link Libraries - installer buggy

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 Assigned To:  jmertic
 New Comment:

[EMAIL PROTECTED]: I'm trying really hard to be civil here. I really
can't explain why you keep reiterating the same things over and over
again when I have very specifically gone into great detail to explain
what's going on.

a) This is an issue both on Windows Vista *AND* Windows XP. I have
tried it on XP Home Edition, Professional, and the Entertainment edition
(whatever that's called). All three fail in exactly the same way. Again,
I'll refer you to the very first paragraph of the bug report...just
scroll all the way up and read it: "This was done on a NEW install of
Windows XP Pro as well
as Vista." 

b) You keep going on about installing extensions that I need only. This
is the fourth time I'm askingwhat extensions do I need?!? I want to
run MySQL but there is NO...I repeat...NO...documentation on extensions
that I should be excluding or including. I can infer, partially, the
extensions I may or may not need. Some are more obvious than others. If
it's a matter of choosing the default installation extensions, well,
they're ALL ENABLED BY DEFAULT! When I install, I hit "next", "next",
"next", "finish". I never choose the extensions, I don't even look at
the file list. So again...which ones do I need, and if I don't need them
all, why are they all enabled by default in the Windows installer? 

I'm really beyond baffled here. I mean, I don't want to be insulting
but I'm on the cusp of hurling out some rather harsh obscenities. I keep
asking the same questions...I keep getting the same responses that fail
to address any of the questions. Please...read again, I mean really
READ, and then respond. This is bordering on ludicrous now :(


Previous Comments:


[2007-10-29 12:01:36] [EMAIL PROTECTED]

I understand your concern about the problems you've had with the
installer. However, since I am not seeing you issue when using WinXP or
Win2003 ( I unfortuantely don't have a Vista machine to test on, though
others who have have reported back successful results on the whole ).

In reading your very descriptive post, the most likely scenerio you are
encountering comes down to two issues.

- Updating the PATH environment variable and the extension_dir
directive in the php.ini file, which the installer handles properly
setting for you.
- Installing extensions you don't need and/or don't have the supporting
libraries for. This is why I recommend to only install the supporting
libraries you need; many require third party libraries that we do not
ship with the installer for various reasons.

Thank you again for using the PHP Windows Installer and I hope to hear
feedback from you after trying the above things.






[2007-10-24 16:12:47] patrick at baynewmedia dot com

"Please reinstall with ONLY the extensions you need."

I wasn't going to write another follow-up but...are you [EMAIL PROTECTED] 
KIDDING
ME?!? What extensions do I need? How about you tell me! What the hell
have I been asking since day one?!? 
You guys are absolutely brutal. You keep going around like a broken
record; you keep saying the same things and when you can't get to the
bottom of the issue, you hand it off to someone else and they
do...EXACTLY THE SAME THING! 

I'm truly lost for words.



[2007-10-24 16:01:24] patrick at baynewmedia dot com

[EMAIL PROTECTED]: *sigh* Do you really want me to repeat everything
ANOTHER time? Did you bother to read any of the posts I made in this
thread? Your "advice" indicates you just skipped everything. I'm not
doing this again...scroll up this page to the top, and read. If you
can't be bothered, please hand this over to someone who cares.



[2007-10-24 11:52:57] [EMAIL PROTECTED]

A few things:

- You shouldn't need to set any PATH environment variables; the
installer does this for you.
- Likewise, you should not need to tweak anything else in the php.ini
file, unless you have some advanced directive that needs set. The
installer takes care of all typical things, including the extension_dir
setting.
- Please reinstall with ONLY the extensions you need.

It sounds like a combination of tweaking things that don't need tweaked
and trying to install everything by default is the culprit here. Let me
know if redoing the install with th

#40735 [Com]: stream_select returns 0 for php > 5.1.6

[patrick at chegg dot com]

 ID:   40735
 Comment by:   patrick at chegg dot com
 Reported By:  rodricg at sellingsource dot com
 Status:   Open
 Bug Type: Streams related
 Operating System: x86_64 GNU/Linux
 PHP Version:  5.2.3
 New Comment:

I'm also seeing this problem... the code from rodricg produces the same
(incorrect) result, returning Selected: 0. I was testing my own
application which is how I found the bug, but rodricg's test script
provides the same result. I do not have my original script, however I
had a working version and when I moved everything to a class the
incorrect return value became a problem, leading me to believe this is a
PHP bug.

This is also an x86_64 machine with openssl and curl.

$ php -v
PHP 5.2.3 (cli) (built: Oct 29 2007 00:07:41) 
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

PHP configure:
./configure --with-apxs2=/usr/local/apache/bin/apxs
--with-config-file-path=/etc --with-bz2 --enable-calendar --with-curl
--with-curlwrappers --with-inifile --enable-exif --enable-ftp --with-gd
--enable-json --with-mysql --with-mysqli --with-pdo-mysql --with-mssql
--enable-soap --enable-sockets --with-pear --with-xsl --with-zlib
--with-openssl --enable-pcntl

Send me an email, I will provide a test account as needed to those with
a @php.net email. Recompiling with -O1 did NOT solve the problem for me.


Previous Comments:


[2007-08-15 08:26:55] [EMAIL PROTECTED]

Nobody else is able to reproduce this on several different (or same)
types of systems -> bogus. (reopen if you can reproduce this on 2
different machines using Fedorda..I can't. :)



[2007-08-03 22:42:15] rodricg at sellingsource dot com

Just verified that I still see the same behavior with:
php-5.2.3
openssl-0.9.8e
gcc-4.1.2

I am using the same test script as before.  

Changing it to use:

-O1 --with-openssl
 *or*
-O2 --without-openssl
 
gives the correct behavior.



[2007-08-03 21:12:20] blade at debian dot org

It is even worse on the current Debian Sid, with 5.2.3-1+b1. It returns
0 and the modified arrays contain just nothing, but there is obviosly
data available there. Tested with slightly adapted code from 
http://netevil.org/blog/2005/may/guru-multiplexing .



[2007-03-16 23:06:09] [EMAIL PROTECTED]

I have a x86(-32) gentoo box with the same gcc version as you and your
script works perfectly. anyway if this is a compiler error, you need
report it to gentoo guys, that will then investigate to see if it is
caused by their patchset or not.



[2007-03-13 19:24:05] [EMAIL PROTECTED]

Still works perfectly fine with or without OpenSSL, with and without
-O2.
I think I'll need an acccount on your machine to reproduce it.



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

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

#42613 [Asn]: Unable to load Dynamic Link Libraries - installer buggy

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 Assigned To:  jmertic
 New Comment:

"Please reinstall with ONLY the extensions you need."

I wasn't going to write another follow-up but...are you [EMAIL PROTECTED] 
KIDDING
ME?!? What extensions do I need? How about you tell me! What the hell
have I been asking since day one?!? 
You guys are absolutely brutal. You keep going around like a broken
record; you keep saying the same things and when you can't get to the
bottom of the issue, you hand it off to someone else and they
do...EXACTLY THE SAME THING! 

I'm truly lost for words.


Previous Comments:
----

[2007-10-24 16:01:24] patrick at baynewmedia dot com

[EMAIL PROTECTED]: *sigh* Do you really want me to repeat everything
ANOTHER time? Did you bother to read any of the posts I made in this
thread? Your "advice" indicates you just skipped everything. I'm not
doing this again...scroll up this page to the top, and read. If you
can't be bothered, please hand this over to someone who cares.



[2007-10-24 11:52:57] [EMAIL PROTECTED]

A few things:

- You shouldn't need to set any PATH environment variables; the
installer does this for you.
- Likewise, you should not need to tweak anything else in the php.ini
file, unless you have some advanced directive that needs set. The
installer takes care of all typical things, including the extension_dir
setting.
- Please reinstall with ONLY the extensions you need.

It sounds like a combination of tweaking things that don't need tweaked
and trying to install everything by default is the culprit here. Let me
know if redoing the install with the above advice helps things out.

----

[2007-10-22 18:00:30] patrick at baynewmedia dot com

[EMAIL PROTECTED]:

No, no files were moved. Files were only copied in this way:

1. When all DLLs continued to fail to load from the original
installation directory (C:\PHP5\ext) I copied them (not moved, just
copied) to the root installation directory (C:\PHP5). Now they were
duplicated but at least they were being found. Any changes I made to the
PHP.ini file regarding the location of extensions seemed to have no
effect. I even tried setting it to weird and exotic locations like the
"Program Files" directories, and so on. However, they would only load
when together with the PHP executable and the INI settings had
absolutely no effect (i.e. regardless of where I specified the path, the
DLLs always loaded up from C:\PHP5).

2. I commented out the offending DLLs to get a basic PHP installation
running (still the same INI file). Now I was getting no errors and
phpinfo() showed that PHP was active albeit with no extended
functionality. At this point I tried getting MySQL enabled. I placed the
"libmysql.dll" file in all of the locations listed in previous entries
in this thread along with updating the INI file. I also did a full
system search to see if there were any other PHP initialization files
sitting anywhere on the system, and to see where all the MySQL DLLs
were. Only one INI file exists on my system, libmysql.dll exists in
about 6 different locations, and simply doesn't load (PHP can't find
it).

So to recap: Upon my initial install on a new machine, I only copied
the extension DLLs from "C:\PHP5\ext" to "C:\PHP5", effectively creating
two copies. Various combinations to the path settings for these
extensions resulted in the same thing: nothing. The extension DLLs are
only ever recognized when in the same directory as the PHP executable.
The only exception to this is the "libmysql.dll" file which fails to
load no matter where I put it (previous posts here should describe in
greater detail what was tried).

The result thus far is that about 60% of the original installation
extension DLLs can be loaded. The remainder (listed above) cannot. The
MySQL extension fails to load regardless of what I do with it or which
version it is. In case I'd forgotten to mention this, all of the above
attempts were tried as a regular user (with administrative privileges on
my Vista machine), and running as an Administrator. On my XP machine,
the results are exactly the same. I also had the thought that  Vista or
64-bit had something to do with these failures, but the XP machine is
32-bit, fully up-to-date and all else running smoothly.



[2007-10-22 13:39:26] [EMAIL PROTECTED]

Did you move the PHP directory or any of it's content

#42613 [Asn]: Unable to load Dynamic Link Libraries - installer buggy

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 Assigned To:  jmertic
 New Comment:

[EMAIL PROTECTED]: *sigh* Do you really want me to repeat everything
ANOTHER time? Did you bother to read any of the posts I made in this
thread? Your "advice" indicates you just skipped everything. I'm not
doing this again...scroll up this page to the top, and read. If you
can't be bothered, please hand this over to someone who cares.


Previous Comments:


[2007-10-24 11:52:57] [EMAIL PROTECTED]

A few things:

- You shouldn't need to set any PATH environment variables; the
installer does this for you.
- Likewise, you should not need to tweak anything else in the php.ini
file, unless you have some advanced directive that needs set. The
installer takes care of all typical things, including the extension_dir
setting.
- Please reinstall with ONLY the extensions you need.

It sounds like a combination of tweaking things that don't need tweaked
and trying to install everything by default is the culprit here. Let me
know if redoing the install with the above advice helps things out.

--------

[2007-10-22 18:00:30] patrick at baynewmedia dot com

[EMAIL PROTECTED]:

No, no files were moved. Files were only copied in this way:

1. When all DLLs continued to fail to load from the original
installation directory (C:\PHP5\ext) I copied them (not moved, just
copied) to the root installation directory (C:\PHP5). Now they were
duplicated but at least they were being found. Any changes I made to the
PHP.ini file regarding the location of extensions seemed to have no
effect. I even tried setting it to weird and exotic locations like the
"Program Files" directories, and so on. However, they would only load
when together with the PHP executable and the INI settings had
absolutely no effect (i.e. regardless of where I specified the path, the
DLLs always loaded up from C:\PHP5).

2. I commented out the offending DLLs to get a basic PHP installation
running (still the same INI file). Now I was getting no errors and
phpinfo() showed that PHP was active albeit with no extended
functionality. At this point I tried getting MySQL enabled. I placed the
"libmysql.dll" file in all of the locations listed in previous entries
in this thread along with updating the INI file. I also did a full
system search to see if there were any other PHP initialization files
sitting anywhere on the system, and to see where all the MySQL DLLs
were. Only one INI file exists on my system, libmysql.dll exists in
about 6 different locations, and simply doesn't load (PHP can't find
it).

So to recap: Upon my initial install on a new machine, I only copied
the extension DLLs from "C:\PHP5\ext" to "C:\PHP5", effectively creating
two copies. Various combinations to the path settings for these
extensions resulted in the same thing: nothing. The extension DLLs are
only ever recognized when in the same directory as the PHP executable.
The only exception to this is the "libmysql.dll" file which fails to
load no matter where I put it (previous posts here should describe in
greater detail what was tried).

The result thus far is that about 60% of the original installation
extension DLLs can be loaded. The remainder (listed above) cannot. The
MySQL extension fails to load regardless of what I do with it or which
version it is. In case I'd forgotten to mention this, all of the above
attempts were tried as a regular user (with administrative privileges on
my Vista machine), and running as an Administrator. On my XP machine,
the results are exactly the same. I also had the thought that  Vista or
64-bit had something to do with these failures, but the XP machine is
32-bit, fully up-to-date and all else running smoothly.



[2007-10-22 13:39:26] [EMAIL PROTECTED]

Did you move the PHP directory or any of it's contents after it was
installed?



[2007-10-22 11:26:50] [EMAIL PROTECTED]

Assigned to the installer maintainer.



[2007-10-18 16:21:28] patrick at baynewmedia dot com

mfvivino at vivmedia dot net:
That's another interesting problem and frankly I don't expect the path
to be missing for seemingly no reason. I'll keep my eyes open for that
and see if it does the trick. Thanks for the research though I'm still
of the opinion that this shouldn't be required ;)

#42613 [Asn]: Unable to load Dynamic Link Libraries - installer buggy

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 Assigned To:  jmertic
 New Comment:

[EMAIL PROTECTED]:

No, no files were moved. Files were only copied in this way:

1. When all DLLs continued to fail to load from the original
installation directory (C:\PHP5\ext) I copied them (not moved, just
copied) to the root installation directory (C:\PHP5). Now they were
duplicated but at least they were being found. Any changes I made to the
PHP.ini file regarding the location of extensions seemed to have no
effect. I even tried setting it to weird and exotic locations like the
"Program Files" directories, and so on. However, they would only load
when together with the PHP executable and the INI settings had
absolutely no effect (i.e. regardless of where I specified the path, the
DLLs always loaded up from C:\PHP5).

2. I commented out the offending DLLs to get a basic PHP installation
running (still the same INI file). Now I was getting no errors and
phpinfo() showed that PHP was active albeit with no extended
functionality. At this point I tried getting MySQL enabled. I placed the
"libmysql.dll" file in all of the locations listed in previous entries
in this thread along with updating the INI file. I also did a full
system search to see if there were any other PHP initialization files
sitting anywhere on the system, and to see where all the MySQL DLLs
were. Only one INI file exists on my system, libmysql.dll exists in
about 6 different locations, and simply doesn't load (PHP can't find
it).

So to recap: Upon my initial install on a new machine, I only copied
the extension DLLs from "C:\PHP5\ext" to "C:\PHP5", effectively creating
two copies. Various combinations to the path settings for these
extensions resulted in the same thing: nothing. The extension DLLs are
only ever recognized when in the same directory as the PHP executable.
The only exception to this is the "libmysql.dll" file which fails to
load no matter where I put it (previous posts here should describe in
greater detail what was tried).

The result thus far is that about 60% of the original installation
extension DLLs can be loaded. The remainder (listed above) cannot. The
MySQL extension fails to load regardless of what I do with it or which
version it is. In case I'd forgotten to mention this, all of the above
attempts were tried as a regular user (with administrative privileges on
my Vista machine), and running as an Administrator. On my XP machine,
the results are exactly the same. I also had the thought that  Vista or
64-bit had something to do with these failures, but the XP machine is
32-bit, fully up-to-date and all else running smoothly.


Previous Comments:


[2007-10-22 13:39:26] [EMAIL PROTECTED]

Did you move the PHP directory or any of it's contents after it was
installed?



[2007-10-22 11:26:50] [EMAIL PROTECTED]

Assigned to the installer maintainer.

--------

[2007-10-18 16:21:28] patrick at baynewmedia dot com

mfvivino at vivmedia dot net:
That's another interesting problem and frankly I don't expect the path
to be missing for seemingly no reason. I'll keep my eyes open for that
and see if it does the trick. Thanks for the research though I'm still
of the opinion that this shouldn't be required ;)



[2007-10-16 11:00:20] mfvivino at vivmedia dot net

It gets weirder for me.

I experienced tons of problems with the installer, so scrapped that
(did uninstall) and installed manually via .zip which was easy enough. I
ONLY enabled mysql, and amazingly enough, it worked!.  I ran a simple
test:

   

which reported mysql as enabled; and I was subsequently able to install
PHP shopping cart software.  So far, so good...

Now for the fun part: after rebooting the machine, mysql is being
reported as not enabled anymore, so I checked the apache log and sure
enough, I see the same cryptic error as others have reported here:

   PHP Warning: PHP Startup: Unable to load dynamic library
'c:/php52/etx\\php_mysql.dll' - The specified module could not be found.
\r\n in Unknown on line 0.

And now of course phpinfo() shows mysql indeed is missing

I thought perhaps the reference to '\r\n' had something to do with
windows linefeeds, so I ran a dos2unix conversion on the php.ini file --
no go.  Still the same problem. 

For fun, I tried disabling mysql and enabling a different module. 
Doesn't seem to matter, get the same problem wit

#42613 [Opn]: Unable to load Dynamic Link Libraries

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Open
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 New Comment:

mfvivino at vivmedia dot net:
That's another interesting problem and frankly I don't expect the path
to be missing for seemingly no reason. I'll keep my eyes open for that
and see if it does the trick. Thanks for the research though I'm still
of the opinion that this shouldn't be required ;)


Previous Comments:


[2007-10-17 11:28:46] mfvivino at vivmedia dot net

Patrick at BayNewMedia:  Thanks for the suggestion.  That was not the
issue for me, however, it was close.  Evidently the sequence of events
went like this:

  (1) Automated install put c:\php52 (my install dir) in the path
  (2) Automated install otherwise screwed up royally
  (3) I uninstalled -- removing c:\php52 from the path! -- only this
was not going take effect for system services (like Apache) until after
a reboot, whenever I happened to do that 
  (4) Did manual install and configuration, tested; I've done enough of
these on Windows before to be sure the path is properly set, buy hey, it
was working, and I wasn't thinking! ;) All looked good for
awhile...except after a reboot some days later, the path was now
missing.

So the fix for me was simple:

  (5) Added c:\php52 back to the path and rebooted.

All appears well enough now...so far.

However, the win32 installer, as has been pointed out elsewhere here,
is a major train wreck and source of confusion.  I suspect unix/linux
platforms get the priority in terms of attention here, and perhaps
that's why responses have not been so forthcoming?  Still, I suggest
that PHP development folks either tighten up and clarify the win32
installer, or pull it entirely, in favor of one clear and simple win32
installation guide. After all, the PHP site already "recommends" a
manual installation in favor of the automated one in any case.  After
this experience, I very, very strongly second that recommendation.  

My $0.02.

--------

[2007-10-16 15:50:27] patrick at baynewmedia dot com

[EMAIL PROTECTED]: I did in fact select everything to install. I was
under the assumption (mistaken, it seems), that installation doesn't
necessarily mean enabling. After all, if I don't install now but at some
point in the future decide that I need a new extension, I could simply
enable it instead of having to re-install or re-download another
package. But that's something to try so I'll give it a whirl. Still
doesn't seem like it should work this way though. Maybe the addition of
"enabled extensions" in the installation routine may be useful.

mfvivino at vivmedia dot net: Wow, that is a little slice of
frustration! The thing I found with the PHP.INI file is that, despite
loading from a specific location at the time of installation, that
location changes on subsequent executions or after reboots. For example,
my first installation was in C:\PHP and the INI file loaded from there.
I changed a variety of settings in the INI file which were reflected in
the next few rounds of execution. One of the suggestions in getting
MySQL going was re-booting so I did and after that, the INI file "could
not be found". It was still there, but after some searching I discovered
it was trying to load from C:\WINDOWS. Why? Who knows...there was no
PATH environment variable pointing there (only to C:\PHP), and there
were no paths within the INI file itself to anything other than C:\PHP
and its subdirectories. Again, this was another case where people were
noting these bugs but the folks at PHP kept insisting there was nothing
for them to fix.

Look, I'm a developer and my work is often far from perfect. I tend to
suspect that there's misuse of my software when people report errors and
I can understand why the people at PHP would tend towards this as well.
At this point, however, it just seems like people are burying their head
in the sand. We've all been through the "fixes" here, I'm sure, and it's
still failing dismally. That part doesn't bother me at all; what I don't
like is that beside these relatively simple fixes, the issue seems to be
being ignored. I can run PHP but for most of the applications I need it
for now, it's useless. It's at a point where I simply *can't* run it for
any useful purposes so the entire PHP project is basically a brick. The
complete lack of concern (or if it's there, I'm not hearing a peep about
it), is the most troubling aspect of this whole fiasco. Again, is anyone
out there listening and looking at this problem? I'm referring

#42613 [Opn]: Unable to load Dynamic Link Libraries

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
 Status:   Open
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 New Comment:

[EMAIL PROTECTED]: I did in fact select everything to install. I was
under the assumption (mistaken, it seems), that installation doesn't
necessarily mean enabling. After all, if I don't install now but at some
point in the future decide that I need a new extension, I could simply
enable it instead of having to re-install or re-download another
package. But that's something to try so I'll give it a whirl. Still
doesn't seem like it should work this way though. Maybe the addition of
"enabled extensions" in the installation routine may be useful.

mfvivino at vivmedia dot net: Wow, that is a little slice of
frustration! The thing I found with the PHP.INI file is that, despite
loading from a specific location at the time of installation, that
location changes on subsequent executions or after reboots. For example,
my first installation was in C:\PHP and the INI file loaded from there.
I changed a variety of settings in the INI file which were reflected in
the next few rounds of execution. One of the suggestions in getting
MySQL going was re-booting so I did and after that, the INI file "could
not be found". It was still there, but after some searching I discovered
it was trying to load from C:\WINDOWS. Why? Who knows...there was no
PATH environment variable pointing there (only to C:\PHP), and there
were no paths within the INI file itself to anything other than C:\PHP
and its subdirectories. Again, this was another case where people were
noting these bugs but the folks at PHP kept insisting there was nothing
for them to fix.

Look, I'm a developer and my work is often far from perfect. I tend to
suspect that there's misuse of my software when people report errors and
I can understand why the people at PHP would tend towards this as well.
At this point, however, it just seems like people are burying their head
in the sand. We've all been through the "fixes" here, I'm sure, and it's
still failing dismally. That part doesn't bother me at all; what I don't
like is that beside these relatively simple fixes, the issue seems to be
being ignored. I can run PHP but for most of the applications I need it
for now, it's useless. It's at a point where I simply *can't* run it for
any useful purposes so the entire PHP project is basically a brick. The
complete lack of concern (or if it's there, I'm not hearing a peep about
it), is the most troubling aspect of this whole fiasco. Again, is anyone
out there listening and looking at this problem? I'm referring to the
core PHP developers...does anyone even care that PHP just doesn't have
much useful functionality left? Has the PHP project simply been
abandoned? It's been two months since I posted this report and no one
has mentioned "Oh...it's being looked at now." As far as I can see,
absolutely zilch is being done about this. That is, if anyone is even
aware that these problems exist.

I'm not expecting quick fixes and maybe there's no simple solution, but
is anyone even aware? I greatly appreciate the community involvement in
trying to address these issues, but this is CORE, BASIC stuff, and no
one seems to be bothered by it in the least. Very, very discouraging.
Python, Ruby, or Java may be good alternatives. Sucks that I'm being
forced to switch because of just plain indifference :(


Previous Comments:


[2007-10-16 11:00:20] mfvivino at vivmedia dot net

It gets weirder for me.

I experienced tons of problems with the installer, so scrapped that
(did uninstall) and installed manually via .zip which was easy enough. I
ONLY enabled mysql, and amazingly enough, it worked!.  I ran a simple
test:

   

which reported mysql as enabled; and I was subsequently able to install
PHP shopping cart software.  So far, so good...

Now for the fun part: after rebooting the machine, mysql is being
reported as not enabled anymore, so I checked the apache log and sure
enough, I see the same cryptic error as others have reported here:

   PHP Warning: PHP Startup: Unable to load dynamic library
'c:/php52/etx\\php_mysql.dll' - The specified module could not be found.
\r\n in Unknown on line 0.

And now of course phpinfo() shows mysql indeed is missing

I thought perhaps the reference to '\r\n' had something to do with
windows linefeeds, so I ran a dos2unix conversion on the php.ini file --
no go.  Still the same problem. 

For fun, I tried disabling mysql and enabling a different module. 
Doesn't seem to matter, get the same problem with any and all.

As othe

#42613 [NoF->Opn]: Unable to load Dynamic Link Libraries

[patrick at baynewmedia dot com]

 ID:   42613
 User updated by:  patrick at baynewmedia dot com
 Reported By:  patrick at baynewmedia dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: *General Issues
 Operating System: Windows XP Pro & Windows Vista
 PHP Version:  5.2.4
 New Comment:

Good to see that absolutely no progress has been made. Does anyone
actually read these bug reports or what?

[EMAIL PROTECTED]: If you'd bothered to read what I'd posted, I said I
didn't know if I needed all these extensions. They're not listed
anywhere and the default php.ini file comes with all of them enabled.
Your suggestion "How about the basic .zip file, just unpack that and try
with
it instead..? " is exactly the type of piddly suggestion I was
referring to. It's dismissive and insulting and yes, I tried that many
times.

azlan01: Good suggestion and thank you for not assuming I'm a complete
idiot. Unfortunately, that didn't make any difference. The pear
extensions also give me some trouble though somewhat less than the
default ones. I've tried disabling all of the extensions erroneously
listed in pop-ups...I say erroneously because the pop-up messages don't
match the ones on the command line when I run PHP. That's just another
problem with the latest PHP release but hardly the biggest.

So, now I have a working PHP install once I've disable all of the
erroneous DLLs (not all are problematic...anyone care to explain why?).
Unfortunately, trying to access a MySQL database has proven to be a
complete dead-end. The "libmysql.dll" file simply fails to load. Period.
I put it in Windows, Windows/system, windows/system32, the php install
directory, the php extensions directory, the c:\ drive; added PATH
directions to it...heck, I pointed the php.ini file *directly* at it
using a full path. Simply, it doesn't load. I tried a myriad version of
the file ranging from the version 4 (PHP) DLL up to the version 5 one,
also including the newest ones from MySQL.org. Still nothing. 

Please please please don't keep ignoring these problems! Maybe there's
a very good reason why I can't run PHP successfully but so far the only
suggestion has been that it's somehow my fault or that during the last
two months I've somehow overlooked the glaringly obvious. "No feedback
was provided for this bug for over a week, so it is
being suspended automatically." ... won't make it go away! Someone
please take some responsibility and look into this!


Previous Comments:


[2007-10-08 19:33:24] parasite84 at mail dot ru

Me too

PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\mysql.so' - The specified module
could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_exif.dll' - The specified module
could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_oci8.dll' - The specified module
could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_openssl.dll' - The operating
system cannot run %1.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_pdo_oci.dll' - The specified
module could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_pdo_oci8.dll' - The specified
module could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_pdo_sqlite_external.dll' - The
specified module could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_pspell.dll' - The specified
module could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_sybase_ct.dll' - The specified
module could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_ibm_db2.dll' - The specified
module could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_ifx.dll' - The specified module
could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\\WebDev\\usr\\local\\PHP\\ext\\php_ingres.dll' - The specified
module could not be found.\r\n in Unknown on

#42814 [NEW]: get_object_vars() fails again on private scope

[patrick dot stadler at gmail dot com]

From: patrick dot stadler at gmail dot com
Operating system: Debian Stable
PHP version:  5.2.4
PHP Bug Type: Class/Object related
Bug description:  get_object_vars() fails again on private scope

Description:

It seems that http://bugs.php.net/bug.php?id=40757 is back again with PHP
5.2.4. 

5.2.4 : get_object_vars($this) does _not_ return private vars.
5.2.3 : get_object_vars($this) does return private vars.

Nothing more to say about. Just use the code from #40757 to reproduce this
bug.



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

#42613 [NEW]: Unable to load Dynamic Link Libraries

[patrick at baynewmedia dot com]

From: patrick at baynewmedia dot com
Operating system: Windows XP Pro & Windows Vista
PHP version:  5.2.4
PHP Bug Type: *Configuration Issues
Bug description:  Unable to load Dynamic Link Libraries

Description:

I have seen this posted on numerous other forums and, oddly, listed
numerous times as bogus or closed with minimal feedback here. However,
despite trying nearly all the suggestions I've found and despite being a
heavy user of PHP since version 3, the newest one has some serious issues
when loading DLLs at startup.

First of all, I downloaded the Windows installer and installed into
"C:\PHP5". I set the PATH environment variable to "C:\PHP5; C:\PHP5\ext".
This was done on a NEW install of Windows XP Pro as well as Vista.

Upon installation, I updated the "php.ini" to read:
...

; Directory in which the loadable extensions (modules) reside.
extension_dir ="C:\PHP5\ext"

When I ran PHP, it popped up a series of "unable to load Dynamic Link
Library" warnings. I moved all the extension DLLs into the C:\PHP5
directory and updated the INI file to read:

; Directory in which the loadable extensions (modules) reside.
extension_dir ="C:\PHP5"

This resulted in the same error (see code section below for errors).

I updated the INI to read:

; Directory in which the loadable extensions (modules) reside.
extension_dir ="\PHP5"

...then...

; Directory in which the loadable extensions (modules) reside.
extension_dir =".\"

...then...

; Directory in which the loadable extensions (modules) reside.
extension_dir ="."

...and...

; Directory in which the loadable extensions (modules) reside.
extension_dir =""

Finally, I repeated these steps using forward slashes in the path instead.
For example: extension_dir ="C:/PHP5"

None of these combinations resulted in any changes to the error messages.
I commented out the offending libraries and got PHP to run. I then decided
to try my luck with MySQL so I downloaded it, installed it, and tried a
basic connection. I got the error that the library "libmysql.dll" could not
be found. Again, I went through page after page of advice on this issue:
Update the DLL using MySQL's code, put the DLL into C:\, put it into
C:\WINDOWS, then C:\WINDOWS\SYSTEM32, the C:\WINDOWS\SYSTEM (and the
equivalents on Windows Vista). I set various security settings, added the
path to the PATH environment variable, and basically ran the gamut of tests
and fixes I could find both here on the PHP bug reports and on other sites
where these bugs are increasingly numerous.

Folks, PHP 5.2.4 simply doesn't work right! As mentioned, I've been using
it now since version 3 and I have NEVER encountered the incredible level of
frustration in trying to set up a simple PHP installation as this. If the
offending DLLs shouldn't be enabled by default, why are they? Why does the
pop-up dialog not state the file name correctly when reporting the DLL? Is
it that the DLLs can't be found (because I assure you they ARE there) or
because there's another problem with them? Finally, why is libmysql.dll
failing? What's happened in the previous few versions that the Windows
installation process is now, basically, not working?

Please don't respond with a piddly trifling response to this. I'm a web
developer and know my way around my system. I've been banging my head
against the wall with this for over a week. Reading responses here like
"you probably forgot to set the PATH" is frankly insulting. I've been
trying to fix this installation now for over a week using a wonderful array
of INI/PATH settings and have not found a solution that works. On Vista I
managed to at least get phpinfo() working (no extra modules like MySQL
loading but at least something)...but on XP Pro, I can't even execute a
script from the command line because:

"The specified module(s) could not be found."

Please...can someone offer a real, working solution that doesn't assume
that I've missed the basic, general setup stuff?

Thanks,
P

Reproduce code:
---
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\php5\php_oci8.dll'
 - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\php5\php_pdo_oci.d
ll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\php5\php_pdo_oci8.
dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\php5\php_pdo_sqlit
e_external.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library
'C:\php5\php_pspell.dl
l' - The sp

#41848 [NEW]: chm french

[patrick dot izzo at free dot fr]

From: patrick dot izzo at free dot fr
Operating system: xp
PHP version:  5.2.3
PHP Bug Type: *General Issues
Bug description:  chm french

Description:

Help
I can't download the french help chm
I'll have try with fire fox and explorer
I don't have a message ou buton to approve the download
But after the chm don't work
I prefer use this format than html
What can i do ??

Sorry for my bad english (i'm french)

Thank


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

#41052 [NEW]: proc_get_status still returns wrong PID (-> closed bug 38542)!

[patrick dot pomme at rtl dot de]

From: patrick dot pomme at rtl dot de
Operating system: Windows XP
PHP version:  5.2.2RC1
PHP Bug Type: Program Execution
Bug description:  proc_get_status still returns wrong PID (-> closed bug 38542)!

Description:

Under Windows XP and server 2003, proc_get_status returns a wrong PID.
While executing a system command I wanted to know its PID to be able to
close it after a defined timeout

Reproduce code:
---
$cmd = "ping -t video-jobcoder";

$descriptorspec = array(
   0 => array("file", "stdin.txt", "a"),  // stdin is a pipe that the
child will read from
   1 => array("file", "stdout.txt", "a"),  // stdout is a pipe that the
child will write to
   2 => array("file", "stderr.txt", "a") // stderr is a file to write to
);

$process = proc_open($cmd, $descriptorspec, $pipes);
$pinfo = proc_get_status($process);
print_r($pinfo);


$timeout = 5;
while(@proc_get_status($process)){
echo "$timeout..";
sleep(1);
$timeout--;
if($timeout == 0) {
echo "\r\nTimeout! Killing process with PID ".$pinfo[pid]."!";
exec($path_to_pskill."pskill -t ".$pinfo[pid]." 2>nul", 
$res_pskill);
for ($i=count($res_pskill)-3; $ihttp://bugs.php.net/?id=41052&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41052&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41052&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41052&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41052&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41052&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41052&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41052&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41052&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41052&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41052&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41052&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41052&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41052&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41052&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41052&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41052&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41052&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41052&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41052&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41052&r=mysqlcfg

#40290 [NEW]: strtotime() returns unexpected result with particular timezone offset

[patrick at papaq dot org]

From: patrick at papaq dot org
Operating system: Win32/CentOS/Fedora
PHP version:  5.2.0
PHP Bug Type: Date/time related
Bug description:  strtotime() returns unexpected result with particular 
timezone offset

Description:

When using strtotime() to parse a date string with a certain timezone
offset it returns an incorrect result.

I got this kind of a timezone "Tue, 30 Jan 2007 12:27:00 +0001" from an
rss feed. Although they actually mean "+0100" strtotime() should return a
time with one minute difference, not 1 month.

Reproduce code:
---


Expected result:

2007-01-31 01:26:00

Actual result:
--
2007-03-04 13:27:00

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

#38584 [NEW]: Segmentation Fault when smarty generates error dialog

[patrick at studioemma dot com]

From: patrick at studioemma dot com
Operating system: Redhat ES3
PHP version:  4.4.4
PHP Bug Type: *General Issues
Bug description:  Segmentation Fault when smarty generates error dialog

Description:

When a compiled template with a error in it (eg not using $ sign when
inserting a var) is used and smarty debugging is on, sometimes (half of
the times) a segmentation fault occurs.


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

#37383 [NEW]: scope of static variable in class member function exists in all object instance

[patrick at factorylabs dot com]

From: patrick at factorylabs dot com
Operating system: Windows
PHP version:  5.1.4
PHP Bug Type: Scripting Engine problem
Bug description:  scope of static variable in class member function exists in 
all object instance

Description:

Given a member function of a class that has a static variable; the value
of the static variable, when changed, is propagated to all object
instances of the class.  (note: may be a duplicate of #16245)

The code below is strictly intended to demonstrate this issue (having a
static variable in a constructor is pointless).

Note that removing the static key word from the $bSwitch declaration
causes the $bSwitch variable to operate with a scope that is unique to the
instance of the class.



Reproduce code:
---
define('endl', "\n");

class CMyWidget {
public function __construct() {
static $bSwitch = false;
echo '$bSwitch = ' . ($bSwitch ? 'true' : 'false') . endl;
if($bSwitch === false)
$bSwitch = true;
}
}

$oTest1 = new CMyWidget();
$oTest2 = new CMyWidget();

Expected result:

$bSwitch = false
$bSwitch = false

Actual result:
--
$bSwitch = false
$bSwitch = true

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

#36323 [NEW]: /usr/informix/lib/esql/checkapi.o is not valid

[patrick at imptoy dot com]

From: patrick at imptoy dot com
Operating system: IBM AIX 5.3L
PHP version:  5CVS-2006-02-07 (CVS)
PHP Bug Type: Compile Failure
Bug description:  /usr/informix/lib/esql/checkapi.o is not valid

Description:

Unable to build with informix support

Reproduce code:
---
./configure --with-apxs=/usr/local/apache/bin/apxs 
--enable-ftp --enable-magic-quotes --enable-track-vars
--with-gettext --with-mysql --with-regex=system
--with-informix=/usr/informix



Expected result:

Sucessful build

Actual result:
--
*** Warning: Linking the shared library libphp5.la against the
non-libtool
*** objects  /usr/informix/lib/esql/checkapi.o is not portable!
0654-210 /usr/informix/lib/esql/checkapi.o is not valid in the current
object fi
le mode.
Use the -X option to specify the desired object mode.
ld: 0711-736 ERROR: Input file /usr/informix/lib/esql/checkapi.o:
XCOFF64 object files are not allowed in 32-bit mode.
collect2: ld returned 8 exit status
make: 1254-004 The error code from the last command is 1.


Stop.


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

#35461 [Com]: Ming extension fails to compile

[patrick at pmenier dot dynalias dot net]

 ID:   35461
 Comment by:   patrick at pmenier dot dynalias dot net
 Reported By:  hostmaster at xenterra dot net
 Status:   Assigned
 Bug Type: Ming related
 Operating System: Slackware Linux 10.2
 PHP Version:  5CVS-2005-11-29 (snap)
 Assigned To:  helly
 New Comment:

Same problem on debian 3.1 sarge. Compile fails if i use bundled ming
or debian libming.


Previous Comments:


[2005-11-29 19:29:56] hostmaster at xenterra dot net

The snapshot php5-200511291530 failed to compile with ext/ming with
essentially the same error messages as were originally reported (see
Actual Result below). It appears that the ming extension code has not
yet been re-worked.



[2005-11-29 10:10:12] [EMAIL PROTECTED]

Could you plz try newer snapshot?
>From what I can see, the problem still exists in the snapshot you've
tried and has been fixed in newer ones.



[2005-11-29 00:29:57] hostmaster at xenterra dot net

Per your suggestion:
http://snaps.php.net/php5-latest.tar.gz is, in fact,
php5-200511282130.tar.gz, which is the CVS version I said I tried. It
did not compile ext/ming with "latest" either.



[2005-11-29 00:03:21] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Most likely fixed in CVS.



[2005-11-28 23:56:40] hostmaster at xenterra dot net

Description:

No script; this is a compile error.
Configure options:
./configure --with-apxs=/usr/local/apache/bin/apxs \
--with-pgsql=/usr/local/pgsql \
--enable-dba \
--with-flatfile \
--with-openssl \
--enable-exif \
--with-gd=/usr/local/gd-2.0.33 \
--with-jpeg-dir=/usr/lib \
--with-png-dir=/usr/lib \
--with-zlib-dir=/usr/lib \
--with-xpm-dir=/usr/X11R6/lib \
--with-imap=/usr/local/imap-2002d \
--with-imap-ssl=/usr/local/ssl \
--with-curl \
--with-curlwrappers \
--enable-ftp \
--enable-soap \
--with-libxml-dir=/usr/local/lib \
--with-ming=/usr/local/lib \
--enable-sockets

Compilation also failed using CVS snapshot php5-200511282130 on
Slackware 10.2, and on Slackware 10.1 using official release.

Ming version is ming-0.3beta1.

Reproduce code:
---
No code.

Expected result:

N/A

Actual result:
--
Following is gcc output right before "make" quit:

/usr/local/php-5.1.1/ext/ming/ming.c: In function
`zif_swfbitmap___construct':
/usr/local/php-5.1.1/ext/ming/ming.c:386: warning: assignment from
incompatible pointer type
/usr/local/php-5.1.1/ext/ming/ming.c: In function
`zif_swfmovie_output':
/usr/local/php-5.1.1/ext/ming/ming.c:2267: error: too few arguments to
function `SWFMovie_output'
/usr/local/php-5.1.1/ext/ming/ming.c: In function
`zif_swfmovie_saveToFile':
/usr/local/php-5.1.1/ext/ming/ming.c:2329: error: too few arguments to
function `SWFMovie_output'
/usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swfmovie_save':
/usr/local/php-5.1.1/ext/ming/ming.c:2380: error: too few arguments to
function `SWFMovie_output'
/usr/local/php-5.1.1/ext/ming/ming.c:2399: error: too few arguments to
function `SWFMovie_output'
/usr/local/php-5.1.1/ext/ming/ming.c: In function
`zif_swftextfield_setFont':
/usr/local/php-5.1.1/ext/ming/ming.c:3741: warning: passing arg 2 of
`SWFTextField_setFont' from incompatible pointer type
make: *** [ext/ming/ming.lo] Error 1






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

#27406 [Com]: php_check_syntax executes code

[patrick at 5etdemi dot com]

 ID:   27406
 Comment by:   patrick at 5etdemi dot com
 Reported By:  thomas at stauntons dot org
 Status:   Assigned
 Bug Type: Unknown/Other Function
 Operating System: All
 PHP Version:  php5.0-200412100930
 Assigned To:  iliaa
 New Comment:

If the file that is syntax checked has includes, the includes won't be
executed. That means as soon as you use php_check_syntax on such a
file, you won't be able to include it and you won't be able to use it
either because it's included files are MIA. That makes the function
pretty useless for any practical purposes.


Previous Comments:


[2005-03-07 22:59:52] linus at mccabe dot nu

Another important use for this function would be when using eval()'s to
test the code before eval'ing it. In this case a string would be the
only option and declaring functions would definately not work...

Since this function isn't experimental any more, I assume it cant be
altered to do this, but a new one would need to be implemented?



[2005-03-03 08:30:18] phpbugs at majiclab dot com

I would have to agree with most of the other posters, that the
php_check_syntax() function as it stands right now does MORE than its
name implies.  I feel that a true php_check_syntax() function that
STRICTLY checks the syntax of a file or string and returns TRUE/FALSE
and has reference to an error message is the best.  In fact, I would
also like to see the possibility of having an additional reference
variable for the line number of an error.

I am developing a fairly advanced framework that does compile certain
aspects of a web site dynamically.  At first glance, I tried to
implement this function to check the syntax of the file both before
saving it and even before including it in the future.  However, I ran
into some confusing messages about my classes being redefined and I
couldn't understand until I read the docs closer.

The simple fact is that the REAL functionality of this function is the
syntax checking, NOT the including.  Any PHP programmer with more than
5 minutes of experience can probably include an external file.  So
adding that particular aspect of the functionality to
php_check_syntax() seems useless.  The code I have in my system goes a
little like this:



Now, I started getting errors all of a sudden saying that a class in
the file being included is being redeclared.  I thought that odd since
I set $bOnce = TRUE, so it shouldn't ever be included more than once. 
I think ideally I should be able to do this:



Basically, it should:

1. Not include the file at all, just strictly do a lint check.
2. It would be nice to be able to get the line number of the file (for
debugging purposes).

At the lowest level, this function should be able to run like described
by many others:



It should be up to the PHP programmer to include the file...



[2005-02-23 17:32:01] de_bruut at hotmail dot com

Couple of points:

1. there are already half a dozen functions that include files or
execute strings
2. there's no other function that allows you to check the validity of a
piece of php code
3. right now, php_check_syntax does more than its name implies (it
includes the file)
4. there are several situations where a 'clean' lint check of php code
is useful (snippet submissions, UNIT TESTS(!), ...)
5. in general, functions should do only one thing, not two only
slightly related things, and one of them badly

I would love to see php_check_syntax implemented as its name implies: a
lint check for a STRING. Not a file (see Wylie's comment), because there
are enough functions to read a file  or stream into a string.

If someone wants to include the file afterwards, they only need to add
a single line of code, or they can write their own two-line function.
This even leaves them the choice between include() and include_once(),
something which php_check_syntax does not do at this point.

Did I mention the potential value of php_check_syntax for >> UNIT TESTS
<< yet? php_check_syntax would allow us to check the syntax of a file
(string) as the first of a group of tests for that file/class, and thus
avoiding a potential fatal error, which could interrupt an entire set of
tests on multiple files. Thus, a syntax check could make quite a number
of very serious PHP developers very happy. Not much point if
php_check_syntax immediately includes the file (string) though...



[2005-02-09 21:42:13] du at bestwaytech dot com

There is one other difference between include and php_check_syntax that
should be noted in the manual. Aside from supressing output buffer, it
only includes functions and classes, it d

#29316 [Fbk->Opn]: Executing Stored Procedure with more than one Resultset

[patrick dot schutte at gmx dot de]

 ID:   29316
 User updated by:  patrick dot schutte at gmx dot de
 Reported By:  patrick dot schutte at gmx dot de
-Status:   Feedback
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Suse8.2
 PHP Version:  5.0.0
 New Comment:

nope, Im using php 5.1.0-dev 200508030930 with freetds 0.62.4.
The stored procedure executes 2 Select-Statements. The frist with no
result, the second with 5 lines.
On tsql-console from freetds:
1> use php
2> go
1> exec dbo.dt_mehrfach
2> go
id  produktname tagesbedarf kvnr
id  produktname tagesbedarf kvnr
17  Schnecken   1 Tüten / Tag   2135860009
18  Colorado1 Tüte / Monat  NULL
19  Gummibärchen2 Tüten / tgl.  NULL
20  TestNULL
16  Phantasia   12 Tüten / WocheNULL
(return status = 0)
the first line "id  produktname tagesbedarf kvnr" show no
matches for the first select.

PHP:
echo "Select1: ".mssql_num_rows($rs);
mssql_next_result($rs);
echo "Select2: ".mssql_num_rows($rs);
Returns
5
5
instead 0,5 still after updating php with latetst snap.
The Problem still exists.


Previous Comments:


[2005-03-06 20:51:38] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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



--------

[2004-07-22 10:35:13] patrick dot schutte at gmx dot de

Description:

I've written stored Procedures that returns 2 and more Resultsets
(Select-Querys). If one of theese Results doesn't have any Matches I
get the next one instead.
System: Suse8.2, freetds 0.62.3 ./configure ... --with-mssql
freetds with TDS-Version 7.0 and MSSQL-Server2000. Same Code works fine
with WindowsNT4.0

Reproduce code:
---
CREATE PROCEDURE [dbo].[dt_mehrfach] AS
-- first Query: no match
SELECT * FROM tbl_haribo
WHERE id=1
-- second Query: 15 matches
SELECT * FROM tbl_haribo
PHP:
$p=mssql_init("dt_mehrfach);
$result=mssql_execute($p);
echo mssql_num_rows($result)."\n";
mssql_next_result($result);
echo mssql_num_rows($result);


Expected result:

0
15
would be ok

Actual result:
--
but  I get 
15
15





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

#31214 [Com]: overloading using __call() initially OK, fails on any subsequent method call

[patrick at arkeon dot com]

 ID:   31214
 Comment by:   patrick at arkeon dot com
 Reported By:  ebypdx at comcast dot net
 Status:   No Feedback
 Bug Type: Class/Object related
 Operating System: Solaris 5.8
 PHP Version:  4.3.10
 New Comment:

A "not real" solution about the "Call to a member function on a
non-object"

Try this:
// Only to avoid the problem...
class Dummy { 
function Dummy() {
}
}
$toto =& new Dummy();

class BaseOverloader {
function BaseOverloader() {}
function __call($method, $args, &$returnValue) {
echo "Call to ".get_class($this)."->$method ";
$returnValue = "return";
return true;
}
}
overload("BaseOverloader");
$toto = new BaseOverloader();
$toto->firstCall();
$toto->secondCall();

Then you got:
Call to baseoverloader->firstcall 
Call to baseoverloader->secondcall 

Weird, no?!?


Previous Comments:


[2004-12-29 01:00:16] php-bugs at lists dot php dot net

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



[2004-12-21 18:05:49] [EMAIL PROTECTED]

leave bug @ feedback until further information is known.



[2004-12-21 17:33:51] ebypdx at comcast dot net

thanks very much for the feedback, if our sysadmins have time to apply
that patch i'll post back the results.  for now we've rolled back a
version.



[2004-12-21 03:58:03] [EMAIL PROTECTED]

Try the patch listed in bug report #31106



[2004-12-21 03:04:38] [EMAIL PROTECTED]

in Zend/zend_execute.c

about line 997: remove this line
PZVAL_UNLOCK(T->EA.data.overloaded_element.object);

about line 1579: remove this line

EX(object).ptr->refcount++;

you have to copy & paste the whole link for it to work / rather than
just pressing on it.




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

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

#31180 [Bgs]: 4.3.10 printf(%.2f) precision bug.

[patrick at ilmander dot com]

 ID:   31180
 User updated by:  patrick at ilmander dot com
 Reported By:  patrick at ilmander dot com
 Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Red Hat Linux
 PHP Version:  4.3.10
 New Comment:

I'm sorry, I should have given you more details. The problem doesn't
seem to be printf() itself, but where I used it. I was using the
following code:
"Rating: "
which worked fine in 4.3.4, but when we upgraded to 4.3.10 it produced
the stated error. I've updated all my code to
"Rating: "
which works fine. I probably shouldn't have used printf() inside a  in the first place, but it worked fine in 4.3.4 and not in 4.3.10,
that's why I reported it as a bug.

Sorry for wasting your time.

// Patrick


Previous Comments:


[2004-12-19 19:18:44] [EMAIL PROTECTED]

works fine.



[2004-12-19 16:54:24] postings-php-bug at hans-spath dot de

I've tried it under PHP 4.3.10/Linux 2.6 and PHP 4.3.8/WinXPsp2, works
as it should.

Could you test with "_%.2f_", just to get sure the last digit isn't
coming from somewhere else in your code?



[2004-12-18 23:43:48] [EMAIL PROTECTED]

This works fine here:

$ php-4.3dev -r 'echo sprintf("%.2f", 42.1231213123);'

42.12

--------

[2004-12-18 12:20:20] patrick at ilmander dot com

Printing a variable with %.2f should output the number with 2 decimals.
After upgrading to 4.3.10 it now outputs 3 decimals. %.1f outputs with 2
decimals and I haven't figured out how to print out just 1 decimal (%.0f
doesn't work), so I'm treating this as a bug.

----

[2004-12-18 12:18:54] patrick at ilmander dot com

Description:

Printing a variable with %.2f should output the number with 2 decimals.
After upgrading to 4.3.10 it now outputs 3 decimals. %.1f outputs with 2
decimals and I haven't figured out how to print out just 1 decimal (%.1f
doesn't work), so I'm treating this as a bug.

Reproduce code:
---
printf("%.2f", $member[score] / $member[votes]);

Expected result:

1.23

Actual result:
--
1.234





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

#31180 [Opn]: 4.3.10 printf(%.2f) precision bug.

[patrick at ilmander dot com]

 ID:   31180
 User updated by:  patrick at ilmander dot com
 Reported By:  patrick at ilmander dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Red Hat Linux
 PHP Version:  4.3.10
 New Comment:

Printing a variable with %.2f should output the number with 2 decimals.
After upgrading to 4.3.10 it now outputs 3 decimals. %.1f outputs with 2
decimals and I haven't figured out how to print out just 1 decimal (%.0f
doesn't work), so I'm treating this as a bug.


Previous Comments:


[2004-12-18 12:18:54] patrick at ilmander dot com

Description:

Printing a variable with %.2f should output the number with 2 decimals.
After upgrading to 4.3.10 it now outputs 3 decimals. %.1f outputs with 2
decimals and I haven't figured out how to print out just 1 decimal (%.1f
doesn't work), so I'm treating this as a bug.

Reproduce code:
---
printf("%.2f", $member[score] / $member[votes]);

Expected result:

1.23

Actual result:
--
1.234





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

#31180 [NEW]: 4.3.10 printf(%.2f) precision bug.

[patrick at ilmander dot com]

From: patrick at ilmander dot com
Operating system: Red Hat Linux
PHP version:  4.3.10
PHP Bug Type: Unknown/Other Function
Bug description:  4.3.10 printf(%.2f) precision bug.

Description:

Printing a variable with %.2f should output the number with 2 decimals.
After upgrading to 4.3.10 it now outputs 3 decimals. %.1f outputs with 2
decimals and I haven't figured out how to print out just 1 decimal (%.1f
doesn't work), so I'm treating this as a bug.

Reproduce code:
---
printf("%.2f", $member[score] / $member[votes]);

Expected result:

1.23

Actual result:
--
1.234

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

#30930 [Opn]: include('./xxx.php') fails!

[patrick dot allaert at belgacom dot be]

 ID:   30930
 User updated by:  patrick dot allaert at belgacom dot be
 Reported By:  patrick dot allaert at belgacom dot be
 Status:   Open
 Bug Type: IIS related
 Operating System: Windows 2000
 PHP Version:  4.3.9
 New Comment:

One more consideration:
The module php ISAPI is loaded in IIS at the site level and not at
server level !! (I found it was also possible to set the ISAPI module
in the WWW Service Master properties, unfortunately, I cannot test if
setting it at this level resolve this problem)


Previous Comments:


[2004-11-29 12:40:21] patrick dot allaert at belgacom dot be

It seems that this problem occurs only when using IIS "virtual sites".

What I mean by "virtual site" (Apache term ?) is that I added a new
"site" in IIS listening on a specific port (8080) and with a specific
Host Header Name...

----

[2004-11-29 12:32:40] patrick dot allaert at belgacom dot be

Description:

Including a script in the current directory with './' fails when IIS is
configured with a virtual site with ISAPI module.

It works well with the cgi installation!

Reproduce code:
---
--- D:\wwwroot\a.php ---



--- D:\wwwroot\b.php ---
TEST


==> http://localhost/a.php

Expected result:

With a cgi installation:
D:\wwwroot TEST

Actual result:
--
With the ISAPI installation:
C:\WINNT\system32
Warning: main(./b.php): failed to open stream: No such file or
directory in D:\wwwroot\a.php on line 3

Warning: main(): Failed opening './b.php' for inclusion
(include_path='.;c:\php\includes;c:\php\pear;c:\php;c:\php\font') in
D:\wwwroot\a.php on line 3





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

#30930 [Opn]: include('./xxx.php') fails!

[patrick dot allaert at belgacom dot be]

 ID:   30930
 User updated by:  patrick dot allaert at belgacom dot be
 Reported By:  patrick dot allaert at belgacom dot be
 Status:   Open
 Bug Type: IIS related
 Operating System: Windows 2000
 PHP Version:  4.3.9
 New Comment:

It seems that this problem occurs only when using IIS "virtual sites".

What I mean by "virtual site" (Apache term ?) is that I added a new
"site" in IIS listening on a specific port (8080) and with a specific
Host Header Name...


Previous Comments:
----

[2004-11-29 12:32:40] patrick dot allaert at belgacom dot be

Description:

Including a script in the current directory with './' fails when IIS is
configured with a virtual site with ISAPI module.

It works well with the cgi installation!

Reproduce code:
---
--- D:\wwwroot\a.php ---



--- D:\wwwroot\b.php ---
TEST


==> http://localhost/a.php

Expected result:

With a cgi installation:
D:\wwwroot TEST

Actual result:
--
With the ISAPI installation:
C:\WINNT\system32
Warning: main(./b.php): failed to open stream: No such file or
directory in D:\wwwroot\a.php on line 3

Warning: main(): Failed opening './b.php' for inclusion
(include_path='.;c:\php\includes;c:\php\pear;c:\php;c:\php\font') in
D:\wwwroot\a.php on line 3





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

#30930 [NEW]: include('./xxx.php') fails!

[patrick dot allaert at belgacom dot be]

From: patrick dot allaert at belgacom dot be
Operating system: Windows 2000
PHP version:  4.3.9
PHP Bug Type: IIS related
Bug description:  include('./xxx.php')  fails!

Description:

Including a script in the current directory with './' fails when IIS is
configured with a virtual site with ISAPI module.

It works well with the cgi installation!

Reproduce code:
---
--- D:\wwwroot\a.php ---



--- D:\wwwroot\b.php ---
TEST


==> http://localhost/a.php

Expected result:

With a cgi installation:
D:\wwwroot TEST

Actual result:
--
With the ISAPI installation:
C:\WINNT\system32
Warning: main(./b.php): failed to open stream: No such file or directory
in D:\wwwroot\a.php on line 3

Warning: main(): Failed opening './b.php' for inclusion
(include_path='.;c:\php\includes;c:\php\pear;c:\php;c:\php\font') in
D:\wwwroot\a.php on line 3

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

#30808 [Com]: oci8 cannot connect after restarting DB

[patrick dot lambert at noggin dot com]

 ID:   30808
 Comment by:   patrick dot lambert at noggin dot com
 Reported By:  michael dot caplan at lechateau dot ca
 Status:   Suspended
 Bug Type: OCI8 related
 Operating System: RHE 3
 PHP Version:  5.0.2
 Assigned To:  tony2001
 New Comment:

It would be great if this flaw in the OCI8 
implementation could be resolved. It has been bugged 
numerous times over the years. And I don't see why a 
solution would necessarily depend on pre-pinging.


Previous Comments:


[2004-11-18 16:59:38] michael dot caplan at lechateau dot ca

Ah, yes -- I suppose pinging every time would be a huge overhead.  But,
how do other db supported by PHP (mysql for example) handle this issue? 
I can most definately restart mysqld without needed to restart apache to
kill all my mysql persistant connections.  The mysql library seams to
handle this without issue (or perhaps this is something that is
negotiated on the mysqld side)?

Also, perhaps I am miss understanding you, but you suggest that this
issue will be fixed in PDO OCI.  If so, why cannot it be fixed in the
current OCI8 library?

Thanks,

Michael



[2004-11-18 15:21:25] [EMAIL PROTECTED]

New ini option is needed because pinging every connection would lead to
huge overhead. 
Your situation in fact is an exception, rather then a rule - most
people do not restart DB every day, so they would definitely not agree
with this slowdown.




[2004-11-18 15:09:14] michael dot caplan at lechateau dot ca

Uncommenting the oci_ping() call does the trick.  Both persitant and
non persistant connection then work after an Oracle restart.

But your reply confuses me.  Why a new ini option (you mean at compile
time?)?  Shouldn't this be the default behaviour?  And why should I
wait till PDO for a stable way to connect to Oracle?  Shouldn't this
issue be resolved in the current PHP OCI8 function library?

Thanks,

Michael



[2004-11-17 07:35:17] [EMAIL PROTECTED]

Currently you have to uncomment oci_ping() call in _oci_open_server()
function (see ext/oci8/oci8.c, line 3048). 
It was planned to add an ini option for that, but it seems that nobody
likes new ini options and I quess we'll take care about it in brand new
PDO OCI driver.

Personally I do not have any objections to adding new ini option, so
I'm marking this resport as suspended for the time present.



[2004-11-16 20:41:22] michael dot caplan at lechateau dot ca

Description:

Every evening, for whatever reason, our Oracle db (9.2.0) is restated.
After it is restarted, I am unable to build a connection with Oracle
from PHP untill Apache is restarted.  
 
Whenever I do an ociplogon() or ocilogon() following an Oracle DB
restart, it fails but I am unable to get a description of the error. 
Restarting Apache "fixes" the problem.  
 
This problem is similar to bug #26829 except that it effects both
persistent and non persistent conneciton.







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

#29488 [Com]: PHP does not compile with freetds 0.62.4

[patrick dot schutte at gmx dot de]

 ID:   29488
 Comment by:   patrick dot schutte at gmx dot de
 Reported By:  ssc at coolspot dot de
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Linux 2.6.7 / Debian sarge
 PHP Version:  4.3.8
 New Comment:

Hi, downlaod the laest snap and copy the ext/mssql folder to your
php-4.3.8 folder. I just compiled php-4.3.9dev (latest snap -
200408100430 -) with freetds-0.62.4 it wokrs fine! No Errors. HTH


Previous Comments:


[2004-08-03 13:17:05] ssc at coolspot dot de

Ha,ha.
Is there somebody out there to fix the bug or
do i realy have to do a diff -wu myself ?
Ok, for your convinience :

>>>
[EMAIL PROTECTED]:~/php-shit$ diff -wu php-4.3.6/ext/mssql/php_mssql.h
php-4.3.8/ext/mssql/php_mssql.h
--- php-4.3.6/ext/mssql/php_mssql.h 2003-07-23 18:53:38.0
+0200
+++ php-4.3.8/ext/mssql/php_mssql.h 2004-04-21 01:37:26.0
+0200
@@ -17,7 +17,7 @@
  */


-/* $Id: php_mssql.h,v 1.23.4.9 2003/07/23 16:53:38 iliaa Exp $ */
+/* $Id: php_mssql.h,v 1.23.4.10 2004/04/20 23:37:26 fmk Exp $ */

 #ifndef PHP_MSSQL_H
 #define PHP_MSSQL_H
@@ -37,6 +37,9 @@
 #include "sqldb.h"

 #if HAVE_FREETDS
+#ifndef SHORT
+typedef short SHORT;
+#endif
 #define SQLTEXT SYBTEXT
 #define SQLCHAR SYBCHAR
 #define SQLVARCHAR SYBVARCHAR
<<<

#ifndef SHORT searches for pre-compiler defines not for
typedefs. But typedef is C not Pre-Processor define.
mh.
Ok, now I really know what PHP is all about.

Use PHP 5 ? An older release ?



[2004-08-03 11:42:53] patrick dot schutte at gmx dot de

it's not a freetds-Problem - the mssql-extentions in php-4.3.7, 4.3.8
causes the errors - try php-5.0.0 or 4.3.6



[2004-08-02 10:02:48] ssc at coolspot dot de

Description:

I installed freetds version 0.62.4 on some debian sarge system, using
./configure --prefix=/usr/freetds --enable-msdblib --with-tdsver=8.0
--enable-shared
echo "/usr/freetds/lib" >> /etc/ld.so.conf ; ldconfig
FreeTDS work ok.
I then tried to compile php with
... --with-mssql=/usr/freetds ...
and to link it against freetds resulting in :

In file included from /root/php-4.3.8/ext/mssql/php_mssql.c:33:
/root/php-4.3.8/ext/mssql/php_mssql.h:41: error: redefinition of
`SHORT'
/usr/freetds/include/sybdb.h:117: error: `SHORT' previously declared
here
make: *** [ext/mssql/php_mssql.lo] Fehler 1

I commented out the line 41 in ext/mssql/php_mssql.h,
which is only a typdef short SHORT;, and it then worked,
as expected.

Compiler Version used is :
Lese Spezifikationen von /usr/lib/gcc-lib/i486-linux/3.3.4/specs
Konfiguriert mit: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
i486-linux
Thread-Modell: posix
gcc-Version 3.3.4 (Debian 1:3.3.4-3)



Reproduce code:
---
Any

Expected result:

Should compile

Actual result:
--
Does not compile





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

#29488 [Com]: PHP does not compile with freetds 0.62.4

[patrick dot schutte at gmx dot de]

 ID:   29488
 Comment by:   patrick dot schutte at gmx dot de
 Reported By:  ssc at coolspot dot de
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Linux 2.6.7 / Debian sarge
 PHP Version:  4.3.8
 New Comment:

it's not a freetds-Problem - the mssql-extentions in php-4.3.7, 4.3.8
causes the errors - try php-5.0.0 or 4.3.6


Previous Comments:


[2004-08-02 10:02:48] ssc at coolspot dot de

Description:

I installed freetds version 0.62.4 on some debian sarge system, using
./configure --prefix=/usr/freetds --enable-msdblib --with-tdsver=8.0
--enable-shared
echo "/usr/freetds/lib" >> /etc/ld.so.conf ; ldconfig
FreeTDS work ok.
I then tried to compile php with
... --with-mssql=/usr/freetds ...
and to link it against freetds resulting in :

In file included from /root/php-4.3.8/ext/mssql/php_mssql.c:33:
/root/php-4.3.8/ext/mssql/php_mssql.h:41: error: redefinition of
`SHORT'
/usr/freetds/include/sybdb.h:117: error: `SHORT' previously declared
here
make: *** [ext/mssql/php_mssql.lo] Fehler 1

I commented out the line 41 in ext/mssql/php_mssql.h,
which is only a typdef short SHORT;, and it then worked,
as expected.

Compiler Version used is :
Lese Spezifikationen von /usr/lib/gcc-lib/i486-linux/3.3.4/specs
Konfiguriert mit: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
i486-linux
Thread-Modell: posix
gcc-Version 3.3.4 (Debian 1:3.3.4-3)



Reproduce code:
---
Any

Expected result:

Should compile

Actual result:
--
Does not compile





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

#29224 [Com]: DB Error: extension not found

[patrick dot allaert at belgacom dot be]

 ID:   29224
 Comment by:   patrick dot allaert at belgacom dot be
 Reported By:  marcschroeder at hotmail dot com
 Status:   Open
 Bug Type: *Configuration Issues
 Operating System: Microsoft Windows XP
 PHP Version:  5.0.0
 New Comment:

After the installation on WindowsXP/IIS of PHP 5.0.0 (stable) in
c:\PHP\ and configuring the php.ini with:

extension_dir = "c:\PHP\ext"

I receive the following message:

"PHP Startup: Unable to load dynamic library
'c:\PHP\ext\php_EXTENSIONNAME.dll' - The specified module could not be
found"

for all extensions except:

php_bz2.dll
php_cpdf.dll
php_curl.dll
php_dba.dll
php_dbase.dll
php_dbx.dll
php_filepro.dll
php_gd2.dll
php_gettext.dll
php_imap.dll
php_ldap.dll
php_mbstring.dll
php_mime_magic.dll
php_ming.dll
php_mysqli.dll
php_openssl.dll
php_oracle.dll
php_pgsql.dll
php_shmop.dll
php_snmp.dll
php_sockets.dll
php_tidy.dll
php_xmlrpc.dll
php_xsl.dll

All the other extensions result in the error above (of course, some of
them cannot be loaded because of 3rd-parties dll missing like with oci8
but what about php_mysql.dll, php_mysqli.dll, ...)


Previous Comments:


[2004-07-17 12:33:40] marcschroeder at hotmail dot com

Remark (3): commenting in the line "extension=php_mysql.dll"
in php.ini does not help either



[2004-07-17 12:19:13] marcschroeder at hotmail dot com

Description:

I had installed the windows binaries php-4.3.6-Win32.zip, and the PEAR
DB package worked fine. After installing the binaries
php-5.0.0-Win32.zip, I got the error "DB Error: extension not found".

Remarks: 
(1) Copying the file php_mysql.dll into the directory
C:\WINDOWS\systm32 does not help.
(2) Even if it did, there would be a bug.






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

#29408 [Com]: Binding certain types of variables clears all bindings

[patrick dot schutte at gmx dot de]

 ID:   29408
 Comment by:   patrick dot schutte at gmx dot de
 Reported By:  mynameisfiber at gmail dot com
 Status:   Open
 Bug Type: MSSQL related
 Operating System: linux 2.6.5-gentoo-r1
 PHP Version:  4.3.7
 New Comment:

Hi,

try mssql_bind($query, "@orgId", $org, SQLINT2,FALSE,FALSE);
mssql_bind($query, "@loginName", $user, SQLVARCHAR,FALSE,FALSE,n);

n=len of varchar in stroed Procedure

Works fine with PHP5/freetds0.62.3/MSSQL2000/tdsversion=7.0


Previous Comments:


[2004-07-27 15:57:47] mynameisfiber at gmail dot com

Description:

i am trying to do mssql (through freetds 0.62.3) with stored proc's
however if i try sending in a parameter of SQLVARCHAR, SQLCHAR,
SQLTEXT, none of the parameters go through... in the following example,
i get an error if @loginName is sent as a SQLVARCHAR (and uppon sniffing
the actual request i see that NO parameters are sent in this case)
however if i change it to SQLINT2 everything works fine (except
@loginName goes in as '0' which isn't productive).

the only possible thing i can think of to explain this is that the
message is too long and becomes truncated? or maybe this version of PHP
hasn't updated it's mssql connection module?  does anyone have any ideas
or even any solutions? 

thanks alot! :-)

Reproduce code:
---
(after connecting to the database)
$query = mssql_init('adSetUserByLogin', $dbcnx); 

$org = 360;
$user = "a";
mssql_bind($query, "@orgId", $org, SQLINT2);
mssql_bind($query, "@loginName", $user, SQLVARCHAR);

$res = mssql_execute($query); 

Expected result:

i would have expected the stored procedure to go on just fine so that
it's output could be later retrieved

Actual result:
--
Warning: mssql_execute(): message: Procedure 'adSetUserByLogin' expects
parameter '@orgId', which was not supplied. (severity 16) in
/var/www/localhost/htdocs/aosr/test.php on line 24

Warning: mssql_execute(): stored procedure execution failed in
/var/www/localhost/htdocs/aosr/test.php on line 24

Warning: mssql_fetch_array(): supplied argument is not a valid MS
SQL-result resource in /var/www/localhost/htdocs/aosr/test.php on line
27





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

#29316 [NEW]: Executing Stored Procedure with more than one Resultset

[patrick dot schutte at gmx dot de]

From: patrick dot schutte at gmx dot de
Operating system: Suse8.2
PHP version:  5.0.0
PHP Bug Type: MSSQL related
Bug description:  Executing Stored Procedure with more than one Resultset

Description:

I've written stored Procedures that returns 2 and more Resultsets
(Select-Querys). If one of theese Results doesn't have any Matches I get
the next one instead.
System: Suse8.2, freetds 0.62.3 ./configure ... --with-mssql
freetds with TDS-Version 7.0 and MSSQL-Server2000. Same Code works fine
with WindowsNT4.0

Reproduce code:
---
CREATE PROCEDURE [dbo].[dt_mehrfach] AS
-- first Query: no match
SELECT * FROM tbl_haribo
WHERE id=1
-- second Query: 15 matches
SELECT * FROM tbl_haribo
PHP:
$p=mssql_init("dt_mehrfach);
$result=mssql_execute($p);
echo mssql_num_rows($result)."\n";
mssql_next_result($result);
echo mssql_num_rows($result);


Expected result:

0
15
would be ok

Actual result:
--
but  I get 
15
15

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

#28183 [Opn]: Variables mix up

[patrick dot hagemeister at krankikom dot de]

 ID:   28183
 User updated by:  patrick dot hagemeister at krankikom dot de
 Reported By:  patrick dot hagemeister at krankikom dot de
 Status:   Open
-Bug Type: Unknown/Other Function
+Bug Type: Scripting Engine problem
 Operating System: Linux SuSE 8.0
 PHP Version:  4.3.6
 New Comment:

Changed category to "Scripting engine problem"


Previous Comments:


[2004-04-27 16:21:04] patrick dot hagemeister at krankikom dot de

Description:

I have a medium-sized php applications (~2 lines), which starts to
produce a few problems.

Sometimes, variables mix up:
i.e. i create a new instance $root of class "CBXTreeNode", but only 3
lines later, suddenly the class type (checked using get_class()) of
$root is "CBXWorkflow", and the value is the one of another variable in
the same function.

But between these lines, i didn't even touch the variable...

In some places, a similar problem shows up:
I instanciate a class CBXTreeNode, but if i do get_class($variable), it
returns "cbxtreenodd" instead of ctxtreenode.

Unfortunately i could not reproduce it on every server, on my
development server it works, on the production server, it doesn't :( 

Also, the exact same source works outside my application, on the same
server.

I updated PHP from 4.2.3 to 4.3.6, but no change.



Reproduce code:
---
$root = $treemgr->getRootNode();
echo "root is class ".get_class($root)."";

$workflow =& $this->getWorkflow();
echo "workflow is class ".get_class($workflow)."";

echo "root is class ".get_class($root)."";


// **Output in my application**
// root is class CBXTreeNode
// workflow is class SPWorkflow
// root is class SPWorkflow


Expected result:

Output should be:

root is class CBXTreeNode
workflow is class SPWorkflow
root is class CBXTreeNode







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

#28183 [NEW]: Variables mix up

[patrick dot hagemeister at krankikom dot de]

From: patrick dot hagemeister at krankikom dot de
Operating system: Linux SuSE 8.0
PHP version:  4.3.6
PHP Bug Type: Unknown/Other Function
Bug description:  Variables mix up

Description:

I have a medium-sized php applications (~2 lines), which starts to
produce a few problems.

Sometimes, variables mix up:
i.e. i create a new instance $root of class "CBXTreeNode", but only 3
lines later, suddenly the class type (checked using get_class()) of $root
is "CBXWorkflow", and the value is the one of another variable in the same
function.

But between these lines, i didn't even touch the variable...

In some places, a similar problem shows up:
I instanciate a class CBXTreeNode, but if i do get_class($variable), it
returns "cbxtreenodd" instead of ctxtreenode.

Unfortunately i could not reproduce it on every server, on my development
server it works, on the production server, it doesn't :( 

Also, the exact same source works outside my application, on the same
server.

I updated PHP from 4.2.3 to 4.3.6, but no change.



Reproduce code:
---
$root = $treemgr->getRootNode();
echo "root is class ".get_class($root)."";

$workflow =& $this->getWorkflow();
echo "workflow is class ".get_class($workflow)."";

echo "root is class ".get_class($root)."";


// **Output in my application**
// root is class CBXTreeNode
// workflow is class SPWorkflow
// root is class SPWorkflow


Expected result:

Output should be:

root is class CBXTreeNode
workflow is class SPWorkflow
root is class CBXTreeNode



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

#27759 [Fbk->Opn]: bcadd() causes crash if first parameter is empty string

[patrick at rap-x dot com]

 ID:   27759
 User updated by:  patrick at rap-x dot com
 Reported By:  patrick at rap-x dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP
 PHP Version:  5.0.0RC1
 New Comment:

The same code causes the same problem with PHP5 RC2. Output from the
first section of phpinfo() below.

-

PHP Version 5.0.0RC2-dev

System  Windows NT ME 5.1 build 2600

Build Date  Apr 3 2004 04:32:40

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

Server API  Apache 2.0 Handler

Virtual Directory Support   enabled

Configuration File (php.ini) Path   C:\WINDOWS\php.ini

PHP API 20031224

PHP Extension   20040316

Zend Extension  90021012

Debug Build no

Thread Safety   enabled

IPv6 Supportenabled

Registered PHP Streams  php, file, http, ftp, compress.zlib

Registered Stream Socket Transports tcp, udp

.

BCMath support  enabled


Previous Comments:


[2004-04-04 21:32:50] [EMAIL PROTECTED]

Latest snapshot



For Windows:

 

  http://snaps.php.net/win32/php5-win32-latest.zip



[2004-04-04 20:48:23] patrick at rap-x dot com

The bug is still reproducible, on the same code base. I don't have a
windows compiler for C, so I can't try the hugely useful suggestion
from polita. 



I've commented out or replaced all instances of bcmath functions in my
code. I don't have a windows compiler for C, so I can't try the hugely
useful suggestion from polita. 



If someone can point me to some binaries I'll test them.



[2004-04-04 14:01:17] [EMAIL PROTECTED]

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





[2004-04-02 09:21:02] marwan at marvonline dot org

I've tested the April 1st build and it still has the problem.



This affects all the bcmath functions and happens when either of the
first two arguments evaluates to zero (this means 0, '0', and '').



I have the same setup as the original submitter.



[2004-03-29 16:29:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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



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

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

#27759 [NoF->Opn]: bcadd() causes crash if first parameter is empty string

[patrick at rap-x dot com]

 ID:   27759
 User updated by:  patrick at rap-x dot com
 Reported By:  patrick at rap-x dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP
 PHP Version:  5.0.0RC1
 New Comment:

The bug is still reproducible, on the same code base. I don't have a
windows compiler for C, so I can't try the hugely useful suggestion
from polita. 



I've commented out or replaced all instances of bcmath functions in my
code. I don't have a windows compiler for C, so I can't try the hugely
useful suggestion from polita. 



If someone can point me to some binaries I'll test them.


Previous Comments:


[2004-04-04 14:01:17] [EMAIL PROTECTED]

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





[2004-04-02 09:21:02] marwan at marvonline dot org

I've tested the April 1st build and it still has the problem.



This affects all the bcmath functions and happens when either of the
first two arguments evaluates to zero (this means 0, '0', and '').



I have the same setup as the original submitter.



[2004-03-29 16:29:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

--------

[2004-03-29 15:43:37] patrick at rap-x dot com

Description:

The following code causes PHP5 RC1 (module)/ WINXP / Apache2 to crash.



The same code doesn't cause a crash on PHP 4.3.4 / WINXP/ IIS (CGI)



Fault discovered by using PEAR :: Benchmark



Workaround is to mess around line 230ish in pear Timer.php so that the
bcadd is not called.

Reproduce code:
---
$total = "0";

$diff = "";

bcadd($total, $diff, 6);

Expected result:

n/a

Actual result:
--
Apache2 crashes



Windows Event Log records:



Faulting application Apache.exe, version 2.0.49.0, faulting module
php5ts.dll, version 5.0.0.0, fault address 0x0003c773.



Apache error log: 



Parent: child process exited with status 3221225477 -- Restarting.

[notice] Parent: Created child process 2120

[notice] Child 2120: Child process is running

[notice] Child 2120: Acquired the start mutex.

[notice] Child 2120: Starting 250 worker threads.



[notice] Parent: Created child process 2120

[notice] Child 2120: Child process is running

[notice] Child 2120: Acquired the start mutex.

[notice] Child 2120: Starting 250 worker threads.

[notice] Parent: child process exited with status 2147483649 --
Restarting.





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

#27759 [NEW]: bcadd() causes crash if first parameter is empty string

[patrick at rap-x dot com]

From: patrick at rap-x dot com
Operating system: Windows XP
PHP version:  5.0.0RC1
PHP Bug Type: Reproducible crash
Bug description:  bcadd() causes crash if first parameter is empty string

Description:

The following code causes PHP5 RC1 (module)/ WINXP / Apache2 to crash.



The same code doesn't cause a crash on PHP 4.3.4 / WINXP/ IIS (CGI)



Fault discovered by using PEAR :: Benchmark



Workaround is to mess around line 230ish in pear Timer.php so that the
bcadd is not called.

Reproduce code:
---
$total = "0";

$diff = "";

bcadd($total, $diff, 6);

Expected result:

n/a

Actual result:
--
Apache2 crashes



Windows Event Log records:



Faulting application Apache.exe, version 2.0.49.0, faulting module
php5ts.dll, version 5.0.0.0, fault address 0x0003c773.



Apache error log: 



Parent: child process exited with status 3221225477 -- Restarting.

[notice] Parent: Created child process 2120

[notice] Child 2120: Child process is running

[notice] Child 2120: Acquired the start mutex.

[notice] Child 2120: Starting 250 worker threads.



[notice] Parent: Created child process 2120

[notice] Child 2120: Child process is running

[notice] Child 2120: Acquired the start mutex.

[notice] Child 2120: Starting 250 worker threads.

[notice] Parent: child process exited with status 2147483649 --
Restarting.

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

#27511 [Opn]: fread crashes Apache with mistakenly big length

[patrick at borgeat dot de]

 ID:   27511
 User updated by:  patrick at borgeat dot de
 Reported By:  patrick at borgeat dot de
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: Windows 2000 SR4
 PHP Version:  5.0.0b4 (beta4)
 New Comment:

I forgot a Semikolon (;) after "echo $res", sorry!


Previous Comments:


[2004-03-06 04:53:43] patrick at borgeat dot de

Description:

As I mistakenly tried to read a very large number of bytes (1078508183)
(more than are in the file) with fread, the Site doesn't react anymore
and i get a apache.exe Task in my Tasklist consuming an average of 80%
CPU Load (with a 1300 Mhz Machine) which can't be stopped (maybe also
due to missing rights). Also the file is blocked.



Never tested this on Linux, but I think if a server does this
mistakenly several times at once the whole server enviroment would
crash.



I run Apache 2.0.48 with PHP 5.0.0b4 as Apache2 Handler on Windows 2000
SR4 on FAT32 Filesystem.

Reproduce code:
---
(in my case test was a textfile with the 3 Letters "AAA")









Expected result:

I expected PHP to be as smart (as it is with smaller numbers for
example like 50 000) to write only 3 Bytes and output "AAA".

Actual result:
--
Apache Task isn't stopable and runs @ Average of 80% CPU Load





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

#27511 [NEW]: fread crashes Apache with mistakenly big length

[patrick at borgeat dot de]

From: patrick at borgeat dot de
Operating system: Windows 2000 SR4
PHP version:  5.0.0b4 (beta4)
PHP Bug Type: Filesystem function related
Bug description:  fread crashes Apache with mistakenly big length 

Description:

As I mistakenly tried to read a very large number of bytes (1078508183)
(more than are in the file) with fread, the Site doesn't react anymore and
i get a apache.exe Task in my Tasklist consuming an average of 80% CPU
Load (with a 1300 Mhz Machine) which can't be stopped (maybe also due to
missing rights). Also the file is blocked.



Never tested this on Linux, but I think if a server does this mistakenly
several times at once the whole server enviroment would crash.



I run Apache 2.0.48 with PHP 5.0.0b4 as Apache2 Handler on Windows 2000
SR4 on FAT32 Filesystem.

Reproduce code:
---
(in my case test was a textfile with the 3 Letters "AAA")









Expected result:

I expected PHP to be as smart (as it is with smaller numbers for example
like 50 000) to write only 3 Bytes and output "AAA".

Actual result:
--
Apache Task isn't stopable and runs @ Average of 80% CPU Load

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

#27398 [Com]: Installing PEAR (go-pear.bat) causes Application Error

[patrick dot schnorbus at tuxcenter dot net]

 ID:   27398
 Comment by:   patrick dot schnorbus at tuxcenter dot net
 Reported By:  WPinegar at healthtech dot net
 Status:   Verified
 Bug Type: Zend Engine 2 problem
 Operating System: *
 PHP Version:  5CVS-2004-02-26
 New Comment:

PEAR support seems to be totally broken in current CVS. 

The this happend somewhere between the 200402241430 and 

200402251630 snaps (200402241430 was the last with working 

PEAR). 

 

aries:/usr/src/php5-200402261630# make install 

Installing PHP SAPI module:   apache2handler 

/usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/

local/apache2/build/libtool' libphp5.la /usr/local/

apache2/modules 

/usr/local/apache2/build/libtool --mode=install cp 

libphp5.la /usr/local/apache2/modules/ 

cp .libs/libphp5.so /usr/local/apache2/modules/libphp5.so 

cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la 

libtool: install: warning: remember to run `libtool 

--finish /usr/src/php5-200402261630/libs' 

chmod 755 /usr/local/apache2/modules/libphp5.so 

[activating module `php5' in /usr/local/apache2/conf/

httpd.conf] 

Installing PHP CLI binary:/usr/local/bin/ 

Installing PHP CLI man page:  /usr/local/man/man1/ 

Installing PEAR environment:  /usr/local/lib/php/ 

 

Fatal error: Declaration of PEAR_Installer::download() 

must be compatible with that of 

PEAR_Downloader::download() in /usr/src/php5-200402261630/

pear/PEAR/Installer.php on line 49 

make[1]: *** [install-pear-installer] Fehler 255 

make: *** [install-pear] Fehler 2 

aries:/usr/src/php5-200402261630# export LC_ALL=C 

aries:/usr/src/php5-200402261630# make install 

Installing PHP SAPI module:   apache2handler 

/usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/

local/apache2/build/libtool' libphp5.la /usr/local/

apache2/modules 

/usr/local/apache2/build/libtool --mode=install cp 

libphp5.la /usr/local/apache2/modules/ 

cp .libs/libphp5.so /usr/local/apache2/modules/libphp5.so 

cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la 

libtool: install: warning: remember to run `libtool 

--finish /usr/src/php5-200402261630/libs' 

chmod 755 /usr/local/apache2/modules/libphp5.so 

[activating module `php5' in /usr/local/apache2/conf/

httpd.conf] 

Installing PHP CLI binary:/usr/local/bin/ 

Installing PHP CLI man page:  /usr/local/man/man1/ 

Installing PEAR environment:  /usr/local/lib/php/ 

 

Fatal error: Declaration of PEAR_Installer::download() 

must be compatible with that of 

PEAR_Downloader::download() in /usr/src/php5-200402261630/

pear/PEAR/Installer.php on line 49 

make[1]: *** [install-pear-installer] Error 255 

make: *** [install-pear] Error 2 

 

Installing PHP5 without PEAR works. 

 

-- 

Pat


Previous Comments:


[2004-02-25 23:41:06] [EMAIL PROTECTED]

Here's the callstack when you run go-pear.bat:



zend_fetch_obj_w_handler(_zend_execute_data * 0x0012f788, _zend_op *
0x015985c8, _zend_op_array * 0x01595ad8, void * * * 0x00972980) line
2044 + 12 bytes

execute(_zend_op_array * 0x01595ad8, void * * * 0x00972980) line 1339 +
23 bytes

zend_do_fcall_common_helper(_zend_execute_data * 0x0012f910, _zend_op *
0x015995c8, _zend_op_array * 0x01594868, void * * * 0x00972980) line
2675 + 34 bytes

zend_do_fcall_by_name_handler(_zend_execute_data * 0x0012f910, _zend_op
* 0x015995c8, _zend_op_array * 0x01594868, void * * * 0x00972980) line
2757 + 21 bytes

execute(_zend_op_array * 0x01594868, void * * * 0x00972980) line 1339 +
23 bytes

zend_do_fcall_common_helper(_zend_execute_data * 0x0012fa98, _zend_op *
0x00c1fd88, _zend_op_array * 0x00a9f818, void * * * 0x00972980) line
2675 + 34 bytes

zend_do_fcall_by_name_handler(_zend_execute_data * 0x0012fa98, _zend_op
* 0x00c1fd88, _zend_op_array * 0x00a9f818, void * * * 0x00972980) line
2757 + 21 bytes

execute(_zend_op_array * 0x00a9f818, void * * * 0x00972980) line 1339 +
23 bytes

zend_execute_scripts(int 8, void * * * 0x00972980, _zval_struct * *
0x, int 3) line 1041 + 34 bytes

php_execute_script(_zend_file_handle * 0x0012ff48, void * * *
0x00972980) line 1650 + 27 bytes

main(int 3, char * * 0x00972580) line 941 + 17 bytes

mainCRTStartup() line 338 + 17 bytes

KERNEL32! 77e814c7()





[2004-02-25 16:12:40] WPinegar at healthtech dot net

Description:

While attempting to install PEAR via the command go-pear.bat (found in
the \PHP directory) I received an application error in php.exe module
php5ts.dll and PEAR does not extract properly.

Reproduce code:
---
Attempt to install PEAR via the command line utility go-pear.bat.  You
will receive an application error and PEAR will not extract properly.

Expected result:

PEAR should extract and install correctly.



--

#27221 [Bgs->Csd]: $_POST superglobal variable not populated after posting a form

[patrick at studioemma dot be]

 ID:   27221
 User updated by:  patrick at studioemma dot be
 Reported By:  patrick at studioemma dot be
-Status:   Bogus
+Status:   Closed
 Bug Type: *General Issues
 Operating System: Redhat 7.3
 PHP Version:  4.3.4
 New Comment:

Thanks, I should have thought as much :)



Closing the issue


Previous Comments:


[2004-02-18 22:13:51] aintlikenospam at www dot ravis dot org/contact/

I wasted 2 full days tracking down something that looks very similar to
this. In my case it's limited to IE and SSL only. Very intermitant.
What solved it for us was this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;831167



and adding 

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

to our apache config in the ssl enabled virtualhost section. Give it a
shot and see if it works for you too.



[2004-02-18 18:21:48] steve dot carrico at louisville dot edu

I don't beleive this is a PHP bug.  We started receiving similar
problem reports at the university I work for after the latest Internet
Explorer security update was released.  I came across the following
Microsoft Knowledge Base article yesterday and the software update
linked under the "Resolution" section appears to fix the problem:



http://support.microsoft.com/default.aspx?scid=kb;en-us;831167



[2004-02-12 10:02:39] [EMAIL PROTECTED]

Can not reproduce using latest CVS (or even with 4.3.4)



----

[2004-02-12 05:10:24] patrick at studioemma dot be

I will wait for the definite release. I can however allready add these
comments:



- only occurs on SSL

- occurs when some fields (no reserved words as names) have spaces,
numeric values, and perhaps others.



In the meantime I moved to just HTTP instead of HTTPS



[2004-02-11 15:02:01] [EMAIL PROTECTED]

Just try the snapshot first.





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

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

#27221 [Fbk->Opn]: $_POST superglobal variable not populated after posting a form

[patrick at studioemma dot be]

 ID:   27221
 User updated by:  patrick at studioemma dot be
 Reported By:  patrick at studioemma dot be
-Status:   Feedback
+Status:   Open
 Bug Type: *General Issues
 Operating System: Redhat 7.3
 PHP Version:  4.3.4
 New Comment:

I will wait for the definite release. I can however allready add these
comments:



- only occurs on SSL

- occurs when some fields (no reserved words as names) have spaces,
numeric values, and perhaps others.



In the meantime I moved to just HTTP instead of HTTPS


Previous Comments:


[2004-02-11 15:02:01] [EMAIL PROTECTED]

Just try the snapshot first.





[2004-02-11 14:51:49] patrick at studioemma dot be

my httpd.conf only mentions:



AddType application/x-httpd-php .php4 .php3 .phtml .php

AddType application/x-httpd-php-source .phps



However I have found a key to the origin: apparently the values I enter
in the form influence the problem. I have been able to reproduce but
cannot figure out any logic. I have to mention I'm only using a-zA-Z
and - signs..

it's like black magic...



I have not yet installed the snapshot, will definitely await final
release. I have to mention as well that I just upgraded to 4.3.4 from
4.3.2 where the problem occured as well.



[2004-02-11 14:04:52] [EMAIL PROTECTED]

Obviously you are not using Apache2, so



Please try using this CVS snapshot:



  http://snaps.php.net/php4-STABLE-latest.tar.gz



For Windows:



  http://snaps.php.net/win32/php4-win32-STABLE-

latest.zip





[2004-02-11 14:01:56] [EMAIL PROTECTED]

See bug #18648 and check your httpd.conf ...



[2004-02-11 13:54:19] patrick at studioemma dot be

Description:

After posting (method POST) a form (of any kind) the $_POST variable
does not get populated. This error is hard to reproduce as it occurs
sporadicily but sometimes more than once on the same form. Apparently
with under the same conditions it sometimes works and sometimes not.



I experience the problem (I believe) only using SSL. I'm using rewrite
rules, but the same as on other sites without SSL.



I read stuff about mentioning the action property in the form tag,
about GPC order, etc... but nothing I've tried can reduce the error to
it's origin. I do not know however how to check apache for incoming
POSTed data.



Apache:

Server  Version:  Apache/1.3.27 (Unix) (Red-Hat/Linux)

   FrontPage/5.0.2.2623 mod_ssl/2.8.12OpenSSL/0.9.6b   
PHP/4.3.4

   mod_perl/1.26 mod_python/2.7.6 Python/1.5.2 mod_webapp/1.2.0-dev

   Server Built: Dec 21 2003 12:00:54



Can you recommend me some actions ? I have not found any relevant info
on the web.






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

#27221 [Fbk->Opn]: $_POST superglobal variable not populated after posting a form

[patrick at studioemma dot be]

 ID:   27221
 User updated by:  patrick at studioemma dot be
 Reported By:  patrick at studioemma dot be
-Status:   Feedback
+Status:   Open
 Bug Type: *Web Server problem
 Operating System: Redhat 7.3
 PHP Version:  4.3.4
 New Comment:

my httpd.conf only mentions:

AddType application/x-httpd-php .php4 .php3 .phtml .php
AddType application/x-httpd-php-source .phps

However I have found a key to the origin: apparently the values I enter
in the form influence the problem. I have been able to reproduce but
cannot figure out any logic. I have to mention I'm only using a-zA-Z
and - signs..
it's like black magic...

I have not yet installed the snapshot, will definitely await final
release. I have to mention as well that I just upgraded to 4.3.4 from
4.3.2 where the problem occured as well.


Previous Comments:


[2004-02-11 14:04:52] [EMAIL PROTECTED]

Obviously you are not using Apache2, so

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz

For Windows:

  http://snaps.php.net/win32/php4-win32-STABLE-
latest.zip




[2004-02-11 14:01:56] [EMAIL PROTECTED]

See bug #18648 and check your httpd.conf ...



[2004-02-11 13:54:19] patrick at studioemma dot be

Description:

After posting (method POST) a form (of any kind) the $_POST variable
does not get populated. This error is hard to reproduce as it occurs
sporadicily but sometimes more than once on the same form. Apparently
with under the same conditions it sometimes works and sometimes not.

I experience the problem (I believe) only using SSL. I'm using rewrite
rules, but the same as on other sites without SSL.

I read stuff about mentioning the action property in the form tag,
about GPC order, etc... but nothing I've tried can reduce the error to
it's origin. I do not know however how to check apache for incoming
POSTed data.

Apache:
Server  Version:  Apache/1.3.27 (Unix) (Red-Hat/Linux)
   FrontPage/5.0.2.2623 mod_ssl/2.8.12OpenSSL/0.9.6b   
PHP/4.3.4
   mod_perl/1.26 mod_python/2.7.6 Python/1.5.2 mod_webapp/1.2.0-dev
   Server Built: Dec 21 2003 12:00:54

Can you recommend me some actions ? I have not found any relevant info
on the web.






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

#27221 [NEW]: $_POST superglobal variable not populated after posting a form

[patrick at studioemma dot be]

From: patrick at studioemma dot be
Operating system: Redhat 7.3
PHP version:  4.3.4
PHP Bug Type: *Web Server problem
Bug description:  $_POST superglobal variable not populated after posting a form

Description:

After posting (method POST) a form (of any kind) the $_POST variable does
not get populated. This error is hard to reproduce as it occurs
sporadicily but sometimes more than once on the same form. Apparently with
under the same conditions it sometimes works and sometimes not.

I experience the problem (I believe) only using SSL. I'm using rewrite
rules, but the same as on other sites without SSL.

I read stuff about mentioning the action property in the form tag, about
GPC order, etc... but nothing I've tried can reduce the error to it's
origin. I do not know however how to check apache for incoming POSTed
data.

Apache:
Server  Version:  Apache/1.3.27 (Unix) (Red-Hat/Linux)
   FrontPage/5.0.2.2623 mod_ssl/2.8.12OpenSSL/0.9.6bPHP/4.3.4
   mod_perl/1.26 mod_python/2.7.6 Python/1.5.2 mod_webapp/1.2.0-dev
   Server Built: Dec 21 2003 12:00:54

Can you recommend me some actions ? I have not found any relevant info on
the web.


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

#27159 [NEW]: Earnings for signal handler and Error in error.c

[patrick dot laux at bessy dot de]

From: patrick dot laux at bessy dot de
Operating system: linux-SuSE 9.0
PHP version:  4.3.4
PHP Bug Type: Compile Failure
Bug description:  Earnings for signal handler and Error in error.c

Description:

Hello 
 
Some Problems 
Compiling PHP 4.3.4 at SuSE 9.0 patch level from 
2004-02-03.  
Following configuration options:  
 
 
 

Reproduce code:
---
Following configuration options: 
./configure --prefix=/usr --with-apxs=/usr/sbin/apxs
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--libexecdir=/usr/
lib/apache/php --with-config-file-path=/etc/httpd
--with-sysconfigdir=/etc/httpd --with-exec-dir=/srv/www/bin
--enable-sigchild --wi
th-openssl=/usr -with-zlib=/usr --with-zlib-dir=/usr --with-bz2=/usr
--enable-calendar --with-jpeg-dir=/usr --enable-dba --with-inif
ile --with-flatfile --enable-dbase --enable-dio --with-dom=/usr
--with-dom-xslt=/usr --enable-exif --enable-filepro --enable-ftp --w
ith-gd=/usr/local --with-zlib-dir=/usr --with-xpm-dir=/usr/X11R6
--with-ttf=/usr --with-freetype=/usr --with-gettext=/usr --with-hyp
erwave --with-java=/usr/lib/java --with-ldap=/usr --enable-mbstring
--with-mcal=/usr --with-mcrypt=/usr --with-openssl-dir=/usr --wi
thout-mysql --with-ncurses=/usr --with-oci8=/opt/oracle/product/9ir2
--with-oracle=/opt/oracle/product/9ir2 --with-iodbc=/usr --with
-unixODBC=/usr --with-pdflib=/usr/local --with-png-dir=/usr
--with-tiff-dir=/usr --with-readline=/usr --with-recode=/usr --with-mm=/
usr --enable-shmop --enable-sockets --with-ming=/usr/local
--enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-wddx --with-e
xpat-dir=/usr --with-iconv-dir=/usr --with-xslt-sablot=/usr --enable-yp

Actual result:
--
Crashes with: 
/bin/sh /srv/ftp/www/php-4.3.4/libtool --silent 
--preserve-dup-deps --mode=compile gcc  -Iext/standard/ 
-I/srv/ftp/www/php-4.3.4/ext/standard/ -DPHP_ATOM_INC -I/
srv/ftp/www/php-4.3.4/include -I/srv/ftp/www/php-4.3.4/
main -I/srv/ftp/www/php-4.3.4 -I/srv/ftp/www/php-4.3.4/
Zend -I/usr/include/libxml2 -I/usr/X11R6/include -I/
include -I/usr/local/include -I/srv/ftp/www/php-4.3.4/ext/
mbstring/mbregex -I/srv/ftp/www/php-4.3.4/ext/mbstring/
libmbfl -I/srv/ftp/www/php-4.3.4/ext/mbstring/libmbfl/mbfl 
-I/usr/include/mcal -I/opt/oracle/product/9ir2/rdbms/
public -I/opt/oracle/product/9ir2/rdbms/demo -I/opt/
oracle/product/9ir2/plsql/public  -I/srv/ftp/www/
php-4.3.4/TSRM  -g -O2  -prefer-pic -c /srv/ftp/www/
php-4.3.4/ext/standard/exec.c -o ext/standard/exec.lo 
/srv/ftp/www/php-4.3.4/ext/standard/exec.c: In function 
`php_Exec': 
/srv/ftp/www/php-4.3.4/ext/standard/exec.c:165: `SIGCHLD' 
undeclared (first use in this function) 
/srv/ftp/www/php-4.3.4/ext/standard/exec.c:165: (Each 
undeclared identifier is reported only once 
/srv/ftp/www/php-4.3.4/ext/standard/exec.c:165: for each 
function it appears in.) 
/srv/ftp/www/php-4.3.4/ext/standard/exec.c:165: `SIG_DFL' 
undeclared (first use in this function) 
/srv/ftp/www/php-4.3.4/ext/standard/exec.c:165: warning: 
assignment makes pointer from integer without a cast 
/srv/ftp/www/php-4.3.4/ext/standard/exec.c:184: warning: 
assignment makes pointer from integer without a cast 
make: *** [ext/standard/exec.lo] Fehler 1 
 
and hav warnings at mcal, sockets, posix, hyperwave module 
like: 
 
In file included from /usr/include/asm/sigcontext.h:4, 
 from /usr/include/bits/sigcontext.h:28, 
 from /usr/include/signal.h:326, 
 from /srv/ftp/www/php-4.3.4/ext/sockets/
sockets.c:56: 
/usr/include/linux/compiler.h:71: warning: 
`__attribute_used__' redefined 
/usr/include/sys/cdefs.h:195: warning: this is the 
location of the previous definition 
 
 

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

#26128 [NEW]: mbstring for GB,BIG-5 support disabled

[patrick at patricktsang dot net]

From: patrick at patricktsang dot net
Operating system: RH9
PHP version:  4.3.4
PHP Bug Type: *Compile Issues
Bug description:  mbstring for GB,BIG-5 support disabled

Description:

I have no problem to enable GB and BIG-5 support with mbstring in 4.3.3

The version 4.3.4 has changed something on mbstring and I don't know why
phpinfo() reports me there is only Japanese supported.

I use: --enable-mbstring=all --enable-mbregex 

The compile just ended with a minor warning on tempname

Helps?
Patrick



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

#22782 [Com]: mktime funcktion fail

[patrick at sorrynospam dot org]

 ID:   22782
 Comment by:   patrick at sorrynospam dot org
 Reported By:  ameoba32 at riscom dot net
 Status:   Open
 Bug Type: Date/time related
 Operating System: W2K
 PHP Version:  4.3.1
 New Comment:

that seems to be correct though. 
remember that:
333: 01:00:00 27-02-2003
334: 01:00:00 28-02-2003  
335: 01:00:00 01-03-2003

see:
for($i=1; $i < 400; $i++){
echo date("$i: H:i:s d-m-Y", mktime(1,0,0,4,$i,2002))."\n";

}


Previous Comments:


[2003-03-19 02:57:20] ameoba32 at riscom dot net

echo date("H:i:s d-m-Y", mktime(0,0,0,4,364,2002))."\n";
echo date("H:i:s d-m-Y", mktime(1,0,0,4,364,2002))."\n";

prints this result:

01:00:00 30-03-2003
01:00:00 30-03-2003

364 is magic day number :) all other days works perfect.
thank you.





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

#21929 [NEW]: gcc: main/alloc: No such file or directory

[patrick . mcandrew]

From: [EMAIL PROTECTED]
Operating system: Solaris 2.8
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  gcc: main/alloc: No such file or directory

Hello,

My system:

Solaris 8
gcc 2.95
flex 2.54
bison 1.875
gmake 3.79
automake 1.7
autoconf 2.13

./configure:

 ./configure --with-oci8=/opt/oracle/product/8.1.6
--with-apache=../apache_1.3.27/

make seems to build the object files fine, it starts to get hairy around
the linking:

$ make
/bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 
-L/usr/ucblib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3
-L/opt/oracle/product/8.1.6/lib  -R /usr/ucblib -R
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3 -R
/opt/oracle/product/8.1.6/lib ext/ctype/ctype.lo ext/mysql/php_mysql.lo
ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo
ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo
ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo
ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo
ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo
ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo
ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo
ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo
ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo
ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo
ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo
ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo
ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo
ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo
ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo
ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo
ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo
ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo
ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo
ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo
ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo
ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo
ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo
ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo
ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo
ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo
ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo
ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo
ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo
ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo
ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo
ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo
ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/oci8/oci8.lo
ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo
ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo
ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo
ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo
ext/standard/array.lo ext/standard/base64.lo
ext/standard/basic_functions.lo ext/standard/browscap.lo
ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo
ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo
ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo
ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo
ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo
ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo
ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo
ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo
ext/standard/pageinfo.lo ext/standard/parsedate.lo
ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo
ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo
ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo
ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo
ext/standard/versioning.lo ext/standard/assert.lo
ext/standard/strnatcmp.lo ext/standard/levenshtein.lo
ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo
ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo
ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo
ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo
ext/standard/aggregation.lo ext/standard/sha1.lo
ext/tokenizer/tokenizer.lo ext/xml/xml.lo ext/xml/expat/xmlparse.lo
ext/xml/expat/xmlrole.lo ext/xml/expat/xmltok.lo regex/regcomp.lo
regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo
TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo
main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo
main/fopen_wrappers.lo main/alloca.lo main/php_ini.lo main/SAPI.lo
main/rfc1867.lo main/php_content_types.lo main/strlcpy.l

#21654 [Com]: BINARIES DOWNLOADED CORRUPTION

[patrick . audemard]

 ID:   21654
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: cURL related
 Operating System: WINDOWS 2000 SP3
 PHP Version:  4CVS-2003-01-15 (stable)
 New Comment:

I tested and it worked.
Sorry, I checked but I forgot the "wb" in the fopen()...

Yours sincerely,

Patrick AUDEMARD


Previous Comments:


[2003-01-15 05:13:57] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

When using PHP on Windows platform it\'s generally necessary to specify
binary mode at fopen() parameter in order to write out non-text data.
But actually the data are always written as binary on CGI or CLI
version of PHP binary unless you specify text mode that is represented
as \"t\". This is a known exception.





[2003-01-15 04:33:35] [EMAIL PROTECTED]

WEB Server : Apache 2.0.42 with SSL enabled
PHP 4.3.1 CVS 2003-01-15-01-30
WINDOWS 2000 SP3
Browser IE6SP1

Script :

$ch = curl_init();
curl_setopt ($ch,CURLOPT_URL,$sitedownload.$_POST'fichier']);
curl_setopt ($ch, CURLOPT_HEADER,0);
curl_setopt ($ch,CURLOPT_PROXY,$proxy);
$fichiersigs = fopen ($_POST['fichier'], "w");
curl_setopt ($ch,CURLOPT_FILE,$fichiersigs);
$test = curl_exec ($ch);
curl_close ($ch);

If you configured PHP with Apache Module (php4apache2.dll) a binary
downloaded file (tested ZIP File) is corrupted. It seemed to convert LF
to CRLF but I'm not sure.

I tried without success :
curl_setopt ($ch,CURLOPT_CRLF,0);

If you configured PHP CGI, it works fine (I tested MD5).

I tested version 4.3.1 CVS 2003-01-14-01-30 and CVS 2003-01-15-01-30. I
think it's easy to reproduce.

Yours sincerely,

Patrick AUDEMARD




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

#21654 [NEW]: BINARIES DOWNLOADED CORRUPTION

[patrick . audemard]

From: [EMAIL PROTECTED]
Operating system: WINDOWS 2000 SP3
PHP version:  4CVS-2003-01-15 (stable)
PHP Bug Type: cURL related
Bug description:  BINARIES DOWNLOADED CORRUPTION

WEB Server : Apache 2.0.42 with SSL enabled
PHP 4.3.1 CVS 2003-01-15-01-30
WINDOWS 2000 SP3
Browser IE6SP1

Script :

$ch = curl_init();
curl_setopt ($ch,CURLOPT_URL,$sitedownload.$_POST'fichier']);
curl_setopt ($ch, CURLOPT_HEADER,0);
curl_setopt ($ch,CURLOPT_PROXY,$proxy);
$fichiersigs = fopen ($_POST['fichier'], "w");
curl_setopt ($ch,CURLOPT_FILE,$fichiersigs);
$test = curl_exec ($ch);
curl_close ($ch);

If you configured PHP with Apache Module (php4apache2.dll) a binary
downloaded file (tested ZIP File) is corrupted. It seemed to convert LF to
CRLF but I'm not sure.

I tried without success :
curl_setopt ($ch,CURLOPT_CRLF,0);

If you configured PHP CGI, it works fine (I tested MD5).

I tested version 4.3.1 CVS 2003-01-14-01-30 and CVS 2003-01-15-01-30. I
think it's easy to reproduce.

Yours sincerely,

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

#21581 [Com]: CURL_EXEC CRASH WITH CURLOPT_FILE

[patrick . audemard]

 ID:   21581
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: cURL related
 Operating System: WINDOWS 2000
 PHP Version:  4.3.0
 New Comment:

Thanks a lot !!!


Previous Comments:


[2003-01-14 09:54:20] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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

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

User reports that the latest snapshot works, closing.



[2003-01-14 09:46:37] [EMAIL PROTECTED]

Snaps php4-win32-STABLE-200301140130.zip works fine !



[2003-01-11 09:22:12] [EMAIL PROTECTED]

Modified to cURL related.



[2003-01-11 08:15:54] [EMAIL PROTECTED]

PHP 4.3.0 crash (php.exe or WEB server) when you use the example code
in PHP Manual. This bug was reported in version 4.2.3 (ID : 19301 ).

$ch = curl_init ("http://www.ebay.com";);
$fp = fopen ("output/result.txt", "w");

curl_setopt ($ch, CURLOPT_FILE, $fp);
curl_setopt ($ch, CURLOPT_HEADER, 0);

curl_exec ($ch);
curl_close ($ch);
fclose ($fp);

It's very easy to reproduce.





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

#21581 [Opn]: CURL_EXEC CRASH WITH CURLOPT_FILE

[patrick . audemard]

 ID:   21581
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: cURL related
 Operating System: WINDOWS 2000
 PHP Version:  4.3.0
 New Comment:

Snaps php4-win32-STABLE-200301140130.zip works fine !


Previous Comments:


[2003-01-11 09:22:12] [EMAIL PROTECTED]

Modified to cURL related.



[2003-01-11 08:15:54] [EMAIL PROTECTED]

PHP 4.3.0 crash (php.exe or WEB server) when you use the example code
in PHP Manual. This bug was reported in version 4.2.3 (ID : 19301 ).

$ch = curl_init ("http://www.ebay.com";);
$fp = fopen ("output/result.txt", "w");

curl_setopt ($ch, CURLOPT_FILE, $fp);
curl_setopt ($ch, CURLOPT_HEADER, 0);

curl_exec ($ch);
curl_close ($ch);
fclose ($fp);

It's very easy to reproduce.





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

#21581 [Opn]: CURL_EXEC CRASH WITH CURLOPT_FILE

[patrick . audemard]

 ID:   21581
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Reproducible crash
+Bug Type: cURL related
 Operating System: WINDOWS 2000
 PHP Version:  4.3.0
 New Comment:

Modified to cURL related.


Previous Comments:


[2003-01-11 08:15:54] [EMAIL PROTECTED]

PHP 4.3.0 crash (php.exe or WEB server) when you use the example code
in PHP Manual. This bug was reported in version 4.2.3 (ID : 19301 ).

$ch = curl_init ("http://www.ebay.com";);
$fp = fopen ("output/result.txt", "w");

curl_setopt ($ch, CURLOPT_FILE, $fp);
curl_setopt ($ch, CURLOPT_HEADER, 0);

curl_exec ($ch);
curl_close ($ch);
fclose ($fp);

It's very easy to reproduce.





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

#21581 [NEW]: CURL_EXEC CRASH WITH CURLOPT_FILE

[patrick . audemard]

From: [EMAIL PROTECTED]
Operating system: WINDOWS 2000
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  CURL_EXEC CRASH WITH CURLOPT_FILE

PHP 4.3.0 crash (php.exe or WEB server) when you use the example code in
PHP Manual. This bug was reported in version 4.2.3 (ID : 19301 ).

$ch = curl_init ("http://www.ebay.com";);
$fp = fopen ("output/result.txt", "w");

curl_setopt ($ch, CURLOPT_FILE, $fp);
curl_setopt ($ch, CURLOPT_HEADER, 0);

curl_exec ($ch);
curl_close ($ch);
fclose ($fp);

It's very easy to reproduce.

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

#15374 [Com]: include_path loses value when executed

[patrick . greer]

 ID:   15374
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: PHP options/info functions
 Operating System: Solaris 8
 PHP Version:  4.2.1
 New Comment:

I am experiencing the same issue with my hosting provider! Plaform is:
* FreeBSD 4.6-STABLE
* Apache/1.3.27 (Unix) FrontPage/5.0.2.2510 mod_ssl/2.8.11
OpenSSL/0.9.6a
* PHP 4.2.3

I have to do the ini_set('include_path', ini_get('include_path'));
trick to pick up any PEAR classes.

It seems, however, that if I set the include_path in an .htaccess
directive, the problem completely goes away...

If I can help diagnose this, I'd be happy to.

Patrick


Previous Comments:


[2002-09-11 01:00:02] [EMAIL PROTECTED]

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



[2002-08-10 09:37:23] [EMAIL PROTECTED]

Any chance you can try the non-stable, development branch of this?  



[2002-08-08 14:34:48] [EMAIL PROTECTED]

php4-STABLE-latest.tar.gz > 08-Aug-2002 09:02   3.3M

still appears that the include_path value doesn't get dropped, but it
also doesn't get used.



[2002-08-08 09:16:18] [EMAIL PROTECTED]

here is more information on that snapshot we installed; in particular
the requirement of absolute paths.  it seems to not drop the
'include_path' information - which is good, but it also doesn't seem to
use the value either.

Warning: main("Class.php") - No such file or directory in
/usr/local/http-data/htdocs/foo/foo.php on line 2

Fatal error: Failed opening required 'Class.php'
(include_path='.:/usr/local/lib/php') in
/usr/local/http-data/htdocs/foo/foo.php on line 2



[2002-07-19 15:51:25] [EMAIL PROTECTED]

that snapshot seems to require absolute pathnames, or atleast rejust
relative paths?

i haven't noticed a warning being generated.  but this is on our
non-production and "less stressed" test web server.



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

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

#20991 [NEW]: GD 2.0.1 lib problem?

[patrick]

From: [EMAIL PROTECTED]
Operating system: RH 7.3
PHP version:  4.3.0RC3
PHP Bug Type: Compile Failure
Bug description:  GD 2.0.1 lib problem?

System: P4-2G
RAM: 1G
OS: RH 7.3

PHP 4.3RC2 compile OK
PHP 4.3RC3 compile FAIL
using the same compile line.

NOTE: gd lib version 2.0.1 (gif hacked)

./configure  --with-apxs=/usr/local/apache/bin/apxs  \
--with-config-file-path=/usr/local/apache/conf  --enable-versioning  \
--with-mysql  --enable-ftp  --enable-bcmath  --enable-inline-optimization
\
--disable-debug  \
--enable-memory-limit=yes  --enable-track-vars --enable-save-mode \
--enable-magic-quotes --with-gettext=/usr/bin \
--with-xml --with-imap=/usr/local/imap \
--with-curl=/usr/local --enable-mbstring --enable-mbstr-enc-trans \
--with-jpeg-dir=/usr --with-png-dir=/usr \
--with-zlib-dir=/usr/local --with-t1lib=/usr/local \
--with-gd=/usr --with-zlib=/usr/local --enable-gd-imgstrttf \
--enable-gd-native-ttf --with-freetype-dir=/usr \
--with-pdflib=/usr/local --with-openssl=/usr/local/openssl \
--enable-trans-sid --with-cpdflib --with-pgsql --with-ming=/usr  \
--with-bz2 --enable-calendar --with-pspell \
--enable-tokenizer --with-iconv=/usr/local \
--with-gmp --with-mcrypt --with-ldap --with-mm \
--with-mbstring=all --enable-mbregex \
--enable-xslt --with-xslt-sablot \
--with-sablot-js --with-expat-dir=/usr/local \


Err Message:
(by PHP 4.3RC3)

/bin/sh libtool --silent --mode=compile gcc -I/usr/include -Iext/gd/
-I/www/compile/php-4.3.0RC3/ext/gd/ -DPHP_ATOM_INC
-I/www/compile/php-4.3.0RC3/include -I/www/compile/php-4.3.0RC3/main
-I/www/compile/php-4.3.0RC3 -I/www/compile/php-4.3.0RC3/Zend
-I/usr/local/openssl/include -I/usr/local/include -I/usr/include/freetype2
-I/usr/local/imap/include -I/usr/include/pspell  -DLINUX=22
-DMOD_SSL=208112 -DUSE_HSREGEX -DEAPI -DEAPI_MM
-I/www/compile/php-4.3.0RC3/TSRM  -g -O2  -prefer-pic -c
/www/compile/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo 
/www/compile/php-4.3.0RC3/ext/gd/gd.c: In function
`_php_image_create_from':
/www/compile/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment makes
pointer from integer without a cast
/www/compile/php-4.3.0RC3/ext/gd/gd.c: In function
`zif_imagecreatefromxpm':
/www/compile/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm'
undeclared (first use in this function)
/www/compile/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared identifier is
reported only once
/www/compile/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it appears
in.)
make: *** [ext/gd/gd.lo] Error 1

thx
Patrick Tsang


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

#20648 [NEW]: PHP 4.3RC1 Java feature list missing

[patrick]

From: [EMAIL PROTECTED]
Operating system: RH 7.3/8.0/AS 2.1
PHP version:  4.3.0RC1
PHP Bug Type: Feature/Change Request
Bug description:  PHP 4.3RC1 Java feature list missing

Sorry for the silly question.

Please provide me the latest PHP 4.3 features on Class set.
I would like to compare and test with some of our old 4.2 classes.

thx
Patrick Tsang

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

#20603 [Fbk->Opn]: Zend Engine problem?

[patrick]

 ID:   20603
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: RH AS 2.1
 PHP Version:  4.3.0RC1
 New Comment:

Thx,
Fixed if CPU in lower speed...
just still got the 'tempnam' -> 'mkstemp' issue.

RH AS 2.1 comes with the buggy gcc 2.96.

PT


Previous Comments:


[2002-11-23 23:05:11] [EMAIL PROTECTED]

Works fine here..what if you run 'make' again? Does the error happen
with same file and with same function?
(this is most likely a hardware problem if it happens with something
else)

Also, what gcc version are you running?





[2002-11-23 22:18:11] [EMAIL PROTECTED]

OS: RH AS 2.1
P4 2.5G
768M RAM

Apache 1.3.27 + PHP 4.30RC1

Compile line:
==

./configure  --with-apxs=/usr/local/apache/bin/apxs  \
--with-config-file-path=/usr/local/apache/conf  --enable-versioning  \
--with-mysql  --enable-ftp  --enable-bcmath 
--enable-inline-optimization \
--disable-debug  \
--enable-memory-limit=yes  --enable-track-vars --enable-save-mode \
--enable-magic-quotes --with-gettext=/usr/bin \
--with-xml --with-imap=/usr/local/imap \
--with-curl=/usr/local --enable-mbstring --enable-mbstr-enc-trans \
--with-jpeg-dir=/usr --with-png-dir=/usr \
--with-zlib-dir=/usr/local --with-t1lib=/usr/local \
--with-gd=/usr --with-zlib=/usr/local --enable-gd-imgstrttf \
--enable-gd-native-ttf --with-freetype-dir=/usr \
--with-pdflib=/usr/local --with-openssl=/usr/local/openssl \
--enable-trans-sid --with-cpdflib --with-pgsql --with-ming=/usr  \
--with-bz2 --enable-calendar --with-qtdom \
--enable-tokenizer --with-iconv=/usr/local \
--with-gmp --with-mcrypt --with-ldap --with-mm \
--with-mbstring=all --enable-mbregex \
--enable-xslt --with-xslt-sablot \
--with-sablot-js --with-expat-dir=/usr/local \


Compile error:
=

/bin/sh libtool --silent --mode=compile gcc  -IZend/
-I/tmp/www/php-4.3.0RC1/Zend/ -DPHP_ATOM_INC
-I/tmp/www/php-4.3.0RC1/include -I/tmp/www/php-4.3.0RC1/main
-I/tmp/www/php-4.3.0RC1 -I/tmp/www/php-4.3.0RC1/Zend
-I/usr/local/openssl/include -I/usr/local/include
-I/usr/include/freetype2 -I/usr/local/imap/include -I/usr/include/pgsql
 -DLINUX=22 -DMOD_SSL=208112 -DUSE_HSREGEX -DEAPI -DEAPI_MM
-I/tmp/www/php-4.3.0RC1/TSRM  -g -O2  -prefer-pic -c
/tmp/www/php-4.3.0RC1/Zend/zend_indent.c -o Zend/zend_indent.lo 
/bin/sh libtool --silent --mode=compile gcc  -IZend/
-I/tmp/www/php-4.3.0RC1/Zend/ -DPHP_ATOM_INC
-I/tmp/www/php-4.3.0RC1/include -I/tmp/www/php-4.3.0RC1/main
-I/tmp/www/php-4.3.0RC1 -I/tmp/www/php-4.3.0RC1/Zend
-I/usr/local/openssl/include -I/usr/local/include
-I/usr/include/freetype2 -I/usr/local/imap/include -I/usr/include/pgsql
 -DLINUX=22 -DMOD_SSL=208112 -DUSE_HSREGEX -DEAPI -DEAPI_MM
-I/tmp/www/php-4.3.0RC1/TSRM  -g -O2  -prefer-pic -c
/tmp/www/php-4.3.0RC1/Zend/zend_builtin_functions.c -o
Zend/zend_builtin_functions.lo 
/tmp/www/php-4.3.0RC1/Zend/zend_builtin_functions.c: In function
`zif_get_class_methods':
/tmp/www/php-4.3.0RC1/Zend/zend_builtin_functions.c:680: Internal
error: Segmentation fault.
Please submit a full bug report.


Seems it's a problem of Zend engine.

Thx
PT






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

#20603 [NEW]: Zend Engine problem?

[patrick]

From: [EMAIL PROTECTED]
Operating system: RH AS 2.1
PHP version:  4.3.0RC1
PHP Bug Type: Compile Failure
Bug description:  Zend Engine problem?

OS: RH AS 2.1
P4 2.5G
768M RAM

Apache 1.3.27 + PHP 4.30RC1

Compile line:
==

./configure  --with-apxs=/usr/local/apache/bin/apxs  \
--with-config-file-path=/usr/local/apache/conf  --enable-versioning  \
--with-mysql  --enable-ftp  --enable-bcmath  --enable-inline-optimization
\
--disable-debug  \
--enable-memory-limit=yes  --enable-track-vars --enable-save-mode \
--enable-magic-quotes --with-gettext=/usr/bin \
--with-xml --with-imap=/usr/local/imap \
--with-curl=/usr/local --enable-mbstring --enable-mbstr-enc-trans \
--with-jpeg-dir=/usr --with-png-dir=/usr \
--with-zlib-dir=/usr/local --with-t1lib=/usr/local \
--with-gd=/usr --with-zlib=/usr/local --enable-gd-imgstrttf \
--enable-gd-native-ttf --with-freetype-dir=/usr \
--with-pdflib=/usr/local --with-openssl=/usr/local/openssl \
--enable-trans-sid --with-cpdflib --with-pgsql --with-ming=/usr  \
--with-bz2 --enable-calendar --with-qtdom \
--enable-tokenizer --with-iconv=/usr/local \
--with-gmp --with-mcrypt --with-ldap --with-mm \
--with-mbstring=all --enable-mbregex \
--enable-xslt --with-xslt-sablot \
--with-sablot-js --with-expat-dir=/usr/local \


Compile error:
=

/bin/sh libtool --silent --mode=compile gcc  -IZend/
-I/tmp/www/php-4.3.0RC1/Zend/ -DPHP_ATOM_INC
-I/tmp/www/php-4.3.0RC1/include -I/tmp/www/php-4.3.0RC1/main
-I/tmp/www/php-4.3.0RC1 -I/tmp/www/php-4.3.0RC1/Zend
-I/usr/local/openssl/include -I/usr/local/include -I/usr/include/freetype2
-I/usr/local/imap/include -I/usr/include/pgsql  -DLINUX=22
-DMOD_SSL=208112 -DUSE_HSREGEX -DEAPI -DEAPI_MM
-I/tmp/www/php-4.3.0RC1/TSRM  -g -O2  -prefer-pic -c
/tmp/www/php-4.3.0RC1/Zend/zend_indent.c -o Zend/zend_indent.lo 
/bin/sh libtool --silent --mode=compile gcc  -IZend/
-I/tmp/www/php-4.3.0RC1/Zend/ -DPHP_ATOM_INC
-I/tmp/www/php-4.3.0RC1/include -I/tmp/www/php-4.3.0RC1/main
-I/tmp/www/php-4.3.0RC1 -I/tmp/www/php-4.3.0RC1/Zend
-I/usr/local/openssl/include -I/usr/local/include -I/usr/include/freetype2
-I/usr/local/imap/include -I/usr/include/pgsql  -DLINUX=22
-DMOD_SSL=208112 -DUSE_HSREGEX -DEAPI -DEAPI_MM
-I/tmp/www/php-4.3.0RC1/TSRM  -g -O2  -prefer-pic -c
/tmp/www/php-4.3.0RC1/Zend/zend_builtin_functions.c -o
Zend/zend_builtin_functions.lo 
/tmp/www/php-4.3.0RC1/Zend/zend_builtin_functions.c: In function
`zif_get_class_methods':
/tmp/www/php-4.3.0RC1/Zend/zend_builtin_functions.c:680: Internal error:
Segmentation fault.
Please submit a full bug report.


Seems it's a problem of Zend engine.

Thx
PT


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

Bug #16796: where is php_oracle.dll

[patrick]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.2.0
PHP Bug Type: *Configuration Issues
Bug description:  where is php_oracle.dll

As i have a ORACLE 7 App running on W2k I am now Missing the php_oracle.dll
extension.

is this a feature or ist this support obsolete

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

Bug #16526 Updated: MySQL pconnect behaviour changed

[patrick]

 ID:   16526
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: MySQL related
 Operating System: Linux RH 7.1
 PHP Version:  4.1.2
 New Comment:

Dear Derick,

In my case it prompts as:
[EMAIL PROTECTED] instead of user@localhost!

I have to add the host access right in MySQL 4.0.

Any better solution?

Patrick Tsang


Previous Comments:


[2002-04-10 08:02:59] [EMAIL PROTECTED]

Hi Derick,

Thanks for the quick response. My hosts file:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1   localhost.localdomain   localhost



[2002-04-10 04:52:21] [EMAIL PROTECTED]

This is actually good news, means that I'm not alone. Can you please
mail me your /etc/hosts file?

Derick



[2002-04-10 03:34:16] [EMAIL PROTECTED]

Hi,

I just upgraded from php 4.0.6 to php-4.2.0RC2, and all of a sudden I
get failures when trying to connect to the mySQL server. It now tries
to connect as '[EMAIL PROTECTED]' where previously it used
'user@localhost'.

Regards,
  Willo




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

Bug #14391 Updated: gmmktime, gmdate work incorrect

[patrick]

 ID:   14391
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: Windows 2000 Server
 PHP Version:  4.0.6
 New Comment:

[seen on: w2k, different php versions since 4.0.4, apache]

Please fix this! The bug still IS an important issue. For different
reasons, the main one being the 'linearity' of gmt-epoch timestamps
that is NOT given an this point. I'm in TZ+1, we just flipped DST on
and my gmt-stamps went crazy!!

$epoch = gmmktime(0,0,0,4,20,2002);
returns not (!!) the same with and without DST (e.g. use: 20.3.2002
versus 20.4.2002 as execution time)

Have some more testcases:
$timgmt = gmmktime(1,0,0,1,1,1970);  //fails in TZ+1 w/o DST
$timgmt = gmmktime(0,0,0,1,1,1970);  //=7199!? should be 0? (8.4.2002)
$timgmt = gmmktime(1,0,1,1,1,1970);  //=0, should be 3600 (8.4.2002)

Try 'looping' across DST boundaries in two ways and you will spot the
problem instantly:

1. count up 'hours' in gmmktime()
-
print "Count (+1) days from 28.3.2002:\n";
for($day=0; $day<7; $day++){
$timgmt = gmmktime(0,0,0,3,28+$day,2002);
$timloc = mktime(0,0,0,3,28+$day,2002);
print $timgmt . "= gmmktim epoch - " . gmdate("D d.m.Y H:i I",$timgmt)
. "\n";
print $timloc . "= mktim epoch - " . date("D d.m.Y H:i  I",$timloc) .
"\n";
}
-
count days:
101727= gmmktim epoch - Wed 27.03.2002 23:00 0
101727= mktim epoch - Thu 28.03.2002 00:00 0

1017356400= gmmktim epoch - Thu 28.03.2002 23:00 0
1017356400= mktim epoch - Fri 29.03.2002 00:00 0

1017442800= gmmktim epoch - Fri 29.03.2002 23:00 0
1017442800= mktim epoch - Sat 30.03.2002 00:00 0

1017529200= gmmktim epoch - Sat 30.03.2002 23:00 0
1017529200= mktim epoch - Sun 31.03.2002 00:00 0

1017619200= gmmktim epoch - Mon 01.04.2002 00:00 0
1017612000= mktim epoch - Mon 01.04.2002 00:00 1

1017705600= gmmktim epoch - Tue 02.04.2002 00:00 0
1017698400= mktim epoch - Tue 02.04.2002 00:00 1

1017792000= gmmktim epoch - Wed 03.04.2002 00:00 0
1017784800= mktim epoch - Wed 03.04.2002 00:00 1
---

2. count up 'seconds' in gmmktime()
-
print "Count (+84600) seconds from 28.3.2002:\n";
$baseepoch = $timloc = gmmktime(0,0,0,3,28,2002);
for($day=0; $day<7; $day++){
$epochnow = $baseepoch + (60 * 60 * 24 * $day);
print $epochnow . "= gmmktim epoch - " . gmdate("D d.m.Y H:i
I",$epochnow) . "\n";
print $epochnow . "= mktim epoch - " . date("D d.m.Y H:i 
I",$epochnow) . "\n";
}
-

101727= gmmktim epoch - Wed 27.03.2002 23:00 0
101727= mktim epoch - Thu 28.03.2002 00:00 0

1017356400= gmmktim epoch - Thu 28.03.2002 23:00 0
1017356400= mktim epoch - Fri 29.03.2002 00:00 0

1017442800= gmmktim epoch - Fri 29.03.2002 23:00 0
1017442800= mktim epoch - Sat 30.03.2002 00:00 0

1017529200= gmmktim epoch - Sat 30.03.2002 23:00 0
1017529200= mktim epoch - Sun 31.03.2002 00:00 0

1017615600= gmmktim epoch - Sun 31.03.2002 23:00 0
1017615600= mktim epoch - Mon 01.04.2002 01:00 1

1017702000= gmmktim epoch - Mon 01.04.2002 23:00 0
1017702000= mktim epoch - Tue 02.04.2002 01:00 1

1017788400= gmmktim epoch - Tue 02.04.2002 23:00 0
1017788400= mktim epoch - Wed 03.04.2002 01:00 1
---

the second loop works correctly from epoch through gmdate, but gmmktime
fails to an 1 hour offset in the first place...

To sum it up: There is no way to get a correct GMT-stamp at this point,
that would remain correct through DST changes.


Previous Comments:


[2002-03-17 14:33:08] [EMAIL PROTECTED]

Reopening.



[2002-03-17 14:24:39] [EMAIL PROTECTED]

Have just replicated it with 4.1.2 on Win2K.

So Solaris and Win2K - the two biggest server platforms - are still
both affected. Could someone please sort this out? Or at least please
change the status of this bug, since there is now ample feedback that
shows that it's still alive...



[2002-02-22 05:52:09] [EMAIL PROTECTED]

I setuped php4.1.1 on my Win2K, and now there is no problem with "Z"
parameter in gmdate() function, but timestamp returned by gmmktime in
winter time is still wrong. 
Will be this bug fixed?



[2002-02-22 05:16:06] [EMAIL PROTECTED]

Hi,

This bug is still here, and still causing grief. Sadly, it's been
marked "No Feedback" now. Will someone please sort this? I can't
imagine it's a particularly complicated thing to fix, since it seems to
be okay on some platforms.

Max



[2002-02-19 15:40:37] [EMAIL PROTECTED]

Any updates on this bug as it appears to sti

Bug #16212 Updated: Using natsort() on multi-dimensional arrays causes the PHP engine to segfault

[patrick]

 ID:   16212
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Mandrake Linux 8.2
 PHP Version:  4.1.2
 New Comment:

Derick,
I am now using RC1 from your page, and I still get the error.
Here are my compile options:

'./configure' '--prefix=/usr' '--with-mysql=/usr'
'--with-apxs=/usr/sbin/apxs' 
'--enable-gd=/usr/lib/gd-1.8.4' '--enable-ftp'

I believe I've found what causes it. If I create a multi-dimensional
that has a sub-array at either 
the beginning or end, the engine does not crash:


[[EMAIL PROTECTED]]-[~]$ php -r 'error_reporting(E_ALL); $x =
array(array(),"c","b","a"); natsort($x); 
print_r($x);';
Array
(
[0] => Array
(
)

[3] => a
[2] => b
[1] => c
)


The engine doesn't seggfault. However, if I create a multi-dimensional
array with a sub-array 
anywhere but at the beginning or end, this happens:


[[EMAIL PROTECTED]]-[~]$ php -r 'error_reporting(E_ALL); $x =
array("c",array(),"b","a"); natsort($x); 
print_r($x);';
Array
(
[1] => Array
(
)

[3] => a
[2] => b
[0] => c
)

Segmentation fault


Previous Comments:


[2002-03-22 03:43:25] [EMAIL PROTECTED]

Me neither, can you try RC1 from www.php.net/~derick ?

Derick



[2002-03-21 18:08:35] [EMAIL PROTECTED]

Weird, can't reproduce this at all:

$ php -r 'error_reporting(E_ALL); $x = array("a",array("x","y"),"b");
natsort($x);'
Command line code(1) : Notice - Array to string conversion
Command line code(1) : Notice - Array to string conversion

Even with 4.1.2 on another machine no esegfault, just the warnings.



[2002-03-21 16:44:54] [EMAIL PROTECTED]

The problem arises when you attempt to natsort() a multi-dimensional
array, which in turn causes the engine 
to segault.

[[EMAIL PROTECTED]]-[~]$ echo '' | php -q
Segmentation fault

This bug exists in both PHP-4.1.2 and the current PHP CVS as of
03/21/02.




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

Bug #16212: Using natsort() on multi-dimensional arrays causes the PHP engine to segfault

[patrick]

From: [EMAIL PROTECTED]
Operating system: Mandrake Linux 8.2
PHP version:  4.1.2
PHP Bug Type: Reproducible crash
Bug description:  Using natsort() on multi-dimensional arrays causes the PHP engine to 
segfault

The problem arises when you attempt to natsort() a multi-dimensional array,
which in turn causes the engine 
to segault.

[[EMAIL PROTECTED]]-[~]$ echo '' | php -q
Segmentation fault

This bug exists in both PHP-4.1.2 and the current PHP CVS as of 03/21/02.
-- 
Edit bug report at http://bugs.php.net/?id=16212&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16212&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16212&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16212&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16212&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16212&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16212&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16212&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16212&r=submittedtwice

Bug #15693: HTTP HEAD request executes entire script

[patrick]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.5
PHP version:  4.1.1
PHP Bug Type: HTTP related
Bug description:  HTTP HEAD request executes entire script

Maybe this is the way it's supposed to work, but it doesn't make a whole
lot of sense to me.

When processing a HEAD request, mod_php executes the script as if it were
a normal GET request. This is unexpected (at least to me) and can lead to
unexpected results, such as duplicate execution when dealing with browsers
that use a HEAD request prior to a GET request.

For example, test script test.php:


and assuming test.out exists and is world-writable.

HEAD /test.php HTTP/1.0

causes the file test.out to be appended to.

This is not what I would expect, but maybe it's unavoidable. A workaround
is to look at $_SERVER['REQUEST_METHOD'] and do nothing if it's a HEAD
request.


 './configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-system-regex' '--disable-debug' '--enable-track-vars'
'--without-gd' '--without-mysql' '--with-zlib' '--with-mcrypt=/usr/local'
'--with-mysql=/usr/local' '--prefix=/usr/local' 'i386--freebsd4.5'




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

Bug #14847 Updated: relative links for including other scripts do not work anymore

[patrick]

 ID:   14847
 Updated by:   [EMAIL PROTECTED]
-Reported By:  [EMAIL PROTECTED]
+Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: W2k
 PHP Version:  4.1.1
 New Comment:

Same OS and version as previous comments. What I have found is that the
include () fails (and causes an error) if used inside a function within
a class.


Previous Comments:


[2002-01-25 03:47:06] [EMAIL PROTECTED]

I have a similar problem using W98 SE + PWS and PHP 4.1.1.

I'll try give an explanation of what goes wrong

In the base directory I have a directory called "admin".

When I include a file menu.php from a file within the "admin" dir. I
get a file menu.php but it comes from the base dir. When I remove this
file from the base dir then the right file from the "admin" dir is
included.

I've installed PHP 4.1.0 and things seem to work properly again.



[2002-01-04 07:26:10] [EMAIL PROTECTED]

- just upgraded from 4.1.0 to 4.1.1 (win32 binaries)
- afterwards, no php-script-includes worked anymore (e.g. include
("includes/bugreport.php");)




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