date:20081211

#46830 [Opn->Bgs]: unexpected termination

2008-12-11 Thread ncross42 at cyworld dot com

 ID:   46830
 User updated by:  ncross42 at cyworld dot com
 Reported By:  ncross42 at cyworld dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Ubuntu-8.04.1-server
 PHP Version:  5.2.8
 New Comment:

I have a reply from Apach maintainer.

"The php manual has comments saying sleep() wakes up when you receive
any signal
(like the traditional C library call documents, man 3 sleep)

Termination due to MaxRequestsPerchild is implemented via a signal."

So, this is not a bug. :)


Previous Comments:


[2008-12-11 04:24:49] ncross42 at cyworld dot com

sorry again.
There is wrong expected results.
-=-= result page of 1.php =-=-
1
11:12:47
11:12:49  <- this is bug results.
-=-= result page of 2.php =-=-
2
11:12:49
11:12:49


-=-= result page of 1.php =-=-
1
11:12:47
11:12:57  <- I expected like this!! (sleeping 10 sec)
-=-= result page of 2.php =-=-
2
11:12:57  <- this value is meaningless
11:12:57  <- but for fast refresh.



[2008-12-11 03:06:21] ncross42 at cyworld dot com

sorry, i don't submitted Actual results.
here is Actual results.
-=-= result page of 1.php =-=-
1
11:49:00
11:49:02
-=-= result page of 2.php =-=-
2
11:49:02
11:49:02



[2008-12-11 02:57:57] ncross42 at cyworld dot com

Description:

This bug is a apache-thread related php excution bug.

This bug is repeatable and clear.

1. System setting.
 a. apache-2.2.10 : mpm=worker and using shared modules.
-=-=-= httpd.conf =-=-=-
for simple test, values are low.

StartServers1
MinSpareThreads 2
MaxSpareThreads 4
ThreadsPerChild 2   # <- this is important.
MaxRequestsPerChild 5   # <- this is important.


 b. PHP-5.2.8 : using apxs2 and enable-maintainer-zts for threadsafe
(no external cache like APC or XCache)


Reproduce code:
---
-=-= code of 1.php =-=-
';

 echo date("H:i:s").'';
sleep(10);
 echo date("H:i:s").'';
?>

-=-= code of 2.php =-=-
';

 echo date("H:i:s").'';
 echo date("H:i:s").'';
?>


Expected result:



 (a) browse 1.php and 2.php . result are not
problem.
-=-= result page of 1.php =-=-
1
11:04:29
11:04:39
-=-= result page of 2.php =-=-
2
11:04:30
11:04:30

 (b) I expected ...
  - browse 1.php and 2.php
  - refresh 2.php over 10 times very fast within 10 sec. (yes, using
F5)
  - I expected below normal resuluts.
-=-= result page of 1.php =-=-
1
11:12:47
11:12:49
-=-= result page of 2.php =-=-
2
11:12:49
11:12:49

Actual result:
--


 (a) initial apache process is here
Shell> ps ax | grep httpd
 5697 ?Ss 0:00 /skcomms/apache/bin/httpd -k restart
 5964 ?Sl 0:00 /skcomms/apache/bin/httpd -k restart
  - becuase below apache setting

StartServers1
MinSpareThreads 2
ThreadsPerChild 2
...


 (b) suppose
  - in (a) action, two connection is established with process 5964
  - in (b) action, new 1.php is sleeping in 5964 and 2.php is excuted
in other new process because below reason.

...
ThreadsPerChild 2
MaxRequestsPerChild 5


 (c) expected in 1.php excution time (within 10 sec)
 5697 ?Ss 0:00 /skcomms/apache/bin/httpd -k restart
 5964 ?Sl 0:00 /skcomms/apache/bin/httpd -k restart (1.php
is sleeping here)
 597x ?Sl 0:00 /skcomms/apache/bin/httpd -k restart (2.php
is browsed here)

 (d) but actually 5964 is terminated early in 2 seconds.
 5697 ?Ss 0:00 /skcomms/apache/bin/httpd -k restart
 5991 ?Sl 0:00 /skcomms/apache/bin/httpd -k restart






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

#46803 [Com]: Sqlite-PDO prepared statement doesn't return any rows when used with bind vars

2008-12-11 Thread nasubi at pako dot ne dot jp

 ID:   46803
 Comment by:   nasubi at pako dot ne dot jp
 Reported By:  scaligo at pt dot lu
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux x86_64
 PHP Version:  5.2.7
 New Comment:

pdo_mysql has same problem on php-5.2.8 (x86_64)


Previous Comments:


[2008-12-08 20:45:04] scaligo at pt dot lu

Description:

A PDO prepared statement doesn't return any results for a given query
performed with bind variables, but works fine when used without. A same
value is used twice and the workaround for WONTFIX #33886 has been
applied.

The initial query (with bind variables) returns the expected results in
another environment (Ruby/SQLite3).

Reproduced on vanilla 5.2.7 and 5.3.0 alpha 3, x86_64.

Compile flags (5.2.7):
./configure \
--enable-debug \
--enable-cli \
--disable-cgi \
--disable-all \
--enable-pdo \
--with-pdo-sqlite \
--enable-sqlite-utf8


Reproduce code:
---
Test case:
http://nopaste.ch/855d0d151ef8216.html

Query:
SELECT u.login, c.code
FROM codes c, users u
WHERE u.id = c.user_id
AND substr(c.code, 1, min(length(c.code), :LEN1)) = substr(:CODE, 1,
min(length(c.code), :LEN2))

Binds:
$statement->bindValue(':CODE', '111-222-', PDO::PARAM_STR);
$statement->bindValue(':LEN1', 8, PDO::PARAM_INT);
$statement->bindValue(':LEN2', 8, PDO::PARAM_INT);


Expected result:

The query should find the same rows with and without using bind
variables.

Actual result:
--
The query returns no rows when used with bind variables and two rows
without. No errors are reported by errorInfo().

The query behaved correctly when only binding :CODE and replacing :LEN1
and :LEN2 by their actual value.





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

#46834 [NEW]: Range of mcrypt functions fail on PHP 6.0

2008-12-11 Thread a...@php.net

From: [EMAIL PROTECTED]
Operating system: Windows, Linux
PHP version:  6CVS-2008-12-11 (snap)
PHP Bug Type: mcrypt related
Bug description:  Range of mcrypt functions fail on PHP 6.0

Description:

A range of PHPTs fail on PHP 6 where they pass on PHP 5.2/5.3. In 
many cases it looks like the function returns different output from 
encryption/decryption calls. The following failing tests are all 
checked into PHP 6 and marked with an XFAIL section:

mcrypt_cbc_3des_encrypt.phpt
mcrypt_cbc_3des_decrypt.phpt
mcrypt_cbc_variation4.phpt
mcrypt_cbc_variation5.phpt
mcrypt_rijndael128_128BitKey.phpt
mcrypt_rijndael128_256BitKey.phpt
mcrypt_decrypt_3des_cbc.phpt
mcrypt_decrypt_variation5.phpt
mcrypt_encrypt_3des_cbc.phpt
mcrypt_encrypt_variation5.phpt
mcrypt_ecb_variation4.phpt

The problem may be common to all the failing tests and looks like 
something has changed with different length initialisation vectors.

Reproduce code:
---
(See the tests checked into CVS)

Expected result:

For example, the mcrypt_cbc_3des_decrypt.phpt test expects:

--- testing different iv lengths

iv length=4

Warning: mcrypt_cbc(): The IV parameter must be as long as the 
blocksize in %s on line %d
unicode(32) "736563726574206d657373616765"

iv length=8
unicode(32) "736563726574206d657373616765"

iv length=9

Warning: mcrypt_cbc(): The IV parameter must be as long as the 
blocksize in %s on line %d
unicode(32) "736563726574206d657373616765"




Actual result:
--
iv length=4

Warning: mcrypt_cbc(): The IV parameter must be as long as the 
blocksize in D:\Testing\php-6.0\mcrypt_cbc_3des_decrypt.php on line 
52
unicode(32) "425750466574206d657373616765"

iv length=8
unicode(32) "736563726574206d657373616765"

iv length=9

Warning: mcrypt_cbc(): The IV parameter must be as long as the 
blocksize in D:\Testing\php-6.0\mcrypt_cbc_3des_decrypt.php on line 
52
unicode(32) "4257504650421755657373616765"

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

#46808 [Com]: Mysqli crashes on LONGTEXT columns

2008-12-11 Thread webmaster at ajeux dot com

 ID:   46808
 Comment by:   webmaster at ajeux dot com
 Reported By:  wcshields at gmail dot com
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Ubuntu 8.04 LTS x86 32 bit
 PHP Version:  5.2.8
 New Comment:

Bug confirmed here on PHP 5.3 with Mysql 5.0.51
SELECT query : 

"SELECT id, UNCOMPRESS(myfield) FROM mytable ORDER BY id LIMIT 8"
myfield is BLOB.

How can we help to get it fixed ?

"Program received signal SIGSEGV, Segmentation fault."

Backtrace:
#0  0xb7aedb00 in mysqli_stmt_fetch_libmysql (ht=0,
return_value=0xb71cbe4c, return_value_ptr=0x0, this_ptr=0xb7265748,
return_value_used=1)
at /usr/src/php5.3-200812091530/ext/mysqli/mysqli_api.c:842
#1  0xb7aedf0d in zif_mysqli_stmt_fetch (ht=0, return_value=0xb71cbe4c,
return_value_ptr=0x0, this_ptr=0xb7265748, return_value_used=1)
at /usr/src/php5.3-200812091530/ext/mysqli/mysqli_api.c:984
#2  0x0827a4b9 in zend_do_fcall_common_helper_SPEC
(execute_data=0xb776af88) at
/usr/src/php5.3-200812091530/Zend/zend_vm_execute.h:313
#3  0x08279a32 in execute (op_array=0xb738bd94) at
/usr/src/php5.3-200812091530/Zend/zend_vm_execute.h:104
#4  0x08253c17 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php5.3-200812091530/Zend/zend.c:1197
#5  0x081faf59 in php_execute_script (primary_file=0xbfb12090) at
/usr/src/php5.3-200812091530/main/main.c:2080
#6  0x082ec5a9 in main (argc=1, argv=0xbfb121e4) at
/usr/src/php5.3-200812091530/sapi/cgi/cgi_main.c:2000


Previous Comments:


[2008-12-09 07:31:00] wcshields at gmail dot com

Description:

Mysqli restores garbage from longtext columns in mysql 5.0.51a
connected over TCP (also happens with Unix domain sockets) and, after a
random number of rows, seg faults.  The number of rows is unpredictable
but consistent.  If you find something that crashes after 11 rows, it
will crash after 11 rows every time.  Change the order by clause and it
might crash every time after 3 rows.

As per bugs #44867 and several others I've found, people have been
reporting this issue since as early as 2005 and it still hasn't been
addressed.  Can someone PLEASE actually look into it?

Reproduce code:
---
prepare("SELECT name, longtext1 FROM sampletable");
$stmt->execute();
$stmt->bind_result($name, $value);
$count = 1;
while ($stmt->fetch()) {
$size = sizeof($value);
echo "$name $size\n";
$count++;
}
$stmt->close();
?>

Expected result:

To retrieve the exact contents of all longtext values without crashing.

Actual result:
--
Segmentation fault.
$ gdb php core
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1
Reading symbols from /lib/tls/i686/cmov/librt.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/librt.so.1
Reading symbols from /lib/tls/i686/cmov/libresolv.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libresolv.so.2
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /usr/lib/libmysqlclient.so.15...done.
Loaded symbols for /usr/lib/libmysqlclient.so.15
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...done.
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
Reading symbols from /lib/tls/i686/cmov/libm.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_files.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_files.so.2
Core was generated by `./php'.
Program terminated with signal 11, Segmentation fault.
[New process 5006]
#0  0x08130eda in zif_mysqli_stmt_fetch (ht=0, return_value=0x856e20c,
return_value_ptr=0x0, this_ptr=0x856e0b8, return_value_used=1)
at /home/wshields/php-5.2.8/ext/mysqli/mysqli_api.c:665
665 if (Z_TYPE_P(stmt->result.vars[i]) ==
IS_STRING) {
(gdb) bt
#0  0x08130eda in zif_mysqli_stmt_fetch (ht=0, return_value=0x856e20c,
return_value_ptr=0x0, this_ptr

#46803 [Opn->Fbk]: Sqlite-PDO prepared statement doesn't return any rows when used with bind vars

2008-12-11 Thread scottmac

 ID:   46803
 Updated by:   [EMAIL PROTECTED]
 Reported By:  scaligo at pt dot lu
-Status:   Open
+Status:   Feedback
 Bug Type: PDO related
 Operating System: Linux x86_64
 PHP Version:  5.2.7
 New Comment:

I can't reproduce this on 5.3.0 alpha 3, works fine both times. It does
however happen in 5.2. I was using regular x86 though.

Are you sure this happened with 5.3?


Previous Comments:


[2008-12-11 09:59:53] nasubi at pako dot ne dot jp

pdo_mysql has same problem on php-5.2.8 (x86_64)



[2008-12-08 20:45:04] scaligo at pt dot lu

Description:

A PDO prepared statement doesn't return any results for a given query
performed with bind variables, but works fine when used without. A same
value is used twice and the workaround for WONTFIX #33886 has been
applied.

The initial query (with bind variables) returns the expected results in
another environment (Ruby/SQLite3).

Reproduced on vanilla 5.2.7 and 5.3.0 alpha 3, x86_64.

Compile flags (5.2.7):
./configure \
--enable-debug \
--enable-cli \
--disable-cgi \
--disable-all \
--enable-pdo \
--with-pdo-sqlite \
--enable-sqlite-utf8


Reproduce code:
---
Test case:
http://nopaste.ch/855d0d151ef8216.html

Query:
SELECT u.login, c.code
FROM codes c, users u
WHERE u.id = c.user_id
AND substr(c.code, 1, min(length(c.code), :LEN1)) = substr(:CODE, 1,
min(length(c.code), :LEN2))

Binds:
$statement->bindValue(':CODE', '111-222-', PDO::PARAM_STR);
$statement->bindValue(':LEN1', 8, PDO::PARAM_INT);
$statement->bindValue(':LEN2', 8, PDO::PARAM_INT);


Expected result:

The query should find the same rows with and without using bind
variables.

Actual result:
--
The query returns no rows when used with bind variables and two rows
without. No errors are reported by errorInfo().

The query behaved correctly when only binding :CODE and replacing :LEN1
and :LEN2 by their actual value.





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

#46834 [Opn->Asn]: Range of mcrypt functions fail on PHP 6.0

2008-12-11 Thread derick

 ID:   46834
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: mcrypt related
 Operating System: Windows, Linux
 PHP Version:  6CVS-2008-12-11 (snap)
-Assigned To:  
+Assigned To:  derick


Previous Comments:


[2008-12-11 10:39:32] [EMAIL PROTECTED]

Description:

A range of PHPTs fail on PHP 6 where they pass on PHP 5.2/5.3. In 
many cases it looks like the function returns different output from 
encryption/decryption calls. The following failing tests are all 
checked into PHP 6 and marked with an XFAIL section:

mcrypt_cbc_3des_encrypt.phpt
mcrypt_cbc_3des_decrypt.phpt
mcrypt_cbc_variation4.phpt
mcrypt_cbc_variation5.phpt
mcrypt_rijndael128_128BitKey.phpt
mcrypt_rijndael128_256BitKey.phpt
mcrypt_decrypt_3des_cbc.phpt
mcrypt_decrypt_variation5.phpt
mcrypt_encrypt_3des_cbc.phpt
mcrypt_encrypt_variation5.phpt
mcrypt_ecb_variation4.phpt

The problem may be common to all the failing tests and looks like 
something has changed with different length initialisation vectors.

Reproduce code:
---
(See the tests checked into CVS)

Expected result:

For example, the mcrypt_cbc_3des_decrypt.phpt test expects:

--- testing different iv lengths

iv length=4

Warning: mcrypt_cbc(): The IV parameter must be as long as the 
blocksize in %s on line %d
unicode(32) "736563726574206d657373616765"

iv length=8
unicode(32) "736563726574206d657373616765"

iv length=9

Warning: mcrypt_cbc(): The IV parameter must be as long as the 
blocksize in %s on line %d
unicode(32) "736563726574206d657373616765"




Actual result:
--
iv length=4

Warning: mcrypt_cbc(): The IV parameter must be as long as the 
blocksize in D:\Testing\php-6.0\mcrypt_cbc_3des_decrypt.php on line 
52
unicode(32) "425750466574206d657373616765"

iv length=8
unicode(32) "736563726574206d657373616765"

iv length=9

Warning: mcrypt_cbc(): The IV parameter must be as long as the 
blocksize in D:\Testing\php-6.0\mcrypt_cbc_3des_decrypt.php on line 
52
unicode(32) "4257504650421755657373616765"





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

#46835 [NEW]: saveHTML automatically replaces unicode letters to entities

2008-12-11 Thread kasparsj at gmail dot com

From: kasparsj at gmail dot com
Operating system: 
PHP version:  5.2.8
PHP Bug Type: DOM XML related
Bug description:  saveHTML automatically replaces unicode letters to entities

Description:

DOMDocument->saveHTML replaces not only predefined entities, but also
unicode letters, like Ä, Å¡, Ä. is this also as expected or a bug?

this is related to:
http://bugs.php.net/bug.php?id=37878

Reproduce code:
---
$doc = new DOMDocument('1.0', 'UTF-8');
$doc->substituteEntities = false;
$doc->appendChild($doc->createElement('p', 'Å¡aÄeÄ'));
var_dump($doc->saveHTML());

Expected result:

Å¡aÄeÄ

Actual result:
--
©šaēeā

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

#45161 [Opn]: Reusing a curl handle leaks memory

2008-12-11 Thread magicaltux

 ID:   45161
 Updated by:   [EMAIL PROTECTED]
 Reported By:  humbads at alum dot mit dot edu
 Status:   Open
 Bug Type: cURL related
 Operating System: *
 PHP Version:  5CVS, 6CVS (2008-12-08)
 New Comment:

This patch will get rid of to_free.str if libcurl version is >= 7.17.0

Also:

[09:25:46]  btw curl doc says: "curl_slist_append() copies the
string.", is this true for all versions of libcurl ?
[09:26:33]  yes

So, code duplicating strings before passing them to curl_slist_append()
has been completly removed.

http://ookoo.org/svn/snip/php_bug45161_curl_textcopy.patch


Previous Comments:


[2008-12-11 06:03:56] [EMAIL PROTECTED]

Hi,

Managed to get rid of to_free.str, with one exception bugging me: when
we call curl_slist_append(), we duplicate the string before, however
curl doc says: "curl_slist_append() copies the string."

Is this true with all versions of curl? I see nothing written about
this in the curl man page.



[2008-10-28 22:25:04] [EMAIL PROTECTED]

I have no time to spend on this right now.



[2008-08-15 15:37:26] [EMAIL PROTECTED]

FYI: This is by design in any resource in PHP. Freeing happens in the
request shutdown. Just do unset($ch); in the end of the for loop and $ch
= curl_init(); in the start of the loop and you get "static" memory
usage. 

I'm going to only look at what Daniel pointed out and make PHP not
duplicate unnecessarily if curl version is >= 7.17.0.



[2008-06-22 22:06:30] daniel at haxx dot se

I could also add that libcurl does duplicate the input strings since a
few versions back (since libcurl 7.17.0), so if such a recent version of
libcurl is detected there's no reason at all for PHP to keep copies.

This goes for everything except CURLOPT_POSTFIELDS which isn't
duplicated for backwards compatiblity reasons, but that one can then be
replaced with CURLOPT_COPYPOSTFIELDS which does copy.



[2008-06-03 19:24:34] humbads at alum dot mit dot edu

I did some more investigation, and found that this is not really a leak
as much as it is runaway memory usage.  PHP does indeed free the memory
eventually.

The problem is in interface.c curl_setopt under CURLOPT_URL.   The
function is making a copy of the string parameter, in this case, the
URL, and saving that to the "to_free" list.  That list is not freed
until sometime later, so repeatedly setting CURLOPT_URL on the same
handle will keep using more memory.  In the sample code I posted, the
memory only increases during the curl_setopt CURLOPT_URL function call.

This is just an inefficient design of the PHP curl handle.  One way
around it is for the code to maintain only one copied string for each
CURLOPT string option.  If the same CURLOPT string option is set again,
it should free the previously created string, and create a new one.

At the PHP level, the only workaround for now is to periodically close
the handle and then create a new one with curl_init.  This seems to cap
the memory usage.



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

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

#46832 [Opn->Bgs]: memleak on handles duplicated with curl_copy_handle()

2008-12-11 Thread magicaltux

 ID:   46832
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: cURL related
 Operating System: Linux
 PHP Version:  5.2CVS-2008-12-11 (CVS)
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Fix for bug #45161 is likely to fix this issue as well, as long as you
have libcurl >= 7.17.0.

Thank you for your interest in PHP.


Previous Comments:


[2008-12-11 05:57:44] [EMAIL PROTECTED]

Description:

When an handle is copied with curl_copy_handle(), its ability to free
memory used by strings is disabled.

In ext/curl/interface.c near line 1215 :

  zend_llist_copy(&dupch->to_free.str, &ch->to_free.str);
  /* Don't try to free copied strings, they're free'd when the original
handle is destroyed */
  dupch->to_free.str.dtor = NULL;
  zend_llist_copy(&dupch->to_free.slist, &ch->to_free.slist);
  zend_llist_copy(&dupch->to_free.post, &ch->to_free.post);

1. New strings allocated by this new handle will have "NULL" as dtor
2. slist and post will still be free'd on both handles. Freeing one
handle first also probably breaks the second handle
3. The copied handle will have unexpected behaviour with libcurl
<7.17.0 if the source handle is freed before the copied handle.

Two options exists here:

1. Disable this function for people who don't have at least libcurl
7.17.0, and let libcurl handle duplication of strings, etc.. (it now
does this automatically, cf bug #45161).
2. Manually duplicate all options that are set in the source curl
handle and register them in newly allocated handle on
curl_copy_handle(). This can lead to errors as we do not keep record of
all set options.

Reproduce code:
---
http://localhost/test/tset/est');

curl_close($ch2);

var_dump(memory_get_usage());
}


Expected result:

(always the same int dumped)

Actual result:
--
[...]
int(415128)
int(415256)
int(415384)
int(415512)
int(415640)
int(415768)
int(415896)
int(416024)
int(416152)
int(416280)
int(416408)
int(416536)
int(416664)
[Thu Dec 11 06:50:37 2008]  Script:  'curl_memleak.php'
ext/curl/interface.c(1342) :  Freeing 0x0198CB78 (31 bytes),
script=curl_memleak.php
Last leak repeated 2047 times
=== Total 2048 memory leaks detected ===






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

#46803 [Com]: Sqlite-PDO prepared statement doesn't return any rows when used with bind vars

2008-12-11 Thread scaligo at pt dot lu

 ID:   46803
 Comment by:   scaligo at pt dot lu
 Reported By:  scaligo at pt dot lu
 Status:   Feedback
 Bug Type: PDO related
 Operating System: Linux x86_64
 PHP Version:  5.2.7
 New Comment:

I re-ran some tests:

It indeed works in 5.3.0 alpha3 if I bind :LEN1 and :LEN2 as
PDO::PARAM_INT, but not as PDO::PARAM_STR. Using :LEN twice actually
works too.

Is it possible to back-port the 5.3.0 changes to 5.2.x?


Previous Comments:


[2008-12-11 11:26:21] [EMAIL PROTECTED]

I can't reproduce this on 5.3.0 alpha 3, works fine both times. It does
however happen in 5.2. I was using regular x86 though.

Are you sure this happened with 5.3?



[2008-12-11 09:59:53] nasubi at pako dot ne dot jp

pdo_mysql has same problem on php-5.2.8 (x86_64)



[2008-12-08 20:45:04] scaligo at pt dot lu

Description:

A PDO prepared statement doesn't return any results for a given query
performed with bind variables, but works fine when used without. A same
value is used twice and the workaround for WONTFIX #33886 has been
applied.

The initial query (with bind variables) returns the expected results in
another environment (Ruby/SQLite3).

Reproduced on vanilla 5.2.7 and 5.3.0 alpha 3, x86_64.

Compile flags (5.2.7):
./configure \
--enable-debug \
--enable-cli \
--disable-cgi \
--disable-all \
--enable-pdo \
--with-pdo-sqlite \
--enable-sqlite-utf8


Reproduce code:
---
Test case:
http://nopaste.ch/855d0d151ef8216.html

Query:
SELECT u.login, c.code
FROM codes c, users u
WHERE u.id = c.user_id
AND substr(c.code, 1, min(length(c.code), :LEN1)) = substr(:CODE, 1,
min(length(c.code), :LEN2))

Binds:
$statement->bindValue(':CODE', '111-222-', PDO::PARAM_STR);
$statement->bindValue(':LEN1', 8, PDO::PARAM_INT);
$statement->bindValue(':LEN2', 8, PDO::PARAM_INT);


Expected result:

The query should find the same rows with and without using bind
variables.

Actual result:
--
The query returns no rows when used with bind variables and two rows
without. No errors are reported by errorInfo().

The query behaved correctly when only binding :CODE and replacing :LEN1
and :LEN2 by their actual value.





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

#46836 [NEW]: $_SERVER['PHP_SELF'] path repeated

2008-12-11 Thread editoria dot francisco at gmail dot com

From: editoria dot francisco at gmail dot com
Operating system: Windows 2000
PHP version:  5.2.8
PHP Bug Type: CGI related
Bug description:  $_SERVER['PHP_SELF'] path repeated

Description:

$_SERVER['PHP_SELF'] path repeated.
Same bug related in:
http://bugs.php.net/bug.php?id=42699, PHP Version: 5.2CVS-2007-09-18
http://bugs.php.net/bug.php?id=42523, PHP Version: 5.2.4

Reproduce code:
---
echo $_SERVER['PHP_SELF'];

Expected result:

/path/test.php


Actual result:
--
/path/test.php/path/test.php

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

#46837 [NEW]: imap. Invalid CL_EXPUNGE are not caught.

2008-12-11 Thread zoe dot slattery at googlemail dot com

From: zoe dot slattery at googlemail dot com
Operating system: Linux
PHP version:  5.3.0alpha3
PHP Bug Type: Scripting Engine problem
Bug description:  imap. Invalid CL_EXPUNGE are not caught.

Description:

The value of CL_EXPUNGE is checked in imap_close() but the check just
ensures that any value that ends in a 1 is treated as valid, this is a
similar issue to #46731 and the fix is similar. The value of CL_EXPUNGE
should be either 0 or 32768.

The attached patches do an explicit check for 0 or 32768.

php52: http://pastebin.ca/1282662
php53: http://pastebin.ca/1282664
php6: http://pastebin.ca/1282667


Reproduce code:
---
This testcase: http://pastebin.ca/1282641


Expected result:

Th expected result is shown in the test case

Actual result:
--
The actual result from PHP52 is: http://pastebin.ca/1282656


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

#35345 [Com]: SQLite won't load (specified module not found)

2008-12-11 Thread saravana dot nsk83 at gmail dot com

 ID:   35345
 Comment by:   saravana dot nsk83 at gmail dot com
 Reported By:  csaba at alum dot mit dot edu
 Status:   No Feedback
 Bug Type: PDO related
 Operating System: Win XP Pro
 PHP Version:  5CVS-2005-11-23 (snap)
 Assigned To:  wez
 New Comment:

Hello sir,

i was unable to connect sqlite with php.


Error: Fatal error: Call to undefined function sqlite_open() in
C:\webs\test\testsqlite.php5 on line 12

thank you,


Saravana


Previous Comments:


[2008-09-03 08:32:21] niz_reez4 at yahoo dot com

";
}

//close database
sqlite_close($db);

?>



[2007-05-24 10:59:57] scriper at mail dot ru

Well, when i upgraded from 5.1.6 i've saved my php.ini, now i have
replaced it with php.ini.recommended from 5.2.2 dist, uncommented
modules and everything goes ok.



[2007-05-24 10:26:32] scriper at mail dot ru

Well, after copying php_pdo.dll and php_sqlite.dll to c:/php i have
another warning coming: Cannot load module 'SQLite' because required
module 'pdo' is not loaded



[2007-05-24 09:50:35] scriper at mail dot ru

Actually i have the same problem. I've have win xp sp2,php 5.2.2 and
apache 2.2.4. In my php.ini i've uncommented:
extension php_pdo.dll
extension php_pdo_mysql.dll
extension php_pdo_sqlite.dll
extension php_pdo_sqlite_external.dll
extension=php_sqlite.dll
I checked ext dir, it contains all of that. After restarting apache,
and give a request for example http://localhost/index.php i get a
Warning:
PHP Startup: Unable to load dynamic library
'C:/php/ext/php_sqlite.dll'- The specified module could not be found.



[2007-05-06 23:43:02] kunalspunjabi at yahoo dot com

I am seeing the following error when I add the following lines to my
php.ini file:
extension=php_pdo.dll
extension=php_pdo_mysql.dll
extension=php_pdo_sqlite.dll
extension=php_sqlite.dll

I then restarted Apache and invoked PHP from the command line:

$ php
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\ext\php_sqlite.dll' - The specified module could not be
found.
 in Unknown on line 0


My PHP extensions directory contains all these DLLs, apparently
php_sqlite.dll is the only one that does not load. Why?



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

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

#46808 [Com]: Mysqli crashes on LONGTEXT columns

2008-12-11 Thread webmaster at ajeux dot com

 ID:   46808
 Comment by:   webmaster at ajeux dot com
 Reported By:  wcshields at gmail dot com
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Ubuntu 8.04 LTS x86 32 bit
 PHP Version:  5.2.8
 New Comment:

Note: No bug when mysqlnd is used. (configure with
--with-mysqli=mysqlnd)


Previous Comments:


[2008-12-11 11:18:32] webmaster at ajeux dot com

Bug confirmed here on PHP 5.3 with Mysql 5.0.51
SELECT query : 

"SELECT id, UNCOMPRESS(myfield) FROM mytable ORDER BY id LIMIT 8"
myfield is BLOB.

How can we help to get it fixed ?

"Program received signal SIGSEGV, Segmentation fault."

Backtrace:
#0  0xb7aedb00 in mysqli_stmt_fetch_libmysql (ht=0,
return_value=0xb71cbe4c, return_value_ptr=0x0, this_ptr=0xb7265748,
return_value_used=1)
at /usr/src/php5.3-200812091530/ext/mysqli/mysqli_api.c:842
#1  0xb7aedf0d in zif_mysqli_stmt_fetch (ht=0, return_value=0xb71cbe4c,
return_value_ptr=0x0, this_ptr=0xb7265748, return_value_used=1)
at /usr/src/php5.3-200812091530/ext/mysqli/mysqli_api.c:984
#2  0x0827a4b9 in zend_do_fcall_common_helper_SPEC
(execute_data=0xb776af88) at
/usr/src/php5.3-200812091530/Zend/zend_vm_execute.h:313
#3  0x08279a32 in execute (op_array=0xb738bd94) at
/usr/src/php5.3-200812091530/Zend/zend_vm_execute.h:104
#4  0x08253c17 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php5.3-200812091530/Zend/zend.c:1197
#5  0x081faf59 in php_execute_script (primary_file=0xbfb12090) at
/usr/src/php5.3-200812091530/main/main.c:2080
#6  0x082ec5a9 in main (argc=1, argv=0xbfb121e4) at
/usr/src/php5.3-200812091530/sapi/cgi/cgi_main.c:2000



[2008-12-09 07:31:00] wcshields at gmail dot com

Description:

Mysqli restores garbage from longtext columns in mysql 5.0.51a
connected over TCP (also happens with Unix domain sockets) and, after a
random number of rows, seg faults.  The number of rows is unpredictable
but consistent.  If you find something that crashes after 11 rows, it
will crash after 11 rows every time.  Change the order by clause and it
might crash every time after 3 rows.

As per bugs #44867 and several others I've found, people have been
reporting this issue since as early as 2005 and it still hasn't been
addressed.  Can someone PLEASE actually look into it?

Reproduce code:
---
prepare("SELECT name, longtext1 FROM sampletable");
$stmt->execute();
$stmt->bind_result($name, $value);
$count = 1;
while ($stmt->fetch()) {
$size = sizeof($value);
echo "$name $size\n";
$count++;
}
$stmt->close();
?>

Expected result:

To retrieve the exact contents of all longtext values without crashing.

Actual result:
--
Segmentation fault.
$ gdb php core
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1
Reading symbols from /lib/tls/i686/cmov/librt.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/librt.so.1
Reading symbols from /lib/tls/i686/cmov/libresolv.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libresolv.so.2
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /usr/lib/libmysqlclient.so.15...done.
Loaded symbols for /usr/lib/libmysqlclient.so.15
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...done.
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
Reading symbols from /lib/tls/i686/cmov/libm.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_files.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_files.so.2
Core was generated by `./php'.
Program terminated with signal 11, Segmentation fault.
[New process 5006]
#0  0x08130eda in zif_mysqli_stmt_fetch (ht=0, return_value=0x856e20c,
return_value_ptr=0x0, this_ptr=0x856e0b8, return_value_used=1)
at /home/wshields/php-5.2.8/ext/mysqli/mysqli_api.c:66

#35345 [NoF->Bgs]: SQLite won't load (specified module not found)

2008-12-11 Thread pajoye

 ID:   35345
 Updated by:   [EMAIL PROTECTED]
 Reported By:  csaba at alum dot mit dot edu
-Status:   No Feedback
+Status:   Bogus
 Bug Type: PDO related
 Operating System: Win XP Pro
 PHP Version:  5CVS-2005-11-23 (snap)
 Assigned To:  wez
 New Comment:

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

Thank you for your interest in PHP.

Please ask support about enabling extensions in the php-install or
php-windows mailing list.


Previous Comments:


[2008-12-11 15:45:05] saravana dot nsk83 at gmail dot com

Hello sir,

i was unable to connect sqlite with php.


Error: Fatal error: Call to undefined function sqlite_open() in
C:\webs\test\testsqlite.php5 on line 12

thank you,


Saravana



[2008-09-03 08:32:21] niz_reez4 at yahoo dot com

";
}

//close database
sqlite_close($db);

?>



[2007-05-24 10:59:57] scriper at mail dot ru

Well, when i upgraded from 5.1.6 i've saved my php.ini, now i have
replaced it with php.ini.recommended from 5.2.2 dist, uncommented
modules and everything goes ok.



[2007-05-24 10:26:32] scriper at mail dot ru

Well, after copying php_pdo.dll and php_sqlite.dll to c:/php i have
another warning coming: Cannot load module 'SQLite' because required
module 'pdo' is not loaded



[2007-05-24 09:50:35] scriper at mail dot ru

Actually i have the same problem. I've have win xp sp2,php 5.2.2 and
apache 2.2.4. In my php.ini i've uncommented:
extension php_pdo.dll
extension php_pdo_mysql.dll
extension php_pdo_sqlite.dll
extension php_pdo_sqlite_external.dll
extension=php_sqlite.dll
I checked ext dir, it contains all of that. After restarting apache,
and give a request for example http://localhost/index.php i get a
Warning:
PHP Startup: Unable to load dynamic library
'C:/php/ext/php_sqlite.dll'- The specified module could not be found.



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

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

#44963 [Com]: Problem with installer package

2008-12-11 Thread buingthai at gmail dot com

 ID:   44963
 Comment by:   buingthai at gmail dot com
 Reported By:  f dot polster at ceisa-packagibg dot com
 Status:   No Feedback
 Bug Type: Windows Installer
 Operating System: windows 2003 SP2
 PHP Version:  5.2.6
 New Comment:

i have the same bugs. it's bad


Previous Comments:


[2008-08-30 01:00:00] php-bugs at lists dot php dot net

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



[2008-08-22 06:53:25] j...@php.net

Please try using this CVS snapshot:

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

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi





[2008-05-10 17:29:17] f dot polster at ceisa-packagibg dot com

Description:

When I try to install the .msi package I choose "IIS ISAPI module"
option.
The installation is starting and I get message this message:
There is a problem with this windows installer package. A script
required for this install to complete couls not be run.  Contact your
support personnel or package vendor

There is not the problem when install witout configuration web serveur
My IIS serveur is V6.0

Hope you could help.

Thanks






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

#13421 [Com]: Problematic MIME-Type "application/x-httpd-php"

2008-12-11 Thread JAMALMNK at HOTMAIL dot COM

 ID:   13421
 Comment by:   JAMALMNK at HOTMAIL dot COM
 Reported By:  php at matthias-wimmer dot de
 Status:   No Feedback
 Bug Type: Apache related
 Operating System: Linux
 PHP Version:  4.0.6
 New Comment:

JAMAL


Previous Comments:


[2003-03-14 06:15:37] bartek at luka dot dagma dot pl

It seems like the same problem occurs in 4.3.1 version of PHP running
on Apache 1.3.x.



[2002-12-23 16:03:27] j dot westendorp at chello dot nl

I have the same problem: I can't view my "Multiviewed" pages (e.g.
http://domain.com/news/38 instead of http://domain.com/news.php?ID=38 )
with a user agent that does not send the "Accept: */*" request header
(like AvantGo 3.2 does) because Apache throws a "406 No Acceptable
Variant" error.

I'm running PHP 4.2.2 on Apache 1.3.19 (Red-Hat/Linux)



[2002-10-16 01:00:06] php-bugs at lists dot php dot net

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



[2002-09-30 20:48:44] il...@php.net

Please try using this CVS snapshot:

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





[2002-08-09 05:39:03] hholz...@php.net

sorry, mixed up two bugs here, reopening



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

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

#44963 [Com]: Problem with installer package

2008-12-11 Thread buingthai at gmail dot com

 ID:   44963
 Comment by:   buingthai at gmail dot com
 Reported By:  f dot polster at ceisa-packagibg dot com
 Status:   No Feedback
 Bug Type: Windows Installer
 Operating System: windows 2003 SP2
 PHP Version:  5.2.6
 New Comment:

ok. i 've installed with php 5.2.7.
I think that bug for php 5.2.8.
please check it again


Previous Comments:


[2008-12-11 18:47:54] buingthai at gmail dot com

i have the same bugs. it's bad



[2008-08-30 01:00:00] php-bugs at lists dot php dot net

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



[2008-08-22 06:53:25] j...@php.net

Please try using this CVS snapshot:

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

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi





[2008-05-10 17:29:17] f dot polster at ceisa-packagibg dot com

Description:

When I try to install the .msi package I choose "IIS ISAPI module"
option.
The installation is starting and I get message this message:
There is a problem with this windows installer package. A script
required for this install to complete couls not be run.  Contact your
support personnel or package vendor

There is not the problem when install witout configuration web serveur
My IIS serveur is V6.0

Hope you could help.

Thanks






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

#40034 [Com]: mssql_connect(): Unable to connect to server

2008-12-11 Thread parvesh_k at hotmail dot com

 ID:   40034
 Comment by:   parvesh_k at hotmail dot com
 Reported By:  chris dot clos at lmcu dot org
 Status:   Assigned
 Bug Type: MSSQL related
 Operating System: Windows Server 2003
 PHP Version:  5.2.0
 Assigned To:  fmk
 New Comment:

I have a windows dll version 2000.80.194.0 and use php 5.2.6

I am trying to connect to MSQL2K5 but get a following error "Unable to
connect to server: "

I have following option turned on mssql.secure_connection = On in
php.ini


Previous Comments:


[2008-10-10 10:40:09] hamzeh dot shaar at ifpexpo dot com

Guys, I have the same problem. I have php 5.2.6 on IIS 6.  I cannot
connect from it my SQL server 2000 (MSDE) running on the same machine
knowing that i have another PHP installation 5.2.5 on the same LAN and
it connects to the same MSDE 2000 Normally.

I tried copying php5isapi.dll and ntwdblib from the working machine to
the other and still it dd not work.

any suggesstions?



[2008-10-10 08:35:20] dirk dot melcher at mdk-nord dot de

thanks everybody for the hints that helped me a lot!

I'm using php Version 4.2.1 and the same problem applied to me.
I downloaded an appropriate version of ntwdblib.dll at:

http://www.dlldll.com/ntwdblib.dll_download.html

Bye,

Dirk



[2008-09-18 13:14:23] spanidis at certh dot gr

Hello to everyone.

Could you please tell us where can we download ntwdblib.dll (ver.
2000.80.2039.0) from? 

Thanks for your help

Pavlos



[2008-08-15 11:51:08] php at blazemonger dot com

I am experiencing this on Linux (CentOS 5) with the stock PHP 5.1.6 and
PHP 5.2.6.  It is intermittent -- the same SQL query to the same DB
server will work sometimes, fail other times.



[2008-07-29 12:37:13] c dot pasticcio at gawab dot com

We have the same problems with sevral configurations on windows 2003.
- webserver: win2k3 + Apache 2.2.9 + Php 5.2.6
- webserver: win2k3 + Apache 2.0.59 + Php 5.1.6
- db server: win2k3 + sql server 2000

We have other 2 webservers with latest Apache and Php releases running
on windows 2000 that don't suffer this problem.

On all webservers we have ntwdblib.dll version 2000.80.194.0.
On db server with win2k3 we have a ntwdblib.dll version
2000.80.2039.0.
We didn't try to change the libs yet.



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

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

#46839 [NEW]: cant compile 5.2.8 with imap c-client compiled manualy

2008-12-11 Thread naox at o2 dot pl

From: naox at o2 dot pl
Operating system: linux centos 5
PHP version:  5.2.8
PHP Bug Type: IMAP related
Bug description:  cant compile 5.2.8 with imap c-client compiled manualy

Description:

I use manualy compiled imap-2007d. I do this because there is a 
problem - c-client has small number FD_SETSIZE. If your apache 
httpd.conf opens a lot of log files than c-client crashes apache 
child if called from PHP. So I cant use standard c-client suplied 
with linux.

Now when I try to compile PHP 5.2.8 with manualy complied c-client

/root/naox/php-5.2.8.mod/ext/imap/php_imap.c: In function 
'zm_startup_imap':
/root/naox/php-5.2.8.mod/ext/imap/php_imap.c:477: error: 'auth_gss' 
undeclared (first use in this function)
/root/naox/php-5.2.8.mod/ext/imap/php_imap.c:477: error: (Each 
undeclared identifier is reported only once
/root/naox/php-5.2.8.mod/ext/imap/php_imap.c:477: error: for each 
function it appears in.)
/root/naox/php-5.2.8.mod/ext/imap/php_imap.c: In function 
'zif_imap_rfc822_parse_adrlist':
/root/naox/php-5.2.8.mod/ext/imap/php_imap.c:2175: warning: passing 
argument 3 of 'rfc822_parse_adrlist' from incompatible pointer type
make: *** [ext/imap/php_imap.lo] Error 1


Problem only occurs in PHP 5.2.8. In PHP 5.2.6 everything works fine. 
Also problem does not appear if I compile PHP 5.2.8 with standard c-
client suplied with linux.

If I copy ext/imap/php_imap.c from 5.2.6 into 5.2.8 I can compile php 
without problems

There are some old bug reports about this problem resolved years ago 
with "fixed in cvs". So I suspect you reverted your php_imap.c in 
5.2.8 to state where it was not fixec.


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

#46796 [Fbk->Opn]: make test: Error 137

2008-12-11 Thread isjackawesome at gmail dot com

 ID:   46796
 User updated by:  isjackawesome at gmail dot com
-Summary:  make test: Error 137 ignored
 Reported By:  isjackawesome at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Streams related
 Operating System: Linux/Ubuntu 8.04
 PHP Version:  5.2.6
 New Comment:

Ive installed the latest snapshot and i still receive the error.

however at the end it says:
 4616/5387 instead of the original 3912/4619

I can make install and use php fine - the make test fails.


Previous Comments:


[2008-12-08 14:03:43] 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-12-08 13:48:27] isjackawesome at gmail dot com

Description:

Compiled with:
./configure with-apxs2=/usr/local/server/apache2/bin/apxs with-
mysqli=/usr/local/server/mysql/bin/mysql_config enable-debug=no --
with-mcrypt=/usr/local/server/libmcrypt enable-ftp with-gd with-
jpeg-dir=/usr/local with-png-dir=/usr/local with-zlib-
dir=/usr/local --enable-shared --enable-static

make - works no errors
make test, stalls on stream_get_meta_data_socket_variation1 
(3912/4619)




Reproduce code:
---
TEST 3912/4619
[ext/standard/tests/streams/stream_get_meta_data_socket_variationOut of
memory: Killed process 4398 (php).
/bin/sh: line 18:  4398 Killed 
TEST_PHP_EXECUTABLE=/root/downloads/php-5.2.6/sapi/cli/php
TEST_PHP_SRCDIR=/root/downloads/php-5.2.6 CC="gcc"
/root/downloads/php-5.2.6/sapi/cli/php -d 'open_basedir=' -d
'output_buffering=0' -d 'memory_limit=-1'
/root/downloads/php-5.2.6/run-tests.php -c
/root/downloads/php-5.2.6/tmp-php.ini -U -d
extension_dir=/root/downloads/php-5.2.6/modules/ ` if test "x" != "x";
then for i in ""; do . $i; /root/downloads/php-5.2.6/build/shtool echo
-n -- " -d extension=$dlname"; done; fi`
make: [test] Error 137 (ignored)








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

#46840 [NEW]: ln: creating symbolic link `..phar': File exists

2008-12-11 Thread moo dot tinys at gmail dot com

From: moo dot tinys at gmail dot com
Operating system: linux
PHP version:  5.3CVS-2008-12-12 (CVS)
PHP Bug Type: PHAR related
Bug description:  ln: creating symbolic link `..phar': File exists

Description:

make install twice and i'll get an error:
ln: creating symbolic link `/home/moo/test/php5-debug-zts//bin/phar': File
exists


Reproduce code:
---
$ LANG=C make  install
.
$ LANG=C make  install
Installing PHP SAPI module:   cgi
Installing PHP CGI binary: /home/moo/test/php5-debug-zts//bin/
Installing PHP CLI binary:/home/moo/test/php5-debug-zts//bin/
Installing PHP CLI man page: 
/home/moo/test/php5-debug-zts//php/man/man1/
Installing build environment:
/home/moo/test/php5-debug-zts//lib/php/build/
Installing header files: 
/home/moo/test/php5-debug-zts//include/php/
Installing helper programs:   /home/moo/test/php5-debug-zts//bin/
  program: phpize
  program: php-config
Installing man pages:
/home/moo/test/php5-debug-zts//php/man/man1/
  page: phpize.1
  page: php-config.1
/home/moo/src/php/php5/build/shtool install -c ext/phar/phar.phar
/home/moo/test/php5-debug-zts//bin
ln -s /home/moo/test/php5-debug-zts//bin/phar.phar
/home/moo/test/php5-debug-zts//bin/phar
ln: creating symbolic link `/home/moo/test/php5-debug-zts//bin/phar': File
exists
make: *** [install-pharcmd] Error 1


Expected result:

make install should finish

Actual result:
--
ln: creating symbolic link `/home/moo/test/php5-debug-zts//bin/phar': File
exists
make: *** [install-pharcmd] Error 1

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

#46748 [Com]: get_headers generates segmentation fault on HTTPS with SSLVerifyClient required

2008-12-11 Thread crrodriguez at opensuse dot org

 ID:   46748
 Comment by:   crrodriguez at opensuse dot org
 Reported By:  romanf at trash dot net
 Status:   Assigned
 Bug Type: HTTP related
 Operating System: Linux (OpenSuse 11)
 PHP Version:  5.2CVS-2008-12-08
 Assigned To:  scottmac
 New Comment:

Cannot reproduce in 5_2 nor 5_3.


Previous Comments:


[2008-12-08 13:51:50] scott...@php.net

I can't reproduce this on any of the branches now, though I only have
x86 to test.

Jani, any chance of a backtrace on HEAD?



[2008-12-08 13:28:50] paj...@php.net

Scott, please clarify it and add tests :)



[2008-12-08 13:22:31] j...@php.net

HEAD seems to crash when it tries to output the error message.



[2008-12-08 13:21:37] j...@php.net

duh..I had a small copy-paste error. :D Reproduced with HEAD (PHP 6),
PHP_5_2 and PHP_5_3 give this error, no crash:

Warning: get_headers(): SSL operation failed with code 1. OpenSSL Error
messages:
error:14094410:SSL routines:func(148):reason(1040)
error:140940E5:SSL routines:func(148):reason(229) in Command line code
on line 1

Warning:
get_headers(https://fish-serv.dyndns.org/php_test/client_require.php):
failed to open stream: HTTP request failed!  in Command line code on
line 1





[2008-12-08 12:55:04] romanf at trash dot net

I have the same bug on two OpenSuse systems. 
Both have:

# rpm -q openssl
openssl-0.9.8e-45.5

installed. I used the following config to compile this mornings
snapshot:

./configure --enable-debug --with-mysql
--with-apxs2=/usr/local/apache2/bin/apxs --with-mcrypt --with-imap
--with-imap-ssl --with-gettext --with-zlib --with-openssl
--with-pdo-mysql --enable-mbstring=all --with-gd

Did you try the get_headers() against an HTTPS-Link that -requires- a
Client-Certificate? I can reproduce this on the test-pages given in my
samples *and* in a company-intranet...

Regards
Roman



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

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

#46699 [Ver->Csd]: xml_parse fails with Bus Error only when parser is namespace aware.

2008-12-11 Thread rrichards

 ID:   46699
 Updated by:   rricha...@php.net
 Reported By:  m dot haarmann at gmail dot com
-Status:   Verified
+Status:   Closed
 Bug Type: XML related
 Operating System: Mac OS 10.5.5
 PHP Version:  5.2CVS-2008-11-28
 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:


[2008-11-30 22:40:17] crrodriguez at opensuse dot org

Reproduced consistently in linux 64 bit. (5_2 and 5_3)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f697a693710 (LWP 31187)]
#0  0x in ?? ()
#1  0x00757e32 in _start_element_handler_ns (user=0xfde0c0,
name=0xff3a23 "stylesheet", prefix=0xff3a1f "xsl",
URI=0xff3a36 "http://www.w3.org/1999/XSL/Transform";,
nb_namespaces=2, namespaces=0xff4030, nb_attributes=1, nb_defaulted=0,
attributes=0xff3e30) at /home/cristian/php5/ext/xml/compat.c:131
#2  0x7f6978743dd8 in ?? () from /usr/lib64/libxml2.so.2
#3  0x7f697874a281 in xmlParseChunk () from
/usr/lib64/libxml2.so.2
#4  0x007588ea in php_XML_Parse (parser=0xfde0c0,
data=0xfdb318 "\n,
"xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\";
\nxmlns:foo=\"http://momo/\";>\n\n\t
http://www.w3.org/1999/XSL/Transform"; 
xmlns:foo="http://momo/";>


node






[2008-11-28 13:30:45] j...@php.net

Ok, is that demo.xml available somewhere?



[2008-11-28 12:58:12] m dot haarmann at gmail dot com

still same error with snapshot.



[2008-11-28 12:29: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/





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

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

#46756 [Ver->Csd]: curl_copy_handle crashes with curl_multi

2008-12-11 Thread magicaltux

 ID:   46756
 Updated by:   magical...@php.net
 Reported By:  kyle at ifixit dot com
-Status:   Verified
+Status:   Closed
 Bug Type: cURL related
 Operating System: *
 PHP Version:  5CVS, 6CVS (2008-12-08)
 New Comment:

This bug has been fixed in libcurl's CVS.

Snapshots of libcurl's sources are packaged every day; this change
will be in the next snapshot. You can grab the snapshot at
http://cool.haxx.se/curl-daily/.
 
Thank you for the report, and for helping us make libcurl and PHP
better.


Previous Comments:


[2008-12-11 07:56:17] magical...@php.net

Confirmed against curl 7.19.2 and more debug data posted to libcurl's
bug tracker.

https://sourceforge.net/tracker/index.php?func=detail&aid=2416182&group_id=976&atid=100976



[2008-12-11 07:18:50] magical...@php.net

This bug has been reproduced without PHP by reproducing the same
sequence in C.

$ svn co http://ookoo.org/svn/snip/curl_bug
...
$ cd curl_bug
$ make
...
$ gdb ./curl_bug 
...
#0  0x7f81692626c9 in ?? () from /usr/lib/libcurl.so.4
#1  0x7f8169263ec4 in ?? () from /usr/lib/libcurl.so.4
#2  0x7f816926444c in Curl_connect () from /usr/lib/libcurl.so.4
#3  0x7f81692721ba in ?? () from /usr/lib/libcurl.so.4
#4  0x7f8169272a6e in curl_multi_perform () from
/usr/lib/libcurl.so.4
#5  0x00400b34 in main (argc=1, argv=0x7fff716a14d8) at
test.c:36

I'll build latest curl with debug mode, check if this can be
reproduced, and if so, I'll open a but on libcurl providing more debug
informations.



[2008-12-10 19:32:11] magical...@php.net

I checked the origin of the crash, and it seems that libcurl does NOT
behave good if you duplicate a handle while it's part of a curl_multi.

Calling curl_multi_remove_handle($mh, $conn[$i]); before $conn2[$i] =
curl_copy_handle($conn[$i]); fixes the issue.

Checking curl's documentation, I found it to be quite picky about
processing order. I believe this is either a bug in libcurl, or a
"feature".

libcurl's manpages are not providing exact informations about calling
curl_easy_duphandle() on a curl handle part of a curl_multi.

I'm going to investigate this more and either fix this bug (by
providing a patch) or mark it as bogus (if this is a curl feature).



[2008-12-08 11:33:38] j...@php.net

Verified with latest CVS + Curl 7.18.2



[2008-12-07 16:45:51] kyle at ifixit dot com

Reproducible using libcurl/7.19.2 OpenSSL/0.9.8b zlib/1.2.3
libidn/0.6.5 
on kernel 2.6.18-53.1.14.el5. This is not a new bug-- also reproducible

with PHP 5.2.6 and an older version of libcurl.



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

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

#46835 [Opn->Bgs]: saveHTML automatically replaces unicode letters to entities

2008-12-11 Thread rrichards

 ID:  46835
 Updated by:  rricha...@php.net
 Reported By: kasparsj at gmail dot com
-Status:  Open
+Status:  Bogus
 Bug Type:DOM XML related
 PHP Version: 5.2.8
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

This is the behavior exhibited from libxml2 when outputting in HTML 
format


Previous Comments:


[2008-12-11 12:16:37] kasparsj at gmail dot com

Description:

DOMDocument->saveHTML replaces not only predefined entities, but also
unicode letters, like Ä, Å¡, Ä. is this also as expected or a bug?

this is related to:
http://bugs.php.net/bug.php?id=37878

Reproduce code:
---
$doc = new DOMDocument('1.0', 'UTF-8');
$doc->substituteEntities = false;
$doc->appendChild($doc->createElement('p', 'Å¡aÄeÄ'));
var_dump($doc->saveHTML());

Expected result:

Å¡aÄeÄ

Actual result:
--
©šaēeā





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

#46841 [NEW]: Session_name issue

2008-12-11 Thread vijaybabur at mobiusservices dot in

From: vijaybabur at mobiusservices dot in
Operating system: Cent OS
PHP version:  5.2.8
PHP Bug Type: *General Issues
Bug description:  Session_name issue

Description:

Hi,

I think this is a bug. I am facing problem in handling more than one
session in a single page. 


When i set the session_name at first, it's working fine. But if i change
the session.name in the next looping, it has changed but the session values
doesn't get changed. It's showing the previous session value's only.

Reproduce code:
---
foreach ($projects as $key => $val)
{   
 ini_set('session.name',$val);
 session_name($val);
 session_start();
 session_regenerate_id(false);
 echo session_id();
 .
 .
 

 .
 session_write_close();
}

Expected result:

I need to handle more than one session values in a single page.


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

#46748 [Asn]: get_headers generates segmentation fault on HTTPS with SSLVerifyClient required

2008-12-11 Thread romanf at trash dot net

 ID:   46748
 User updated by:  romanf at trash dot net
 Reported By:  romanf at trash dot net
 Status:   Assigned
 Bug Type: HTTP related
 Operating System: Linux (OpenSuse 11)
 PHP Version:  5.2CVS-2008-12-08
 Assigned To:  scottmac
 New Comment:

What output -do- you get when you run the two tests?

-Roman


Previous Comments:


[2008-12-12 04:10:47] crrodriguez at opensuse dot org

Cannot reproduce in 5_2 nor 5_3.



[2008-12-08 13:51:50] scott...@php.net

I can't reproduce this on any of the branches now, though I only have
x86 to test.

Jani, any chance of a backtrace on HEAD?



[2008-12-08 13:28:50] paj...@php.net

Scott, please clarify it and add tests :)



[2008-12-08 13:22:31] j...@php.net

HEAD seems to crash when it tries to output the error message.



[2008-12-08 13:21:37] j...@php.net

duh..I had a small copy-paste error. :D Reproduced with HEAD (PHP 6),
PHP_5_2 and PHP_5_3 give this error, no crash:

Warning: get_headers(): SSL operation failed with code 1. OpenSSL Error
messages:
error:14094410:SSL routines:func(148):reason(1040)
error:140940E5:SSL routines:func(148):reason(229) in Command line code
on line 1

Warning:
get_headers(https://fish-serv.dyndns.org/php_test/client_require.php):
failed to open stream: HTTP request failed!  in Command line code on
line 1





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

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

#45989 [Com]: json_decode() passes through certain invalid JSON strings

2008-12-11 Thread kevin at metalaxe dot com

 ID:   45989
 Comment by:   kevin at metalaxe dot com
 Reported By:  steven at acko dot net
 Status:   Assigned
 Bug Type: JSON related
 Operating System: Mac OS X
 PHP Version:  5.2.6
 Assigned To:  magicaltux
 New Comment:

The JSON spec states:
"
A JSON text is a sequence of tokens.  The set of tokens includes six
   structural characters, strings, numbers, and three literal names.

A JSON text is a serialized object or array.
"

So, in order to maintain compliance, PHP must also support
non-objects/arrays as input properly.

If I understand your patch correctly:

If the input is json_decode("null"); the output would be NULL (I saw no
test case for null input in the patch itself). We would have no way of
knowing a problem exists if one were to have an input of
json_decode('[');.

Can't this function throw an exception on failure? Failing that,could
we at least get a PHP warning? Otherwise it will be impossible to full
rely on this function in the case where null is the actual input...


Previous Comments:


[2008-12-03 22:29:58] magical...@php.net

And here are patches against PHP_5_3 and HEAD:

http://ookoo.org/svn/snip/php_5_3-json-returntype-final-fix.patch

http://ookoo.org/svn/snip/php_head-json-returntype-final-fix.patch

Some tests now work on json on HEAD (less failure than what's currently
displayed on gcov.php.net) but still two fails. As those failures are
not within the scope of this bug (and are specific to HEAD) they be
fixed in different patches.

I believe that once this is commited to the CVS, this bug should be
marked as "To be documented". I also believe till wants to submit some
additional tests for those this issue...



[2008-12-03 21:17:33] magical...@php.net

Just a note for documentation:

http://docs.php.net/json_decode

Right now the documentation says the function returns an object, OR an
array. This is not strictly true as it may return a string, a boolean,
an integer, a double... depending on the input.

Also, the fact json_decode() may return NULL on error isn't explicitly
documented either, instead some examples which happens to return NULL
with the current implementation are provided. I think it would be a good
idea to explicitly document this behavior, if the change I'm proposing
here is accepted.



[2008-12-03 21:10:50] magical...@php.net

Ok guys, I've had a look at the CVS history for json, and checked why
it was following this weird behaviour (returning what was passed in some
cases, and NULL in other cases).

The CVS commit log message for this relates to bug #38680, however it
seems that the behaviour in parsing strings not handled by json is doing
too much to try to "fix" things and find a way to provide parsed value.

Anyway here's a patch that changes this behaviour to make json_decode()
return NULL when we get invalid JSON data, while still keeping null,
true, false and integers parsing.

Some tests were fixed (the result depended on broken behaviour), and
the other tests still run fine.


The patch itself, against PHP_5_2:

http://ookoo.org/svn/snip/php_5_2-json-returntype-final-fix.patch


If nobody can find anything against this (being a bit more strict with
obviously wrong values) I'll add patchs against HEAD and PHP_5_3.



[2008-12-02 18:52:36] steven at acko dot net

till said:
"but it's supposed to return the string as is -- in case it's a literal

type, but why does it in some cases return "null" then?"

What argument is there for having (some) unparseable sequences returned

as is? If json_decode() returns a string, then that should mean that
the 
input was a valid JSON encoding of that string, no?

The only literal types JSON allows are numbers and the pre-defined 
constants 'true' 'false' and 'null'. Strings must be quote-delimited.

The fact that you can switch between 'return NULL' and 'return the 
argument as-is' just by adding/removing a leading space is a pretty big

sign that something is wrong here. To be honest, it seems a bit silly 
that this is even an argument.



[2008-12-01 17:16:06] t...@php.net

Just to add to this:

I know that the function is not supposed to be a JSON validator, but
it's supposed to return the string as is -- in case it's a literal type,
but why does it in some cases return "null" then?

For example:
$bad_json = "{ 'bar': 'baz' }";
json_decode($bad_json); // null

I know this is "probably" an edge-case but $bad_json could be my own
/valid/ string -- not valid JSON. Because a string could look like
anything. Point well taken, I'm passing in a pretty /funky/ looking
string. But instead of "NULL", json_decode should retu

#46842 [NEW]: calls to mysql_connect crash

2008-12-11 Thread pdp2108 at gmail dot com

From: pdp2108 at gmail dot com
Operating system: Windows XP SP2
PHP version:  5.2.8
PHP Bug Type: Reproducible crash
Bug description:  calls to mysql_connect crash

Description:

I have an isolated test case that reliably generates a segmentation fault
in php5ts.dll. 

Here is the environment:

Windows XP, SP2, Single Athlon 64 3200+ CPU, 1 GB RAM

MySQL version 5.1.30 for Win32
Apache version 2.2.10 for Win32
PHP 5.2.8

PHP was installed with the .msi installer.  The following extensions were
added at installation:  GD, mysql, mysqli and multi-byte string.

I have configured Apache & MySQL and have created some databases, which I
can access through mysql and Navicat.  I have used a simple phpinfo.php
script to track down an incorrect libmysql.dll in my path and have
eliminated that and have verified that the client version of libmysql is
5.1.30 in phpinfo.



Reproduce code:
---



Expected result:

One expects to see the "Past mysql_connect" statement print out.

Actual result:
--
Thread 0 - System ID 4232
Entry point   php!mainCRTStartup 
Create time   12/12/2008 2:17:59 AM 
Time spent in user mode   0 Days 0:0:0.0 
Time spent in kernel mode   0 Days 0:0:0.31 






Function Arg 1 Arg 2 Arg 3   Source 
php5ts!zend_mm_search_large_block+fa 00f35230 0048
001c
php5ts!_zend_mm_alloc_int+153  003f 1009ba69
php5ts!_emalloc+39 003f 0111c4c8 00f327a0
php5ts!_zend_hash_add_or_update+2d9 00f36148 0111c4e0 001c
   
php_mysql!php_mysql_do_connect+867 0111c460 0111c4c8  
  
php_mysql!zif_mysql_connect+25 0003 0111c4c8 
php5ts!zend_do_fcall_common_helper_SPEC+7d9 00c0fbd0 00f327a0
0111be8c
php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+e5  00f327a0
00f327a0
php5ts!execute+1c5 0111be98 00f327a0 
php5ts!zend_execute_scripts+107 0008 00f327a0    

php5ts!php_execute_script+20d 00c0fec8 00f327a0 000e
php!main+bca 0003 00f33fd0 00f32d60
php!mainCRTStartup+e3 000e  7ffdf000
kernel32!BaseProcessStart+23 00402f72  




PHP5TS!ZEND_MM_SEARCH_LARGE_BLOCK+FAIn
php__PID__3284__Date__12_12_2008__Time_02_18_29AM__734__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!zend_mm_search_large_block+fa in
C:\PHP\php5ts.dll from The PHP Group has caused an access violation
exception (0xC005) when trying to read from memory location 0x0014
on thread 0

Module Information 
Image Name: C:\PHP\php5ts.dll   Symbol Type:  PDB 
Base address: 0x1000   Time Stamp:  Mon Dec 08 14:31:08 2008  
Checksum: 0x   Comments:   
COM DLL: False   Company Name:  The PHP Group 
ISAPIExtension: False   File Description:  PHP Script Interpreter 
ISAPIFilter: False   File Version:  5.2.8.8 
Managed DLL: False   Internal Name:  php5ts.dll 
VB DLL: False   Legal Copyright:  Copyright © 1997-2007 The PHP Group 
Loaded Image Name:  php5ts.dll   Legal Trademarks:  PHP 
Mapped Image Name:  C:\PHP\php5ts.dll   Original filename:  php5ts.dll 
Module name:  php5ts   Private Build:   
Single Threaded:  False   Product Name:  PHP Script Interpreter 
Module Size:  4.98 MBytes   Product Version:  5.2.8 
Symbol File Name:  C:\PHP_Debug\php5ts.pdb   Special Build:  & 


-- 
Edit bug report at http://bugs.php.net/?id=46842&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46842&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46842&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46842&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46842&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=46842&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46842&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=46842&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=46842&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=46842&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=46842&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=46842&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=46842&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=46842&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46842&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=46842&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46842&r=dst
IIS Stability:   
h

#46830 [Opn->Bgs]: unexpected termination

#46803 [Com]: Sqlite-PDO prepared statement doesn't return any rows when used with bind vars

#46834 [NEW]: Range of mcrypt functions fail on PHP 6.0

#46808 [Com]: Mysqli crashes on LONGTEXT columns

#46803 [Opn->Fbk]: Sqlite-PDO prepared statement doesn't return any rows when used with bind vars

#46834 [Opn->Asn]: Range of mcrypt functions fail on PHP 6.0

#46835 [NEW]: saveHTML automatically replaces unicode letters to entities

#45161 [Opn]: Reusing a curl handle leaks memory

#46832 [Opn->Bgs]: memleak on handles duplicated with curl_copy_handle()

#46803 [Com]: Sqlite-PDO prepared statement doesn't return any rows when used with bind vars

#46836 [NEW]: $_SERVER['PHP_SELF'] path repeated

#46837 [NEW]: imap. Invalid CL_EXPUNGE are not caught.

#35345 [Com]: SQLite won't load (specified module not found)

#46808 [Com]: Mysqli crashes on LONGTEXT columns

#35345 [NoF->Bgs]: SQLite won't load (specified module not found)

#44963 [Com]: Problem with installer package

#13421 [Com]: Problematic MIME-Type "application/x-httpd-php"

#44963 [Com]: Problem with installer package

#40034 [Com]: mssql_connect(): Unable to connect to server

#46839 [NEW]: cant compile 5.2.8 with imap c-client compiled manualy

#46796 [Fbk->Opn]: make test: Error 137

#46840 [NEW]: ln: creating symbolic link `..phar': File exists

#46748 [Com]: get_headers generates segmentation fault on HTTPS with SSLVerifyClient required

#46699 [Ver->Csd]: xml_parse fails with Bus Error only when parser is namespace aware.

#46756 [Ver->Csd]: curl_copy_handle crashes with curl_multi

#46835 [Opn->Bgs]: saveHTML automatically replaces unicode letters to entities

#46841 [NEW]: Session_name issue

#46748 [Asn]: get_headers generates segmentation fault on HTTPS with SSLVerifyClient required

#45989 [Com]: json_decode() passes through certain invalid JSON strings

#46842 [NEW]: calls to mysql_connect crash

30 matches

Site Navigation

Mail list logo

Footer information