Bug #52211 [Csd->ReO]: iconv() returns part of string on error

2011-12-18 Thread ezyang 
Edit report at https://bugs.php.net/bug.php?id=52211&edit=1

 ID: 52211
 Updated by: ezy...@php.net
 Reported by:raphgivernaud at yahoo dot fr
 Summary:iconv() returns part of string on error
-Status: Closed
+Status: Re-Opened
 Type:   Bug
 Package:ICONV related
 Operating System:   Windows Vista
 PHP Version:5.3.2
 Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

I don't think this bug was fixed correctly. In particular, iconv doesn't handle 
'//IGNORE' correctly now.

ezyang@javelin:~$ cat test.php
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

This bug has been only fixed on trunk, because from what I can see, it might 
cause BC issue on 5.3 series.


[2010-07-01 03:11:10] fel...@php.net

Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=300894
Log: - Fixed bug #52211 (iconv() returns part of string on error)




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

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


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

Bug #48147 [Bgs]: iconv with //IGNORE cuts the string

2011-12-18 Thread ezyang 
Edit report at https://bugs.php.net/bug.php?id=48147&edit=1

 ID: 48147
 Updated by: ezy...@php.net
 Reported by:kulakov74 at yandex dot ru
 Summary:iconv with //IGNORE cuts the string
 Status: Bogus
 Type:   Bug
 Package:ICONV related
 Operating System:   Linux
 PHP Version:5.*, 6CVS (2009-05-05)
 Block user comment: N
 Private report: N

 New Comment:

Not broken in latest version of libiconv

ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n --version
iconv (GNU libiconv 1.14)
Copyright (C) 2000-2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.
ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n -f utf-8 -t 
iso-8859-1//IGNORE ~/iconv.html | wc -c
15312
ezyang@javelin:~/Desktop/libiconv-1.14/src$ iconv -f utf-8 -t 
iso-8859-1//IGNORE ~/iconv.html | wc -c
iconv: illegal input sequence at position 8168
8157


Previous Comments:

[2009-05-07 13:58:21] j...@php.net

We still can't fix bugs in glibc iconv implementation. Try this on 
command line and you get same results:

# iconv -f utf-8 -t iso-8859-1 iconv.html > /dev/null
iconv: illegal input sequence at position 3589

# iconv -f utf-8 -t iso-8859-1//IGNORE iconv.html > /dev/null
iconv: illegal input sequence at position 8168



[2009-05-07 07:50:52] lbarn...@php.net

Marked it as verified as I got exactly the same results:

The first iconv() call (the one without //IGNORE) fails on the emphasis 
character "…" (value="Search…"), which can't be represented in ISO-8859-1.

The second iconv() call (the one with //IGNORE) fails later (so the emphasis is 
ignored, which may means that the //IGNORE flag is supported), and there is no 
apparent reason for failing at offset 8157 (only regular ASCII chars around).


[2009-05-06 18:36:10] j...@php.net

Arnaud: Please don't reopen bogus bugs without explanation. 


[2009-05-06 18:18:07] kulakov74 at yandex dot ru

No. The fact the script displays the notice "iconv(): Detected an illegal 
character ..." in both cases is not related to the fact whether the option is 
implemented: this is controlled by error_reporting(E_ALL). The option IGNORE 
only controls whether iconv will stop at the character or not. 

Also, the length of the resulting string is different (greater) with IGNORE, 
and while without it the string ends at exactly where the illegal character is, 
with IGNORE it ends at a random point where no such characters occur. 

Also, I did not mention - this is not the only file I converted, many others 
were converted correctly with the option, and their length only decreased a 
little. But there were 2 files which were truncated, 1 of them (the smaller) is 
used for the test case. 

Can you run the test with the latest PHP releases? Actually this is why I 
reported the bug. I tried it on other servers with PHP 4.3.3, 5.1.4, 5.1.6, 
5.2.4 and 5.2.6 and yep! - I finally found one with 5.2.9 (built Feb 27 2009) 
and it displayed the same results everywhere. 

I repeat, the TRANSLIT option works fine, while it does the same and even more.


[2009-05-06 14:38:39] j...@php.net

It just means you're using glibc iconv implementation which does not 
have the IGNORE parameter implemented.




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

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


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

Bug #48147 [Bgs]: iconv with //IGNORE cuts the string

2011-12-18 Thread ezyang 
Edit report at https://bugs.php.net/bug.php?id=48147&edit=1

 ID: 48147
 Updated by: ezy...@php.net
 Reported by:kulakov74 at yandex dot ru
 Summary:iconv with //IGNORE cuts the string
 Status: Bogus
 Type:   Bug
 Package:ICONV related
 Operating System:   Linux
 PHP Version:5.*, 6CVS (2009-05-05)
 Block user comment: N
 Private report: N

 New Comment:

Upstream bugs:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=13517
http://sources.redhat.com/bugzilla/show_bug.cgi?id=13518


Previous Comments:

[2011-12-18 19:37:53] ezy...@php.net

Not broken in latest version of libiconv

ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n --version
iconv (GNU libiconv 1.14)
Copyright (C) 2000-2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.
ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n -f utf-8 -t 
iso-8859-1//IGNORE ~/iconv.html | wc -c
15312
ezyang@javelin:~/Desktop/libiconv-1.14/src$ iconv -f utf-8 -t 
iso-8859-1//IGNORE ~/iconv.html | wc -c
iconv: illegal input sequence at position 8168
8157


[2009-05-07 13:58:21] j...@php.net

We still can't fix bugs in glibc iconv implementation. Try this on 
command line and you get same results:

# iconv -f utf-8 -t iso-8859-1 iconv.html > /dev/null
iconv: illegal input sequence at position 3589

# iconv -f utf-8 -t iso-8859-1//IGNORE iconv.html > /dev/null
iconv: illegal input sequence at position 8168



[2009-05-07 07:50:52] lbarn...@php.net

Marked it as verified as I got exactly the same results:

The first iconv() call (the one without //IGNORE) fails on the emphasis 
character "…" (value="Search…"), which can't be represented in ISO-8859-1.

The second iconv() call (the one with //IGNORE) fails later (so the emphasis is 
ignored, which may means that the //IGNORE flag is supported), and there is no 
apparent reason for failing at offset 8157 (only regular ASCII chars around).


[2009-05-06 18:36:10] j...@php.net

Arnaud: Please don't reopen bogus bugs without explanation. 


[2009-05-06 18:18:07] kulakov74 at yandex dot ru

No. The fact the script displays the notice "iconv(): Detected an illegal 
character ..." in both cases is not related to the fact whether the option is 
implemented: this is controlled by error_reporting(E_ALL). The option IGNORE 
only controls whether iconv will stop at the character or not. 

Also, the length of the resulting string is different (greater) with IGNORE, 
and while without it the string ends at exactly where the illegal character is, 
with IGNORE it ends at a random point where no such characters occur. 

Also, I did not mention - this is not the only file I converted, many others 
were converted correctly with the option, and their length only decreased a 
little. But there were 2 files which were truncated, 1 of them (the smaller) is 
used for the test case. 

Can you run the test with the latest PHP releases? Actually this is why I 
reported the bug. I tried it on other servers with PHP 4.3.3, 5.1.4, 5.1.6, 
5.2.4 and 5.2.6 and yep! - I finally found one with 5.2.9 (built Feb 27 2009) 
and it displayed the same results everywhere. 

I repeat, the TRANSLIT option works fine, while it does the same and even more.




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

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


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

Bug #48147 [Bgs->ReO]: iconv with //IGNORE cuts the string

2011-12-22 Thread ezyang 
Edit report at https://bugs.php.net/bug.php?id=48147&edit=1

 ID: 48147
 Updated by: ezy...@php.net
 Reported by:kulakov74 at yandex dot ru
 Summary:iconv with //IGNORE cuts the string
-Status: Bogus
+Status: Re-Opened
 Type:   Bug
 Package:ICONV related
 Operating System:   Linux
 PHP Version:5.*, 6CVS (2009-05-05)
 Block user comment: N
 Private report: N

 New Comment:

I think I understand how to fix this bug, without modifying glibc. We need to 
modify our invocation of iconv in order to mirror the behavior of 
iconv_prog.c:process_block() when the '-c' flag is set (if we mimic the code 
closely enough, we also get an extra bonus of sensible block processing 
behavior, which is better than the horrible over-allocation iconv does right 
now). In particular, we need to handle the EILSEQ error code correctly.


Previous Comments:

[2011-12-18 22:34:38] ezy...@php.net

Upstream bugs:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=13517
http://sources.redhat.com/bugzilla/show_bug.cgi?id=13518


[2011-12-18 19:37:53] ezy...@php.net

Not broken in latest version of libiconv

ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n --version
iconv (GNU libiconv 1.14)
Copyright (C) 2000-2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.
ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n -f utf-8 -t 
iso-8859-1//IGNORE ~/iconv.html | wc -c
15312
ezyang@javelin:~/Desktop/libiconv-1.14/src$ iconv -f utf-8 -t 
iso-8859-1//IGNORE ~/iconv.html | wc -c
iconv: illegal input sequence at position 8168
8157


[2009-05-07 13:58:21] j...@php.net

We still can't fix bugs in glibc iconv implementation. Try this on 
command line and you get same results:

# iconv -f utf-8 -t iso-8859-1 iconv.html > /dev/null
iconv: illegal input sequence at position 3589

# iconv -f utf-8 -t iso-8859-1//IGNORE iconv.html > /dev/null
iconv: illegal input sequence at position 8168



[2009-05-07 07:50:52] lbarn...@php.net

Marked it as verified as I got exactly the same results:

The first iconv() call (the one without //IGNORE) fails on the emphasis 
character "…" (value="Search…"), which can't be represented in ISO-8859-1.

The second iconv() call (the one with //IGNORE) fails later (so the emphasis is 
ignored, which may means that the //IGNORE flag is supported), and there is no 
apparent reason for failing at offset 8157 (only regular ASCII chars around).


[2009-05-06 18:36:10] j...@php.net

Arnaud: Please don't reopen bogus bugs without explanation. 




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

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


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

Bug #63450 [ReO]: iconv returns false when illegal character encountered

2013-03-07 Thread ezyang 
Edit report at https://bugs.php.net/bug.php?id=63450&edit=1

 ID: 63450
 Updated by: ezy...@php.net
 Reported by:trollofdarkness at gmail dot com
 Summary:iconv returns false when illegal character
 encountered
 Status: Re-Opened
 Type:   Bug
 Package:ICONV related
 Operating System:   Debian 5 Lenny
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

This is a dupe of https://bugs.php.net/bug.php?id=48147 (not that I don't think 
it should be fixed!) Here is the glibc bug: 
http://sourceware.org/bugzilla/show_bug.cgi?id=13541


Previous Comments:

[2012-11-08 02:24:27] ahar...@php.net

Reopening per above. Anyone more familiar with iconv and the build system want 
to opine?


[2012-11-07 21:58:24] trollofdarkness at gmail dot com

Hi,

So, I had a look at it and this is not a libiconv related bug. It is a glibc 
related bug (so, iconv, but the glibc implementation) as I was not using the 
GNU 
libiconv implementation but the glibc one.

Actually, I had the 2.7 version of glibc. I tested on another machine - a 
Ubuntu 
12.04 LTS server - where the glibc version was 2.14 and, indeed, the bug was 
not 
present. So it is in recent versions of glibc.

To correct the problem on Debian, you can recompile PHP to use the libiconv 
implementation instead of the glibc one.

But it is NOT quite easy because PHP looks for glic implementation BEFORE 
libiconv and select it if present... even with every --with-iconv=something 
parameter you can use when running ./configure.

I used the solution presented there : 
 and as one 
of 
the comments states, I had to change global configure file and not (only) the 
one of ext/iconv. (note that, first, you have to actually download libiconv and 
compile it... but that's just wget && ./configure && make && make install).

I now have the libiconv implementation in use and it's working perfectly.

I storngly think PHP should change the behaviour of the configure file, we 
should not have to edit it to use the libiconv implementation, we should just 
be 
able to use the right configure parameter!


[2012-11-06 22:19:13] trollofdarkness at gmail dot com

Hi Rasmus,

Thanks for your help!

I will have a look at that on the spot and will post an update to say if it 
works 
to downgrade the libiconv.


[2012-11-06 21:54:00] ras...@php.net

This is not a PHP issue. This is a change in recent versions of libiconv. If 
you 
link PHP against an older version of libiconv it will work again or you can use 
mbstring_convert_encoding(). And we have a new uconverter extension feature 
coming that will do a better job than either of these. See 
https://wiki.php.net/rfc/uconverter


[2012-11-06 21:45:33] trollofdarkness at gmail dot com

Description:

Hi everyone,

I have been, since I think the version 5.3.x is out (and still with 5.4.8), 
experiencing issues with iconv.


Especially, when an illegal character is encountered and the //IGNORE flag is 
set on the target charset, the function returns FALSE instead of just skipping 
this character.

This is problematic because if a single character in a 50 000 chars long string 
is "illegal" then the output is nothing, just for one char... 

It does not happen with the TRANSLIT flag.

I experienced that with UTF8 (from) and ISO-8859-15 (to) charsets, I did not 
test with other ones. Below is an example to reproduce the bug.

Note : I saw there are other bug reports about similar issues, but they're all 
saying the string is cut... In my case, it literally returns false. So, might 
be 
different? 

Test script:
---


Expected result:

foo

foo


Actual result:
--
false






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

#46338 [Opn->Ver]: Segfault on script ending

2008-10-20 Thread ezyang 
 ID:   46338
 Updated by:   [EMAIL PROTECTED]
 Reported By:  spam at pamignot dot org
-Status:   Open
+Status:   Verified
 Bug Type: Scripting Engine problem
-Operating System: Linux 2.6.22-15-generic (Ubuntu)
+Operating System: Irrelevant
 PHP Version:  5.3.0alpha2
 New Comment:

I believe this is a problem with the error handler stack. I get
"zend_mm_heap corrupted" when I set the error handler twice.

purify('something');
set_error_handler(array('myException', 'exception_error_handler'));

?>



[2008-10-20 15:51:12] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2008-10-18 21:52:49] spam at pamignot dot org

Surely not related to Apache2, but maybe GC (?), deplaced in
Unknown/Other.



[2008-10-18 21:27:58] spam at pamignot dot org

Description:

I just passed from 5.1.6 to 5.3.

I cannot give a quick code to reproduce the bug, but the script
actually does those actions :
- getting GET POST COOKIE information, giving them to HTMLPurifier and
set an array of the result
- define custom error handler
- execute action given by user
- display HTML result page

The script goes to the end, echo'ing wanted html page but it results in
a segfault.

If I comment out the next line, or if I comment out the static method
'exception_error_handler' from my class MyException, the script just
works fine :

set_error_handler(array('MyException', 'exception_error_handler'));

But if I let declared the method 'exception_error_handler', even with
no code inside, returning true or false, or throwing an exception, the
script ends up with a segfault.


Reproduce code:
---
/* some code using some PEAR packages, 
custom error handler, echo'ing a HTML page */
exit();

Expected result:

Expected result is displaying HTML page to user.

Actual result:
--
The actual result is the output of my desired HTML page, ending with a
segfault :

# gdb php
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library
"/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r index.php
Starting program: /usr/local/bin/php index.php
[Thread debugging using libthread_db enabled]
[New Thread -1223292352 (LWP 21507)]

/* here comes my HTML page */

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223292352 (LWP 21507)]
zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) bt
#0  zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
#1  0x083d34e7 in _zval_dtor_func (zvalue=0x8ce9a78) at
/home/myhome/php-5.3.0alpha2/Zend/zend_variables.c:43
#2  0x083d2c55 in zend_ptr_stack_apply (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>) at
/home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:90
#3  0x083d2c9f in zend_ptr_stack_clean (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>, free_elements=1 '\001')
at /home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:97
#4  0x083c67f9 in shutdown_executor (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend_execute_API.c:271
#5  0x083d3ab9 in zend_deactivate (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend.c:899
#6  0x0837995a in php_request_shutdown (dummy=0x0) at
/home/myhome/php-5.3.0alpha2/main/main.c:1516
#7  0x0846a6da in main (argc=2, argv=0xbfc9d7a4) at
/home/myhome/php-5.3.0alpha2/sapi/cli/php_cli.c:1311
(gdb) 


When I try from my browser and gdb "run -X" option, the backtrace looks
like this :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216632640 (LWP 21116)]
zend_hash_destroy (ht=0x85e50e8) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) bt
#0  zend_hash_destroy (ht=0x85e50e8) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
#1  0xb72b9a57 in _zval_dtor_func (zvalue=0x85e509c) at
/home/myhome/php-5.3.0alpha2/Z

#46338 [Ver]: Segfault on script ending

2008-10-20 Thread ezyang 
 ID:   46338
 Updated by:   [EMAIL PROTECTED]
 Reported By:  spam at pamignot dot org
 Status:   Verified
 Bug Type: Scripting Engine problem
 Operating System: Irrelevant
-PHP Version:  5.3.0alpha2
+PHP Version:  5.3.0alpha3-dev
 New Comment:

Oh, also, I tested it on the latest alpha3-dev build.

php --version
PHP 5.3.0alpha3-dev (cli) (built: Oct 20 2008 20:49:57)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies


Previous Comments:


[2008-10-20 18:54:55] [EMAIL PROTECTED]

I believe this is a problem with the error handler stack. I get
"zend_mm_heap corrupted" when I set the error handler twice.

purify('something');
set_error_handler(array('myException', 'exception_error_handler'));

?>



[2008-10-20 15:51:12] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2008-10-18 21:52:49] spam at pamignot dot org

Surely not related to Apache2, but maybe GC (?), deplaced in
Unknown/Other.



[2008-10-18 21:27:58] spam at pamignot dot org

Description:

I just passed from 5.1.6 to 5.3.

I cannot give a quick code to reproduce the bug, but the script
actually does those actions :
- getting GET POST COOKIE information, giving them to HTMLPurifier and
set an array of the result
- define custom error handler
- execute action given by user
- display HTML result page

The script goes to the end, echo'ing wanted html page but it results in
a segfault.

If I comment out the next line, or if I comment out the static method
'exception_error_handler' from my class MyException, the script just
works fine :

set_error_handler(array('MyException', 'exception_error_handler'));

But if I let declared the method 'exception_error_handler', even with
no code inside, returning true or false, or throwing an exception, the
script ends up with a segfault.


Reproduce code:
---
/* some code using some PEAR packages, 
custom error handler, echo'ing a HTML page */
exit();

Expected result:

Expected result is displaying HTML page to user.

Actual result:
--
The actual result is the output of my desired HTML page, ending with a
segfault :

# gdb php
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library
"/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r index.php
Starting program: /usr/local/bin/php index.php
[Thread debugging using libthread_db enabled]
[New Thread -1223292352 (LWP 21507)]

/* here comes my HTML page */

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223292352 (LWP 21507)]
zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) bt
#0  zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
#1  0x083d34e7 in _zval_dtor_func (zvalue=0x8ce9a78) at
/home/myhome/php-5.3.0alpha2/Zend/zend_variables.c:43
#2  0x083d2c55 in zend_ptr_stack_apply (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>) at
/home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:90
#3  0x083d2c9f in zend_ptr_stack_clean (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>, free_elements=1 '\001')
at /home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:97
#4  0x083c67f9 in shutdown_executor (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend_execute_API.c:271
#5  0x083d3ab9 in zend_deactivate (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend.c:899
#6  0x0837995a in php_request_shutdown (dummy=0x0) at
/home/myhome/php-5.3.0alpha2/main/main.c:1516
#7  0x0846a6da in main (argc=2, argv=0xbfc9d7a4) at
/home/myhome/php-5.3.0alpha2/sapi/cli/php_cli.c:1311
(gdb) 


When I try from my browser and gdb "run -X" option, the backtrace looks
like this :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216632640 (LWP 21116)]
zend_hash_destroy (ht=0x85e50e8) at

#46338 [Ver]: Segfault on multiple error handler

2008-10-21 Thread ezyang 
 ID:   46338
 Updated by:   [EMAIL PROTECTED]
 Reported By:  spam at pamignot dot org
 Status:   Verified
 Bug Type: Scripting Engine problem
 Operating System: Irrelevant
 PHP Version:  5.3.0alpha3-dev
 New Comment:

Yeah, these are most definitely duplicates. (Doesn't know how to close
a bug as a dupe).


Previous Comments:


[2008-10-21 06:35:17] clemens dot kalb at netlogix dot de

Setting the error handler twice does indeed seem to be the problem. I
can reproduce this with 5.3 alpha3-dev Build Date Oct 19 2008 04:42:11.
See #46241 for a possible duplicate of this entry.



[2008-10-20 19:00:28] [EMAIL PROTECTED]

Oh, also, I tested it on the latest alpha3-dev build.

php --version
PHP 5.3.0alpha3-dev (cli) (built: Oct 20 2008 20:49:57)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies



[2008-10-20 18:54:55] [EMAIL PROTECTED]

I believe this is a problem with the error handler stack. I get
"zend_mm_heap corrupted" when I set the error handler twice.

purify('something');
set_error_handler(array('myException', 'exception_error_handler'));

?>



[2008-10-20 15:51:12] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





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

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

#46241 [Opn->Ctl]: Error handler stacking broken

2008-10-22 Thread ezyang 
 ID:   46241
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Critical
 Bug Type: Reproducible crash
 Operating System: Gentoo
 PHP Version:  5.3.0alpha2
 New Comment:

Upgrading to critical, as it is a crash and clear breakage of
functionality.


Previous Comments:


[2008-10-21 21:04:33] clemens dot kalb at netlogix dot de

Here is one thing that has been more clear in the other, duplicate and
now closed - bug entry (#46338). The first code sample with object
methods does not only miss out on the second error handler, it also
segfaults *on shutdown* of the PHP process:

---SNIP-
Starting program: /usr/bin/php5 segfault2.php
[Thread debugging using libthread_db enabled]
[New Thread -1215695168 (LWP 5622)]
Caught on first level: 'Foo'

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1215695168 (LWP 5622)]
zend_hash_destroy (ht=0xb786bf08) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) bt
#0  zend_hash_destroy (ht=0xb786bf08) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_hash.c:524
#1  0x0836dc41 in _zval_dtor_func (zvalue=0xb786bf70) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_variables.c:43
#2  0x0836d3b3 in zend_ptr_stack_apply (stack=0x880d470, func=0x836dbf0
<_zval_dtor_func>) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_ptr_stack.c:90
#3  0x0836d3fd in zend_ptr_stack_clean (stack=0x880d470, func=0x836dbf0
<_zval_dtor_func>, free_elements=1 '\001')
at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_ptr_stack.c:97
#4  0x08360f68 in shutdown_executor () at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_execute_API.c:272
#5  0x0836e28b in zend_deactivate () at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend.c:899
#6  0x08316df6 in php_request_shutdown (dummy=0x0) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/main/main.c:1522
#7  0x08408203 in main (argc=2, argv=0xbffa0b14) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/sapi/cli/php_cli.c:1311
---SNAP-

The problem persists with PHP 5.3.0alpha3-dev (cli) (built: Oct 21 2008
22:10:26).



[2008-10-06 13:03:21] [EMAIL PROTECTED]

Description:

Stacking 2 error handlers is broken. With object methods only the first
error handler is invoked, with functions I even get a PHP crash.

Reproduce code:
---
-- Object methods ---



-- Functions ---



Expected result:

-- Object methods ---
Caught on second level: 'Foo'
-- Functions ---
Caught on second level: 'Foo'

Actual result:
--
-- Object methods --- 
Caught on first level: 'Foo'
-- Functions ---
Caught on first level: 'Foo'
zend_mm_heap corrupted





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

#46656 [Fbk->Opn]: Crash on array allocation/gc

2008-11-25 Thread ezyang 
 ID:   46656
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows Vista
 PHP Version:  5.3CVS-2008-11-24 (snap)
 New Comment:

Nope, I cannot reproduce on the latest 5.3 snap on Ubuntu Linux
Intrepid.


Previous Comments:


[2008-11-25 08:37:04] [EMAIL PROTECTED]

Can you reproduce this on a real OS, like some Linux for example?



[2008-11-24 00:38:39] [EMAIL PROTECTED]

Description:

I am getting a crash on the following code:

class SimpleMock {
// ...
function SimpleMock() {
$this->actions = new SimpleCallSchedule();
$this->expectations = new SimpleCallSchedule();
$this->call_counts = array();
$this->expected_counts = array(); // here
$this->max_counts = array();
$this->expected_args = array();
$this->expected_args_at = array();
$this->getCurrentTestCase()->tell($this);
}

Which is quite strange, because allocating an array shouldn't cause a
crash! Here is the stack dump:

Thread 0 - System ID 4752
Entry point   php+2af2 
Create time   11/23/2008 7:29:25 PM 
Time spent in user mode   0 Days 0:0:3.73 
Time spent in kernel mode   0 Days 0:0:1.669 

Function Arg 1 Arg 2 Arg 3   Source 
php5!zend_hash_apply+5  1008ff40 1008fe0d
php5!gc_collect_cycles+2fc 04895474 00c0eb10 04ab4898
php5!gc_collect_cycles+24d 04ab0ab8 04ab4898 105286f0
php5!gc_collect_cycles+4b 04ab4898 1008cfaa 04ab4898
php5!gc_zval_possible_root+ce      


PHP5!ZEND_HASH_APPLY+5WARNING - DebugDiag was not able to locate debug
symbols for php5.dll, so the information below may be incomplete.

In
php__PID__4896__Date__11_23_2008__Time_07_30_05PM__248__Second_Chance_Exception_C005.dmp
the assembly instruction at php5!zend_hash_apply+5 in
C:\Software\PHP\versions\5.3.0alpha3-dev\php5.dll from The PHP Group has
caused an access violation exception (0xC005) when trying to read
from memory location 0x0026 on thread 0

I might be doing something wrong with regards to setting up the
backtrace, since it's complaining about php5.dll even though I do have
php5.dbg in my path. If you need a better backtrace, I can see what I
can do.

If you're interested in attempting to reproduce this, the configuration
is fairly standard. Use the instructions here
 to setup the HTML Purifier
development environment, and run the full test suite. (It doesn't work
if you try to run just the test that PHP dies on, or try to run it by
parts.)






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

#46656 [Opn]: Crash on array allocation/gc

2008-12-08 Thread ezyang 
 ID:   46656
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: win32 only - Windows Vista
 PHP Version:  5.3CVS-2008-11-24 (snap)
 New Comment:

No luck. Poke me if any of you try to set things up on Windows.


Previous Comments:


[2008-12-09 03:05:14] [EMAIL PROTECTED]

Some new information about reproducing:

I have been able to reproduce on another machine, but not without a
little bit of coaxing. In particular, these conditions must be met:

* PHPT tests must be set up. If they are skipped, the segfault does not
occur.

* `php tests/index.php` --flush must be run with a PHP 5.2 version,
prior to running `php tests/index.php` with a PHP 5.3 snap. The segfault
does not occur on a cold run of the test suite.

It might be possible to reproduce on Linux; I'm currently
reconstructing the experimental setup and will report back.



[2008-11-25 17:49:07] [EMAIL PROTECTED]

Nope, I cannot reproduce on the latest 5.3 snap on Ubuntu Linux
Intrepid.



[2008-11-25 08:37:04] [EMAIL PROTECTED]

Can you reproduce this on a real OS, like some Linux for example?



[2008-11-24 00:38:39] [EMAIL PROTECTED]

Description:

I am getting a crash on the following code:

class SimpleMock {
// ...
function SimpleMock() {
$this->actions = new SimpleCallSchedule();
$this->expectations = new SimpleCallSchedule();
$this->call_counts = array();
$this->expected_counts = array(); // here
$this->max_counts = array();
$this->expected_args = array();
$this->expected_args_at = array();
$this->getCurrentTestCase()->tell($this);
}

Which is quite strange, because allocating an array shouldn't cause a
crash! Here is the stack dump:

Thread 0 - System ID 4752
Entry point   php+2af2 
Create time   11/23/2008 7:29:25 PM 
Time spent in user mode   0 Days 0:0:3.73 
Time spent in kernel mode   0 Days 0:0:1.669 

Function Arg 1 Arg 2 Arg 3   Source 
php5!zend_hash_apply+5  1008ff40 1008fe0d
php5!gc_collect_cycles+2fc 04895474 00c0eb10 04ab4898
php5!gc_collect_cycles+24d 04ab0ab8 04ab4898 105286f0
php5!gc_collect_cycles+4b 04ab4898 1008cfaa 04ab4898
php5!gc_zval_possible_root+ce      


PHP5!ZEND_HASH_APPLY+5WARNING - DebugDiag was not able to locate debug
symbols for php5.dll, so the information below may be incomplete.

In
php__PID__4896__Date__11_23_2008__Time_07_30_05PM__248__Second_Chance_Exception_C005.dmp
the assembly instruction at php5!zend_hash_apply+5 in
C:\Software\PHP\versions\5.3.0alpha3-dev\php5.dll from The PHP Group has
caused an access violation exception (0xC005) when trying to read
from memory location 0x0026 on thread 0

I might be doing something wrong with regards to setting up the
backtrace, since it's complaining about php5.dll even though I do have
php5.dbg in my path. If you need a better backtrace, I can see what I
can do.

If you're interested in attempting to reproduce this, the configuration
is fairly standard. Use the instructions here
 to setup the HTML Purifier
development environment, and run the full test suite. (It doesn't work
if you try to run just the test that PHP dies on, or try to run it by
parts.)






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

#46656 [Opn->Csd]: Crash on array allocation/gc

2008-12-20 Thread ezyang 
 ID:   46656
 Updated by:   ezy...@php.net
 Reported By:  ezy...@php.net
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: win32 only - Windows Vista
 PHP Version:  5.3CVS-2008-11-24 (snap)
 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.

Can't repro with latest snaps, so I'm assuming this has been fixed.


Previous Comments:


[2008-12-09 03:30:35] ezy...@php.net

No luck. Poke me if any of you try to set things up on Windows.



[2008-12-09 03:05:14] ezy...@php.net

Some new information about reproducing:

I have been able to reproduce on another machine, but not without a
little bit of coaxing. In particular, these conditions must be met:

* PHPT tests must be set up. If they are skipped, the segfault does not
occur.

* `php tests/index.php` --flush must be run with a PHP 5.2 version,
prior to running `php tests/index.php` with a PHP 5.3 snap. The segfault
does not occur on a cold run of the test suite.

It might be possible to reproduce on Linux; I'm currently
reconstructing the experimental setup and will report back.



[2008-11-25 17:49:07] ezy...@php.net

Nope, I cannot reproduce on the latest 5.3 snap on Ubuntu Linux
Intrepid.



[2008-11-25 08:37:04] j...@php.net

Can you reproduce this on a real OS, like some Linux for example?



[2008-11-24 00:38:39] ezy...@php.net

Description:

I am getting a crash on the following code:

class SimpleMock {
// ...
function SimpleMock() {
$this->actions = new SimpleCallSchedule();
$this->expectations = new SimpleCallSchedule();
$this->call_counts = array();
$this->expected_counts = array(); // here
$this->max_counts = array();
$this->expected_args = array();
$this->expected_args_at = array();
$this->getCurrentTestCase()->tell($this);
}

Which is quite strange, because allocating an array shouldn't cause a
crash! Here is the stack dump:

Thread 0 - System ID 4752
Entry point   php+2af2 
Create time   11/23/2008 7:29:25 PM 
Time spent in user mode   0 Days 0:0:3.73 
Time spent in kernel mode   0 Days 0:0:1.669 

Function Arg 1 Arg 2 Arg 3   Source 
php5!zend_hash_apply+5  1008ff40 1008fe0d
php5!gc_collect_cycles+2fc 04895474 00c0eb10 04ab4898
php5!gc_collect_cycles+24d 04ab0ab8 04ab4898 105286f0
php5!gc_collect_cycles+4b 04ab4898 1008cfaa 04ab4898
php5!gc_zval_possible_root+ce      


PHP5!ZEND_HASH_APPLY+5WARNING - DebugDiag was not able to locate debug
symbols for php5.dll, so the information below may be incomplete.

In
php__PID__4896__Date__11_23_2008__Time_07_30_05PM__248__Second_Chance_Exception_C005.dmp
the assembly instruction at php5!zend_hash_apply+5 in
C:\Software\PHP\versions\5.3.0alpha3-dev\php5.dll from The PHP Group has
caused an access violation exception (0xC005) when trying to read
from memory location 0x0026 on thread 0

I might be doing something wrong with regards to setting up the
backtrace, since it's complaining about php5.dll even though I do have
php5.dbg in my path. If you need a better backtrace, I can see what I
can do.

If you're interested in attempting to reproduce this, the configuration
is fairly standard. Use the instructions here
 to setup the HTML Purifier
development environment, and run the full test suite. (It doesn't work
if you try to run just the test that PHP dies on, or try to run it by
parts.)






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

#42362 [WFx->Opn]: PHP should not send GZIP empty data after a 304 response

2009-02-17 Thread ezyang 
 ID:   42362
 Updated by:   ezy...@php.net
-Summary:  PHP sends GZIP empty data after a 304 response
 Reported By:  ob dot php at daevel dot net
-Status:   Wont fix
+Status:   Open
-Bug Type: HTTP related
+Bug Type: Zlib Related
 Operating System: Debian Etch
 PHP Version:  5.2.3
 New Comment:

I'm reopening this bug, under the contention that while PHP is not
strictly at fault, it would be nice if it "did the right thing" when it
noticed that output was empty, if only because gzipping nothing
increases the size, not decrease it!

Either that, or this is a documentation bug, in which case header()
and/or zlib.output_compression should warn users that any HTTP status
codes which are required to return no output must have
zlib.output_compression turned off.


Previous Comments:


[2007-09-05 17:38:39] m...@php.net

Well, the key issue is, zlib.output_compression and ob_gzhandler are
not the same thing. Enabling zlib.output_compression starts the output
handler without regard whether there's output or not unless you disable
it again without sending output. ob_gzhandler is only initialized if
there's been output.



[2007-09-05 14:30:02] ob dot php at daevel dot net

Yes of course if I disable the compression (with ini_set), there is not
the problem. But is it really to the script to check and correct an
internal behavior ?
An old script which use ob_start( 'gz_handler' ) doesn't meet this
"bug".



[2007-09-04 12:33:58] j...@php.net

AFAICT, you're sending the 304 in your script, it's not done by PHP. So
in that case, isn't it your script that should turn off the compression?



[2007-09-04 07:04:34] ob dot php at daevel dot net

The RFC say :
"The 304 response MUST NOT contain a message-body, and thus is always
terminated by the first empty line after the header fields."

Source : http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
(cf 10.3.5 "304 Not Modified" )


Actually PHP sent the "GZIP Magic Header" (I'm not talking about the
HTTP headers, but the start of a gzip compressed data).



[2007-08-27 11:07:01] j...@php.net

How is this a bug when you tell in your request that you accept gzipped
data? Of course you get that header then.



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

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

#44648 [Opn]: All-or-nothing for production checks in DOM interface

2008-04-05 Thread ezyang 
 ID:   44648
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: DOM XML related
 Operating System: Windows Vista
 PHP Version:  5.2.5
 Assigned To:  rrichards
 New Comment:

You're right, that was my mistake.

I suppose that any of the places where the DOM specification could
raise an exception would be the places where there needs to be
error-checking.

Ought of curiosity, how come we don't use gdome2?


Previous Comments:


[2008-04-05 23:22:24] [EMAIL PROTECTED]

You should read the specs more closely. Names are most certainly
checked 
and a DOMException with an INVALID_CHARACTER_ERROR error is thrown.

Some of the others I need to look at because it is perfectly fine to 
create non well formed XML using DOM though it should error during 
serialization, so for those the bug would onl be in the saveXML
routine. 
Other extensions it is not a bug because non-well formed XML support is

required because the output when used in a larger context is well
formed




[2008-04-05 23:02:49] [EMAIL PROTECTED]

One more: ]]> is not allowed in CDATA blocks.

I also suspect that the other XML extensions have bugs here.



[2008-04-05 23:02:02] [EMAIL PROTECTED]

IIRC, DOM does not make any demands on names or things like that.
libxml2, which is known for its strictness, doesn't either. So, I'm
still hoping that you'll let the checks be turned off. :-)

Some things from my investigation:

- Double hyphens (--) are not allowed in comments
- Most of the text inputs don't check for UTF-8 well-formedness.
Haven't tested numeric character entities either, but those are
suspicious
- Fake namespace declarations in attributes
($d->appendChild($d->createElement('foo:bar')); results in invalid XML,
as foo namespace was never defined)

All these result in a $d->saveXML(); that is invalid XML, and probably
some more.



[2008-04-05 22:54:04] [EMAIL PROTECTED]

assign to self.

The strictness is dependent upon the DOM specs and setAttribute should

be throwing an exception in that case. While I am going to go through 
and check other methods, let me know if you come across any others that

are not validating names correctly.





[2008-04-05 21:55:06] [EMAIL PROTECTED]

Description:

libxml2 is fairly lenient when it comes to what it allows to go into
its nodes; you can set attributes and tags with illegal characters in
them and it won't complain. The burden is on the userland code to
perform an appropriate check with the xmlValidate*() functions.

PHP's DOM implementation is extremely spotty when it comes to these
checks, which allows for some broken XML to easily be generated. For
example,

$d = new DOMDocument();
$d->appendChild($n = $d->createElement('a'));
$n->setAttribute('"@', 'foo');
echo $d->saveXML();

outputs:




Which is clearly incorrect. However, if I attempt to

$d->createElement('a@');

DOM complains, because xmlValidateName was called on the element name.

Now, I actually don't mind the lack of checking; the DOM tree is useful
for things like HTML, where the rules are slightly different from XMLs;
an HTML tree can contain a "a@" node, although it would not be valid
HTML. (You can try it out for yourself on Firefox by putting that in a
document and then inspecting the DOM).

However, I want consistency, and I also want the ability to switch on
strict checking when I so desire (especially when I'm producing XML). So
I want all-or-nothing production checks in PHP DOM, adding another
property in DOMDocument (or maybe even a global libxml configuration
option) that specifies whether or not strict production checking should
be done.






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

Bug #48819 [ReO->Ver]: dl function is undefined

2011-11-10 Thread ezyang 
Edit report at https://bugs.php.net/bug.php?id=48819&edit=1

 ID: 48819
 Updated by: ezy...@php.net
 Reported by:pkwan at advsofteng dot net
 Summary:dl function is undefined
-Status: Re-Opened
+Status: Verified
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Multiple
 PHP Version:5.3.0-5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Yeah, this is definitely either a documentation bug or a code bug. Have we just 
decided that dl() is too buggy to want to deal with?


Previous Comments:

[2011-01-13 12:30:46] ci...@php.net

For those still struggling with this problem, we reverted the patch as shown on 
http://www.mail-archive.com/php-cvs@lists.php.net/msg39628.html and the problem 
went away. 

IMHO this patch should be reversed, as it says  "Disable dl() in CGI and 
FastCGI modes" while the website states "The only SAPI's that allow dl() are: 
[...] CGI"


[2011-01-12 18:45:41] ci...@php.net

We are currently experiencing the same problem on php-5.3.3. To confuse the 
matter even more:

We use an Apache/2.2.14 (Debian) server with suexec enable.
* When running the CGI-binary from the command line everything works fine, dl() 
is available and works as expected.
* When running the CGI-binary through apache2's suexec command everything works.
* The CLI binary also works without any problem.
* Only when running php in CGI/FastCGI mode through Apache's suexec things stop 
working and php dies with the "Call to undefined function dl()", instead of the 
expected correct behaviour, or even throwing an error.


[2010-08-16 17:13:17] cy...@php.net

this bug is not bogus.  it's either valid or should be reclassified as a 
documentation bug.  the manual says (as of August 16, 2010):

5.3.0dl() is now disabled in some SAPI's due to stability issues. The only 
SAPI's that allow dl() are: CLI, CGI and Embed.

in fact, a peek at php-5.3.3/ext/standard/dl.c suggests that the manual is 
quite misleading as it leaves the reader thinking that dl() will work in non-TS 
versions of CLI, CGI and Embed just find, when in fact the function is 
E_DEPRECATED across the board:

if ((strncmp(sapi_module.name, "cgi", 3) != 0) &&
(strcmp(sapi_module.name, "cli") != 0) &&
(strncmp(sapi_module.name, "embed", 5) != 0)
) {
#ifdef ZTS
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Not supported in 
multithreaded Web servers - use extension=%s in your php.ini", filename);
RETURN_FALSE;
#else
php_error_docref(NULL TSRMLS_CC, E_DEPRECATED, "dl() is 
deprecated - use extension=%s in your php.ini", filename);
#endif
}


that's correct as long as i run php-cgi.exe on the command line:

  var_dump(extension_loaded('sqlsrv'));
  dl('php_sqlsrv.dll');
  var_dump(extension_loaded('sqlsrv'));

run with

  php-cgi -nq -d extension_dir=$somewhere -d error_reporting=-1 test.php

gives

  bool(false)
  bool(true)

however, running the same php-cgi inside Apache 2.2 on Windows, the dl() 
function does not exist.

tested with 5.3.3-nts-vc9.


[2009-07-06 17:32:18] pkwan at advsofteng dot net

This is definitely a bug. According to PHP 5.3 documentation, dl should work, 
at least for CLI, CGI and Embed. Pease read the PHP documentation.

The PHP 5.3 documentation for "dl" says:

This function now throws an E_DEPRECATED notice on all sapi's except for CLI, 
CGI and Embed. 

Also, the PHP 5.3 change log "http://www.php.net/ChangeLog-5.php"; says:

Changed dl() to be disabled by default. Enabled only when explicitly registered 
by the SAPI. Currently enabled with cli, cgi and embed SAPIs. (Dmitry) 

So the above clearly says dl should work on CLI, CGI and Embed SAPI. I am 
testing using CGI, and it does not work. Therefore it is a bug.

Furthermore, from the PHP documentation on dl, the E_DEPRECATED is only a 
"notice", not an error. So dl should work in all other SAPI as well.


[2009-07-06 16:24:10] j...@php.net

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






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

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


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

#47756 [NEW]: Segfault on HTML Purifier test suite

2009-03-23 Thread ezyang at mit dot edu 
From: ezyang at mit dot edu
Operating system: Ubuntu Linux
PHP version:  6CVS-2009-03-24 (CVS)
PHP Bug Type: Reproducible crash
Bug description:  Segfault on HTML Purifier test suite

Description:

I get a segfault when running the HTML Purifier test suite on PHP 6
(multitude of userspace errors not withstanding). I was not able to boil it
down to a simple section of code. I've posted the coredump here:

http://web.mit.edu/~ezyang/Public/core.3491


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

#47756 [Fbk->Csd]: Segfault on HTML Purifier test suite

2009-12-10 Thread ezyang at mit dot edu 
 ID:   47756
 User updated by:  ezyang at mit dot edu
 Reported By:  ezyang at mit dot edu
-Status:   Feedback
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Ubuntu Linux
 PHP Version:  6CVS-2009-03-24 (CVS)
 New Comment:

Segfault appears to have gone away.


Previous Comments:


[2009-12-08 23:14:07] fel...@php.net

Please try using this snapshot:

  http://snaps.php.net/php6.0-latest.tar.gz
 
For Windows:

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





[2009-03-24 03:07:52] ezyang at mit dot edu

Description:

I get a segfault when running the HTML Purifier test suite on PHP 6
(multitude of userspace errors not withstanding). I was not able to boil
it down to a simple section of code. I've posted the coredump here:

http://web.mit.edu/~ezyang/Public/core.3491






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