#38303 [Opn->Asn]: spl_autoload_register() supress all errors silently
ID: 38303 Updated by: [EMAIL PROTECTED] Reported By: marcos dot neves at gmail dot com -Status: Open +Status: Assigned Bug Type: SPL related Operating System: WINXP PHP Version: 5CVS-2006-08-03 (snap) -Assigned To: +Assigned To: iliaa Previous Comments: [2006-08-03 02:34:43] marcos dot neves at gmail dot com Description: If an error happens inside the loaded class, it dies silently with no display. That is horrible to debugging. Reproduce code: --- Expected result: Parse error: parse error, unexpected T_CLASS, expecting ',' or ';' in abc.php on line 5 Actual result: -- nothing is displayed -- Edit this bug report at http://bugs.php.net/?id=38303&edit=1
#38303 [NEW]: spl_autoload_register() supress all errors silently
From: marcos dot neves at gmail dot com Operating system: WINXP PHP version: 5CVS-2006-08-03 (snap) PHP Bug Type: SPL related Bug description: spl_autoload_register() supress all errors silently Description: If an error happens inside the loaded class, it dies silently with no display. That is horrible to debugging. Reproduce code: --- Expected result: Parse error: parse error, unexpected T_CLASS, expecting ',' or ';' in abc.php on line 5 Actual result: -- nothing is displayed -- Edit bug report at http://bugs.php.net/?id=38303&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38303&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38303&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38303&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38303&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38303&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38303&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38303&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38303&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38303&r=support Expected behavior:http://bugs.php.net/fix.php?id=38303&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38303&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38303&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38303&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38303&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38303&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38303&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38303&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38303&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38303&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38303&r=mysqlcfg
#38302 [NEW]: Warning:No such file or directory
From: fyini at hkespow dot com Operating system: windows2000 PHP version: 5.1.4 PHP Bug Type: Directory function related Bug description: Warning:No such file or directory Description: directory www |- test.php |- test | |- a.php | |- b.php | |- test | | |- c.php Reproduce code: --- test.php a.php c.php Expected result: require Actual result: -- Warning: require_once(../b.php) [function.require-once]: failed to open stream: No such file or directory in E:\testweb\test\test\c.php on line 1 Fatal error: require_once() [function.require]: Failed opening required '../b.php' (include_path='.;C:\php5\pear') in E:\testweb\test\test\c.php on line 1 -- Edit bug report at http://bugs.php.net/?id=38302&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38302&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38302&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38302&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38302&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38302&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38302&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38302&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38302&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38302&r=support Expected behavior:http://bugs.php.net/fix.php?id=38302&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38302&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38302&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38302&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38302&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38302&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38302&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38302&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38302&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38302&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38302&r=mysqlcfg
#38301 [NEW]: field enclosure behavior in fputcsv
From: programmer at tklee dot com
Operating system: Linux
PHP version: 5.1.4
PHP Bug Type: Feature/Change Request
Bug description: field enclosure behavior in fputcsv
Description:
Regarding the field enclosure parameter in fputcsv...
1. It's unrealistic to require the field enclosure to be one character
because it's very common to have "empty string" as the field delimiter
(especially when TAB is used as field delimiter). I tried to use "\0" as
the field enclosure, hoping that'd be interpreted as an empty string, but
fputcsv translated it into literal.
2. fputcsv wrongly adds the field enclosures whenever a field contains a
space. The expected behavior should be adding the field enclosures when a
field contains a field delimiter.
Reproduce code:
---
/*
test_in.csv has only one line:
$line = "field 0\tfield_1\tfield 2\n";
*/
$fh_in=fopen("test_in.csv","r");
$fh_out=fopen("test_out.csv","w");
// since "" is not accepted as the 4th parameter, I use "\0" instead
$fields = fgetcsv($fh_in, 0, "\t", "\0");
fputcsv($fh_out, $fields, "\t", "\0");
close($fh_in);
close($fh_out);
Expected result:
/*
One would expect to see in test_out.csv :
$line = "field 0\tfield_1\tfield_2\n";
*/
Actual result:
--
/*
However, the result shows:
$line = "\0field 0\0\tfield_1\t\0field 2\0\n";
Unexpected:
1. Since space is not the field delimiter, there is no point of using the
field enclosure.
2. Empty enclosure is very common and should be accepted.
*/
--
Edit bug report at http://bugs.php.net/?id=38301&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38301&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38301&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38301&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38301&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38301&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38301&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38301&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38301&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38301&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38301&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38301&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38301&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38301&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38301&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38301&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38301&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38301&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38301&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38301&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38301&r=mysqlcfg
#38300 [Opn->Bgs]: equation result error
ID: 38300 Updated by: [EMAIL PROTECTED] Reported By: rogergg at gmail dot com -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: linux/windows PHP Version: 5.1.4 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. Previous Comments: [2006-08-02 22:28:18] rogergg at gmail dot com Description: the result for $a is 40 exactly. you can check it but i donk know why the if choosed that it is different. the problem is with the result that this take from the equation. if you print the result this show 40 but if you compare this with 40 say that is different thanks for all Reproduce code: --- Expected result: is good 40 Actual result: -- is bad 40 -- Edit this bug report at http://bugs.php.net/?id=38300&edit=1
#38300 [NEW]: equation result error
From: rogergg at gmail dot com Operating system: linux/windows PHP version: 5.1.4 PHP Bug Type: *Compile Issues Bug description: equation result error Description: the result for $a is 40 exactly. you can check it but i donk know why the if choosed that it is different. the problem is with the result that this take from the equation. if you print the result this show 40 but if you compare this with 40 say that is different thanks for all Reproduce code: --- Expected result: is good 40 Actual result: -- is bad 40 -- Edit bug report at http://bugs.php.net/?id=38300&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38300&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38300&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38300&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38300&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38300&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38300&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38300&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38300&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38300&r=support Expected behavior:http://bugs.php.net/fix.php?id=38300&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38300&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38300&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38300&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38300&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38300&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38300&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38300&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38300&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38300&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38300&r=mysqlcfg
#38299 [Opn->Bgs]: intval() does not convert floats when called from array_filter
ID: 38299
Updated by: [EMAIL PROTECTED]
Reported By: aeontech at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: mac os 10.4
PHP Version: 5.1.4
New Comment:
http://php.net/array_filter
Check out what array_filter() function _really_ does.
Previous Comments:
[2006-08-02 18:52:17] aeontech at gmail dot com
Description:
when I try to use array_filter to ensure that I have only integers in
my array, I come across this error.
Reproduce code:
---
$arr = array('1','3.1',3.1,'a');
echo implode(',',array_filter($arr,'intval'));
Expected result:
1,3,3
Actual result:
--
1,3.1,3.1
--
Edit this bug report at http://bugs.php.net/?id=38299&edit=1
#38299 [NEW]: intval() does not convert floats when called from array_filter
From: aeontech at gmail dot com
Operating system: mac os 10.4
PHP version: 5.1.4
PHP Bug Type: Scripting Engine problem
Bug description: intval() does not convert floats when called from array_filter
Description:
when I try to use array_filter to ensure that I have only integers in my
array, I come across this error.
Reproduce code:
---
$arr = array('1','3.1',3.1,'a');
echo implode(',',array_filter($arr,'intval'));
Expected result:
1,3,3
Actual result:
--
1,3.1,3.1
--
Edit bug report at http://bugs.php.net/?id=38299&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38299&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38299&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38299&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38299&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38299&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38299&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38299&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38299&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38299&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38299&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38299&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38299&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38299&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38299&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38299&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38299&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38299&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38299&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38299&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38299&r=mysqlcfg
#34804 [Com]: More information about static class methods
ID: 34804
Comment by: benjaminhill at gmail dot com
Reported By: toomuchphp-phpbugs at yahoo dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 5.x
New Comment:
even something as simple as...
class Parent {
static function myCurrentClassName() {
return (__CALLINGCLASS__);
}
}
class Child extends Parent {
// empty
}
echo Child::myCurrentClassName()
returns "Child"
Previous Comments:
[2006-06-24 23:20:38] DouglasStewart at creighton dot edu
Understood toomuch, thanks.
I would then request the following:
Please provide the following on the static side:
$this -- in the context of a class side(static) method. $this
represents an instance of ReflectionClass with all methods answering
correctly as to the context of the call. So, for instance, statically
implemented "$this->fileName()" would return the fileName that the
current context class was loaded from. With this feature in place, I am
confident that self will no longer be used for anything except in a root
class like Object.
$sender -- Either a ReflectionClass instance when the call is made from
a class-side implementation or a regular object instance.
class() -- An instance method that all objects inherit, that returns an
instance of ReflectionClass for the class of the object context making
the call.
Smalltalk offers some rather elegant solutions to these true OO
problems that PHP's sudo-OO implementation struggles with.
[2006-06-19 23:44:53] toomuchphp-phpbugs at yahoo dot com
The reason why some of the bug reports get dismissed so easily is
because they ask for one of the existing features ('self' or
'__CLASS__') to be modified to solve this problem, but 'self' and
'__CLASS__' are both already very useful and proably very widely used,
so it's not good to change them, and therefore we need a *new way* to
find out what class the static method was part of.
Something I find very disappointing is the fact that bug #30828
destroyed the only existing solution to this problem -
debug_backtrace(). In PHP 5.0.4, debug_backtrace() could have been
used here to discover the static class name, but somebody wanted it
working the other way (like __CLASS__ instead), the bug was reported,
fixed in 5.0.5, and so we lost our only solution to this problem. This
bugfix actually broke some of my existing code a year ago when it was
released, but it wasn't so important to me at the time. It's only over
the past year as I've been writing object-oriented code full time, and
studying implementations by other languages (Java, AspectJ, Ruby) that
I've realized how damaging the change to debug_backtrace() was.
I am hoping that as Zend continue writing their Framework, they'll
realize just how broken static methods are and will try to fix them
somehow.
[2006-06-19 20:41:34] DouglasStewart at creighton dot edu
I am unsure where to comment on this. This particular issue that folks
are having with __CLASS__ and self not playing in the proper calling
context makes life very difficult. The bug report responses like "This
is not a bug" and "is designed and intended to work that way" are, I
suppose, the discretion of the current developer base or ZEND or
whoever.
Maybe if someone could elaborate on the wisdom of this design decision.
Imparting this knowledge may illuminate the reasons why this feature
that many OO programmers are accustomed to having available is being
dismissed so readily.
The current implementation of __CLASS__ is not useful.
If you wish to ask a class for its name, php is not yet prepared to
provide you with the answer. The following examples illustrate why:
class TopClass {
public static function ClassNameIndirect() {
return self::ClassName();
}
public static function ClassName() {
return 'TopClass';
}
public static function ClassNameKeyword() {
return __CLASS__;
}
public static function ClassNameKeywordUninherited() {
return self::ClassNameKeyword();
}
public static function ClassNameSelfInstance() {
$object = new self;
return get_class($object);
}
public static function ClassNameSelfInstanceUninherited() {
return self::ClassNameSelfInstance();
}
public static function ClassNameKeywordUninheritedIndirect() {
return self::ClassNameKeywordUninherited();
}
public static function ClassNameSelfInstanceUninheritedIndirect() {
return self::ClassNameSelfInstanceUninherited();
}
public static function ClassNameHack() {
$bt = debug_backtrace(
#38298 [Bgs]: serializing of simplexml objects
ID: 38298 User updated by: aeldarin at hotmail dot com Reported By: aeldarin at hotmail dot com Status: Bogus Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.1.4 New Comment: Or perhaps the performance gain on serializing the SimpleXML object with such translation neccessary would be minimal compared to reparsing an XML representation ? Hmmm ... Previous Comments: [2006-08-02 16:22:04] aeldarin at hotmail dot com I guess SimpleXML employs a lot of referencing pointers for performance reasons which makes it not possible to serialize without some intermediary which would do a sort of "memblock" with relative pointers/indexes ? Such a intermediary layer for serializing would mean a lot of work, I guess. [2006-08-02 15:33:40] [EMAIL PROTECTED] There is no way to store internal data structures as text. [2006-08-02 15:19:39] aeldarin at hotmail dot com Description: http://www.php.net/manual/en/function.serialize.php says that built-in objects can't be serialized. This also means that SimpleXML objects can NOT be stored in the Memcached server since PHP automatically (un)serializes content stored/retrieved to/from Memcached. What happens is that hundreds of "Node does not exist"-warnings are reported by the memcached-api (via unserialize) when trying to retrieve the SimplXML object. Being able to easily and efficiently cache SimpleXML with Memcached would be tremendously helpful. -- Edit this bug report at http://bugs.php.net/?id=38298&edit=1
#38298 [Bgs]: serializing of simplexml objects
ID: 38298 User updated by: aeldarin at hotmail dot com Reported By: aeldarin at hotmail dot com Status: Bogus Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.1.4 New Comment: I guess SimpleXML employs a lot of referencing pointers for performance reasons which makes it not possible to serialize without some intermediary which would do a sort of "memblock" with relative pointers/indexes ? Such a intermediary layer for serializing would mean a lot of work, I guess. Previous Comments: [2006-08-02 15:33:40] [EMAIL PROTECTED] There is no way to store internal data structures as text. [2006-08-02 15:19:39] aeldarin at hotmail dot com Description: http://www.php.net/manual/en/function.serialize.php says that built-in objects can't be serialized. This also means that SimpleXML objects can NOT be stored in the Memcached server since PHP automatically (un)serializes content stored/retrieved to/from Memcached. What happens is that hundreds of "Node does not exist"-warnings are reported by the memcached-api (via unserialize) when trying to retrieve the SimplXML object. Being able to easily and efficiently cache SimpleXML with Memcached would be tremendously helpful. -- Edit this bug report at http://bugs.php.net/?id=38298&edit=1
#37118 [Com]: is_file returns false for uploaded file
ID: 37118 Comment by: fartal at lanbyte dot com Reported By: kimmo dot laine at zarga dot net Status: No Feedback Bug Type: Filesystem function related Operating System: Windows 2003 IIS 6 PHP Version: 5.1.2 New Comment: Same bug found in Windows 2000 server IIS and PHP Version 4.3.11 Previous Comments: [2006-06-28 01:00:02] 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". [2006-06-20 15:09:26] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-04-24 06:18:11] kimmo dot laine at zarga dot net adding var_dump($_FILES['myfile']['tmp_name']); to the code echoes the following: string(27) "C:\WINDOWS\TEMP\phpAC2A.tmp" [2006-04-22 17:42:51] [EMAIL PROTECTED] What do you get if you add var_dump($_FILES['myfile']['tmp_name']); to your code? [2006-04-18 09:48:25] kimmo dot laine at zarga dot net Description: Running IIS 6 on Windows 2003 server. After an update to the most recent version of php 5.1.2, for some reacon a function handling uploaded using is_file stopped working. is_file failed for existing files. I fixed it by changing is_file to file_exists, then it worked again. Prior to the update, in the older version, presumably it was 5.0.1, is_file worked just fine without problems. Reproduce code: --- Expected result: is_file:truefile_exists:true Actual result: -- is_file:falsefile_exists:true -- Edit this bug report at http://bugs.php.net/?id=37118&edit=1
#37322 [Com]: unable to link php to already installed mysql
ID: 37322 Comment by: sorin at intersol dot ro Reported By: raosid at rediffmail dot com Status: No Feedback Bug Type: *Configuration Issues Operating System: fedora core 4 PHP Version: 4.4.2 New Comment: I confirm this bug in Fedora Core 5. Previous Comments: [2006-05-14 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". [2006-05-06 09:30:41] [EMAIL PROTECTED] It looks like you have a headers mess in your system. The configure option should be --with-mysql='INSTALL PREFIX of mysql', not SOURCE. Please try using the right option and post the results here. [2006-05-05 05:04:13] raosid at rediffmail dot com Description: hi , i am having a problem in configuring php4.4.2 with already installed mysql. when i say --with-mysql=/'source of mysql'. it says... lresolv -lm -ldl -lnsl -lcrypt -lcrypt -o sapi/cgi/php ext/mysql/php_mysql.o(.text+0x2095): In function `zif_mysql_create_db': /home/siddharth/Desktop/php-4.4.2/ext/mysql/php_mysql.c:1163: undefined reference to `mysql_create_db' ext/mysql/php_mysql.o(.text+0x22cb): In function `zif_mysql_drop_db': /home/siddharth/Desktop/php-4.4.2/ext/mysql/php_mysql.c:1205: undefined reference to `mysql_drop_db' collect2: ld returned 1 exit status make: *** [sapi/cgi/php] Error 1 any suggestions -- Edit this bug report at http://bugs.php.net/?id=37322&edit=1
#38298 [Opn->Bgs]: serializing of simplexml objects
ID: 38298 Updated by: [EMAIL PROTECTED] Reported By: aeldarin at hotmail dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.1.4 New Comment: There is no way to store internal data structures as text. Previous Comments: [2006-08-02 15:19:39] aeldarin at hotmail dot com Description: http://www.php.net/manual/en/function.serialize.php says that built-in objects can't be serialized. This also means that SimpleXML objects can NOT be stored in the Memcached server since PHP automatically (un)serializes content stored/retrieved to/from Memcached. What happens is that hundreds of "Node does not exist"-warnings are reported by the memcached-api (via unserialize) when trying to retrieve the SimplXML object. Being able to easily and efficiently cache SimpleXML with Memcached would be tremendously helpful. -- Edit this bug report at http://bugs.php.net/?id=38298&edit=1
#37322 [Com]: unable to link php to already installed mysql
ID: 37322 Comment by: sorin at intersol dot ro Reported By: raosid at rediffmail dot com Status: No Feedback Bug Type: *Configuration Issues Operating System: fedora core 4 PHP Version: 4.4.2 New Comment: OOps, My mistake. I think that the problem is that the compiled mysql in FC4 and FC5 may not include old functions?! Any suggestion not including the recompilation of mysql. Previous Comments: [2006-08-02 15:47:27] sorin at intersol dot ro It seamns that you must define USE_OLD_FUNCTIONS before including mysql.h (At least in mysql 5 the missing functions are including only if USE_OLD_FUNCTIONS is defined). [2006-08-02 15:37:22] sorin at intersol dot ro I confirm this bug in Fedora Core 5. [2006-05-14 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". [2006-05-06 09:30:41] [EMAIL PROTECTED] It looks like you have a headers mess in your system. The configure option should be --with-mysql='INSTALL PREFIX of mysql', not SOURCE. Please try using the right option and post the results here. [2006-05-05 05:04:13] raosid at rediffmail dot com Description: hi , i am having a problem in configuring php4.4.2 with already installed mysql. when i say --with-mysql=/'source of mysql'. it says... lresolv -lm -ldl -lnsl -lcrypt -lcrypt -o sapi/cgi/php ext/mysql/php_mysql.o(.text+0x2095): In function `zif_mysql_create_db': /home/siddharth/Desktop/php-4.4.2/ext/mysql/php_mysql.c:1163: undefined reference to `mysql_create_db' ext/mysql/php_mysql.o(.text+0x22cb): In function `zif_mysql_drop_db': /home/siddharth/Desktop/php-4.4.2/ext/mysql/php_mysql.c:1205: undefined reference to `mysql_drop_db' collect2: ld returned 1 exit status make: *** [sapi/cgi/php] Error 1 any suggestions -- Edit this bug report at http://bugs.php.net/?id=37322&edit=1
#37322 [Com]: unable to link php to already installed mysql
ID: 37322 Comment by: sorin at intersol dot ro Reported By: raosid at rediffmail dot com Status: No Feedback Bug Type: *Configuration Issues Operating System: fedora core 4 PHP Version: 4.4.2 New Comment: It seamns that you must define USE_OLD_FUNCTIONS before including mysql.h (At least in mysql 5 the missing functions are including only if USE_OLD_FUNCTIONS is defined). Previous Comments: [2006-08-02 15:37:22] sorin at intersol dot ro I confirm this bug in Fedora Core 5. [2006-05-14 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". [2006-05-06 09:30:41] [EMAIL PROTECTED] It looks like you have a headers mess in your system. The configure option should be --with-mysql='INSTALL PREFIX of mysql', not SOURCE. Please try using the right option and post the results here. [2006-05-05 05:04:13] raosid at rediffmail dot com Description: hi , i am having a problem in configuring php4.4.2 with already installed mysql. when i say --with-mysql=/'source of mysql'. it says... lresolv -lm -ldl -lnsl -lcrypt -lcrypt -o sapi/cgi/php ext/mysql/php_mysql.o(.text+0x2095): In function `zif_mysql_create_db': /home/siddharth/Desktop/php-4.4.2/ext/mysql/php_mysql.c:1163: undefined reference to `mysql_create_db' ext/mysql/php_mysql.o(.text+0x22cb): In function `zif_mysql_drop_db': /home/siddharth/Desktop/php-4.4.2/ext/mysql/php_mysql.c:1205: undefined reference to `mysql_drop_db' collect2: ld returned 1 exit status make: *** [sapi/cgi/php] Error 1 any suggestions -- Edit this bug report at http://bugs.php.net/?id=37322&edit=1
#37611 [Opn->Csd]: WDDX serializer encodes all non-ascii characters with
ID: 37611
Updated by: [EMAIL PROTECTED]
Reported By: jdolecek at NetBSD dot org
-Status: Open
+Status: Closed
Bug Type: WDDX related
Operating System: Any
PHP Version: 5.1.5CVS
New Comment:
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-06-30 08:41:25] wiktor at eworld dot hu
After the PHP upgrade from 5.0 to 5.1, the hungarian letters with
accents in our javascript framework (using js library from
www.wddx.org) our Hungarian letters with accents disappeared. We have
to solve it quickly, so here is our patch to fix this incompatibility.
$foo = wddx_serialize_value($bar);
$foo = preg_replace("/()/e", "('\\2'<'80' ? '\\1' :
chr(hexdec('\\2')))", $foo);
[2006-06-05 20:03:20] jdolecek at NetBSD dot org
127 serializes/deserialized just fine on my system even without your
change, test script:
$str = wddx_deserialize(wddx_serialize_value(chr(127)));
echo ord($str[0])."\n";
wddx_deserialize() expects UTF-8 input and gives iso-8859-1 output.
There are ways around this, but this is the default way.
wddx_serialize_value() doesn't particularily care, it takes both UTF-8
and iso-8869-1.
So the right way to use the API is to UTF-8-encode text before
serializing, so that we'd get proper output after deserializing.
I'd also point out that both 1) and 2) points still hold, and both are
very painfull for non-english speakers. _Please_ back the change off.
[2006-05-31 22:22:04] [EMAIL PROTECTED]
Without the 127 bit on chr(128) for example becomes translated
to 0 causing irreversible data loss.
As far as chr(200) you don't need to utf8 encode it.
[2006-05-30 15:59:24] jdolecek at NetBSD dot org
Yes it is a bug.
1) it breaks current code using UTF-8 and expecting to get iso-8859-1
result from wddx_deserialize(), i.e.
$str = chr(200);
$str_u8 = utf8_encode($str);
$result = wddx_deserialize(wddx_Serialize_value($str_u8));
When run with PHP 5.1.4 or when the data has been serialized with
the older version, $result == $str.
New version has $result == $str_u8.
So, _all_ old serialized UTF-8 data (i.e. stored
in database) serializes to different encoding
then newly serialized data. This is major
backward incompatibility, and is problem for any
current applications using serializing of
UTF-8 input.
(Arguably serializing UTF-8 strings wasn't really
very usable before due to Bug #37571, but you get
the idea)
2) it explodes the size of packet, and it's not clear
what was the reason for the change. This is serious
problem when storing the result serialized data,
and totally unnecessary. XML is designed 8-bit
clean, so encoding high-bit characters this
way doesn't make sense.
Please explain why encoding characters >= 127 is right. Please revert
this part of the patch.
If you want to fix wddx so that the encoding on input is same as
encoding on output it's fine, but it must be done in
backward-compatible way, such as adding some extra parameters to either
wddx_serialize_value() or wddx_deserialize().
[2006-05-28 15:13:29] [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
This is definitely not left over debug code, it is needed on
some system to ensure proper encoding of non-ascii characters.
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/37611
--
Edit this bug report at http://bugs.php.net/?id=37611&edit=1
#38213 [Asn->Csd]: Wddx serializer and umlaute in $_SESSION variables don't work together
ID: 38213 Updated by: [EMAIL PROTECTED] Reported By: wf at bitplan dot com -Status: Assigned +Status: Closed Bug Type: Session related Operating System: Windows XP PHP Version: 5.1.4 Assigned To: iliaa New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-07-26 00:00:30] wf at bitplan dot com Description: When setting the serialize handler to wddx in php.in: session.serialize_handler = wddx using any Umlaut in a $_SESSION variable will lead to misbehaviour of the system e.g. Apache crashing or the session file content to be destroyed Reproduce code: --- sesstest1.php: = "; ?> Page 2 sesstest2.php: = "; unset ($_SESSION['sess_var']); session_write_close(); ?> Page 1 Expected result: there are several ways to do this properly, one is to set the encoding: in the first line of the wddx file, another one is to use utf-8 encoding on encoding and decoding Actual result: -- äöüßÄÖÜßé And the system might throw-up on decoding when e.g. using french, spanish, swedish or other accented characters. -- Edit this bug report at http://bugs.php.net/?id=38213&edit=1
#37571 [Opn->Csd]: WDDX cannot deserialize serialized UTF-8 encoded non-ASCII text
ID: 37571
Updated by: [EMAIL PROTECTED]
Reported By: jdolecek at NetBSD dot org
-Status: Open
+Status: Closed
Bug Type: WDDX related
Operating System: Any
PHP Version: 5.1.4
New Comment:
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-05-25 12:28:33] jdolecek at NetBSD dot org
You probably don't understand the problem. I'm not talking about
problem encoding iso-8859-1 text, but problem encoding text in
_UTF-8_.
UTF-8 stream legally contains characters in 128-160
range. Hopefully we agree here.
WDDX uses iscntrl() to determine if it should record the character to
form. So it takes each character of multicharacter
UTF-8 sequence and if _the single character of the sequence_ is
determined to be control character according to current locale, it
turns the component of multibyte sequence into
construct.
So, it turns perfectly valid UTF-8 stream into invalid text stream,
where some UTF-8 sequences are valid and some not.
The problem is that it uses iscntrl(), while it arguably should enforce
valid UTF-8 input and use something along iswcntrl(). But this would
change the interface and likely break existing code using WDDX which
depend on using iso-8859-1 text as input to serializer.
Using iscntrl() + isascii() definitely solves the problem in the least
obtrusive way AFAICS.
[2006-05-24 06:46:22] [EMAIL PROTECTED]
Latin 1 doesn't define those characters in the 128-160 range... so it's
perfectly correct not to encode them to UTF-8. You simply need to make
sure you have valid text in the first place.
[2006-05-23 22:50:20] jdolecek at NetBSD dot org
Description:
WDDX cannot be used to encode certain UTF8-encoded iso-8859-1 text.
Particularily those iso-8859-1 characters, which after conversion to
UTF-8 generate sequence of characters with value in 128-160 range,
which are recognized as control characters. Control characters are
turned into sequence by WDDX.
wddx_deserialize() expects UTF-8 encoded string, and implicitly
converts the text back to iso-8859-1 before deserializing the
structure. This is done _before_
the is replaced by the character. The < is thus
recognized as part of the UTF-8 sequence, two-byte sequence is recoded
to single-byte character and the result contains invalid XML (fragment
'char code="XX"/>'). Deserialization thus fails silently.
I.e.:
1. iso-8859-1 is Z (ord(Z) > 128)
2. UTF-8 string is XY
3. WDDX serializes that as X
4. deserializer converts UTF-8 input to iso-8859-1 before
starting deserialization, result is Bchar code="ord(Y)"/>
5. deserializer detects invalid XML and aborts the decode,
returns empty string
Fix:
Only recode ASCII control characters to sequence:
--- wddx.c.orig 2006-05-24 00:39:34.0 +0200
+++ wddx.c
@@ -399,7 +399,8 @@ static void php_wddx_serialize_string(wd
break;
default:
- if (iscntrl((int)*(unsigned
char *)p)) {
+ if (iscntrl((int)*(unsigned
char *)p)
+ && isascii((int)*(unsigned
char *)p)) {
FLUSH_BUF();
sprintf(control_buf,
WDDX_CHAR, *p);
php_wddx_add_chunk(packet, control_buf);
Note - this patch also makes problem of Bug #37569 go away, but that
patch is still useful to apply for code clarity.
This bug is probably same problem as Bug #35241.
Reproduce code:
---
On UNIX with iso-8859-1 locale or Windows with Windows-1250 locale:
var_dump(
wddx_deserialize(wddx_serialize_value(utf8_encode(chr(200
);
Expected result:
string(1) "Č"
Actual result:
--
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=37571&edit=1
#38297 [Opn->Bgs]: empty() crashed during parsing if not variable given
ID: 38297 Updated by: [EMAIL PROTECTED] Reported By: pityu-kg at rainstorm dot org -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Win32 PHP Version: 4CVS-2006-08-02 (snap) New Comment: Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting T_VARIABLE or '$' Previous Comments: [2006-08-02 15:16:00] pityu-kg at rainstorm dot org Description: crashes without any message, despite E_ALL config. It crashes during parsing, this code doesn't have to be accessible. empty() should get only variables as parameter, not values. Reproduce code: --- Expected result: Some error or warning telling empty() should get variable, not a value. Actual result: -- PHP crash without any message. Apache does not crash. -- Edit this bug report at http://bugs.php.net/?id=38297&edit=1
#38298 [NEW]: serializing of simplexml objects
From: aeldarin at hotmail dot com Operating system: Windows PHP version: 5.1.4 PHP Bug Type: Feature/Change Request Bug description: serializing of simplexml objects Description: http://www.php.net/manual/en/function.serialize.php says that built-in objects can't be serialized. This also means that SimpleXML objects can NOT be stored in the Memcached server since PHP automatically (un)serializes content stored/retrieved to/from Memcached. What happens is that hundreds of "Node does not exist"-warnings are reported by the memcached-api (via unserialize) when trying to retrieve the SimplXML object. Being able to easily and efficiently cache SimpleXML with Memcached would be tremendously helpful. -- Edit bug report at http://bugs.php.net/?id=38298&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38298&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38298&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38298&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38298&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38298&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38298&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38298&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38298&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38298&r=support Expected behavior:http://bugs.php.net/fix.php?id=38298&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38298&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38298&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38298&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38298&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38298&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38298&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38298&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38298&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38298&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38298&r=mysqlcfg
#38297 [NEW]: empty() crashed during parsing if not variable given
From: pityu-kg at rainstorm dot org Operating system: Win32 PHP version: 4CVS-2006-08-02 (snap) PHP Bug Type: Reproducible crash Bug description: empty() crashed during parsing if not variable given Description: crashes without any message, despite E_ALL config. It crashes during parsing, this code doesn't have to be accessible. empty() should get only variables as parameter, not values. Reproduce code: --- Expected result: Some error or warning telling empty() should get variable, not a value. Actual result: -- PHP crash without any message. Apache does not crash. -- Edit bug report at http://bugs.php.net/?id=38297&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38297&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38297&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38297&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38297&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38297&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38297&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38297&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38297&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38297&r=support Expected behavior:http://bugs.php.net/fix.php?id=38297&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38297&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38297&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38297&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38297&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38297&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38297&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38297&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38297&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38297&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38297&r=mysqlcfg
#37870 [Asn->Fbk]: Deallocation of prepared statement that hasn't been allocated under postgresql
ID: 37870
Updated by: [EMAIL PROTECTED]
Reported By: sagi at adamnet dot co dot il
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Debian Sarge
PHP Version: 5.1.4
Assigned To: wez
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Appears to work fine (at least for me) in latest CVS.
Previous Comments:
[2006-06-21 07:52:22] sagi at adamnet dot co dot il
Description:
Using PHP 5.1.4 to connect to a postgresql 8.1.4 database, native
prepared statements.
When allocating a prepared statement and then trying to unset it, PDO
attemps to deallocate it even if it never been used (eg. when running a
query against an empty set).
PDO does not throw an exception in such case, but an error such as:
ERROR: prepared statement "pdo_pgsql_stmt_085b2f2c" does not exist
Appers in the server log.
When running inside a transaction, such error aborts it.
Reproduce code:
---
$pdo->beginTransaction();
$stmt = $pdo->prepare("SELECT 'never executed'");
unset($stmt);
$res = $pdo->query('SELECT 123');
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[25P02]: In failed sql transaction: 7 ERROR: current
transaction is aborted, commands ignored until end of transaction
block' in XXX:13
Stack trace:
#0 XXX: PDO->query('SELECT 123')
--
Edit this bug report at http://bugs.php.net/?id=37870&edit=1
#38296 [Opn->Bgs]: $_SESSION['|'] = 1 does crash session file
ID: 38296
Updated by: [EMAIL PROTECTED]
Reported By: muhtarov at oviont dot ru
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: w2k
PHP Version: 5.1.4
New Comment:
"|" is not valid variable name, this is well expected.
Previous Comments:
[2006-08-02 13:48:47] muhtarov at oviont dot ru
Description:
separator "|" as key in $_SESSION does crash sess_* file to empty file
Reproduce code:
---
session_start();
$_SESSION['|'] = 1;
echo 'See into ' . ini_get('session.save_path') . '/sess_' .
session_id() . ' file!'
Expected result:
Size of file sess_* > 0
Actual result:
--
Size of file sess_* = 0
--
Edit this bug report at http://bugs.php.net/?id=38296&edit=1
#38296 [NEW]: $_SESSION['|'] = 1 does crash session file
From: muhtarov at oviont dot ru
Operating system: w2k
PHP version: 5.1.4
PHP Bug Type: Session related
Bug description: $_SESSION['|'] = 1 does crash session file
Description:
separator "|" as key in $_SESSION does crash sess_* file to empty file
Reproduce code:
---
session_start();
$_SESSION['|'] = 1;
echo 'See into ' . ini_get('session.save_path') . '/sess_' . session_id()
. ' file!'
Expected result:
Size of file sess_* > 0
Actual result:
--
Size of file sess_* = 0
--
Edit bug report at http://bugs.php.net/?id=38296&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38296&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38296&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38296&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38296&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38296&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38296&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38296&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38296&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38296&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38296&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38296&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38296&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38296&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38296&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38296&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38296&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38296&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38296&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38296&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38296&r=mysqlcfg
#26738 [Asn->Csd]: PHP-OCI binding error
ID: 26738
Updated by: [EMAIL PROTECTED]
Reported By: mbaranidharan at yahoo dot com
-Status: Assigned
+Status: Closed
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4.3.4
Assigned To: tony2001
New Comment:
Fixed since OCI8 release 1.2 and PHP release 5.1.2.
You can use oci_bind_array_by_name() to bind PL/SQL arrays.
Previous Comments:
[2005-06-30 11:33:07] svjoy at yandex dot ru
Absolutely agree this is a serious problem. The way I am using to
overcome this - temporary tables. But this requires another
statement/cursor/parse and overhead. Many other languages HAVE the
possibility. I cant understand why PHP doesn't. There is a great need
for the way to pass structured data directly from PL/SQL environment to
PHP (more preferrable, to native PHP array, but not fetchable
Oracle-native). If I get such volume of structured data that can be
allocated in RAM, why sholud I use cursors and other DBMS-related
features? Why cant I get it in native PHP data type and forget about
DBMS and release its resources?
[2005-06-14 17:19:47] [EMAIL PROTECTED]
Please *do not* add any comments to the report if they are not related
to the current bug. Either create a new report (hint: use var_dump() in
your code instead of echo()) or ask your questions somewhere else.
This system is not a support forum and this report is not a forum
topic.
[2005-06-14 16:58:22] lukasz608 at o2 dot pl
A some more:
The function names in code above comes from PHP4, because i tried it
also with PHP4.
[2005-06-14 16:55:35] lukasz608 at o2 dot pl
Hello,
I have the code like this:
"
$stmt = ociParse($conn, "BEGIN ".
" UTL_PC_CA_PATCH.patch_raport('TST', 21511,
:data); ".
"END;");
$data = ocinewcollection($conn, 'VARCHAR2TABTYPE');
ociBindByName($stmt, ":data", &$data, -1, OCI_B_NTY);
ociExecute($stmt, OCI_DEFAULT);
echo "SIZE: ".$data->size."";
echo $data->getelem(1);
ocilogoff($conn);
"
The result is:
"
SIZE:
"
Can you explain me why $data is empty?
1. Type VARCHAR2TABTYPE is defined on users schema.
2. I'm sure that PL/SQL procedure returns table containg several
elements in ":data".
[2004-03-05 08:05:08] mbaranidharan at yahoo dot com
Hi is there a solution available for this prob. Pls let me know.
I have a c++ code which uses oracle OCI library to call the package and
get me the result as array. Is there any detailed example available to
create php extension in c++ which returns a array. Pls let me know.
Thanks
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/26738
--
Edit this bug report at http://bugs.php.net/?id=26738&edit=1
#38293 [Opn->Bgs]: Oracle connection
ID: 38293 Updated by: [EMAIL PROTECTED] Reported By: chaitgsi at yahoo dot com -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: Redhat Linux 2006 PHP Version: 4.4.2 New Comment: You are strongly encouraged to use OCI8 from PECL with PHP4.x. Also, no need to specify --with-oracle, as this is completely different thing. Previous Comments: [2006-08-02 11:44:20] chaitgsi at yahoo dot com Description: There is a bogus bug on http://bugs.php.net/bug.php?id=35572 We faced same problem. ORACLE_PATH was wrong in config.php. We were able to solve problem but we were not getting connection failuer error all time. If that page is executed 100 times, it use to throw error 30 times. It was surprising as there was wrong path declaration and half times it use to work half time not. We are using Apache 2.0 PHP is compiled as follows --host=i686-redhat-linux-gnu' '--build=i686-redhat-linux-gnu' '--target=i386-redhat-linux' --with-oci8=/oracle/product/9.2.0' '--with-oracle=/oracle/product/9.2.0' '--enable-sigchild' --with-apxs2=/usr/sbin/apxs' -- Edit this bug report at http://bugs.php.net/?id=38293&edit=1
#31894 [Com]: Calling restore_error_handler inside destructor crashes PHP
ID: 31894
Comment by: f dot boender at electricmonk dot nl
Reported By: adove at mindrage dot com
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: WinXP
PHP Version: 5.0.3
New Comment:
Oops, small correction on the test program in my first comment. It
turns out {} doesn't actually represent a new scope at all. It's the
redefining of $test that causes the destructor of the previous $test to
get triggered instead of going out of scope. Same results though.
Previous Comments:
[2006-08-02 11:27:11] f dot boender at electricmonk dot nl
I've succesfully reproduced the Segmentation fault of the above test
program on the following systems: (All Debian GNU/Linux systems);
Commandline:
PHP 5.0.5-Debian-0.8~sarge1 (cli) (built: Oct 27 2005
10:43:05) (Debian GNU/Linux) Copyright (c) 1997-2004
The PHP Group
Commandline:
PHP 5.0.4-0.9sarge1 (cli) (built: Jul 20 2005 17:08:52)
(Debian GNU/Linux) Copyright (c) 1997-2004 The PHP
Group Zend Engine v2.0.4-dev, Copyright (c) 1998-2004
Zend Technologies
Apache module:
PHP Version 5.1.2-1+b1
System = Linux jib 2.6.15.5 #2 i686
Build Date = Mar 20 2006 04:04:37
Server API = Apache 2.0 Handler
Virtual Directory Support = disabled
PHP API = 20041225
PHP Extension = 20050922
Zend Extension = 220051025
[2006-08-02 11:13:29] f dot boender at electricmonk dot nl
I'm experiencing the same bug. Here's my bugreport:
Description:
PHP crashes with a segmentation fault when restoring the error
handler in
the destructor.
Environment:
PHP:
PHP 5.1.2-1+b1 (cli) (built: Mar 20 2006 04:17:24)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
php.ini excerpt:
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
display_errors = On
display_startup_errors = Off
log_errors = Off
log_errors_max_len = 1024
ignore_repeated_errors = Off
track_errors = Off
Observations:
-
* The test program crashes with a segfault when run as shown here.
* The test program does NOT crash when the destructor is called due
to
the instance of Test going out of scope. (Comment out the
OUT-OF-SCOPE
piece). Not even the unset() crashes after the OUT-OF-SCOPE test
has
run first.
Test program:
-
prevErrorReporting = error_reporting(E_ALL);
set_error_handler(array(&$this, "errorHandler"));
}
public function __destruct() {
restore_error_handler();
error_reporting($this->prevErrorReporting);
echo("trace1");
}
public function errorHandler($errno, $errmsg, $filename, $linenum,
$vars) {
}
}
// OUT-OF-SCOPE TEST
// {
// $test = new Test();
// }
// UNSET TEST
$test = new Test();
unset($test); // Unsetting, destructor is called, SegFault (unless
OUT-OF-SCOPE test has run)
?>
Expected output:
[EMAIL PROTECTED]/dev/tlib-php$ export MALLOC_CHECK_=1
[EMAIL PROTECTED]/dev/tlib-php$ php ./tlib-test.php
malloc: using debugging hooks
trace1
Actual output:
--
[EMAIL PROTECTED]/dev/tlib-php$ export MALLOC_CHECK_=1
[EMAIL PROTECTED]/dev/tlib-php$ php ./tlib-test.php
malloc: using debugging hooks
Segmentation fault
GDB output:
---
Here's some output from GDB; might be useful. Duplicate lines and
default
GDB messages have been removed.
> (gdb) run
> Starting program: /usr/bin/php tlib-test.php
> malloc: using debugging hooks
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08298316 in zend_std_read_property ()
> (gdb)
Strace output:
--
Useless probably, but anyway:
> rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
> ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf86e0d8) = -1 ENOTTY
(Inappropriate ioctl for device)
> read(5, " read(5, "", 4096) = 0
> read(5, "", 8192) = 0
> close(5)= 0
> munmap(0xb78ad000, 4096)= 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> Process 5638 detached
[2005-02-28 01:00:04] 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".
---
#31894 [Com]: Calling restore_error_handler inside destructor crashes PHP
ID: 31894
Comment by: f dot boender at electricmonk dot nl
Reported By: adove at mindrage dot com
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: WinXP
PHP Version: 5.0.3
New Comment:
I've succesfully reproduced the Segmentation fault of the above test
program on the following systems: (All Debian GNU/Linux systems);
Commandline:
PHP 5.0.5-Debian-0.8~sarge1 (cli) (built: Oct 27 2005
10:43:05) (Debian GNU/Linux) Copyright (c) 1997-2004
The PHP Group
Commandline:
PHP 5.0.4-0.9sarge1 (cli) (built: Jul 20 2005 17:08:52)
(Debian GNU/Linux) Copyright (c) 1997-2004 The PHP
Group Zend Engine v2.0.4-dev, Copyright (c) 1998-2004
Zend Technologies
Apache module:
PHP Version 5.1.2-1+b1
System = Linux jib 2.6.15.5 #2 i686
Build Date = Mar 20 2006 04:04:37
Server API = Apache 2.0 Handler
Virtual Directory Support = disabled
PHP API = 20041225
PHP Extension = 20050922
Zend Extension = 220051025
Previous Comments:
[2006-08-02 11:13:29] f dot boender at electricmonk dot nl
I'm experiencing the same bug. Here's my bugreport:
Description:
PHP crashes with a segmentation fault when restoring the error
handler in
the destructor.
Environment:
PHP:
PHP 5.1.2-1+b1 (cli) (built: Mar 20 2006 04:17:24)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
php.ini excerpt:
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
display_errors = On
display_startup_errors = Off
log_errors = Off
log_errors_max_len = 1024
ignore_repeated_errors = Off
track_errors = Off
Observations:
-
* The test program crashes with a segfault when run as shown here.
* The test program does NOT crash when the destructor is called due
to
the instance of Test going out of scope. (Comment out the
OUT-OF-SCOPE
piece). Not even the unset() crashes after the OUT-OF-SCOPE test
has
run first.
Test program:
-
prevErrorReporting = error_reporting(E_ALL);
set_error_handler(array(&$this, "errorHandler"));
}
public function __destruct() {
restore_error_handler();
error_reporting($this->prevErrorReporting);
echo("trace1");
}
public function errorHandler($errno, $errmsg, $filename, $linenum,
$vars) {
}
}
// OUT-OF-SCOPE TEST
// {
// $test = new Test();
// }
// UNSET TEST
$test = new Test();
unset($test); // Unsetting, destructor is called, SegFault (unless
OUT-OF-SCOPE test has run)
?>
Expected output:
[EMAIL PROTECTED]/dev/tlib-php$ export MALLOC_CHECK_=1
[EMAIL PROTECTED]/dev/tlib-php$ php ./tlib-test.php
malloc: using debugging hooks
trace1
Actual output:
--
[EMAIL PROTECTED]/dev/tlib-php$ export MALLOC_CHECK_=1
[EMAIL PROTECTED]/dev/tlib-php$ php ./tlib-test.php
malloc: using debugging hooks
Segmentation fault
GDB output:
---
Here's some output from GDB; might be useful. Duplicate lines and
default
GDB messages have been removed.
> (gdb) run
> Starting program: /usr/bin/php tlib-test.php
> malloc: using debugging hooks
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08298316 in zend_std_read_property ()
> (gdb)
Strace output:
--
Useless probably, but anyway:
> rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
> ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf86e0d8) = -1 ENOTTY
(Inappropriate ioctl for device)
> read(5, " read(5, "", 4096) = 0
> read(5, "", 8192) = 0
> close(5)= 0
> munmap(0xb78ad000, 4096)= 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> Process 5638 detached
[2005-02-28 01:00:04] 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".
[2005-02-09 23:44:31] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possib
#38293 [NEW]: Oracle connection
From: chaitgsi at yahoo dot com Operating system: Redhat Linux 2006 PHP version: 4.4.2 PHP Bug Type: OCI8 related Bug description: Oracle connection Description: There is a bogus bug on http://bugs.php.net/bug.php?id=35572 We faced same problem. ORACLE_PATH was wrong in config.php. We were able to solve problem but we were not getting connection failuer error all time. If that page is executed 100 times, it use to throw error 30 times. It was surprising as there was wrong path declaration and half times it use to work half time not. We are using Apache 2.0 PHP is compiled as follows --host=i686-redhat-linux-gnu' '--build=i686-redhat-linux-gnu' '--target=i386-redhat-linux' --with-oci8=/oracle/product/9.2.0' '--with-oracle=/oracle/product/9.2.0' '--enable-sigchild' --with-apxs2=/usr/sbin/apxs' -- Edit bug report at http://bugs.php.net/?id=38293&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38293&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38293&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38293&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38293&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38293&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38293&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38293&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38293&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38293&r=support Expected behavior:http://bugs.php.net/fix.php?id=38293&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38293&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38293&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38293&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38293&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38293&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38293&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38293&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38293&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38293&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38293&r=mysqlcfg
#38291 [Opn->Bgs]: Segfault at compiling PHP with SNMP
ID: 38291 Updated by: [EMAIL PROTECTED] Reported By: mail at dirkje dot net -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Debian 3.1r2 PHP Version: 5.1.4 New Comment: Ok, yet another problem caused by recent YaSSL addition to binary MySQL packages. Previous Comments: [2006-08-02 11:34:05] mail at dirkje dot net That's right. I already solved the bug. I downloaded the MySQL source and compiled the libraries with my glibc installation. This works! :) [2006-08-02 09:02:28] [EMAIL PROTECTED] I guess MySQL version is 5.0.22+, right? [2006-08-02 08:49:38] mail at dirkje dot net Found something: when compiling without --with-mysql, it works. So not a PHP malfunction! [2006-08-02 08:26:15] mail at dirkje dot net Description: When I compile PHP-5.1.4 --with-snmp, I get a segfault at make install. I also tried to install PHP-4.4.2 but it doesn't work either. I also tried both PHP versions on a Slackware system but that distro gave me the same segfault. If I configure the PHP distro without PEAR, the make install works, but PHP will give me a segfault. Tried both Apache 1.3.34 and Apache 2.2.3. The SNMP packages I use: ucd-snmp-4.2.6 net-snmp-5.3.1 My configuration line: ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-zlib --with-jpeg-dir=/usr/lib --with-gd --with-png-dir=/usr/lib --with-snmp=/usr/local Also tried: ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-zlib --with-jpeg-dir=/usr/lib --with-gd --with-png-dir=/usr/lib --with-snmp Reproduce code: --- make install Installing PHP SAPI module: apache2handler /usr/local/apache/build/instdso.sh SH_LIBTOOL='/usr/local/apache/build/libtool' libphp5.la /usr/local/apache/modules /usr/local/apache/build/libtool --mode=install cp libphp5.la /usr/local/apache/modules/ cp .libs/libphp5.so /usr/local/apache/modules/libphp5.so cp .libs/libphp5.lai /usr/local/apache/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /root/php-5.1.4/libs' chmod 755 /usr/local/apache/modules/libphp5.so [activating module `php5' in /usr/local/apache/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 Expected result: No segfault :) -- Edit this bug report at http://bugs.php.net/?id=38291&edit=1
#38291 [Fbk->Opn]: Segfault at compiling PHP with SNMP
ID: 38291 User updated by: mail at dirkje dot net Reported By: mail at dirkje dot net -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Debian 3.1r2 PHP Version: 5.1.4 New Comment: That's right. I already solved the bug. I downloaded the MySQL source and compiled the libraries with my glibc installation. This works! :) Previous Comments: [2006-08-02 09:02:28] [EMAIL PROTECTED] I guess MySQL version is 5.0.22+, right? [2006-08-02 08:49:38] mail at dirkje dot net Found something: when compiling without --with-mysql, it works. So not a PHP malfunction! [2006-08-02 08:26:15] mail at dirkje dot net Description: When I compile PHP-5.1.4 --with-snmp, I get a segfault at make install. I also tried to install PHP-4.4.2 but it doesn't work either. I also tried both PHP versions on a Slackware system but that distro gave me the same segfault. If I configure the PHP distro without PEAR, the make install works, but PHP will give me a segfault. Tried both Apache 1.3.34 and Apache 2.2.3. The SNMP packages I use: ucd-snmp-4.2.6 net-snmp-5.3.1 My configuration line: ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-zlib --with-jpeg-dir=/usr/lib --with-gd --with-png-dir=/usr/lib --with-snmp=/usr/local Also tried: ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-zlib --with-jpeg-dir=/usr/lib --with-gd --with-png-dir=/usr/lib --with-snmp Reproduce code: --- make install Installing PHP SAPI module: apache2handler /usr/local/apache/build/instdso.sh SH_LIBTOOL='/usr/local/apache/build/libtool' libphp5.la /usr/local/apache/modules /usr/local/apache/build/libtool --mode=install cp libphp5.la /usr/local/apache/modules/ cp .libs/libphp5.so /usr/local/apache/modules/libphp5.so cp .libs/libphp5.lai /usr/local/apache/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /root/php-5.1.4/libs' chmod 755 /usr/local/apache/modules/libphp5.so [activating module `php5' in /usr/local/apache/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 Expected result: No segfault :) -- Edit this bug report at http://bugs.php.net/?id=38291&edit=1
#31894 [Com]: Calling restore_error_handler inside destructor crashes PHP
ID: 31894
Comment by: f dot boender at electricmonk dot nl
Reported By: adove at mindrage dot com
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: WinXP
PHP Version: 5.0.3
New Comment:
I'm experiencing the same bug. Here's my bugreport:
Description:
PHP crashes with a segmentation fault when restoring the error
handler in
the destructor.
Environment:
PHP:
PHP 5.1.2-1+b1 (cli) (built: Mar 20 2006 04:17:24)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
php.ini excerpt:
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
display_errors = On
display_startup_errors = Off
log_errors = Off
log_errors_max_len = 1024
ignore_repeated_errors = Off
track_errors = Off
Observations:
-
* The test program crashes with a segfault when run as shown here.
* The test program does NOT crash when the destructor is called due
to
the instance of Test going out of scope. (Comment out the
OUT-OF-SCOPE
piece). Not even the unset() crashes after the OUT-OF-SCOPE test
has
run first.
Test program:
-
prevErrorReporting = error_reporting(E_ALL);
set_error_handler(array(&$this, "errorHandler"));
}
public function __destruct() {
restore_error_handler();
error_reporting($this->prevErrorReporting);
echo("trace1");
}
public function errorHandler($errno, $errmsg, $filename, $linenum,
$vars) {
}
}
// OUT-OF-SCOPE TEST
// {
// $test = new Test();
// }
// UNSET TEST
$test = new Test();
unset($test); // Unsetting, destructor is called, SegFault (unless
OUT-OF-SCOPE test has run)
?>
Expected output:
[EMAIL PROTECTED]/dev/tlib-php$ export MALLOC_CHECK_=1
[EMAIL PROTECTED]/dev/tlib-php$ php ./tlib-test.php
malloc: using debugging hooks
trace1
Actual output:
--
[EMAIL PROTECTED]/dev/tlib-php$ export MALLOC_CHECK_=1
[EMAIL PROTECTED]/dev/tlib-php$ php ./tlib-test.php
malloc: using debugging hooks
Segmentation fault
GDB output:
---
Here's some output from GDB; might be useful. Duplicate lines and
default
GDB messages have been removed.
> (gdb) run
> Starting program: /usr/bin/php tlib-test.php
> malloc: using debugging hooks
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08298316 in zend_std_read_property ()
> (gdb)
Strace output:
--
Useless probably, but anyway:
> rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
> ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf86e0d8) = -1 ENOTTY
(Inappropriate ioctl for device)
> read(5, " read(5, "", 4096) = 0
> read(5, "", 8192) = 0
> close(5)= 0
> munmap(0xb78ad000, 4096)= 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> Process 5638 detached
Previous Comments:
[2005-02-28 01:00:04] 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".
[2005-02-09 23:44:31] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Also, please try CVS snapshot first - I can't reproduce it with the
parts of the code you've posted.
[2005-02-09 12:24:28] adove at mindrage dot com
Description:
This may be related to an older bug that was fixed (#24708) but I can
reproduce reliably (having spent days and hours chasing!). Basically,
if you call restore_error_handler from __destruct() things go horribly
ary. Interestingly enough, calling restore_exception_handler works just
fine.
This happens both CLI and Apache 2.x.
Note that it does not matter if you use $this or &$this in the
constructor.
Reproduce code:
---
function __construct(
&$aConfig
)
{
if(is_array($aConfig)
#38273 [Opn]: Incorrect return address after the execution of a signal handler?
ID: 38273
User updated by: axelluttgens at swing dot be
Reported By: axelluttgens at swing dot be
Status: Open
Bug Type: PCNTL related
Operating System: Mac OS 10.4.7
PHP Version: 4.4.2
New Comment:
As a follow-up: a "switch" statement, instead of reproduce code's "if"
statement, does not seem to be affected by the problem.
So, replacing the while loop in reproduce code with this one:
while (!socket_select($r = array($endpoint), $w = NULL, $e = NULL,
NULL))
switch ($err = socket_last_error())
{
case SOCKET_EINTR:
socket_clear_error();
PollSigs();
break;
default:
echo "socket_select() failed with $err\n";
break 2;
}
I get the expected behavior back (without having to resort to the
"dummy statement" kludge):
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 32
Received SIGINT
Handling SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 32
Received SIGINT
Handling SIGINT
Could this be of some help for narrowing the cause?
Previous Comments:
[2006-08-01 11:59:14] axelluttgens at swing dot be
Hello Tony, thanks again for your follow up!
For various reasons, I am currently really stuck with PHP 4 here. In
that sense, PHP 5 isn't an alternative for me yet.
But perhaps were you considering a very precise point?
Do you want me to try something else?
TIA,
Axel
[2006-07-31 20:13:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-07-31 19:40:17] axelluttgens at swing dot be
Description:
It seems there is a problem with the construction of the return address
to be used after an interrupt handler.
Now, I'm not sure whether the problem is a general one, or more
precisely located in the socket_xxx() family of functions.
I used the socket_select() function for building the example, as I
needed a function whose execution is liable to be suspended until the
occurence of an interrupt.
But the "workaround" described hereafter anyway seems to reveal some
misbehavior.
Reproduce code:
---
Create an executable file, say "sigtest.php", with following contents:
#!/usr/local/bin/php
Expected result:
During execution of above file on the terminal, a break (^C) should
result in:
1. the capture of SIGINT, and thus the execution of SaveINT(),
2. the continuation of execution after socket_select(), and thus the
execution of HandleINT() consecutively to the call of PollSigs().
Actual result:
--
[1] With above code, launching the executable yields:
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Handling SIGINT
Received SIGINT
[2] Now, uncomment the
# $err = $err;
line in the source and launch the executable again:
$ /Volumes/Data/Sources/sigtest.php
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
Handling SIGINT
^C
Warning: socket_select() unable to select [4]: Interrupted system call
in /Volumes/Data/Sources/sigtest.php on line 31
Received SIGINT
Handling SIGINT
The dummy instruction (ie, $err = $err;) thus allows to restore
exepected behavior.
--
Edit this bug report at http://bugs.php.net/?id=38273&edit=1
#36895 [Com]: Access Violation and Faulting Application (both Apache & IIS)
ID: 36895
Comment by: matthius at pointbtel dot com
Reported By: jsschuetz at knapheide dot com
Status: No Feedback
Bug Type: ODBC related
Operating System: server2003/WinXP Pro
PHP Version: 5.1.2
New Comment:
I'm fairly certain that I am suffering from this same bug.
Though I am not using ODBC, I do however hit MySQL pretty
hard.
Sadly I'm not equipped to generate a backtrace on this
machine. This is a major problem though, I am going to have
to roll everything back to PHP4 bacause i can't seem to keep
Apache on its feet for more than 15 min as it is.
I'm currently running PHP 5.1.4 and I've tried Apache 2.0.53
and 2.2.3. - both die the same way :-(
- Matt
Previous Comments:
[2006-04-20 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2006-04-12 14:59:28] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2006-04-12 13:30:47] jsschuetz at knapheide dot com
I narrowed down the code causing the problem. The below is the entire
program that will cause the error at random.
I am connecting to a DB2 database on an AS400 Iseries with ODCB drivers
provided by IBM client access software.
-
$con = odbc_connect('as400','username','password');
?>
Version 6
http://bugs.php.net/?id=36895&edit=1
#38292 [Opn->Bgs]: php pages not work on IIS
ID: 38292 Updated by: [EMAIL PROTECTED] Reported By: sameera at iitcampus dot com -Status: Open +Status: Bogus Bug Type: IIS related Operating System: windows 2000 server PHP Version: 5.1.4 New Comment: 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. Previous Comments: [2006-08-02 10:14:48] sameera at iitcampus dot com Description: I have configured IIS and Apache servers in a same computer with different ports and also i have installed zip vertion of the PHP 5 in this computer. when i'm running php pages on Apache server they are working properly and gives output immediately but with IIS it doesn't works. it gives CGI Time out. Reproduce code: --- Expected result: Hello World Actual result: -- CGI Timeout The specified CGI application exceeded the allowed time for processing. The server has deleted the process. -- Edit this bug report at http://bugs.php.net/?id=38292&edit=1
#38292 [NEW]: php pages not work on IIS
From: sameera at iitcampus dot com Operating system: windows 2000 server PHP version: 5.1.4 PHP Bug Type: IIS related Bug description: php pages not work on IIS Description: I have configured IIS and Apache servers in a same computer with different ports and also i have installed zip vertion of the PHP 5 in this computer. when i'm running php pages on Apache server they are working properly and gives output immediately but with IIS it doesn't works. it gives CGI Time out. Reproduce code: --- Expected result: Hello World Actual result: -- CGI Timeout The specified CGI application exceeded the allowed time for processing. The server has deleted the process. -- Edit bug report at http://bugs.php.net/?id=38292&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38292&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38292&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38292&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38292&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38292&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38292&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38292&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38292&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38292&r=support Expected behavior:http://bugs.php.net/fix.php?id=38292&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38292&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38292&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38292&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38292&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38292&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38292&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38292&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38292&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38292&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38292&r=mysqlcfg
#38283 [Opn->Fbk]: mysql_pconnect can't reuse the connections
ID: 38283
Updated by: [EMAIL PROTECTED]
Reported By: sanry at now dot net dot cn
-Status: Open
+Status: Feedback
Bug Type: MySQL related
Operating System: SUSE9.3 x86_64
PHP Version: 5.1.4
New Comment:
Can't reproduce with Apache2.0.55/worker and 5.2-CVS on Intel 64
server.
I get 1 persistent connection per Apache child/thread and this is the
expected result.
Previous Comments:
[2006-08-01 14:39:35] sanry at now dot net dot cn
Description:
mysql_pconnect create too many connections ,
not using the same connection in x86_64
(web server and mysql server not in the same computer)
I have test in 32bit system is okay,
both using the same mysql5.0.22
Reproduce code:
---
';
echo mysql_stat($db).'';
$t2=getmicrotime();
$tt=$t2-$t1;
$sql="SHOW PROCESSLIST ";
$res=mysql_query($sql);
if($res){
$dbstatus=mysql_num_rows($res);
}else $dbstatus=mysql_error();
//mysql_close($db);
echo "there are ".$dbstatus." connections ";
echo "time for connect is $tt ***";
?>
--
Edit this bug report at http://bugs.php.net/?id=38283&edit=1
#38271 [Opn->Fbk]: Type Hint with Array nulls given argument
ID: 38271
Updated by: [EMAIL PROTECTED]
Reported By: martin dot nowack at xiranet dot com
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: Linux x86 64Bit
PHP Version: 5.1.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Can't reproduce.
Previous Comments:
[2006-07-31 15:59:57] martin dot nowack at xiranet dot com
Description:
I tried to add a type hint for a function with an array:
function test(array $supi) ...
if I var_dump the content of the variable it is null but
should be array.
This problem is x86 64bit specific.
It doesn't happen on 32bit architecture.
Thank you for your help and support.
Reproduce code:
---
test($testArray);
$b = new B();
$b->test2($b);
?>
Expected result:
A:test
array(1) {
[0]=>
string(4) "test"
}
object(B)#2 (0) {
}
Actual result:
--
A:test
NULL
object(B)#2 (0) {
}
--
Edit this bug report at http://bugs.php.net/?id=38271&edit=1
#38291 [Opn->Fbk]: Segfault at compiling PHP with SNMP
ID: 38291 Updated by: [EMAIL PROTECTED] Reported By: mail at dirkje dot net -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Debian 3.1r2 PHP Version: 5.1.4 New Comment: I guess MySQL version is 5.0.22+, right? Previous Comments: [2006-08-02 08:49:38] mail at dirkje dot net Found something: when compiling without --with-mysql, it works. So not a PHP malfunction! [2006-08-02 08:26:15] mail at dirkje dot net Description: When I compile PHP-5.1.4 --with-snmp, I get a segfault at make install. I also tried to install PHP-4.4.2 but it doesn't work either. I also tried both PHP versions on a Slackware system but that distro gave me the same segfault. If I configure the PHP distro without PEAR, the make install works, but PHP will give me a segfault. Tried both Apache 1.3.34 and Apache 2.2.3. The SNMP packages I use: ucd-snmp-4.2.6 net-snmp-5.3.1 My configuration line: ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-zlib --with-jpeg-dir=/usr/lib --with-gd --with-png-dir=/usr/lib --with-snmp=/usr/local Also tried: ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-zlib --with-jpeg-dir=/usr/lib --with-gd --with-png-dir=/usr/lib --with-snmp Reproduce code: --- make install Installing PHP SAPI module: apache2handler /usr/local/apache/build/instdso.sh SH_LIBTOOL='/usr/local/apache/build/libtool' libphp5.la /usr/local/apache/modules /usr/local/apache/build/libtool --mode=install cp libphp5.la /usr/local/apache/modules/ cp .libs/libphp5.so /usr/local/apache/modules/libphp5.so cp .libs/libphp5.lai /usr/local/apache/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /root/php-5.1.4/libs' chmod 755 /usr/local/apache/modules/libphp5.so [activating module `php5' in /usr/local/apache/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 Expected result: No segfault :) -- Edit this bug report at http://bugs.php.net/?id=38291&edit=1
#38290 [Opn->Asn]: configure script ignores --without-cdb
ID: 38290 Updated by: [EMAIL PROTECTED] Reported By: tietew at tietew dot net -Status: Open +Status: Assigned Bug Type: *Configuration Issues Operating System: Linux PHP Version: 5.1.4 -Assigned To: +Assigned To: helly New Comment: Marcus. from what I can see, you enable most of the dba options even if they were explicitly disabled: Index: ext/dba/config.m4 === RCS file: /repository/php-src/ext/dba/config.m4,v retrieving revision 1.70.2.2 diff -u -p -d -r1.70.2.2 config.m4 --- ext/dba/config.m4 29 Nov 2005 18:25:58 - 1.70.2.2 +++ ext/dba/config.m4 2 Aug 2006 09:21:07 - @@ -463,7 +463,7 @@ AC_DEFUN([PHP_DBA_BUILTIN_CDB],[ AC_ARG_WITH(cdb, [ --with-cdb[=DIR] DBA: Include CDB support],[ - if test "$withval" = "yes" || test "$HAVE_DBA" = "1"; then + if test "$withval" = "yes"; then PHP_DBA_BUILTIN_CDB elif test "$withval" != "no"; then PHP_DBA_STD_BEGIN @@ -493,7 +493,7 @@ AC_ARG_WITH(cdb, PHP_DBA_STD_ATTACH fi ],[ - if test "$PHP_DBA" != "no" || test "$HAVE_DBA" = "1"; then + if test "$PHP_DBA" != "no"; then PHP_DBA_BUILTIN_CDB fi ]) @@ -511,7 +511,7 @@ AC_ARG_WITH(inifile, PHP_DBA_BUILTIN_INI fi ],[ - if test "$PHP_DBA" != "no" || test "$HAVE_DBA" = "1"; then + if test "$PHP_DBA" != "no"; then PHP_DBA_BUILTIN_INI fi ]) @@ -532,7 +532,7 @@ AC_ARG_WITH(flatfile, PHP_DBA_BUILTIN_FLATFILE fi ],[ - if test "$PHP_DBA" != "no" || test "$HAVE_DBA" = "1"; then + if test "$PHP_DBA" != "no"; then PHP_DBA_BUILTIN_FLATFILE fi ]) Previous Comments: [2006-08-02 06:26:22] tietew at tietew dot net Description: I want to compile PHP with dba but I don't want to include cdb support in order to resolve libcdb confliction problem temporarily. I passed "--enable-dba --without-cdb" to configure script but the script have ignored --without-cdb. Reproduce code: --- ./configure --enable-dba --with-gdbm --with-db4 --without-cdb Expected result: PHP is compiled with dba but without cdb support. Actual result: -- PHP is compiled with cdb support. -- Edit this bug report at http://bugs.php.net/?id=38290&edit=1
#38289 [Opn->Csd]: session_decode()/$_SESSION problem
ID: 38289 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Session related PHP Version: 5.1.4 New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-08-02 01:59:50] [EMAIL PROTECTED] Description: session_decode() core dumps if $_SESSION is set to null before calling it. Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=38289&edit=1
#38291 [Opn]: Segfault at compiling PHP with SNMP
ID: 38291 User updated by: mail at dirkje dot net Reported By: mail at dirkje dot net Status: Open Bug Type: Compile Failure Operating System: Debian 3.1r2 PHP Version: 5.1.4 New Comment: Found something: when compiling without --with-mysql, it works. So not a PHP malfunction! Previous Comments: [2006-08-02 08:26:15] mail at dirkje dot net Description: When I compile PHP-5.1.4 --with-snmp, I get a segfault at make install. I also tried to install PHP-4.4.2 but it doesn't work either. I also tried both PHP versions on a Slackware system but that distro gave me the same segfault. If I configure the PHP distro without PEAR, the make install works, but PHP will give me a segfault. Tried both Apache 1.3.34 and Apache 2.2.3. The SNMP packages I use: ucd-snmp-4.2.6 net-snmp-5.3.1 My configuration line: ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-zlib --with-jpeg-dir=/usr/lib --with-gd --with-png-dir=/usr/lib --with-snmp=/usr/local Also tried: ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-zlib --with-jpeg-dir=/usr/lib --with-gd --with-png-dir=/usr/lib --with-snmp Reproduce code: --- make install Installing PHP SAPI module: apache2handler /usr/local/apache/build/instdso.sh SH_LIBTOOL='/usr/local/apache/build/libtool' libphp5.la /usr/local/apache/modules /usr/local/apache/build/libtool --mode=install cp libphp5.la /usr/local/apache/modules/ cp .libs/libphp5.so /usr/local/apache/modules/libphp5.so cp .libs/libphp5.lai /usr/local/apache/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /root/php-5.1.4/libs' chmod 755 /usr/local/apache/modules/libphp5.so [activating module `php5' in /usr/local/apache/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 Expected result: No segfault :) -- Edit this bug report at http://bugs.php.net/?id=38291&edit=1
#38291 [NEW]: Segfault at compiling PHP with SNMP
From: mail at dirkje dot net Operating system: Debian 3.1r2 PHP version: 5.1.4 PHP Bug Type: Compile Failure Bug description: Segfault at compiling PHP with SNMP Description: When I compile PHP-5.1.4 --with-snmp, I get a segfault at make install. I also tried to install PHP-4.4.2 but it doesn't work either. I also tried both PHP versions on a Slackware system but that distro gave me the same segfault. If I configure the PHP distro without PEAR, the make install works, but PHP will give me a segfault. Tried both Apache 1.3.34 and Apache 2.2.3. The SNMP packages I use: ucd-snmp-4.2.6 net-snmp-5.3.1 My configuration line: ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-zlib --with-jpeg-dir=/usr/lib --with-gd --with-png-dir=/usr/lib --with-snmp=/usr/local Also tried: ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-zlib --with-jpeg-dir=/usr/lib --with-gd --with-png-dir=/usr/lib --with-snmp Reproduce code: --- make install Installing PHP SAPI module: apache2handler /usr/local/apache/build/instdso.sh SH_LIBTOOL='/usr/local/apache/build/libtool' libphp5.la /usr/local/apache/modules /usr/local/apache/build/libtool --mode=install cp libphp5.la /usr/local/apache/modules/ cp .libs/libphp5.so /usr/local/apache/modules/libphp5.so cp .libs/libphp5.lai /usr/local/apache/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /root/php-5.1.4/libs' chmod 755 /usr/local/apache/modules/libphp5.so [activating module `php5' in /usr/local/apache/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 Expected result: No segfault :) -- Edit bug report at http://bugs.php.net/?id=38291&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38291&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38291&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38291&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38291&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38291&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38291&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38291&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38291&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38291&r=support Expected behavior:http://bugs.php.net/fix.php?id=38291&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38291&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38291&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38291&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38291&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38291&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38291&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38291&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38291&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38291&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38291&r=mysqlcfg
