#47818 [NEW]: Segfault due to bound callback param
From: galaxy dot mipt at gmail dot com
Operating system: Linux 2.6.18 x86
PHP version: 5.2.9
PHP Bug Type: XMLRPC-EPI related
Bug description: Segfault due to bound callback param
Description:
In my particular case when the callback for
xmlrpc_server_register_method() is a class method attempt to save some of
the parameters passed to that callback during xmlrpc_server_call_method()
call results in segfault.
Well, I cannot provide short code that would reproduce the segfault I get
in my application - it's sort of unstable. But the code below at least show
that something is really wrong here.
I believe that $method_name just gets garbage-collected no matter that it
is bound with $this->method. Decoupling them, for example like this,
helps:
$this->method = (string)$method_name;
Reproduce code:
---
class MyXmlRpc {
private $s;
private $method;
function impl($method_name, $params, $user_data){
$this->method = $method_name;
print "Inside impl(): {$this->method}\n";
return array_sum($params);
}
function __construct() {
$this->s = xmlrpc_server_create();
xmlrpc_server_register_method($this->s,'add', array($this,
'impl'));
}
function call($req) {
return xmlrpc_server_call_method($this->s, $req, null);
}
function getMethod() {return $this->method;}
}
$x = new MyXmlRpc;
$resp = $x->call(xmlrpc_encode_request('add',array(1,2,3)));
$method = $x->getMethod();
print "Global scope: $method\n";
Expected result:
Inside impl(): add
Global scope: add
Actual result:
--
Inside impl(): add
Global scope:
--
Edit bug report at http://bugs.php.net/?id=47818&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47818&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47818&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47818&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47818&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47818&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47818&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47818&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47818&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47818&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47818&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47818&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47818&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47818&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47818&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47818&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47818&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47818&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47818&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47818&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47818&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47818&r=mysqlcfg
#47816 [Opn]: pcntl tests failing on NetBSD
ID: 47816
Updated by: lbarn...@php.net
Reported By: mbecc...@php.net
Status: Open
Bug Type: PCNTL related
Operating System: NetBSD 4
PHP Version: 5.3CVS-2009-03-28 (CVS)
New Comment:
Hi,
This looks good, please commit :)
Thanks for your tests on NetBSD.
Previous Comments:
[2009-03-28 01:43:19] mbecc...@php.net
Description:
There are a few problems with the new pcntl extension on my NetBSD 4.0
system. The extension compiles fine, but a few tests fail.
First, it seems that NetBSD sigtimedwait / sigwaitinfo implementations
return 0 on success and -1 on failure, rather then the signal number:
see http://www.daemon-systems.org/man/sigwait.2.html
A patch is available here:
http://www.beccati.com/misc/php/pcntl_sigtimedwait_HEAD.diff
I didn't commit myself as you might want a better (autoconf based?)
fix.
Second, there are a couple of kernel bugs interfering with pcntl
properly working:
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=41076 (Fixed in
-current)
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=41085 (Under
investigation)
Once those bugs have been fixed the extensions should be properly
working on NetBSD.
Reproduce code:
---
pcntl_sigprocmask(SIG_BLOCK, array(SIGTERM));
posix_kill(posix_getpid(), SIGTERM);
var_dump(pcntl_sigwaitinfo(array(SIGTERM), $siginfo));
var_dump($siginfo);
Expected result:
int(15)
array(3) {
[u"signo"]=>
int(15)
[u"errno"]=>
int(0)
[u"code"]=>
int(0)
}
Actual result:
--
int(0)
NULL
--
Edit this bug report at http://bugs.php.net/?id=47816&edit=1
#47817 [NEW]: PHP hangs when running proc_open()
From: steven dot abarnett at gmail dot com
Operating system: Windows XP
PHP version: 5.2.9
PHP Bug Type: Reproducible crash
Bug description: PHP hangs when running proc_open()
Description:
Unfortunately as far as I can tell, I am the only person having this
problem- which leads me to wonder if it's an issue with my PHP
configuration. Although I keep using default configuration, so I am at a
loss. I have tried installing PHP and Apache, I have tried in xampp, and I
have tried in WAMP. Every time after running the proc_open() command the
PHP script will wait for the process to close before reading the next line-
making reading or writing to any pipes impossible.
$fileDesc = array(
0 => array("pipe", "r"), // STDIN
1 => array("pipe", "w"), // STDOUT
2 => array("pipe", "w") // STDERR
);
die("Got this far");
$handle = proc_open("C:/wherever/program.exe", $fileDesc, $pipes);
fwrite($pipes[0], "input");
fclose($pipes[0]);
proc_close($handle);
Displays "Got this far" and dies, as expected. However:
$fileDesc = array(
0 => array("pipe", "r"), // STDIN
1 => array("pipe", "w"), // STDOUT
2 => array("pipe", "w") // STDERR
);
$handle = proc_open("C:/wherever/program.exe", $fileDesc, $pipes);
die("Got this far");
fwrite($pipes[0], "input");
fclose($pipes[0]);
proc_close($handle);
Will simply hang and seem to cease all function. The moment that I close
program.exe through task manager the script continues as if nothing were
wrong, dying with the output "Got this far". The input is never passed to
the program, although no errors are raised when I hit the proc_close()
line.
Reproduce code:
---
$descriptors = array(
0 => array("pipe", "r"), // STDIN. Used to feed input
1 => array("pipe", "w"), // STDOUT. Used to read output
2 => array("pipe", "w"), // STDERR. Used to read errors
3 => array("pipe", "r") // We can feed the passphrase here
);
// Build the command line and start the process
$cmd = '"C:/program files/gnu/gnupg/gpg.exe" --batch --no-verbose
--passphrase-fd 3 --output decrypted.zip --decrypt encrypted.zip.gpg';
$gpg = proc_open( $cmd, $descriptors, $pipes);
if(is_resource($gpg)) {
// Push passphrase to custom pipe
fwrite($pipes[3], $passphrase);
fclose($pipes[3]);
proc_close($gpg);
}
Expected result:
Expected to find decrypted.zip in the same directory as the PHP script (a
decrypted version of encrypted.zip.gpg, which is located in the same
directory as the PHP script)
Actual result:
--
When localhost/test.php was run the webpage continued to load
indefinitely. I waited as long as 20 minutes. The PHP.ini file should stop
execution after 30 seconds. When gpg.exe was killed with task manager the
page loaded but the .zip file was never created.
--
Edit bug report at http://bugs.php.net/?id=47817&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47817&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47817&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47817&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47817&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47817&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47817&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47817&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47817&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47817&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47817&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47817&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47817&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47817&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47817&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47817&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47817&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47817&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47817&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47817&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47817&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47817&r=mysqlcfg
#47816 [NEW]: pcntl tests failing on NetBSD
From: mbecc...@php.net
Operating system: NetBSD 4
PHP version: 5.3CVS-2009-03-28 (CVS)
PHP Bug Type: PCNTL related
Bug description: pcntl tests failing on NetBSD
Description:
There are a few problems with the new pcntl extension on my NetBSD 4.0
system. The extension compiles fine, but a few tests fail.
First, it seems that NetBSD sigtimedwait / sigwaitinfo implementations
return 0 on success and -1 on failure, rather then the signal number: see
http://www.daemon-systems.org/man/sigwait.2.html
A patch is available here:
http://www.beccati.com/misc/php/pcntl_sigtimedwait_HEAD.diff
I didn't commit myself as you might want a better (autoconf based?) fix.
Second, there are a couple of kernel bugs interfering with pcntl properly
working:
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=41076 (Fixed in
-current)
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=41085 (Under
investigation)
Once those bugs have been fixed the extensions should be properly working
on NetBSD.
Reproduce code:
---
pcntl_sigprocmask(SIG_BLOCK, array(SIGTERM));
posix_kill(posix_getpid(), SIGTERM);
var_dump(pcntl_sigwaitinfo(array(SIGTERM), $siginfo));
var_dump($siginfo);
Expected result:
int(15)
array(3) {
[u"signo"]=>
int(15)
[u"errno"]=>
int(0)
[u"code"]=>
int(0)
}
Actual result:
--
int(0)
NULL
--
Edit bug report at http://bugs.php.net/?id=47816&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47816&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47816&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47816&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47816&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47816&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47816&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47816&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47816&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47816&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47816&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47816&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47816&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47816&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47816&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47816&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47816&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47816&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47816&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47816&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47816&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47816&r=mysqlcfg
#47799 [Fbk->Opn]: Segfault with Regex
ID: 47799
User updated by: mb at insidetheweb dot de
Reported By: mb at insidetheweb dot de
-Status: Feedback
+Status: Open
Bug Type:PCRE related
PHP Version: 5.2.9
New Comment:
Sorry, no clue how to get a backtrace on a running system.
This httpd -X does not work. Not even mod_backtrace.
Simply
Download the Text_Wiki with Mediawiki and parse some large Table. You
get the error then yourself. I really doubt its system related.
Previous Comments:
[2009-03-27 16:16:34] fel...@php.net
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.
[2009-03-27 01:09:11] mb at insidetheweb dot de
Description:
When i do this Regex
#^\{\|(.*?)(?:^\|\+(.*?))?(^(?:((?R))|.)*?)^\|}#msi
on larger requests, it causes a seqfault.
You just need to be some chars above some kind of limit and you got the
error.
Reproduce code:
---
http://cvs.php.net/viewvc.cgi/pear/Text_Wiki/Text/Wiki/Parse/Mediawiki/Table.php?revision=1.11&view=markup
Its Text_Wiki_Mediawiki.
Expected result:
HTTPD Seqfault
--
Edit this bug report at http://bugs.php.net/?id=47799&edit=1
#47811 [Com]: preg_match that can cause segmentation fault
ID: 47811
Comment by: dennis dot birkholz at nexxes dot net
Reported By: travis at wikihow dot com
Status: Open
Bug Type: Reproducible crash
Operating System: CentOS release 4.4 & Mac OS 10.4
PHP Version: 5.2.9
New Comment:
I have a similar segfault testcase for preg_match. It always crashes at
a stringlength of around 6700. PHP is 5.2.8 on gentoo linux.
# Create my test-string
for ($i=0; $i<2; $i++) {
$string .= 'a';
}
# The pattern matches for \\, \", everything except " and "
$pattern = '/^(|\\"|[^"]|")+$/';
print "Trying with string length " . "\033" . '[s';
for ($counter=6600; $counter@im', $text, $matches);
Reproduce code:
---
http://wikidiy.com/php_bug_crash.txt
Expected result:
Apache not supposed to crash, completes preg_match, dumps $matches
array.
Actual result:
--
Apache seg faults
[Fri Mar 27 12:16:05 2009] [notice] child pid 6391 exit signal
Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=47811&edit=1
#47815 [Opn]: Compile time computation of hash value decrease hash lookup time.
ID: 47815
User updated by: basant dot kukreja at gmail dot com
Reported By: basant dot kukreja at gmail dot com
Status: Open
Bug Type: Performance problem
Operating System: Solaris 10
PHP Version: 5.2.9
New Comment:
Some signifiant percentage of the time is spent in calculating the hash
value
of string contants.
If we compute the hash value of string constants during compilation
then
lookup time can be improved a lot.
With the above submitted patch results are better :
Excl. Incl. Name
User CPU User CPU
sec. sec.
414.450 726.638 zend_fetch_dimension_address
74.922238.016 zend_get_property_info_hval
Note the 150 second (~20 % time) less time spent in
zend_fetch_dimension_address and 190 second (45% time) reduction in
zend_get_property_info.
It showed 1% performance overall.
Previous Comments:
[2009-03-27 22:59:55] basant dot kukreja at gmail dot com
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_compile.h
--- a/php-5.2.9RC3/Zend/zend_compile.h Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_compile.h Fri Mar 27 10:18:13 2009 -0700
@@ -83,6 +83,7 @@
znode op1;
znode op2;
ulong extended_value;
+ ulong hval;
uint lineno;
zend_uchar opcode;
};
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_execute.c
--- a/php-5.2.9RC3/Zend/zend_execute.c Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_execute.c Fri Mar 27 10:18:13 2009 -0700
@@ -930,11 +930,12 @@
return NULL;
}
-static inline zval **zend_fetch_dimension_address_inner(HashTable *ht,
zval *dim, int type TSRMLS_DC)
+static inline zval **zend_fetch_dimension_address_inner(HashTable *ht,
zval *dim, int type, zend_ulong hval, int usehval TSRMLS_DC)
{
zval **retval;
char *offset_key;
int offset_key_length;
+ int ret;
switch (dim->type) {
case IS_NULL:
@@ -948,7 +949,13 @@
offset_key_length = dim->value.str.len;
fetch_string_dim:
- if (zend_symtable_find(ht, offset_key,
offset_key_length+1, (void
**) &retval) == FAILURE) {
+ if (usehval) {
+ ret = zend_symtable_quick_find(ht, offset_key,
offset_key_length+1, hval, (void **) &retval);
+ }
+ else {
+ ret = zend_symtable_find(ht, offset_key,
offset_key_length+1,
(void **) &retval);
+ }
+ if (ret == FAILURE) {
switch (type) {
case BP_VAR_R:
zend_error(E_NOTICE, "Undefined
index: %s", offset_key);
@@ -1023,7 +1030,7 @@
return retval;
}
-static void zend_fetch_dimension_address(temp_variable *result, zval
**container_ptr, zval *dim, int dim_is_tmp_var, int type TSRMLS_DC)
+static void zend_fetch_dimension_address(temp_variable *result, zval
**container_ptr, zval *dim, int dim_is_tmp_var, int type, zend_ulong
hval, int usehval TSRMLS_DC)
{
zval *container;
@@ -1078,7 +1085,7 @@
new_zval->refcount--;
}
} else {
- retval =
zend_fetch_dimension_address_inner(Z_ARRVAL_P(container),
dim, type TSRMLS_CC);
+ retval =
zend_fetch_dimension_address_inner(Z_ARRVAL_P(container),
dim, type, hval, usehval TSRMLS_CC);
}
if (result) {
result->var.ptr_ptr = retval;
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_hash.h
--- a/php-5.2.9RC3/Zend/zend_hash.h Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_hash.h Fri Mar 27 10:18:13 2009 -0700
@@ -354,6 +354,12 @@
return zend_hash_find(ht, arKey, nKeyLength, pData);
}
+static inline int zend_symtable_quick_find(HashTable *ht, char *arKey,
uint nKeyLength, ulong h, void **pData)
+{
+ HANDLE_NUMERIC(arKey, nKeyLength, zend_hash_index_find(ht, idx,
pData));
+ return zend_hash_quick_find(ht, arKey, nKeyLength, h, pData);
+}
+
static inline int zend_symtable_exists(HashTable *ht, char *arKey,
uint nKeyLength)
{
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_object_handlers.c
--- a/php-5.2.9RC3/Zend/zend_object_handlers.c Tue Mar 17 11:27:02 2009
-0700
+++ b/php-5.2.9RC3/Zend/zend_object_handlers.c Fri Mar 27 10:18:13 2009
-0700
@@ -175,24 +175,11 @@
return 0;
}
-ZEND_API struct _zend_property_info
*zend_get_property_info(zend_class_entry *ce, zval *member, int silent
TSRMLS_DC)
+static struct _zend_property_info
*zend_get_property_info_hval(zend_class_entry *ce, zval *member, int
silent, ulong h TSRMLS_DC)
{
zend_property
#47815 [Opn]: Compile time computation of hash value decrease hash lookup time.
ID: 47815
User updated by: basant dot kukreja at gmail dot com
Reported By: basant dot kukreja at gmail dot com
Status: Open
Bug Type: Performance problem
Operating System: Solaris 10
PHP Version: 5.2.9
New Comment:
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_compile.h
--- a/php-5.2.9RC3/Zend/zend_compile.h Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_compile.h Fri Mar 27 10:18:13 2009 -0700
@@ -83,6 +83,7 @@
znode op1;
znode op2;
ulong extended_value;
+ ulong hval;
uint lineno;
zend_uchar opcode;
};
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_execute.c
--- a/php-5.2.9RC3/Zend/zend_execute.c Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_execute.c Fri Mar 27 10:18:13 2009 -0700
@@ -930,11 +930,12 @@
return NULL;
}
-static inline zval **zend_fetch_dimension_address_inner(HashTable *ht,
zval *dim, int type TSRMLS_DC)
+static inline zval **zend_fetch_dimension_address_inner(HashTable *ht,
zval *dim, int type, zend_ulong hval, int usehval TSRMLS_DC)
{
zval **retval;
char *offset_key;
int offset_key_length;
+ int ret;
switch (dim->type) {
case IS_NULL:
@@ -948,7 +949,13 @@
offset_key_length = dim->value.str.len;
fetch_string_dim:
- if (zend_symtable_find(ht, offset_key,
offset_key_length+1, (void
**) &retval) == FAILURE) {
+ if (usehval) {
+ ret = zend_symtable_quick_find(ht, offset_key,
offset_key_length+1, hval, (void **) &retval);
+ }
+ else {
+ ret = zend_symtable_find(ht, offset_key,
offset_key_length+1,
(void **) &retval);
+ }
+ if (ret == FAILURE) {
switch (type) {
case BP_VAR_R:
zend_error(E_NOTICE, "Undefined
index: %s", offset_key);
@@ -1023,7 +1030,7 @@
return retval;
}
-static void zend_fetch_dimension_address(temp_variable *result, zval
**container_ptr, zval *dim, int dim_is_tmp_var, int type TSRMLS_DC)
+static void zend_fetch_dimension_address(temp_variable *result, zval
**container_ptr, zval *dim, int dim_is_tmp_var, int type, zend_ulong
hval, int usehval TSRMLS_DC)
{
zval *container;
@@ -1078,7 +1085,7 @@
new_zval->refcount--;
}
} else {
- retval =
zend_fetch_dimension_address_inner(Z_ARRVAL_P(container),
dim, type TSRMLS_CC);
+ retval =
zend_fetch_dimension_address_inner(Z_ARRVAL_P(container),
dim, type, hval, usehval TSRMLS_CC);
}
if (result) {
result->var.ptr_ptr = retval;
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_hash.h
--- a/php-5.2.9RC3/Zend/zend_hash.h Tue Mar 17 11:27:02 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_hash.h Fri Mar 27 10:18:13 2009 -0700
@@ -354,6 +354,12 @@
return zend_hash_find(ht, arKey, nKeyLength, pData);
}
+static inline int zend_symtable_quick_find(HashTable *ht, char *arKey,
uint nKeyLength, ulong h, void **pData)
+{
+ HANDLE_NUMERIC(arKey, nKeyLength, zend_hash_index_find(ht, idx,
pData));
+ return zend_hash_quick_find(ht, arKey, nKeyLength, h, pData);
+}
+
static inline int zend_symtable_exists(HashTable *ht, char *arKey,
uint nKeyLength)
{
diff -r 00438f7eebe4 php-5.2.9RC3/Zend/zend_object_handlers.c
--- a/php-5.2.9RC3/Zend/zend_object_handlers.c Tue Mar 17 11:27:02 2009
-0700
+++ b/php-5.2.9RC3/Zend/zend_object_handlers.c Fri Mar 27 10:18:13 2009
-0700
@@ -175,24 +175,11 @@
return 0;
}
-ZEND_API struct _zend_property_info
*zend_get_property_info(zend_class_entry *ce, zval *member, int silent
TSRMLS_DC)
+static struct _zend_property_info
*zend_get_property_info_hval(zend_class_entry *ce, zval *member, int
silent, ulong h TSRMLS_DC)
{
zend_property_info *property_info = NULL;
zend_property_info *scope_property_info;
zend_bool denied_access = 0;
- ulong h;
-
- if (Z_STRVAL_P(member)[0] == '\0') {
- if (!silent) {
- if (Z_STRLEN_P(member) == 0) {
- zend_error(E_ERROR, "Cannot access empty
property");
- } else {
- zend_error(E_ERROR, "Cannot access property
started with '\\0'");
- }
- }
- return NULL;
- }
- h = zend_get_hash_value(Z_STRVAL_P(member), Z_STRLEN_P(member) + 1);
if (zend_hash_quick_find(&ce->properties_info, Z_STRVAL_P(member),
Z_STRLEN_P(member)+1, h, (void **) &property_info)
#47815 [NEW]: Compile time computation of hash value decrease hash lookup time.
From: basant dot kukreja at gmail dot com Operating system: Solaris 10 PHP version: 5.2.9 PHP Bug Type: Performance problem Bug description: Compile time computation of hash value decrease hash lookup time. Description: In specweb ecommerce php benchmark, hash lookup consumes a lot of time. For a 30 minutes measurement : Excl. Incl. Name User CPU User CPU sec. sec. 434.304 914.980 zend_fetch_dimension_address 136.195 427.119 zend_get_property_info 914 seconds (13 % of user time) are spent in zend_fetch_dimension_address out of total 6947 seconds. Reproduce code: --- specweb benchmark. Expected result: Low time spent in zend_fetch_dimension_address and zend_get_property_info Actual result: -- Time spend in zend_fetch_dimension_address and zend_get_property_info is very high. -- Edit bug report at http://bugs.php.net/?id=47815&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47815&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47815&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47815&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47815&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47815&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47815&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47815&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47815&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47815&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47815&r=support Expected behavior: http://bugs.php.net/fix.php?id=47815&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47815&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47815&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47815&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47815&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47815&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47815&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47815&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47815&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47815&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47815&r=mysqlcfg
#47812 [Asn]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Updated by: paj...@php.net Reported By: oeriksson at mandriva dot com Status: Assigned Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: Please do not use this report to discuss other topics. But to answer your questions, yes, they are provided as patch upstream as well and we try to keep everything synced as much as possible. But they tend to stay behind for some fixes, especially edge cases for crashes or windows support. You can follow the libzip mailing list if you are interested. Previous Comments: [2009-03-27 21:10:56] oeriksson at mandriva dot com Thanks Pierre, What about the private changes in libzip? Will you be able to sync that with upstream as well? [2009-03-27 20:55:35] paj...@php.net There is work being done in libgd.org to bring 2.1.0 out (which should be synced with php). All fixes are done in both libraries (thanks Tabe for taking care of most of them) and many features have made their way. By the way, if the tempo is too slow, you can always give us a hand. I'm not willing to begin again a discussion with the Debian maintainer, I tried many times without success. [2009-03-27 20:40:39] oeriksson at mandriva dot com Excuse me for bothering you with petty issues. Why is it the bundled libgd is not in sync with the more "official" libgd as you are the sole upstream maintainer? gd hasn't had a new release since 2007-11-28, and none of the bling-bling found in the bundled libgd has found its way into any official libgd release. There are other bundled libraries. What about them then and private changes? [2009-03-27 20:33:12] crrodriguez at opensuse dot org Pierre: is there any summary on what has to be done exactly to sync both libraries so distributions can just ship one copy of libgd ? Maybe all interested parties can hack into it. [2009-03-27 20:18:51] ras...@php.net Right, so you figured it out. You are talking to Pierre here. He is the upstream maintainer of the library. And the library is a PHP project. Telling us to do a better job pushing changes upstream (to ourselves?) doesn't make much sense. 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/47812 -- Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Com]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Comment by: oeriksson at mandriva dot com Reported By: oeriksson at mandriva dot com Status: Assigned Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: Thanks Pierre, What about the private changes in libzip? Will you be able to sync that with upstream as well? Previous Comments: [2009-03-27 20:55:35] paj...@php.net There is work being done in libgd.org to bring 2.1.0 out (which should be synced with php). All fixes are done in both libraries (thanks Tabe for taking care of most of them) and many features have made their way. By the way, if the tempo is too slow, you can always give us a hand. I'm not willing to begin again a discussion with the Debian maintainer, I tried many times without success. [2009-03-27 20:40:39] oeriksson at mandriva dot com Excuse me for bothering you with petty issues. Why is it the bundled libgd is not in sync with the more "official" libgd as you are the sole upstream maintainer? gd hasn't had a new release since 2007-11-28, and none of the bling-bling found in the bundled libgd has found its way into any official libgd release. There are other bundled libraries. What about them then and private changes? [2009-03-27 20:33:12] crrodriguez at opensuse dot org Pierre: is there any summary on what has to be done exactly to sync both libraries so distributions can just ship one copy of libgd ? Maybe all interested parties can hack into it. [2009-03-27 20:18:51] ras...@php.net Right, so you figured it out. You are talking to Pierre here. He is the upstream maintainer of the library. And the library is a PHP project. Telling us to do a better job pushing changes upstream (to ourselves?) doesn't make much sense. [2009-03-27 20:14:17] oeriksson at mandriva dot com Upstream gd is nowadays libgd.org and I read there "The library was originally developped by Thomas Boutell and is now maintained by Pierre-A. Joye under the umbrella of PHP.net.". Is this a problem? 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/47812 -- Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Asn]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Updated by: paj...@php.net Reported By: oeriksson at mandriva dot com Status: Assigned Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: There is work being done in libgd.org to bring 2.1.0 out (which should be synced with php). All fixes are done in both libraries (thanks Tabe for taking care of most of them) and many features have made their way. By the way, if the tempo is too slow, you can always give us a hand. I'm not willing to begin again a discussion with the Debian maintainer, I tried many times without success. Previous Comments: [2009-03-27 20:40:39] oeriksson at mandriva dot com Excuse me for bothering you with petty issues. Why is it the bundled libgd is not in sync with the more "official" libgd as you are the sole upstream maintainer? gd hasn't had a new release since 2007-11-28, and none of the bling-bling found in the bundled libgd has found its way into any official libgd release. There are other bundled libraries. What about them then and private changes? [2009-03-27 20:33:12] crrodriguez at opensuse dot org Pierre: is there any summary on what has to be done exactly to sync both libraries so distributions can just ship one copy of libgd ? Maybe all interested parties can hack into it. [2009-03-27 20:18:51] ras...@php.net Right, so you figured it out. You are talking to Pierre here. He is the upstream maintainer of the library. And the library is a PHP project. Telling us to do a better job pushing changes upstream (to ourselves?) doesn't make much sense. [2009-03-27 20:14:17] oeriksson at mandriva dot com Upstream gd is nowadays libgd.org and I read there "The library was originally developped by Thomas Boutell and is now maintained by Pierre-A. Joye under the umbrella of PHP.net.". Is this a problem? [2009-03-27 20:05:33] paj...@php.net You missed my point. These distributions do not have updated libraries, or even worst for debian, they break the compatibility with the normal GD. I'm working to sync the external gd and php's gd so both can be used smoothly, but I have serious doubts that Debian will change, for example. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47812 -- Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Com]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Comment by: oeriksson at mandriva dot com Reported By: oeriksson at mandriva dot com Status: Assigned Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: Excuse me for bothering you with petty issues. Why is it the bundled libgd is not in sync with the more "official" libgd as you are the sole upstream maintainer? gd hasn't had a new release since 2007-11-28, and none of the bling-bling found in the bundled libgd has found its way into any official libgd release. There are other bundled libraries. What about them then and private changes? Previous Comments: [2009-03-27 20:33:12] crrodriguez at opensuse dot org Pierre: is there any summary on what has to be done exactly to sync both libraries so distributions can just ship one copy of libgd ? Maybe all interested parties can hack into it. [2009-03-27 20:18:51] ras...@php.net Right, so you figured it out. You are talking to Pierre here. He is the upstream maintainer of the library. And the library is a PHP project. Telling us to do a better job pushing changes upstream (to ourselves?) doesn't make much sense. [2009-03-27 20:14:17] oeriksson at mandriva dot com Upstream gd is nowadays libgd.org and I read there "The library was originally developped by Thomas Boutell and is now maintained by Pierre-A. Joye under the umbrella of PHP.net.". Is this a problem? [2009-03-27 20:05:33] paj...@php.net You missed my point. These distributions do not have updated libraries, or even worst for debian, they break the compatibility with the normal GD. I'm working to sync the external gd and php's gd so both can be used smoothly, but I have serious doubts that Debian will change, for example. [2009-03-27 20:04:23] ras...@php.net That argument completely falls apart if you do a bit of research on who the upstream for the gd library is. 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/47812 -- Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Com]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Comment by: crrodriguez at opensuse dot org Reported By: oeriksson at mandriva dot com Status: Assigned Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: Pierre: is there any summary on what has to be done exactly to sync both libraries so distributions can just ship one copy of libgd ? Maybe all interested parties can hack into it. Previous Comments: [2009-03-27 20:18:51] ras...@php.net Right, so you figured it out. You are talking to Pierre here. He is the upstream maintainer of the library. And the library is a PHP project. Telling us to do a better job pushing changes upstream (to ourselves?) doesn't make much sense. [2009-03-27 20:14:17] oeriksson at mandriva dot com Upstream gd is nowadays libgd.org and I read there "The library was originally developped by Thomas Boutell and is now maintained by Pierre-A. Joye under the umbrella of PHP.net.". Is this a problem? [2009-03-27 20:05:33] paj...@php.net You missed my point. These distributions do not have updated libraries, or even worst for debian, they break the compatibility with the normal GD. I'm working to sync the external gd and php's gd so both can be used smoothly, but I have serious doubts that Debian will change, for example. [2009-03-27 20:04:23] ras...@php.net That argument completely falls apart if you do a bit of research on who the upstream for the gd library is. [2009-03-27 19:59:07] oeriksson at mandriva dot com The PHP devs should try harder to not bundle common libraries and instead push private changes upstream (IMHO). 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/47812 -- Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Asn]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Updated by: ras...@php.net Reported By: oeriksson at mandriva dot com Status: Assigned Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: Right, so you figured it out. You are talking to Pierre here. He is the upstream maintainer of the library. And the library is a PHP project. Telling us to do a better job pushing changes upstream (to ourselves?) doesn't make much sense. Previous Comments: [2009-03-27 20:14:17] oeriksson at mandriva dot com Upstream gd is nowadays libgd.org and I read there "The library was originally developped by Thomas Boutell and is now maintained by Pierre-A. Joye under the umbrella of PHP.net.". Is this a problem? [2009-03-27 20:05:33] paj...@php.net You missed my point. These distributions do not have updated libraries, or even worst for debian, they break the compatibility with the normal GD. I'm working to sync the external gd and php's gd so both can be used smoothly, but I have serious doubts that Debian will change, for example. [2009-03-27 20:04:23] ras...@php.net That argument completely falls apart if you do a bit of research on who the upstream for the gd library is. [2009-03-27 19:59:07] oeriksson at mandriva dot com The PHP devs should try harder to not bundle common libraries and instead push private changes upstream (IMHO). [2009-03-27 19:49:27] paj...@php.net You should really not use the system libgd, especially not on the following systems: - debian - RHEL - Centos The problem still has to be fixed tho' :) 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/47812 -- Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Com]: undefined symbol: gdJpegGetVersionInt
ID: 47812
Comment by: oeriksson at mandriva dot com
Reported By: oeriksson at mandriva dot com
Status: Assigned
Bug Type: GD related
Operating System: Mandriva Linux
PHP Version: 5.3.0RC1
Assigned To: pajoye
New Comment:
Upstream gd is nowadays libgd.org and I read there "The library was
originally developped by Thomas Boutell and is now maintained by
Pierre-A. Joye under the umbrella of PHP.net.". Is this a problem?
Previous Comments:
[2009-03-27 20:05:33] paj...@php.net
You missed my point.
These distributions do not have updated libraries, or even worst for
debian, they break the compatibility with the normal GD.
I'm working to sync the external gd and php's gd so both can be used
smoothly, but I have serious doubts that Debian will change, for
example.
[2009-03-27 20:04:23] ras...@php.net
That argument completely falls apart if you do a bit of research on who
the upstream for the gd library is.
[2009-03-27 19:59:07] oeriksson at mandriva dot com
The PHP devs should try harder to not bundle common libraries and
instead push private changes upstream (IMHO).
[2009-03-27 19:49:27] paj...@php.net
You should really not use the system libgd, especially not on the
following systems:
- debian
- RHEL
- Centos
The problem still has to be fixed tho' :)
[2009-03-27 19:45:31] oeriksson at mandriva dot com
I described it in "Description:" :-)
Here's a proposed fix:
--- ext/gd/gd.c 2009-01-31 16:27:52.0 +0100
+++ ext/gd/gd.c.oden2009-03-27 20:27:14.0 +0100
@@ -55,6 +55,15 @@
#if HAVE_LIBGD
+#ifdef HAVE_GD_PNG
+/* needs to be first */
+# include
+#endif
+
+#ifdef HAVE_GD_JPG
+# include
+#endif
+
static int le_gd, le_gd_font;
#if HAVE_LIBT1
#include
@@ -1293,8 +1302,13 @@ PHP_MINFO_FUNCTION(gd)
#endif
#ifdef HAVE_GD_JPG
{
+#if HAVE_GD_BUNDLED
char tmp[12];
snprintf(tmp, sizeof(tmp), "%d",
gdJpegGetVersionInt());
+#else
+ char tmp[256];
+ snprintf(tmp, sizeof(tmp), "%d", JPEG_LIB_VERSION);
+#endif
php_info_print_table_row(2, "JPG Support", "enabled");
php_info_print_table_row(2, "libJPEG Version", tmp);
}
@@ -1302,7 +1316,11 @@ PHP_MINFO_FUNCTION(gd)
#ifdef HAVE_GD_PNG
php_info_print_table_row(2, "PNG Support", "enabled");
+#if HAVE_GD_BUNDLED
php_info_print_table_row(2, "libPNG Version",
gdPngGetVersionString());
+#else
+ php_info_print_table_row(2, "libPNG Version",
PNG_LIBPNG_VER_STRING);
+#endif
#endif
#ifdef HAVE_GD_WBMP
php_info_print_table_row(2, "WBMP Support", "enabled");
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/47812
--
Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Asn]: undefined symbol: gdJpegGetVersionInt
ID: 47812
Updated by: paj...@php.net
Reported By: oeriksson at mandriva dot com
Status: Assigned
Bug Type: GD related
Operating System: Mandriva Linux
PHP Version: 5.3.0RC1
Assigned To: pajoye
New Comment:
You missed my point.
These distributions do not have updated libraries, or even worst for
debian, they break the compatibility with the normal GD.
I'm working to sync the external gd and php's gd so both can be used
smoothly, but I have serious doubts that Debian will change, for
example.
Previous Comments:
[2009-03-27 20:04:23] ras...@php.net
That argument completely falls apart if you do a bit of research on who
the upstream for the gd library is.
[2009-03-27 19:59:07] oeriksson at mandriva dot com
The PHP devs should try harder to not bundle common libraries and
instead push private changes upstream (IMHO).
[2009-03-27 19:49:27] paj...@php.net
You should really not use the system libgd, especially not on the
following systems:
- debian
- RHEL
- Centos
The problem still has to be fixed tho' :)
[2009-03-27 19:45:31] oeriksson at mandriva dot com
I described it in "Description:" :-)
Here's a proposed fix:
--- ext/gd/gd.c 2009-01-31 16:27:52.0 +0100
+++ ext/gd/gd.c.oden2009-03-27 20:27:14.0 +0100
@@ -55,6 +55,15 @@
#if HAVE_LIBGD
+#ifdef HAVE_GD_PNG
+/* needs to be first */
+# include
+#endif
+
+#ifdef HAVE_GD_JPG
+# include
+#endif
+
static int le_gd, le_gd_font;
#if HAVE_LIBT1
#include
@@ -1293,8 +1302,13 @@ PHP_MINFO_FUNCTION(gd)
#endif
#ifdef HAVE_GD_JPG
{
+#if HAVE_GD_BUNDLED
char tmp[12];
snprintf(tmp, sizeof(tmp), "%d",
gdJpegGetVersionInt());
+#else
+ char tmp[256];
+ snprintf(tmp, sizeof(tmp), "%d", JPEG_LIB_VERSION);
+#endif
php_info_print_table_row(2, "JPG Support", "enabled");
php_info_print_table_row(2, "libJPEG Version", tmp);
}
@@ -1302,7 +1316,11 @@ PHP_MINFO_FUNCTION(gd)
#ifdef HAVE_GD_PNG
php_info_print_table_row(2, "PNG Support", "enabled");
+#if HAVE_GD_BUNDLED
php_info_print_table_row(2, "libPNG Version",
gdPngGetVersionString());
+#else
+ php_info_print_table_row(2, "libPNG Version",
PNG_LIBPNG_VER_STRING);
+#endif
#endif
#ifdef HAVE_GD_WBMP
php_info_print_table_row(2, "WBMP Support", "enabled");
[2009-03-27 19:36:56] der...@php.net
Are you using the bundled libgd, or an external one?
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/47812
--
Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Asn]: undefined symbol: gdJpegGetVersionInt
ID: 47812
Updated by: ras...@php.net
Reported By: oeriksson at mandriva dot com
Status: Assigned
Bug Type: GD related
Operating System: Mandriva Linux
PHP Version: 5.3.0RC1
Assigned To: pajoye
New Comment:
That argument completely falls apart if you do a bit of research on who
the upstream for the gd library is.
Previous Comments:
[2009-03-27 19:59:07] oeriksson at mandriva dot com
The PHP devs should try harder to not bundle common libraries and
instead push private changes upstream (IMHO).
[2009-03-27 19:49:27] paj...@php.net
You should really not use the system libgd, especially not on the
following systems:
- debian
- RHEL
- Centos
The problem still has to be fixed tho' :)
[2009-03-27 19:45:31] oeriksson at mandriva dot com
I described it in "Description:" :-)
Here's a proposed fix:
--- ext/gd/gd.c 2009-01-31 16:27:52.0 +0100
+++ ext/gd/gd.c.oden2009-03-27 20:27:14.0 +0100
@@ -55,6 +55,15 @@
#if HAVE_LIBGD
+#ifdef HAVE_GD_PNG
+/* needs to be first */
+# include
+#endif
+
+#ifdef HAVE_GD_JPG
+# include
+#endif
+
static int le_gd, le_gd_font;
#if HAVE_LIBT1
#include
@@ -1293,8 +1302,13 @@ PHP_MINFO_FUNCTION(gd)
#endif
#ifdef HAVE_GD_JPG
{
+#if HAVE_GD_BUNDLED
char tmp[12];
snprintf(tmp, sizeof(tmp), "%d",
gdJpegGetVersionInt());
+#else
+ char tmp[256];
+ snprintf(tmp, sizeof(tmp), "%d", JPEG_LIB_VERSION);
+#endif
php_info_print_table_row(2, "JPG Support", "enabled");
php_info_print_table_row(2, "libJPEG Version", tmp);
}
@@ -1302,7 +1316,11 @@ PHP_MINFO_FUNCTION(gd)
#ifdef HAVE_GD_PNG
php_info_print_table_row(2, "PNG Support", "enabled");
+#if HAVE_GD_BUNDLED
php_info_print_table_row(2, "libPNG Version",
gdPngGetVersionString());
+#else
+ php_info_print_table_row(2, "libPNG Version",
PNG_LIBPNG_VER_STRING);
+#endif
#endif
#ifdef HAVE_GD_WBMP
php_info_print_table_row(2, "WBMP Support", "enabled");
[2009-03-27 19:36:56] der...@php.net
Are you using the bundled libgd, or an external one?
[2009-03-27 19:16:37] oeriksson at mandriva dot com
Description:
I get an unresolved symbol when linking against system libgd.
Reproduce code:
---
Just running php-cli
Expected result:
Should work.
Actual result:
--
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib64/php/extensions/gd.so' - /usr/lib64/php/extensions/gd.so:
undefined symbol: gdJpegGetVersionInt in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Com]: undefined symbol: gdJpegGetVersionInt
ID: 47812
Comment by: oeriksson at mandriva dot com
Reported By: oeriksson at mandriva dot com
Status: Assigned
Bug Type: GD related
Operating System: Mandriva Linux
PHP Version: 5.3.0RC1
Assigned To: pajoye
New Comment:
The PHP devs should try harder to not bundle common libraries and
instead push private changes upstream (IMHO).
Previous Comments:
[2009-03-27 19:49:27] paj...@php.net
You should really not use the system libgd, especially not on the
following systems:
- debian
- RHEL
- Centos
The problem still has to be fixed tho' :)
[2009-03-27 19:45:31] oeriksson at mandriva dot com
I described it in "Description:" :-)
Here's a proposed fix:
--- ext/gd/gd.c 2009-01-31 16:27:52.0 +0100
+++ ext/gd/gd.c.oden2009-03-27 20:27:14.0 +0100
@@ -55,6 +55,15 @@
#if HAVE_LIBGD
+#ifdef HAVE_GD_PNG
+/* needs to be first */
+# include
+#endif
+
+#ifdef HAVE_GD_JPG
+# include
+#endif
+
static int le_gd, le_gd_font;
#if HAVE_LIBT1
#include
@@ -1293,8 +1302,13 @@ PHP_MINFO_FUNCTION(gd)
#endif
#ifdef HAVE_GD_JPG
{
+#if HAVE_GD_BUNDLED
char tmp[12];
snprintf(tmp, sizeof(tmp), "%d",
gdJpegGetVersionInt());
+#else
+ char tmp[256];
+ snprintf(tmp, sizeof(tmp), "%d", JPEG_LIB_VERSION);
+#endif
php_info_print_table_row(2, "JPG Support", "enabled");
php_info_print_table_row(2, "libJPEG Version", tmp);
}
@@ -1302,7 +1316,11 @@ PHP_MINFO_FUNCTION(gd)
#ifdef HAVE_GD_PNG
php_info_print_table_row(2, "PNG Support", "enabled");
+#if HAVE_GD_BUNDLED
php_info_print_table_row(2, "libPNG Version",
gdPngGetVersionString());
+#else
+ php_info_print_table_row(2, "libPNG Version",
PNG_LIBPNG_VER_STRING);
+#endif
#endif
#ifdef HAVE_GD_WBMP
php_info_print_table_row(2, "WBMP Support", "enabled");
[2009-03-27 19:36:56] der...@php.net
Are you using the bundled libgd, or an external one?
[2009-03-27 19:16:37] oeriksson at mandriva dot com
Description:
I get an unresolved symbol when linking against system libgd.
Reproduce code:
---
Just running php-cli
Expected result:
Should work.
Actual result:
--
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib64/php/extensions/gd.so' - /usr/lib64/php/extensions/gd.so:
undefined symbol: gdJpegGetVersionInt in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Opn->Asn]: undefined symbol: gdJpegGetVersionInt
ID: 47812
Updated by: paj...@php.net
Reported By: oeriksson at mandriva dot com
-Status: Open
+Status: Assigned
Bug Type: GD related
Operating System: Mandriva Linux
PHP Version: 5.3.0RC1
-Assigned To:
+Assigned To: pajoye
New Comment:
You should really not use the system libgd, especially not on the
following systems:
- debian
- RHEL
- Centos
The problem still has to be fixed tho' :)
Previous Comments:
[2009-03-27 19:45:31] oeriksson at mandriva dot com
I described it in "Description:" :-)
Here's a proposed fix:
--- ext/gd/gd.c 2009-01-31 16:27:52.0 +0100
+++ ext/gd/gd.c.oden2009-03-27 20:27:14.0 +0100
@@ -55,6 +55,15 @@
#if HAVE_LIBGD
+#ifdef HAVE_GD_PNG
+/* needs to be first */
+# include
+#endif
+
+#ifdef HAVE_GD_JPG
+# include
+#endif
+
static int le_gd, le_gd_font;
#if HAVE_LIBT1
#include
@@ -1293,8 +1302,13 @@ PHP_MINFO_FUNCTION(gd)
#endif
#ifdef HAVE_GD_JPG
{
+#if HAVE_GD_BUNDLED
char tmp[12];
snprintf(tmp, sizeof(tmp), "%d",
gdJpegGetVersionInt());
+#else
+ char tmp[256];
+ snprintf(tmp, sizeof(tmp), "%d", JPEG_LIB_VERSION);
+#endif
php_info_print_table_row(2, "JPG Support", "enabled");
php_info_print_table_row(2, "libJPEG Version", tmp);
}
@@ -1302,7 +1316,11 @@ PHP_MINFO_FUNCTION(gd)
#ifdef HAVE_GD_PNG
php_info_print_table_row(2, "PNG Support", "enabled");
+#if HAVE_GD_BUNDLED
php_info_print_table_row(2, "libPNG Version",
gdPngGetVersionString());
+#else
+ php_info_print_table_row(2, "libPNG Version",
PNG_LIBPNG_VER_STRING);
+#endif
#endif
#ifdef HAVE_GD_WBMP
php_info_print_table_row(2, "WBMP Support", "enabled");
[2009-03-27 19:36:56] der...@php.net
Are you using the bundled libgd, or an external one?
[2009-03-27 19:16:37] oeriksson at mandriva dot com
Description:
I get an unresolved symbol when linking against system libgd.
Reproduce code:
---
Just running php-cli
Expected result:
Should work.
Actual result:
--
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib64/php/extensions/gd.so' - /usr/lib64/php/extensions/gd.so:
undefined symbol: gdJpegGetVersionInt in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Fbk->Opn]: undefined symbol: gdJpegGetVersionInt
ID: 47812
User updated by: oeriksson at mandriva dot com
Reported By: oeriksson at mandriva dot com
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Mandriva Linux
PHP Version: 5.3.0RC1
New Comment:
I described it in "Description:" :-)
Here's a proposed fix:
--- ext/gd/gd.c 2009-01-31 16:27:52.0 +0100
+++ ext/gd/gd.c.oden2009-03-27 20:27:14.0 +0100
@@ -55,6 +55,15 @@
#if HAVE_LIBGD
+#ifdef HAVE_GD_PNG
+/* needs to be first */
+# include
+#endif
+
+#ifdef HAVE_GD_JPG
+# include
+#endif
+
static int le_gd, le_gd_font;
#if HAVE_LIBT1
#include
@@ -1293,8 +1302,13 @@ PHP_MINFO_FUNCTION(gd)
#endif
#ifdef HAVE_GD_JPG
{
+#if HAVE_GD_BUNDLED
char tmp[12];
snprintf(tmp, sizeof(tmp), "%d",
gdJpegGetVersionInt());
+#else
+ char tmp[256];
+ snprintf(tmp, sizeof(tmp), "%d", JPEG_LIB_VERSION);
+#endif
php_info_print_table_row(2, "JPG Support", "enabled");
php_info_print_table_row(2, "libJPEG Version", tmp);
}
@@ -1302,7 +1316,11 @@ PHP_MINFO_FUNCTION(gd)
#ifdef HAVE_GD_PNG
php_info_print_table_row(2, "PNG Support", "enabled");
+#if HAVE_GD_BUNDLED
php_info_print_table_row(2, "libPNG Version",
gdPngGetVersionString());
+#else
+ php_info_print_table_row(2, "libPNG Version",
PNG_LIBPNG_VER_STRING);
+#endif
#endif
#ifdef HAVE_GD_WBMP
php_info_print_table_row(2, "WBMP Support", "enabled");
Previous Comments:
[2009-03-27 19:36:56] der...@php.net
Are you using the bundled libgd, or an external one?
[2009-03-27 19:16:37] oeriksson at mandriva dot com
Description:
I get an unresolved symbol when linking against system libgd.
Reproduce code:
---
Just running php-cli
Expected result:
Should work.
Actual result:
--
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib64/php/extensions/gd.so' - /usr/lib64/php/extensions/gd.so:
undefined symbol: gdJpegGetVersionInt in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [Opn->Fbk]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Updated by: der...@php.net Reported By: oeriksson at mandriva dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 New Comment: Are you using the bundled libgd, or an external one? Previous Comments: [2009-03-27 19:16:37] oeriksson at mandriva dot com Description: I get an unresolved symbol when linking against system libgd. Reproduce code: --- Just running php-cli Expected result: Should work. Actual result: -- PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/extensions/gd.so' - /usr/lib64/php/extensions/gd.so: undefined symbol: gdJpegGetVersionInt in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#47812 [NEW]: undefined symbol: gdJpegGetVersionInt
From: oeriksson at mandriva dot com Operating system: Mandriva Linux PHP version: 5.3.0RC1 PHP Bug Type: GD related Bug description: undefined symbol: gdJpegGetVersionInt Description: I get an unresolved symbol when linking against system libgd. Reproduce code: --- Just running php-cli Expected result: Should work. Actual result: -- PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/extensions/gd.so' - /usr/lib64/php/extensions/gd.so: undefined symbol: gdJpegGetVersionInt in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=47812&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47812&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47812&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47812&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47812&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47812&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47812&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47812&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47812&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47812&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47812&r=support Expected behavior: http://bugs.php.net/fix.php?id=47812&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47812&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47812&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47812&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47812&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47812&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47812&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47812&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47812&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47812&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47812&r=mysqlcfg
#47809 [Opn]: PHP doesn't parse the php.ini file
ID: 47809 User updated by: privat at timohummel dot com Reported By: privat at timohummel dot com Status: Open Bug Type: PHP options/info functions Operating System: Gentoo PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: I just ran apache with strace to make sure that the php.ini file is actually opened. It is opened, but I'm not sure how to debug if the values are getting parsed and probably overwritten later or if the values in the php.ini file are silently ignored. Previous Comments: [2009-03-27 16:11:27] privat at timohummel dot com I rebuilt PHP from the CVS, snapshot http://snaps.php.net/php5.3-200903271530.tar.bz2 (latest snapshot currently available). The issue remains, all php.ini-entries are ignored silently when using the apache2 SAPI. Oddly enough, the CLI SAPI works fine and reads the config file as expected. Here's my configure line: './configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64' '--disable-cli' '--with-apxs2=/usr/sbin/apxs2' '--disable-cgi' '--with-config-file-path=/etc/php/apache2-php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active' '--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar' '--with-curl' '--without-curlwrappers' '--disable-dbase' '--disable-exif' '--without-fbsql' '--disable-fileinfo' '--enable-ftp' '--with-gettext' '--with-gmp' '--disable-hash' '--without-kerberos' '--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql' '--without-mssql' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--with-pgsql' '--disable-posix' '--with-pspell' '--without-recode' '--disable-simplexml' '--disable-shmop' '--with-snmp' '--enable-soap' '--disable-sockets' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy' '--enable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--with-xmlrpc' '--with-xsl' '--enable-zip' '--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-gd' '--with-imap' '--with-imap-ssl' '--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=/usr/bin/mysql_config' '--without-pdo-dblib' '--with-pdo-mysql=/usr' '--without-pdo-odbc' '--with-pdo-pgsql' '--with-pdo-sqlite=/usr' '--with-readline' '--without-libedit' '--without-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8' '--with-sqlite3' [2009-03-27 15:06:54] paj...@php.net 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. [2009-03-27 15:02:57] privat at timohummel dot com Description: I just upgraded to PHP 5.3.0-rc1 using a custom ebuild. However, it seems that PHP does not parse (or silently ignore) changes done to the php.ini file. I copied the php.ini-development from the distribution to /etc/php/apache2-php5/php.ini. phpinfo() tells me that the loaded configuration file is /etc/php/apache2-php5/php.ini, in which I also did my changes. I wonder if that has something to do with the new development/production configurations. -- Edit this bug report at http://bugs.php.net/?id=47809&edit=1
#46015 [Com]: Build fails with system gd
ID: 46015
Comment by: tsteiner at nerdclub dot net
Reported By: Fedora at FamilleCollet dot com
Status: Assigned
Bug Type: GD related
Operating System: Linux (Fedora 9)
PHP Version: 5.3.0alpha2
Assigned To: pajoye
New Comment:
Here's a quick patch that removes support for building against an
external libgd and replaces it with an error message. It seems to work
as intended but I am by no means experienced with the autoconf system.
--- php-5.3.0RC1.orig/ext/gd/config.m4 2009-01-14
13:05:59.0 -0600
+++ php-5.3.0RC1/ext/gd/config.m4 2009-03-27 13:42:01.071603975
-0500
@@ -262,7 +262,6 @@
dnl
if test "$PHP_GD" = "yes"; then
- GD_MODULE_TYPE=builtin
extra_sources="libgd/gd.c libgd/gd_gd.c libgd/gd_gd2.c libgd/gd_io.c
libgd/gd_io_dp.c \
libgd/gd_io_file.c libgd/gd_ss.c libgd/gd_io_ss.c
libgd/gd_png.c libgd/gd_jpeg.c \
libgd/gdxpm.c libgd/gdfontt.c libgd/gdfonts.c
libgd/gdfontmb.c libgd/gdfontl.c \
@@ -339,57 +338,7 @@
else
if test "$PHP_GD" != "no"; then
- GD_MODULE_TYPE=external
- extra_sources="gdcache.c"
-
-dnl Various checks for GD features
- PHP_GD_ZLIB
- PHP_GD_TTSTR
- PHP_GD_JPEG
- PHP_GD_PNG
- PHP_GD_XPM
- PHP_GD_FREETYPE2
- PHP_GD_T1LIB
-
-dnl Header path
- for i in include/gd1.3 include/gd include gd1.3 gd ""; do
-test -f "$PHP_GD/$i/gd.h" && GD_INCLUDE="$PHP_GD/$i"
- done
-
-dnl Library path
- for i in $PHP_LIBDIR/gd1.3 $PHP_LIBDIR/gd $PHP_LIBDIR gd1.3 gd "";
do
-test -f "$PHP_GD/$i/libgd.$SHLIB_SUFFIX_NAME" || test -f
"$PHP_GD/$i/libgd.a" && GD_LIB="$PHP_GD/$i"
- done
-
- if test -n "$GD_INCLUDE" && test -n "$GD_LIB"; then
-PHP_ADD_LIBRARY_WITH_PATH(gd, $GD_LIB, GD_SHARED_LIBADD)
-AC_DEFINE(HAVE_LIBGD,1,[ ])
-PHP_GD_CHECK_VERSION
- elif test -z "$GD_INCLUDE"; then
-AC_MSG_ERROR([Unable to find gd.h anywhere under $PHP_GD])
- else
-AC_MSG_ERROR([Unable to find libgd.(a|so) anywhere under
$PHP_GD])
- fi
-
- PHP_EXPAND_PATH($GD_INCLUDE, GD_INCLUDE)
-
- dnl
- dnl Check for gd 2.0.4 greater availability
- dnl
- old_CPPFLAGS=$CPPFLAGS
- CPPFLAGS=-I$GD_INCLUDE
- AC_TRY_COMPILE([
-#include
-#include
- ], [
-gdIOCtx *ctx;
-ctx = malloc(sizeof(gdIOCtx));
-ctx->gd_free = 1;
- ], [
-AC_DEFINE(HAVE_LIBGD204, 1, [ ])
- ])
- CPPFLAGS=$old_CPPFLAGS
-
+ AC_MSG_ERROR([Building the GD extension against an external libgd is
not supported.])
fi
fi
@@ -399,23 +348,13 @@
if test "$PHP_GD" != "no"; then
PHP_NEW_EXTENSION(gd, gd.c $extra_sources, $ext_shared,,
\\$(GDLIB_CFLAGS))
- if test "$GD_MODULE_TYPE" = "builtin"; then
-GDLIB_CFLAGS="-I$ext_srcdir/libgd $GDLIB_CFLAGS"
-PHP_ADD_BUILD_DIR($ext_builddir/libgd)
-GD_HEADER_DIRS="ext/gd/ ext/gd/libgd/"
-
-PHP_TEST_BUILD(foobar, [], [
- AC_MSG_ERROR([GD build test failed. Please check the config.log
for details.])
-], [ $GD_SHARED_LIBADD ], [char foobar () {}])
- else
-GD_HEADER_DIRS="ext/gd/"
-GDLIB_CFLAGS="-I$GD_INCLUDE $GDLIB_CFLAGS"
-PHP_ADD_INCLUDE($GD_INCLUDE)
-
-PHP_CHECK_LIBRARY(gd, gdImageCreate, [], [
- AC_MSG_ERROR([GD build test failed. Please check the config.log
for details.])
-], [ -L$GD_LIB $GD_SHARED_LIBADD ])
- fi
+ GDLIB_CFLAGS="-I$ext_srcdir/libgd $GDLIB_CFLAGS"
+ PHP_ADD_BUILD_DIR($ext_builddir/libgd)
+ GD_HEADER_DIRS="ext/gd/ ext/gd/libgd/"
+
+ PHP_TEST_BUILD(foobar, [], [
+AC_MSG_ERROR([GD build test failed. Please check the config.log
for details.])
+ ], [ $GD_SHARED_LIBADD ], [char foobar () {}])
PHP_INSTALL_HEADERS([$GD_HEADER_DIRS])
PHP_SUBST(GDLIB_CFLAGS)
Previous Comments:
[2009-03-27 18:03:22] tsteiner at nerdclub dot net
This is still an issue in 5.3.0RC1. If building against an external
version of GD is no longer supported, the configure script should
probably be updated to throw an error or at least a warning should one
try to do so. Currently, the build just fails during "make" with the
error:
ext/gd/gd.c:72:23: error: gdhelpers.h: No such file or directory
leaving the user with no idea what to do.
[2008-12-05 18:53:05] php-bugs-2008 at ryandesign dot com
Thanks for letting us know why specifically the bundled libgd is
superior (the imagefilter and imagerotate functions). Given this, I will
switch MacPorts php5 back to using the bundled libgd.
You must admit however there is room for confusion. The first sentence
on the installation instructions [1] says "If you have the GD library
(available at » http://www.libgd.org/) you will also be able to create
and manipulate images." And the libgd homepage in turn says "The library
[...] is now maintained by Pierre-A. Joye under the umbrella of
PHP.net." This gives the impression that the standalone libgd is being
developed by the same people who develop PHP's bundled libgd. The
#46015 [Com]: Build fails with system gd
ID: 46015 Comment by: tsteiner at nerdclub dot net Reported By: Fedora at FamilleCollet dot com Status: Assigned Bug Type: GD related Operating System: Linux (Fedora 9) PHP Version: 5.3.0alpha2 Assigned To: pajoye New Comment: This is still an issue in 5.3.0RC1. If building against an external version of GD is no longer supported, the configure script should probably be updated to throw an error or at least a warning should one try to do so. Currently, the build just fails during "make" with the error: ext/gd/gd.c:72:23: error: gdhelpers.h: No such file or directory leaving the user with no idea what to do. Previous Comments: [2008-12-05 18:53:05] php-bugs-2008 at ryandesign dot com Thanks for letting us know why specifically the bundled libgd is superior (the imagefilter and imagerotate functions). Given this, I will switch MacPorts php5 back to using the bundled libgd. You must admit however there is room for confusion. The first sentence on the installation instructions [1] says "If you have the GD library (available at » http://www.libgd.org/) you will also be able to create and manipulate images." And the libgd homepage in turn says "The library [...] is now maintained by Pierre-A. Joye under the umbrella of PHP.net." This gives the impression that the standalone libgd is being developed by the same people who develop PHP's bundled libgd. The note further down the installation instructions reads "Since PHP 4.3 there is a bundled version of the GD lib [which] should be used in preference to the external library since its codebase is better maintained and more stable." Because PHP 4.3 is so old, someone reading this note might well assume the information is outdated, and that since libgd is now under PHP.net's umbrella, the unique changes in PHP's bundled libgd are now in the standalone libgd as well. php5 has supported standalone libgd, up to and including php 5.3.0 alpha 1. So it would be good if php 5.3.0 final did not break this. Or, if it is your intention to break this, then do so with a friendlier message in the configure phase and update the documentation. [1] http://www.php.net/manual/en/image.setup.php [2008-12-05 09:13:40] paj...@php.net The bundled GD is the recommend version anyway. It has more bug fixes and features than almost all GD distributions out there (the worst is debian's gd which should not be used at all). Functions like imagefilter, imagerotate are not available when an external GD is used. php6 may support external GD but only a recent version and only when a minimum set of features are enabled. [2008-12-05 08:56:05] karsten at typo3 dot org I had the same issue yesterday and switched to the bundled GD to make it compile. Now, it would be interesting to know what functionality difference this means and what the other issue is, this is related to. [2008-09-08 10:57:48] paj...@php.net This patch is not correct as then the function defined in gdhelper.h will not be defined and the default signature will be used. please do not apply it, I will fix the issue while working on another similar issue in gd. [2008-09-08 10:26:57] spher...@php.net Had the same problem and came up with similar fix. Would someone apply this patch to CVS? My karma is not sufficient. 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/46015 -- Edit this bug report at http://bugs.php.net/?id=46015&edit=1
#42685 [Com]: imagefilledellipse wrong size
ID: 42685 Comment by: andrew at ameshome dot ca Reported By: chinhnt2k3 at yahoo dot com Status: No Feedback Bug Type: GD related Operating System: * PHP Version: 5.2.4 Assigned To: pajoye New Comment: I can confirm this still occurs in PPH 5.2.9-1 An elipse with an even size is rounded to an odd size Previous Comments: [2008-11-10 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-11-02 13:04:02] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-05-06 11:28:31] ka...@php.net The same effect occurs for the imageellipse(), I belive this bug is in libgd [2007-09-17 04:41:13] chinhnt2k3 at yahoo dot com Description: imagefilledellipse() produces an ellipse with a different size if the size is even. Reproduce code: --- Expected result: An ellipse with the size of 26. Actual result: -- An ellipse with the size of 27. -- Edit this bug report at http://bugs.php.net/?id=42685&edit=1
#47811 [NEW]: preg_match that can cause segmentation fault
From: travis at wikihow dot com
Operating system: CentOS release 4.4 & Mac OS 10.4
PHP version: 5.2.9
PHP Bug Type: Reproducible crash
Bug description: preg_match that can cause segmentation fault
Description:
Run a preg_match with source text attached and get a seg fault. Apache 2.2
/ PHP 5.2.9 and PHP 5.2.4.
preg_match('@@im', $text, $matches);
Reproduce code:
---
http://wikidiy.com/php_bug_crash.txt
Expected result:
Apache not supposed to crash, completes preg_match, dumps $matches array.
Actual result:
--
Apache seg faults
[Fri Mar 27 12:16:05 2009] [notice] child pid 6391 exit signal
Segmentation fault (11)
--
Edit bug report at http://bugs.php.net/?id=47811&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47811&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47811&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47811&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47811&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47811&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47811&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47811&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47811&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47811&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47811&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47811&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47811&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47811&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47811&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47811&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47811&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47811&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47811&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47811&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47811&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47811&r=mysqlcfg
#47799 [Opn->Fbk]: Segfault with Regex
ID: 47799
Updated by: fel...@php.net
Reported By: mb at insidetheweb dot de
-Status: Open
+Status: Feedback
Bug Type:PCRE related
PHP Version: 5.2.9
New Comment:
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.
Previous Comments:
[2009-03-27 01:09:11] mb at insidetheweb dot de
Description:
When i do this Regex
#^\{\|(.*?)(?:^\|\+(.*?))?(^(?:((?R))|.)*?)^\|}#msi
on larger requests, it causes a seqfault.
You just need to be some chars above some kind of limit and you got the
error.
Reproduce code:
---
http://cvs.php.net/viewvc.cgi/pear/Text_Wiki/Text/Wiki/Parse/Mediawiki/Table.php?revision=1.11&view=markup
Its Text_Wiki_Mediawiki.
Expected result:
HTTPD Seqfault
--
Edit this bug report at http://bugs.php.net/?id=47799&edit=1
#47809 [Csd->Opn]: PHP doesn't parse the php.ini file
ID: 47809 User updated by: privat at timohummel dot com Reported By: privat at timohummel dot com -Status: Closed +Status: Open Bug Type: PHP options/info functions Operating System: Gentoo PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: I rebuilt PHP from the CVS, snapshot http://snaps.php.net/php5.3-200903271530.tar.bz2 (latest snapshot currently available). The issue remains, all php.ini-entries are ignored silently when using the apache2 SAPI. Oddly enough, the CLI SAPI works fine and reads the config file as expected. Here's my configure line: './configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64' '--disable-cli' '--with-apxs2=/usr/sbin/apxs2' '--disable-cgi' '--with-config-file-path=/etc/php/apache2-php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active' '--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar' '--with-curl' '--without-curlwrappers' '--disable-dbase' '--disable-exif' '--without-fbsql' '--disable-fileinfo' '--enable-ftp' '--with-gettext' '--with-gmp' '--disable-hash' '--without-kerberos' '--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql' '--without-mssql' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--with-pgsql' '--disable-posix' '--with-pspell' '--without-recode' '--disable-simplexml' '--disable-shmop' '--with-snmp' '--enable-soap' '--disable-sockets' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy' '--enable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--with-xmlrpc' '--with-xsl' '--enable-zip' '--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-gd' '--with-imap' '--with-imap-ssl' '--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=/usr/bin/mysql_config' '--without-pdo-dblib' '--with-pdo-mysql=/usr' '--without-pdo-odbc' '--with-pdo-pgsql' '--with-pdo-sqlite=/usr' '--with-readline' '--without-libedit' '--without-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8' '--with-sqlite3' Previous Comments: [2009-03-27 15:06:54] paj...@php.net 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. [2009-03-27 15:02:57] privat at timohummel dot com Description: I just upgraded to PHP 5.3.0-rc1 using a custom ebuild. However, it seems that PHP does not parse (or silently ignore) changes done to the php.ini file. I copied the php.ini-development from the distribution to /etc/php/apache2-php5/php.ini. phpinfo() tells me that the loaded configuration file is /etc/php/apache2-php5/php.ini, in which I also did my changes. I wonder if that has something to do with the new development/production configurations. -- Edit this bug report at http://bugs.php.net/?id=47809&edit=1
#47810 [NEW]: SoapClient and Multipart response
From: opi at gmx dot at Operating system: Linux PHP version: 5.2.9 PHP Bug Type: SOAP related Bug description: SoapClient and Multipart response Description: SoapClient doesn't understand Multipart response from Server. Instead the full buffer is sent to the xml function. Reproduce code: --- No Free Test WebServer available. Expected result: Method to get the Multiparts. Actual result: -- SoapFault exception: [Client] looks like we got no XML document in ... -- Edit bug report at http://bugs.php.net/?id=47810&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47810&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47810&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47810&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47810&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47810&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47810&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47810&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47810&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47810&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47810&r=support Expected behavior: http://bugs.php.net/fix.php?id=47810&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47810&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47810&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47810&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47810&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47810&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47810&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47810&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47810&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47810&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47810&r=mysqlcfg
#47809 [Opn->Csd]: PHP doesn't parse the php.ini file
ID: 47809 Updated by: paj...@php.net Reported By: privat at timohummel dot com -Status: Open +Status: Closed Bug Type: PHP options/info functions Operating System: Gentoo PHP Version: 5.3.0RC1 -Assigned To: +Assigned To: pajoye 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: [2009-03-27 15:02:57] privat at timohummel dot com Description: I just upgraded to PHP 5.3.0-rc1 using a custom ebuild. However, it seems that PHP does not parse (or silently ignore) changes done to the php.ini file. I copied the php.ini-development from the distribution to /etc/php/apache2-php5/php.ini. phpinfo() tells me that the loaded configuration file is /etc/php/apache2-php5/php.ini, in which I also did my changes. I wonder if that has something to do with the new development/production configurations. -- Edit this bug report at http://bugs.php.net/?id=47809&edit=1
#47809 [NEW]: PHP doesn't parse the php.ini file
From: privat at timohummel dot com Operating system: Gentoo PHP version: 5.3.0RC1 PHP Bug Type: PHP options/info functions Bug description: PHP doesn't parse the php.ini file Description: I just upgraded to PHP 5.3.0-rc1 using a custom ebuild. However, it seems that PHP does not parse (or silently ignore) changes done to the php.ini file. I copied the php.ini-development from the distribution to /etc/php/apache2-php5/php.ini. phpinfo() tells me that the loaded configuration file is /etc/php/apache2-php5/php.ini, in which I also did my changes. I wonder if that has something to do with the new development/production configurations. -- Edit bug report at http://bugs.php.net/?id=47809&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47809&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47809&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47809&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47809&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47809&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47809&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47809&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47809&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47809&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47809&r=support Expected behavior: http://bugs.php.net/fix.php?id=47809&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47809&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47809&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47809&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47809&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47809&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47809&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47809&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47809&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47809&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47809&r=mysqlcfg
#47808 [NEW]: hasProperty inconsistent with getProperty and new ReflectionProperty
From: sven dot arduwie at gmail dot com
Operating system: win xp pro sp3
PHP version: 5.3.0RC1
PHP Bug Type: Reflection related
Bug description: hasProperty inconsistent with getProperty and new
ReflectionProperty
Description:
In the reproduce code hasProperty() in Base::__get() returns true while
getProperty() throws an exception with message "Fatal error: Uncaught
exception 'ReflectionException' with message 'Property test does not
exist'"
A more appropriate message would be "Fatal error: Uncaught exception
'ReflectionException' with message 'Cannot access non-public member
Child::test'", OR, and perhaps this would be best, change the behavior of
hasProperty() to return false.
The current behavior is really annoying if you're, like me, trying to
write a __get() method that returns the value of private/protected
properties using 'getters', e.g.: getMyProperty() for property $myProperty.
Reproduce code:
---
hasProperty($property)) {
return $reflector->getProperty($property)->getValue();
}
}
}
class Child extends Base {
private $test = 'This is a test.';
}
class Test extends Child {
}
$test = new Test;
var_dump($test->test);
Expected result:
getProperty() to throw "Fatal error: Uncaught exception
'ReflectionException' with message 'Cannot access non-public member
Child::test'"
or
hasProperty() to return false
Actual result:
--
hasProperty() returns true while getProperty() throws a message with an
inappropriate message
--
Edit bug report at http://bugs.php.net/?id=47808&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47808&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47808&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47808&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47808&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47808&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47808&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47808&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47808&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47808&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47808&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47808&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47808&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47808&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47808&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47808&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47808&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47808&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47808&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47808&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47808&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47808&r=mysqlcfg
#47806 [NEW]: mktime should return -1 or false on invalid args, but returns 943912800
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: mktime should return -1 or false on invalid args, but returns 943912800 Description: http://php.net/mktime "mktime() returns the Unix timestamp of the arguments given. If the arguments are invalid, the function returns FALSE (before PHP 5.1 it returned -1)." but it returns "Tue Nov 30 00:00:00 1999 +0200" instead when invalid input like null (or undefined) is used: php -r 'echo mktime(0, 0, 0, null, null, null), "\n";' 943912800 ok, i understand if all params are 0, then it would make sense: "The number of the year, may be a two or four digit value, with values between 0-69 mapping to 2000-2069 and 70-100 to 1970-2000. On systems where time_t is a 32bit signed integer, as most common today, the valid range for year is somewhere between 1901 and 2038. However, before PHP 5.1.0 this range was limited from 1970 to 2038 on some systems (e.g. Windows)." Year as 0 is 2000, Month 0 is calculated as 12 of the last year, thus it gets December and 0 December is 30 November please make using undefined variables and nulls being invalid input (so that you must cast to int, to treat empty input as 0): php -r 'echo mktime(0, 0, 0, (int )$_GET['day'], (int )$_GET['month'], (int )$_GET['year']), "\n";' -- Edit bug report at http://bugs.php.net/?id=47806&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47806&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47806&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47806&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47806&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47806&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47806&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47806&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47806&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47806&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47806&r=support Expected behavior: http://bugs.php.net/fix.php?id=47806&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47806&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47806&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47806&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47806&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47806&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47806&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47806&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47806&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47806&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47806&r=mysqlcfg
#15373 [Com]: mail() not working, no error with invalid SMTP or email address
ID: 15373
Comment by: real_ganesh at yahoo dot co dot in
Reported By: alonso at admintek dot net
Status: No Feedback
Bug Type: Mail related
Operating System: win2000
PHP Version: 4.2.1
Assigned To: mfischer
New Comment:
Am php to send E-mail,but will be Error.
Failed to connect to mailserver at "localhost" port 25, verify your
"SMTP" and "smtp_port" setting in php.ini or use ini_set() in
-code
Contact.html
---
Cultuzz Digital Media GmbH - Contact
Contact Us
Enter your To
Address:
E-mail your From
Address:
Enter your
Password:
Enter your
Subject:
Enter your
Content:
-
mailto.php
--
: $toAddr ";
echo "This is From--->: $fromAddr ";
echo "This is Password--->: $toPass ";
echo "This is Subject--->: $subject ";
echo "This is Content--->: $content ";
echo "This is Headers--->: $headers ";
?>
Previous Comments:
[2009-03-19 00:47:46] rmsadik dot ece at gmail dot com
i have problem sending email using mail(). it was working couple of
weeks before but now on its not working ...i dont know whats the problem
and here is the code
if ($db_result) {
echo "Successful";
$to = $email;
$from = "msa...@gmail.com";
$subject = "Password Request From";
$message = "PLEASE DO NOT REPLY TO THIS EMAIL\n\n";
$message .= "unless others can read your email.\n\n\n";
$message .= "Password: ".$password;
$headers = "From: ".$from;
// Set the name of the server for mail processing. This should
be
handled at the server level but the following
// statement allows dynamic setting of the SMPT server for
testing
purposes.
ini_set("SMTP","mail.sunet.com.au");
// Attempt to send the mail message.
//$db_result = mail($to,$subject,$message,$headers);
mail($to,$subject,$message,$headers);
}
[2008-11-25 17:17:49] jeff at jouster dot org
I have this same problem.
I have Windows Server 2003 SP2 IIS 6. PHP6-dev (also same problem with
5.4)
Port 25 is open and I can telnet to the server from my home machine
completely outside the network and manually send an email. So I know
that SMTP is not the problem and relaying is not a problem.
Here's my script:
");
echo ($success);
if ($success)
{
echo (" success!");
}
else
{
echo (" problem...");
}
?>
When I run this test script I see:
1 success!
However I never get an email. I have php.ini set to log errors (have
also tried display errors) and there is never any errors logged or
displayed.
php.ini SMTP section:
[mail function]
; For Win32 only.
SMTP = localhost
smtp_port = 25
; For Win32 only.
sendmail_from = m...@address.tld
phpinfo() shows all of this information properly (only after I moved
the .ini file into the PHP install directory.
I have PHPRC environment variable set to PHP install directory and have
added same directory to my PATH env var.
Mail was successfully being sent until another issue caused me to
uninstall and reinstall the SMTP Service portion of IIS.
I see no solutions or cause to this problem in this thread. Any new
news? Original issue was posted 6 years ago... I can't believe this is
still cropping up for people.
[2008-07-10 15:47:04] phpseven at yahoo dot com
smtp server can't run. i tried my best to solve it but it can't send
the mail.
#47805 [NEW]: integer overflows it is converted to double but it is not done in vice versa.
From: vivekanandan8 at yahoo dot com
Operating system: Debian
PHP version: 5.2CVS-2009-03-27 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: integer overflows it is converted to double but it is not
done in vice versa.
Description:
when the integer overflows it is converted to double but it is not done in
vice versa.
Hence i fell:
it is not done from double to long.
Hence in the function increment_function(zend_operators.c)
we have to add the validation as follows
case IS_DOUBLE:
if(op1->value.dval == LONG_MIN) {
op1->value.lval = (long) op1->value.dval+1;
op1->type = IS_LONG;
}else{
op1->value.dval = op1->value.dval + 1;
}
Reproduce code:
---
Expected result:
int(-2147483647) int(-2147483648) float(-2147483649) int(-2147483648)
int(-2147483647)
Actual result:
--
int(-2147483647) int(-2147483648) float(-2147483649) float(-2147483648)
float(-2147483647)
--
Edit bug report at http://bugs.php.net/?id=47805&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47805&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47805&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47805&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47805&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47805&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47805&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47805&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47805&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47805&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47805&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47805&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47805&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47805&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47805&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47805&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47805&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47805&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47805&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47805&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47805&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47805&r=mysqlcfg
#46479 [Com]: virtual() prints output to browser
ID: 46479 Comment by: macke at meteli dot net Reported By: rosenfield dot albert at gmail dot com Status: Feedback Bug Type: Apache2 related Operating System: win32 PHP Version: 5.2CVS-2008-11-01 New Comment: Since I really need this functionality (to create a intelligent proxy solution using PHP and Apache) I made a desperate try to work around the problem by modifying php source directly. I don't know if this is the right place for the ramblings of clueless php coders but here are my findings: - latest snapshots of 5.2/5.3/6.0 all have the same issue (by looking at the code). - sorry, the relevant file for apache2 is not /sapi/php_apache.c but sapi/apache2handler/php_functions.c I tried commenting out these rows (98-104): php_end_ob_buffers(1 TSRMLS_CC); php_header(TSRMLS_C); ap_rflush(rr->main); and something changes but the headers are still sent from php somewhere else and now the Content-type: header will always become application/x-httpd-php. Here are some additional information: http://issues.apache.org/bugzilla/show_bug.cgi?id=17629 Previous Comments: [2009-03-26 21:53:29] macke at meteli dot net Newest 5.2 snapshot has the same problem. Lines 334-335 in /sapi/php_apache.c are the same as before: php_end_ob_buffers(1 TSRMLS_CC); php_header(TSRMLS_C); Is the solution as simple as removing those two lines or are there other implications? If so, could we at least add a new parameter to virtual() that disables those two? It would be backward compatible also. [2009-03-21 23:18:37] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-11-05 11:37:25] rosenfield dot albert at gmail dot com Did not realize the Apache version was relevant, sorry. I've experienced the problem on more than one server, some of them that I administrate (some not). Given that virtual() is one of the more 'professional tools' in the PHP 'toolbox', it is probably not used much overall by developers, so I doubt that the code behind had changed and just marked it as being in the "newest version". Sorry about that! A server with the newest Apache/PHP combo installed, which also has a filter installed where this is a problem is www.heidisql.com - a GET on port 80 will retrieve the version numbers (via the Server: header): Apache/2.2.9 (win32) PHP/5.2.7RC3-dev (win32) [2008-11-04 22:30:09] j...@php.net Since you failed to give the actual Apache version (and I doubt you're using 5.3 either) I'm assuming you have apache 2 something. Please update that information. Also, give the exact PHP version. [2008-11-04 13:39:29] rosenfield dot albert at gmail dot com Description: When execution is redirected with virtual(), before the Apache sub-request is carried out, PHP prints headers and document contents. The document contents are never a practical problem, because you never have any - you're in the act of redirecting the request. The headers however ARE a problem. PHP generates some headers itself, and these are then sent to the browser. Whoops, there we go - now the new/real destination of the request is unable to, for example, set it's own Content-Type header. Or anything else, because PHP has already printed something completely unrelated to the contents the actual document is going to contain. It could seem that the idea was to implement something akin to with a "virtual" keyword on it (often used in IIS for ASP), but currently php's virtual() does not work like that. Nobody uses it for this purpose, rather developers use include() and require() (often with __FILE__ or similar to hit a relative directory) because these do not flush headers. Where virtual() is really useful is in it's ability to perform Apache sub-requests. With this, and a simple Apache RewriteRule, any request can be re-routed to a PHP script (effectively a filter), and then routed back to the original destination after processing with virtual(). (This is an extremely convenient way to implement modular functionality in web applications, for example a security filter written in PHP.) As is currently, a significant number of hacks are required to work around the fact that virtual() prints headers before redirection. I personally have about a hundred lines of code that does nothing but try and predict which Content-Type the destination generates and try to coerce PHP into printing that instead, when it would have been much more practical if PHP just had discarded it's buffers in the firs
#47804 [Opn->Bgs]: hm
ID: 47804 Updated by: paj...@php.net Reported By: karni at world-of-requiem dot de -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: win xp Servicepack 3 PHP Version: 5.3CVS-2009-03-27 (snap) New Comment: There is no bug and the error message is clear. Set a TZ in your php.ini. Previous Comments: [2009-03-27 10:15:15] karni at world-of-requiem dot de Description: Warnin on display phpinfo(); date Warning: phpinfo() [function.phpinfo]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Paris' for '1.0/no DST' instead in D:\Programmierung\xampp\htdocs\phpinfo.php on line 2 Reproduce code: --- Expected result: see description -- Edit this bug report at http://bugs.php.net/?id=47804&edit=1
#47804 [NEW]: hm
From: karni at world-of-requiem dot de Operating system: win xp Servicepack 3 PHP version: 5.3CVS-2009-03-27 (snap) PHP Bug Type: *General Issues Bug description: hm Description: Warnin on display phpinfo(); date Warning: phpinfo() [function.phpinfo]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Paris' for '1.0/no DST' instead in D:\Programmierung\xampp\htdocs\phpinfo.php on line 2 Reproduce code: --- Expected result: see description -- Edit bug report at http://bugs.php.net/?id=47804&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47804&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47804&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47804&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47804&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47804&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47804&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47804&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47804&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47804&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47804&r=support Expected behavior: http://bugs.php.net/fix.php?id=47804&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47804&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47804&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47804&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47804&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47804&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47804&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47804&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47804&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47804&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47804&r=mysqlcfg
#47803 [NEW]: Executing prepared statements is succesfull only for the first two statements
From: egil at wp dot pl Operating system: Windows XP SP 3 PHP version: 5.2.9 PHP Bug Type: ODBC related Bug description: Executing prepared statements is succesfull only for the first two statements Description: I do odbc_prepare and then I would like to be able to execute this statement with different paramas. This is what it is for, right? Fortunately not after 2 odbc_execute calls third call gives (mssql 2005 as you may see): [Microsoft][SQL Native Client]Invalid character value for cast specification Reproduce code: --- Expected result: successful execution (note that it works fine if I move prepare to foreach block) Actual result: -- After third execution I get an error: [Microsoft][SQL Native Client]Invalid character value for cast specification -- Edit bug report at http://bugs.php.net/?id=47803&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47803&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47803&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47803&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47803&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47803&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47803&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47803&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47803&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47803&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47803&r=support Expected behavior: http://bugs.php.net/fix.php?id=47803&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47803&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47803&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47803&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47803&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47803&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47803&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47803&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47803&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47803&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47803&r=mysqlcfg
#47802 [NEW]: PDO_MYSQL doesn't use the charset parameter
From: disbursement at dublin dot com
Operating system: all
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: PDO_MYSQL doesn't use the charset parameter
Description:
static int pdo_mysql_handle_factory(pdo_dbh_t *dbh, zval *driver_options
TSRMLS_DC) /* {{{ */
{
...
struct pdo_data_src_parser vars[] = {
{ "charset", NULL, 0 },
{ "dbname", "", 0 },
{ "host", "localhost",0 },
{ "port", "3306", 0 },
{ "unix_socket", PDO_MYSQL_UNIX_ADDR, 0 },
};
The option "charset"/vars[0] is never used, but would be a nice feature.
--
Edit bug report at http://bugs.php.net/?id=47802&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47802&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47802&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47802&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47802&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47802&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47802&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47802&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47802&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47802&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47802&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47802&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47802&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47802&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47802&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47802&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47802&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47802&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47802&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47802&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47802&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47802&r=mysqlcfg
