Bug #65667 [Com]: ftp_nb_continue produces segfault
Edit report at https://bugs.php.net/bug.php?id=65667&edit=1
ID: 65667
Comment by: phofstetter at sensational dot ch
Reported by:imprec at gmail dot com
Summary:ftp_nb_continue produces segfault
Status: Open
Type: Bug
Package:FTP related
Operating System: OSX
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Ok. Official Pull-Request submitted here:
https://github.com/php/php-src/pull/478
Sorry for the spam. I initially just wanted to confirm the issue, but then I
felt compelled to dig deeper and deeper, commenting more and more :-)
Previous Comments:
[2013-10-02 06:30:51] phofstetter at sensational dot ch
I think the bug was introduced in
https://github.com/php/php-src/commit/a93a462dcefd62e07963dd2da506fbb3409c88b5
where php_stream_close(outstream); is called unconditionally. Thus any further
ftp_nb_continue() will work on a stream that has already been closed.
When I restore the behaviour pre-patch, the segfault goes away.
I will create a proper pull request and attach it to this bug.
[2013-10-02 06:14:18] phofstetter at sensational dot ch
and here's one stack frame higher (giving you the data you requested):
(gdb) p ftp
$1 = (ftpbuf_t *) 0x77fcf1f8
(gdb) p ftp->stream
$2 = (php_stream *) 0x77fceb78
(gdb) p data
$3 = (databuf_t *) 0x77fd1388
(gdb) p ftp->stream->ops
$4 = (php_stream_ops *) 0x0
Again, something is wrong with that stream.
[2013-10-02 06:00:46] phofstetter at sensational dot ch
Here's a bit of poking around in gdb:
Program received signal SIGSEGV, Segmentation fault.
0x0070080d in _php_stream_write (stream=0x18eecb8,
buf=0x19511b4
"\243\060\060\060\060\060\060\060\061\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\065\063\061\243\060\060\060\060\060\060\060\061\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\063\066\061\243\060\060\060\060\060\060\060\062\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\064\065\070\060\243\060\060\060\060\060\060\062\071\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\060\060\066\243\060\060\060\060\060\060\060\063\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\060\063\061\061\243\060\060\060\060\060\060\060\065\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\066\063\061\065\243\060\060\060\060\060\060\060\066\243\r\nPA"...,
count=1352) at
/home/crazyhat/popscan-deb/downloads/php-5.5.4/main/streams/streams.c:1233
warning: Source file is more recent than executable.
1233if (buf == NULL || count == 0 || stream->ops->write == NULL) {
(gdb) p count
$1 = 1352
(gdb) p stream
$2 = (php_stream *) 0x18eecb8
(gdb) p stream->ops
$3 = (php_stream_ops *) 0x0
(gdb)
stream->ops seems to be NULL
------------
[2013-10-02 05:52:56] phofstetter at sensational dot ch
I can confirm this to happen on Linux too.
Also in 5.4.20 (5.4.16 was fine) and 5.5.4
[2013-09-17 08:36:21] imprec at gmail dot com
Well, not so much chance :(
(gdb) run
Starting program: /usr/local/bin/php
/Users/romain/Documents/workspace/Phraseanet/ftp.php
Reading symbols for shared libraries
+... done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries ... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
bt full
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x000100387a75 in _php_stream_write ()
(gdb) bt full
#0 0x000100387a75 in _php_stream_write ()
No symbol table info available.
#1 0x00010013ab6f in ftp_nb_continue_read ()
No symbol table info available.
#2 0x000100137c2c in zif_ftp_nb_continue ()
No symbol table info available.
#3 0x0001003bf524 in dtrace_execute_internal ()
No symbol table info available.
#4 0x0001004430c2 in zend_do_fcall_common_helper_SPEC ()
No symbol table info available.
#5 0x0001003f310a in execute_ex ()
No symbol table info available.
#6 0x0001003bf458 in dtrace_execute_ex ()
No symbol table info available.
#7 0x0001003ce7ac in zend_execute_scripts ()
No symbol table info available.
#8 0x000100374602 in php_execute_script ()
No symbol table info available.
#9 0x000100467075 in do_cli ()
No symbol table info av
Bug #65667 [Com]: ftp_nb_continue produces segfault
Edit report at https://bugs.php.net/bug.php?id=65667&edit=1
ID: 65667
Comment by: phofstetter at sensational dot ch
Reported by:imprec at gmail dot com
Summary:ftp_nb_continue produces segfault
Status: Open
Type: Bug
Package:FTP related
Operating System: OSX
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
I think the bug was introduced in
https://github.com/php/php-src/commit/a93a462dcefd62e07963dd2da506fbb3409c88b5
where php_stream_close(outstream); is called unconditionally. Thus any further
ftp_nb_continue() will work on a stream that has already been closed.
When I restore the behaviour pre-patch, the segfault goes away.
I will create a proper pull request and attach it to this bug.
Previous Comments:
[2013-10-02 06:14:18] phofstetter at sensational dot ch
and here's one stack frame higher (giving you the data you requested):
(gdb) p ftp
$1 = (ftpbuf_t *) 0x77fcf1f8
(gdb) p ftp->stream
$2 = (php_stream *) 0x77fceb78
(gdb) p data
$3 = (databuf_t *) 0x77fd1388
(gdb) p ftp->stream->ops
$4 = (php_stream_ops *) 0x0
Again, something is wrong with that stream.
[2013-10-02 06:00:46] phofstetter at sensational dot ch
Here's a bit of poking around in gdb:
Program received signal SIGSEGV, Segmentation fault.
0x0070080d in _php_stream_write (stream=0x18eecb8,
buf=0x19511b4
"\243\060\060\060\060\060\060\060\061\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\065\063\061\243\060\060\060\060\060\060\060\061\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\063\066\061\243\060\060\060\060\060\060\060\062\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\064\065\070\060\243\060\060\060\060\060\060\062\071\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\060\060\066\243\060\060\060\060\060\060\060\063\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\060\063\061\061\243\060\060\060\060\060\060\060\065\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\066\063\061\065\243\060\060\060\060\060\060\060\066\243\r\nPA"...,
count=1352) at
/home/crazyhat/popscan-deb/downloads/php-5.5.4/main/streams/streams.c:1233
warning: Source file is more recent than executable.
1233if (buf == NULL || count == 0 || stream->ops->write == NULL) {
(gdb) p count
$1 = 1352
(gdb) p stream
$2 = (php_stream *) 0x18eecb8
(gdb) p stream->ops
$3 = (php_stream_ops *) 0x0
(gdb)
stream->ops seems to be NULL
------------
[2013-10-02 05:52:56] phofstetter at sensational dot ch
I can confirm this to happen on Linux too.
Also in 5.4.20 (5.4.16 was fine) and 5.5.4
[2013-09-17 08:36:21] imprec at gmail dot com
Well, not so much chance :(
(gdb) run
Starting program: /usr/local/bin/php
/Users/romain/Documents/workspace/Phraseanet/ftp.php
Reading symbols for shared libraries
+... done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries ... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
bt full
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x000100387a75 in _php_stream_write ()
(gdb) bt full
#0 0x000100387a75 in _php_stream_write ()
No symbol table info available.
#1 0x00010013ab6f in ftp_nb_continue_read ()
No symbol table info available.
#2 0x000100137c2c in zif_ftp_nb_continue ()
No symbol table info available.
#3 0x0001003bf524 in dtrace_execute_internal ()
No symbol table info available.
#4 0x0001004430c2 in zend_do_fcall_common_helper_SPEC ()
No symbol table info available.
#5 0x0001003f310a in execute_ex ()
No symbol table info available.
#6 0x0001003bf458 in dtrace_execute_ex ()
No symbol table info available.
#7 0x0001003ce7ac in zend_execute_scripts ()
No symbol table info available.
#8 0x000100374602 in php_execute_script ()
No symbol table info available.
#9 0x000100467075 in do_cli ()
No symbol table info available.
#10 0x000100465e3d in main ()
No symbol table info available.
(gdb) p ftp
No symbol "ftp" in current context.
(gdb) p data
No symbol "data" in current context.
(gdb) p rcvd
No symbol "rcvd" in current context.
(gdb)
Whereas my PHP is compiled with debug :
PHP 5.5.3 (cli) (built: Sep 12 2013 02:41:16) (DEBUG)
Copyri
Bug #65667 [Com]: ftp_nb_continue produces segfault
Edit report at https://bugs.php.net/bug.php?id=65667&edit=1
ID: 65667
Comment by: phofstetter at sensational dot ch
Reported by:imprec at gmail dot com
Summary:ftp_nb_continue produces segfault
Status: Open
Type: Bug
Package:FTP related
Operating System: OSX
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
and here's one stack frame higher (giving you the data you requested):
(gdb) p ftp
$1 = (ftpbuf_t *) 0x77fcf1f8
(gdb) p ftp->stream
$2 = (php_stream *) 0x77fceb78
(gdb) p data
$3 = (databuf_t *) 0x77fd1388
(gdb) p ftp->stream->ops
$4 = (php_stream_ops *) 0x0
Again, something is wrong with that stream.
Previous Comments:
[2013-10-02 06:00:46] phofstetter at sensational dot ch
Here's a bit of poking around in gdb:
Program received signal SIGSEGV, Segmentation fault.
0x0070080d in _php_stream_write (stream=0x18eecb8,
buf=0x19511b4
"\243\060\060\060\060\060\060\060\061\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\065\063\061\243\060\060\060\060\060\060\060\061\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\063\066\061\243\060\060\060\060\060\060\060\062\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\064\065\070\060\243\060\060\060\060\060\060\062\071\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\060\060\066\243\060\060\060\060\060\060\060\063\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\060\063\061\061\243\060\060\060\060\060\060\060\065\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\066\063\061\065\243\060\060\060\060\060\060\060\066\243\r\nPA"...,
count=1352) at
/home/crazyhat/popscan-deb/downloads/php-5.5.4/main/streams/streams.c:1233
warning: Source file is more recent than executable.
1233if (buf == NULL || count == 0 || stream->ops->write == NULL) {
(gdb) p count
$1 = 1352
(gdb) p stream
$2 = (php_stream *) 0x18eecb8
(gdb) p stream->ops
$3 = (php_stream_ops *) 0x0
(gdb)
stream->ops seems to be NULL
------------
[2013-10-02 05:52:56] phofstetter at sensational dot ch
I can confirm this to happen on Linux too.
Also in 5.4.20 (5.4.16 was fine) and 5.5.4
[2013-09-17 08:36:21] imprec at gmail dot com
Well, not so much chance :(
(gdb) run
Starting program: /usr/local/bin/php
/Users/romain/Documents/workspace/Phraseanet/ftp.php
Reading symbols for shared libraries
+... done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries ... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
bt full
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x000100387a75 in _php_stream_write ()
(gdb) bt full
#0 0x000100387a75 in _php_stream_write ()
No symbol table info available.
#1 0x00010013ab6f in ftp_nb_continue_read ()
No symbol table info available.
#2 0x000100137c2c in zif_ftp_nb_continue ()
No symbol table info available.
#3 0x0001003bf524 in dtrace_execute_internal ()
No symbol table info available.
#4 0x0001004430c2 in zend_do_fcall_common_helper_SPEC ()
No symbol table info available.
#5 0x0001003f310a in execute_ex ()
No symbol table info available.
#6 0x0001003bf458 in dtrace_execute_ex ()
No symbol table info available.
#7 0x0001003ce7ac in zend_execute_scripts ()
No symbol table info available.
#8 0x000100374602 in php_execute_script ()
No symbol table info available.
#9 0x000100467075 in do_cli ()
No symbol table info available.
#10 0x000100465e3d in main ()
No symbol table info available.
(gdb) p ftp
No symbol "ftp" in current context.
(gdb) p data
No symbol "data" in current context.
(gdb) p rcvd
No symbol "rcvd" in current context.
(gdb)
Whereas my PHP is compiled with debug :
PHP 5.5.3 (cli) (built: Sep 12 2013 02:41:16) (DEBUG)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
[2013-09-17 00:58:19] fel...@php.net
Hi, when seeing the backtrace on gdb, please run the following commands (and
post the results):
p ftp
p data
p rcvd
Thanks.
[2013-09-13 16:11:48] imprec at gmail dot com
Description:
Running the following code on my OSX produces a
Bug #65667 [Com]: ftp_nb_continue produces segfault
Edit report at https://bugs.php.net/bug.php?id=65667&edit=1
ID: 65667
Comment by: phofstetter at sensational dot ch
Reported by:imprec at gmail dot com
Summary:ftp_nb_continue produces segfault
Status: Open
Type: Bug
Package:FTP related
Operating System: OSX
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Here's a bit of poking around in gdb:
Program received signal SIGSEGV, Segmentation fault.
0x0070080d in _php_stream_write (stream=0x18eecb8,
buf=0x19511b4
"\243\060\060\060\060\060\060\060\061\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\065\063\061\243\060\060\060\060\060\060\060\061\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\063\066\061\243\060\060\060\060\060\060\060\062\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\064\065\070\060\243\060\060\060\060\060\060\062\071\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\067\060\060\066\243\060\060\060\060\060\060\060\063\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\060\063\061\061\243\060\060\060\060\060\060\060\065\243\r\nPAD\243\060\243\060\060\062\063\071\060\243\060\060\066\063\061\065\243\060\060\060\060\060\060\060\066\243\r\nPA"...,
count=1352) at
/home/crazyhat/popscan-deb/downloads/php-5.5.4/main/streams/streams.c:1233
warning: Source file is more recent than executable.
1233if (buf == NULL || count == 0 || stream->ops->write == NULL) {
(gdb) p count
$1 = 1352
(gdb) p stream
$2 = (php_stream *) 0x18eecb8
(gdb) p stream->ops
$3 = (php_stream_ops *) 0x0
(gdb)
stream->ops seems to be NULL
Previous Comments:
[2013-10-02 05:52:56] phofstetter at sensational dot ch
I can confirm this to happen on Linux too.
Also in 5.4.20 (5.4.16 was fine) and 5.5.4
[2013-09-17 08:36:21] imprec at gmail dot com
Well, not so much chance :(
(gdb) run
Starting program: /usr/local/bin/php
/Users/romain/Documents/workspace/Phraseanet/ftp.php
Reading symbols for shared libraries
+... done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries ... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
bt full
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x000100387a75 in _php_stream_write ()
(gdb) bt full
#0 0x000100387a75 in _php_stream_write ()
No symbol table info available.
#1 0x00010013ab6f in ftp_nb_continue_read ()
No symbol table info available.
#2 0x000100137c2c in zif_ftp_nb_continue ()
No symbol table info available.
#3 0x0001003bf524 in dtrace_execute_internal ()
No symbol table info available.
#4 0x0001004430c2 in zend_do_fcall_common_helper_SPEC ()
No symbol table info available.
#5 0x0001003f310a in execute_ex ()
No symbol table info available.
#6 0x0001003bf458 in dtrace_execute_ex ()
No symbol table info available.
#7 0x0001003ce7ac in zend_execute_scripts ()
No symbol table info available.
#8 0x000100374602 in php_execute_script ()
No symbol table info available.
#9 0x000100467075 in do_cli ()
No symbol table info available.
#10 0x000100465e3d in main ()
No symbol table info available.
(gdb) p ftp
No symbol "ftp" in current context.
(gdb) p data
No symbol "data" in current context.
(gdb) p rcvd
No symbol "rcvd" in current context.
(gdb)
Whereas my PHP is compiled with debug :
PHP 5.5.3 (cli) (built: Sep 12 2013 02:41:16) (DEBUG)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
[2013-09-17 00:58:19] fel...@php.net
Hi, when seeing the backtrace on gdb, please run the following commands (and
post the results):
p ftp
p data
p rcvd
Thanks.
[2013-09-13 16:11:48] imprec at gmail dot com
Description:
Running the following code on my OSX produces a segfault, see backtrace
(gdb) (gdb) Starting program: /usr/local/bin/php /Users/romain/ftp-script.php
Reading symbols for shared libraries
+... done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries ... done
Reading symbols for shared libraries .
Bug #65667 [Com]: ftp_nb_continue produces segfault
Edit report at https://bugs.php.net/bug.php?id=65667&edit=1
ID: 65667
Comment by: phofstetter at sensational dot ch
Reported by:imprec at gmail dot com
Summary:ftp_nb_continue produces segfault
Status: Open
Type: Bug
Package:FTP related
Operating System: OSX
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
I can confirm this to happen on Linux too.
Also in 5.4.20 (5.4.16 was fine) and 5.5.4
Previous Comments:
[2013-09-17 08:36:21] imprec at gmail dot com
Well, not so much chance :(
(gdb) run
Starting program: /usr/local/bin/php
/Users/romain/Documents/workspace/Phraseanet/ftp.php
Reading symbols for shared libraries
+... done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries ... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
bt full
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x000100387a75 in _php_stream_write ()
(gdb) bt full
#0 0x000100387a75 in _php_stream_write ()
No symbol table info available.
#1 0x00010013ab6f in ftp_nb_continue_read ()
No symbol table info available.
#2 0x000100137c2c in zif_ftp_nb_continue ()
No symbol table info available.
#3 0x0001003bf524 in dtrace_execute_internal ()
No symbol table info available.
#4 0x0001004430c2 in zend_do_fcall_common_helper_SPEC ()
No symbol table info available.
#5 0x0001003f310a in execute_ex ()
No symbol table info available.
#6 0x0001003bf458 in dtrace_execute_ex ()
No symbol table info available.
#7 0x0001003ce7ac in zend_execute_scripts ()
No symbol table info available.
#8 0x000100374602 in php_execute_script ()
No symbol table info available.
#9 0x000100467075 in do_cli ()
No symbol table info available.
#10 0x000100465e3d in main ()
No symbol table info available.
(gdb) p ftp
No symbol "ftp" in current context.
(gdb) p data
No symbol "data" in current context.
(gdb) p rcvd
No symbol "rcvd" in current context.
(gdb)
Whereas my PHP is compiled with debug :
PHP 5.5.3 (cli) (built: Sep 12 2013 02:41:16) (DEBUG)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
[2013-09-17 00:58:19] fel...@php.net
Hi, when seeing the backtrace on gdb, please run the following commands (and
post the results):
p ftp
p data
p rcvd
Thanks.
[2013-09-13 16:11:48] imprec at gmail dot com
Description:
Running the following code on my OSX produces a segfault, see backtrace
(gdb) (gdb) Starting program: /usr/local/bin/php /Users/romain/ftp-script.php
Reading symbols for shared libraries
+... done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries ... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x000100387a75 in _php_stream_write ()
(gdb) #0 0x000100387a75 in _php_stream_write ()
No symbol table info available.
#1 0x00010013ab6f in ftp_nb_continue_read ()
No symbol table info available.
#2 0x000100137c2c in zif_ftp_nb_continue ()
No symbol table info available.
#3 0x0001003bf524 in dtrace_execute_internal ()
No symbol table info available.
#4 0x0001004430c2 in zend_do_fcall_common_helper_SPEC ()
No symbol table info available.
#5 0x0001003f310a in execute_ex ()
No symbol table info available.
#6 0x0001003bf458 in dtrace_execute_ex ()
No symbol table info available.
#7 0x0001003ce7ac in zend_execute_scripts ()
No symbol table info available.
#8 0x000100374602 in php_execute_script ()
No symbol table info available.
#9 0x000100467075 in do_cli ()
No symbol table info available.
#10 0x000100465e3d in main ()
No symbol table info available.
(gdb) %
Test script:
---
$connection = ftp_connect('hostname', 21);
ftp_login($connection, 'login', 'password');
$localfile = __DIR__ . '/ftpfile';
$start = file_exists($localfile) ? FTP_AUTORESUME : 0;
$result = ftp_nb
[PHP-BUG] Bug #62596 [NEW]: getallheaders() missing with PHP-FPM
From: phofstetter at sensational dot ch Operating system: MacOS X, Linux PHP version: 5.4.4 Package: FPM related Bug Type: Bug Bug description:getallheaders() missing with PHP-FPM Description: getallheaders() is supposed to be available outside of the Apache SAPI since PHP 5.4.0. This is true for php-cgi for example, but it is not true for php-fpm where getallheaders() still causes Fatal error: Call to undefined function getallheaders() Test script: --- https://bugs.php.net/bug.php?id=62596&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62596&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62596&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62596&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62596&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62596&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62596&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62596&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62596&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62596&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62596&r=support Expected behavior: https://bugs.php.net/fix.php?id=62596&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62596&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62596&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62596&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62596&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62596&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62596&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62596&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62596&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62596&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62596&r=mysqlcfg
Bug #54478 [Opn]: The pdo_pgsql specific implementation of inTransaction doesn't work as expected
Edit report at http://bugs.php.net/bug.php?id=54478&edit=1 ID: 54478 User updated by:phofstetter at sensational dot ch Reported by:phofstetter at sensational dot ch Summary:The pdo_pgsql specific implementation of inTransaction doesn't work as expected Status: Open Type: Bug Package:PDO related Operating System: OSX, Linux, likely all PHP Version:5.3.6 Block user comment: N Private report: N New Comment: A bit of investigation revealed that the feature was removed in 300464 http://svn.php.net/viewvc?view=revision&revision=300464 I guess the unit test should be removed too, as well as the note in the manual which states "Note that currently only the PostgreSQL driver implements this method." Previous Comments: [2011-04-06 14:59:11] phofstetter at sensational dot ch Description: PHP 5.3.3 supposedly brought PDO::inTransaction() with a special implementation for PostgreSQL wich uses libpq's PQtransactionStatus instead of internal bookkeeping. According to the test attached with the revision where this was added (is_in_transaction.phpt, revision 300351), inTransaction() is supposed to return any of the PGSQL_TRANSACTION_* constants. Unfortunately that's not the case and inTransaction(), even when used in conjunction with PostgreSQL only returns boolean and doesn't use the actual transaction status of the connection but just returns true or false depending on whether PDO::beginTransaction() has been called or not. PHP's own test runner illustrates the problem, which is why I don't bother adding an additional test script - the included is_in_transaction.phpt is enough: http://gcov.php.net/viewer.php? version=PHP_5_3&func=tests&file=ext%2Fpdo_pgsql%2Ftests%2Fis_in_transaction.phpt Expected result: When running the phpt file, I expect the following output: Test PDO::PGSQL_TRANSACTION_INTRANS int(2) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Test PDO::PGSQL_TRANSACTION_INERROR int(3) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Actual result: -- When running the phpt file, I (and PHP's webbased test runner) is getting Test PDO::PGSQL_TRANSACTION_INTRANS int(1) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Test PDO::PGSQL_TRANSACTION_INERROR int(1) Test PDO::PGSQL_TRANSACTION_IDLE int(0) -- Edit this bug report at http://bugs.php.net/bug.php?id=54478&edit=1
[PHP-BUG] Bug #54478 [NEW]: The pdo_pgsql specific implementation of inTransaction doesn't work as expected
From: Operating system: OSX, Linux, likely all PHP version: 5.3.6 Package: PDO related Bug Type: Bug Bug description:The pdo_pgsql specific implementation of inTransaction doesn't work as expected Description: PHP 5.3.3 supposedly brought PDO::inTransaction() with a special implementation for PostgreSQL wich uses libpq's PQtransactionStatus instead of internal bookkeeping. According to the test attached with the revision where this was added (is_in_transaction.phpt, revision 300351), inTransaction() is supposed to return any of the PGSQL_TRANSACTION_* constants. Unfortunately that's not the case and inTransaction(), even when used in conjunction with PostgreSQL only returns boolean and doesn't use the actual transaction status of the connection but just returns true or false depending on whether PDO::beginTransaction() has been called or not. PHP's own test runner illustrates the problem, which is why I don't bother adding an additional test script - the included is_in_transaction.phpt is enough: http://gcov.php.net/viewer.php? version=PHP_5_3&func=tests&file=ext%2Fpdo_pgsql%2Ftests%2Fis_in_transaction.phpt Expected result: When running the phpt file, I expect the following output: Test PDO::PGSQL_TRANSACTION_INTRANS int(2) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Test PDO::PGSQL_TRANSACTION_INERROR int(3) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Actual result: -- When running the phpt file, I (and PHP's webbased test runner) is getting Test PDO::PGSQL_TRANSACTION_INTRANS int(1) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Test PDO::PGSQL_TRANSACTION_INERROR int(1) Test PDO::PGSQL_TRANSACTION_IDLE int(0) -- Edit bug report at http://bugs.php.net/bug.php?id=54478&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54478&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54478&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54478&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54478&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54478&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54478&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54478&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54478&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54478&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54478&r=support Expected behavior: http://bugs.php.net/fix.php?id=54478&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54478&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54478&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54478&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54478&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54478&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54478&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54478&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54478&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54478&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54478&r=mysqlcfg
Req #42396 [Com]: Followup to #36711: __halt_compiler() and unicode detection
Edit report at http://bugs.php.net/bug.php?id=42396&edit=1 ID: 42396 Comment by: phofstetter at sensational dot ch Reported by: francois at tekwire dot net Summary: Followup to #36711: __halt_compiler() and unicode detection Status: Assigned Type: Feature/Change Request Package: Feature/Change Request Operating System: all PHP Version: 5.2.3 Assigned To: hirokawa New Comment: somehow, recently, the default value of detect_unicode seems to have changed. With detect_unicode enabled, it's impossible to run any PHAR-file - neither through the CLI or through the web server. IMHO, this should really be looked into. Previous Comments: [2007-08-27 08:38:58] j...@php.net IMHO, #42396 is not a bug, but it is the specification. The normal script doesn't contain a null byte if it is not encoded in Unicode. It is understandable the addition of a unique byte seqence '0x' detection to support PHAR/PHK, but it is a change to add a new feature. Rui [2007-08-24 10:30:12] j...@php.net Patch posted to internals: http://news.php.net/php.internals/31870 [2007-08-24 10:29:05] j...@php.net The same folks who maintain mbstring have added that support so it's not so wrong choice. Reclassified though. And assigned to the maintainer. [2007-08-23 16:24:33] francois at tekwire dot net Not sure it should be reclassified as mbstring related, as the bug is in Zend/zend_multibyte.c and has nothing to do with mbstring. PHP5 has a little unicode part in the engine. It even has an (undocumented) 'detect_unicode' option. [2007-08-23 14:08:09] j...@php.net Reclassified: There is no unicode in PHP 5. Just mbstring. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=42396 -- Edit this bug report at http://bugs.php.net/bug.php?id=42396&edit=1
#48507 [Com]: fgetcsv() ignoring special characters
ID: 48507
Comment by: phofstetter at sensational dot ch
Reported By: krynble at yahoo dot com dot br
Status: Verified
Bug Type: Filesystem function related
Operating System: Unix
PHP Version: 5.2.9
New Comment:
below you'll find a small script which shows how to implement a user
filter that can be used to on-the-fly utf8-encode the data so that
fgetcsv is happy and returns correct output even if the first character
in a field has its high-bit set and is not valid utf-8:
Remember: This is a workaround and impacts performance. This is not a
valid fix for the bug.
I didn't yet have time to deeply look into the C implementation for
fgetcsv, but all these calls to php_mblen() feel suspicious to me.
I'll try and have a look into this later today, but for now, I'm just
glad I have this workaround (quickly hacked together - keep that in
mind):
is_utf8($bucket->data))
$bucket->data = utf8_encode($bucket->data);
$consumed += $bucket->datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
/* Register our filter with PHP */
stream_filter_register("utf8encode", "utf8encode_filter")
or die("Failed to register filter");
$fp = fopen($_SERVER['argv'][1], "r");
/* Attach the registered filter to the stream just opened */
stream_filter_prepend($fp, "utf8encode");
while($data = fgetcsv($fp, 0, ';', '"'))
print_r($data);
fclose($fp);
Previous Comments:
--------
[2009-09-22 14:45:22] phofstetter at sensational dot ch
I was looking into this (after having been bitten by it) and I can add
another tidbit that might help tracking this down:
The bug doesn't happen if the file fgetcsv() is reading is in
UTF-8-format.
I have created a test-file in ISO-8859-1 and then used
file_put_contents(utf8encode(file_get_contents())) to create the
UTF8-version of it (explaining this here because I'm not sure whether
this would write a BOM or not - probably not though).
That version could be read correctly.
I'm now writing a stream filter that does the UTF-8 conversion on the
fly to hook that in between the file and fgetcsv() - while I would lose
a bit of performance, in my case, this is the cleanest workaround.
[2009-09-21 18:11:47] dmulryan at calendarwiz dot com
Note: Previous comment has error where URL is shown in array element.
This is not a bug but my error in the example. Bug is in special
characters.
[2009-09-21 18:07:42] dmulryan at calendarwiz dot com
Similar problem when parsing the following line:
0909211132,1,ØÊááàÑ,äÆæç,CForm,Y,1,1,1,97.95.176.240,2530
which produces empty array elements for fields with special
characters:
Array ( [0] => 0909211132 [1] => 1 [2] => [3] => [4] => URL [5] => Y
[6] => 1 [7] => 1 [8] => 1 [9] => 97.95.176.240 [10] => 2530 )
[2009-06-26 19:35:22] sjoerd-php at linuxonly dot nl
Could reproduce with php 5.2.10, php 5.2.11-dev (200906261830) and php
5.3rc4. Example code:
Expected: string(5) "?TICA"
Actual: string(4) "TICA"
[2009-06-13 18:10:03] krynble at yahoo dot com dot br
Unfortunately I'm unable to test it because the server is running in a
Datacenter.
If someone can give a feedback about it, I would apreciate.
Still, thanks for the help!
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/48507
--
Edit this bug report at http://bugs.php.net/?id=48507&edit=1
#48507 [Com]: fgetcsv() ignoring special characters
ID: 48507 Comment by: phofstetter at sensational dot ch Reported By: krynble at yahoo dot com dot br Status: Verified Bug Type: Filesystem function related Operating System: Unix PHP Version: 5.2.9 New Comment: I was looking into this (after having been bitten by it) and I can add another tidbit that might help tracking this down: The bug doesn't happen if the file fgetcsv() is reading is in UTF-8-format. I have created a test-file in ISO-8859-1 and then used file_put_contents(utf8encode(file_get_contents())) to create the UTF8-version of it (explaining this here because I'm not sure whether this would write a BOM or not - probably not though). That version could be read correctly. I'm now writing a stream filter that does the UTF-8 conversion on the fly to hook that in between the file and fgetcsv() - while I would lose a bit of performance, in my case, this is the cleanest workaround. Previous Comments: [2009-09-21 18:11:47] dmulryan at calendarwiz dot com Note: Previous comment has error where URL is shown in array element. This is not a bug but my error in the example. Bug is in special characters. [2009-09-21 18:07:42] dmulryan at calendarwiz dot com Similar problem when parsing the following line: 0909211132,1,ØÊááàÑ,äÆæç,CForm,Y,1,1,1,97.95.176.240,2530 which produces empty array elements for fields with special characters: Array ( [0] => 0909211132 [1] => 1 [2] => [3] => [4] => URL [5] => Y [6] => 1 [7] => 1 [8] => 1 [9] => 97.95.176.240 [10] => 2530 ) [2009-06-26 19:35:22] sjoerd-php at linuxonly dot nl Could reproduce with php 5.2.10, php 5.2.11-dev (200906261830) and php 5.3rc4. Example code: Expected: string(5) "?TICA" Actual: string(4) "TICA" [2009-06-13 18:10:03] krynble at yahoo dot com dot br Unfortunately I'm unable to test it because the server is running in a Datacenter. If someone can give a feedback about it, I would apreciate. Still, thanks for the help! [2009-06-10 12:47:52] 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/48507 -- Edit this bug report at http://bugs.php.net/?id=48507&edit=1
#29521 [Com]: compress.bzip2 wrapper
ID: 29521 Comment by: phofstetter at sensational dot ch Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Bzip2 Related Operating System: win32 only PHP Version: 5.2CVS-2007-01-10 Assigned To: iliaa New Comment: Hi, being the reporter of bug #42117, I think this really is the same thing and I actually reported a duplicate (terribly sorry for this), though "my" bug is about the bzip2.compress *filter* where this is about the stream *wrapper*, but the bug really feels like being the same problem. Also, the warning is consistent to what I have seen in my case and to what the incorrect checking of that error code (see #42117) would cause. I'm really having my hopes up that this is going to be fixed now :-) Philip Previous Comments: [2007-08-04 21:03:19] [EMAIL PROTECTED] See bug #42117 which might be the same issue. Nuno, can you try the patch? [2007-01-12 22:10:27] [EMAIL PROTECTED] yep, it still issue the same warning. [2007-01-12 16:45:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2005-11-17 19:18:23] [EMAIL PROTECTED] Warning: fopen(compress.bzip2://http://pt.php.net/backend/notes/all.bz2): failed to open stream: Invalid argument in C:\Documents and Settings\Nuno\- on line 3 [2005-07-01 16:08:32] [EMAIL PROTECTED] Yes, I'm using the binaries from snaps.php.net BTW, my builds work :) (on cygwin, as I don't have the MSVC) 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/29521 -- Edit this bug report at http://bugs.php.net/?id=29521&edit=1
#42117 [Fbk->Opn]: bzip2.compress loses data in internal buffer
ID: 42117
User updated by: phofstetter at sensational dot ch
Reported By: phofstetter at sensational dot ch
-Status: Feedback
+Status: Open
Bug Type: Bzip2 Related
Operating System: Linux and Mac OSX
PHP Version: 5.2.3
New Comment:
Hello,
even with the latest snapshot, the bug is still there. Data in bzip's
internal buffer is lost on stream close due to the problem I discovered
in bz2_filter.c
The patch I proposed blow seems to do the right thing and in fact is
now creating more than 1000 correct bzip2-streams per day, so I think
it's save to say that it really does its job :-)
It's illegal to compare the return code of
BZ2_bzCompress(&(data->strm), BZ_FINISH); with BZ_OUTBUFF_FULL as
BZ2_bzCompress *never* returns BZ_OUTBUFF_FULL (which is a return value
of one of the higher level convenience functions in bzlib.
Philip
Previous Comments:
[2007-08-04 20:56:33] [EMAIL PROTECTED]
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
[2007-07-27 10:06:28] phofstetter at sensational dot ch
looking at the documentation wasn't enough. When I looked at the source
of bzlib, I found out this:
BZ2_bzCompress called with BZ_FINISH keeps returning
BZ_FINISH_OK
(instead of BZ_RUN_OK which I assumed after reading the docs) until
it's really done. Then it will return
BZ_STREAM_END
So the following patch fixes this bug:
--- bz2_filter.c.orig 2007-07-27 11:24:44.0 +0200
+++ bz2_filter.c2007-07-27 11:54:35.0 +0200
@@ -228,8 +228,8 @@
if (flags & PSFS_FLAG_FLUSH_CLOSE) {
/* Spit it out! */
- status = BZ_OUTBUFF_FULL;
- while (status == BZ_OUTBUFF_FULL) {
+ status = BZ_FINISH_OK;
+ while (status == BZ_FINISH_OK) {
status = BZ2_bzCompress(&(data->strm),
BZ_FINISH);
if (data->strm.avail_out < data->outbuf_len) {
size_t bucketlen = data->outbuf_len -
data->strm.avail_out;
With this modification, the complete data gets written out to the
stream.
Please consider applying this patch as without it, the bzip2.compress
filter will sometimes (often - if the data is large enough to be bigger
than the internal buffer) create corrupted data.
Philip
PS: The patch is against 5.2.2 as I'm unable to compile 5.2.3 on OSX
with GD enabled due to gcc being called with an empty -L tag somewhere
in configure.
--------------------
[2007-07-27 09:21:38] phofstetter at sensational dot ch
after finally getting some sleep, today I looked at the problem in
bz2_filter.c and I may have found something.
On line 229+ we have
if (flags & PSFS_FLAG_FLUSH_CLOSE) {
/* Spit it out! */
status = BZ_OUTBUFF_FULL;
while (status == BZ_OUTBUFF_FULL) {
status = BZ2_bzCompress(&(data->strm), BZ_FINISH);
if (data->strm.avail_out < data->outbuf_len) {
size_t bucketlen = data->outbuf_len -
data->strm.avail_out;
bucket = php_stream_bucket_new(stream,
estrndup(data->outbuf,
bucketlen), bucketlen, 1, 0 TSRMLS_CC);
php_stream_bucket_append(buckets_out, bucket
TSRMLS_CC);
data->strm.avail_out = data->outbuf_len;
data->strm.next_out = data->outbuf;
exit_status = PSFS_PASS_ON;
}
}
}
now the problem is IMHO that BZ2_bzCompress with BZ_FINISH will never
return BZ_OUTBUFF_FULL. Looking at the documentation, it will return
BZ_RUN_OK until all data has been processed when it will return
BZ_FINISH_OK.
So with the code as it is currently in PHP, it will only do one run ob
BZ2_bzCompress and then stop working even though more calls could be
needed.
This is consistent with how the bug manifests itself.
I will try to correct the return code handling, but keep in mind that
my C-skills are subpar, so the patch I'm going to post afterwards is
probably not as good as it could be, so please have a look at the
thing.
Philip
------------
[2007-07-26 22:53:50] phofstetter at sensational dot ch
Description:
When bzip2.compress is attached to a stream and enough data is created
so the output will be larger than som
#42117 [Opn]: bzip2.compress loses data in internal buffer
ID: 42117
User updated by: phofstetter at sensational dot ch
Reported By: phofstetter at sensational dot ch
Status: Open
Bug Type: Bzip2 Related
Operating System: Linux and Mac OSX
PHP Version: 5.2.3
New Comment:
looking at the documentation wasn't enough. When I looked at the source
of bzlib, I found out this:
BZ2_bzCompress called with BZ_FINISH keeps returning
BZ_FINISH_OK
(instead of BZ_RUN_OK which I assumed after reading the docs) until
it's really done. Then it will return
BZ_STREAM_END
So the following patch fixes this bug:
--- bz2_filter.c.orig 2007-07-27 11:24:44.0 +0200
+++ bz2_filter.c2007-07-27 11:54:35.0 +0200
@@ -228,8 +228,8 @@
if (flags & PSFS_FLAG_FLUSH_CLOSE) {
/* Spit it out! */
- status = BZ_OUTBUFF_FULL;
- while (status == BZ_OUTBUFF_FULL) {
+ status = BZ_FINISH_OK;
+ while (status == BZ_FINISH_OK) {
status = BZ2_bzCompress(&(data->strm),
BZ_FINISH);
if (data->strm.avail_out < data->outbuf_len) {
size_t bucketlen = data->outbuf_len -
data->strm.avail_out;
With this modification, the complete data gets written out to the
stream.
Please consider applying this patch as without it, the bzip2.compress
filter will sometimes (often - if the data is large enough to be bigger
than the internal buffer) create corrupted data.
Philip
PS: The patch is against 5.2.2 as I'm unable to compile 5.2.3 on OSX
with GD enabled due to gcc being called with an empty -L tag somewhere
in configure.
Previous Comments:
------------
[2007-07-27 09:21:38] phofstetter at sensational dot ch
after finally getting some sleep, today I looked at the problem in
bz2_filter.c and I may have found something.
On line 229+ we have
if (flags & PSFS_FLAG_FLUSH_CLOSE) {
/* Spit it out! */
status = BZ_OUTBUFF_FULL;
while (status == BZ_OUTBUFF_FULL) {
status = BZ2_bzCompress(&(data->strm), BZ_FINISH);
if (data->strm.avail_out < data->outbuf_len) {
size_t bucketlen = data->outbuf_len -
data->strm.avail_out;
bucket = php_stream_bucket_new(stream,
estrndup(data->outbuf,
bucketlen), bucketlen, 1, 0 TSRMLS_CC);
php_stream_bucket_append(buckets_out, bucket
TSRMLS_CC);
data->strm.avail_out = data->outbuf_len;
data->strm.next_out = data->outbuf;
exit_status = PSFS_PASS_ON;
}
}
}
now the problem is IMHO that BZ2_bzCompress with BZ_FINISH will never
return BZ_OUTBUFF_FULL. Looking at the documentation, it will return
BZ_RUN_OK until all data has been processed when it will return
BZ_FINISH_OK.
So with the code as it is currently in PHP, it will only do one run ob
BZ2_bzCompress and then stop working even though more calls could be
needed.
This is consistent with how the bug manifests itself.
I will try to correct the return code handling, but keep in mind that
my C-skills are subpar, so the patch I'm going to post afterwards is
probably not as good as it could be, so please have a look at the
thing.
Philip
--------------------
[2007-07-26 22:53:50] phofstetter at sensational dot ch
Description:
When bzip2.compress is attached to a stream and enough data is created
so the output will be larger than some internal buffer, all data in the
last not totally full buffer seems to get lost on the way out.
The sample code contains quite a lot of filler text which is needed to
actually fill up the internal buffer full enough to trigger the
problem.
I always had this problem since the stream filters got introduced into
PHP, but now I could finally create a very much reduced test case
explaining the problem.
Reproduce code:
---
Expected result:
If I call the script with
./script.php blah
and then use
bzcat blah
I expect the complete data output to the console.
from
BEGIN (0)
to
END ()
Actual result:
--
bzcat outputs until somewhere around "END (9207)" and then bails out
with
bzcat: Compressed file ends unexpectedly;
perhaps it is corrupted? *Possible* reason follows.
bzcat: Unknown error: 0
Input file = blah, output file = (stdout)
It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.
You can use the `bzip2recover' program to attempt to recover
d
#42117 [Opn]: bzip2.compress loses data in internal buffer
ID: 42117
User updated by: phofstetter at sensational dot ch
Reported By: phofstetter at sensational dot ch
Status: Open
Bug Type: Bzip2 Related
Operating System: Linux and Mac OSX
PHP Version: 5.2.3
New Comment:
after finally getting some sleep, today I looked at the problem in
bz2_filter.c and I may have found something.
On line 229+ we have
if (flags & PSFS_FLAG_FLUSH_CLOSE) {
/* Spit it out! */
status = BZ_OUTBUFF_FULL;
while (status == BZ_OUTBUFF_FULL) {
status = BZ2_bzCompress(&(data->strm), BZ_FINISH);
if (data->strm.avail_out < data->outbuf_len) {
size_t bucketlen = data->outbuf_len -
data->strm.avail_out;
bucket = php_stream_bucket_new(stream,
estrndup(data->outbuf,
bucketlen), bucketlen, 1, 0 TSRMLS_CC);
php_stream_bucket_append(buckets_out, bucket
TSRMLS_CC);
data->strm.avail_out = data->outbuf_len;
data->strm.next_out = data->outbuf;
exit_status = PSFS_PASS_ON;
}
}
}
now the problem is IMHO that BZ2_bzCompress with BZ_FINISH will never
return BZ_OUTBUFF_FULL. Looking at the documentation, it will return
BZ_RUN_OK until all data has been processed when it will return
BZ_FINISH_OK.
So with the code as it is currently in PHP, it will only do one run ob
BZ2_bzCompress and then stop working even though more calls could be
needed.
This is consistent with how the bug manifests itself.
I will try to correct the return code handling, but keep in mind that
my C-skills are subpar, so the patch I'm going to post afterwards is
probably not as good as it could be, so please have a look at the
thing.
Philip
Previous Comments:
------------
[2007-07-26 22:53:50] phofstetter at sensational dot ch
Description:
When bzip2.compress is attached to a stream and enough data is created
so the output will be larger than some internal buffer, all data in the
last not totally full buffer seems to get lost on the way out.
The sample code contains quite a lot of filler text which is needed to
actually fill up the internal buffer full enough to trigger the
problem.
I always had this problem since the stream filters got introduced into
PHP, but now I could finally create a very much reduced test case
explaining the problem.
Reproduce code:
---
Expected result:
If I call the script with
./script.php blah
and then use
bzcat blah
I expect the complete data output to the console.
from
BEGIN (0)
to
END ()
Actual result:
--
bzcat outputs until somewhere around "END (9207)" and then bails out
with
bzcat: Compressed file ends unexpectedly;
perhaps it is corrupted? *Possible* reason follows.
bzcat: Unknown error: 0
Input file = blah, output file = (stdout)
It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.
You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.
and true enough - the file is not completely written.
--
Edit this bug report at http://bugs.php.net/?id=42117&edit=1
#42117 [NEW]: bzip2.compress loses data in internal buffer
From: phofstetter at sensational dot ch Operating system: Linux and Mac OSX PHP version: 5.2.3 PHP Bug Type: Streams related Bug description: bzip2.compress loses data in internal buffer Description: When bzip2.compress is attached to a stream and enough data is created so the output will be larger than some internal buffer, all data in the last not totally full buffer seems to get lost on the way out. The sample code contains quite a lot of filler text which is needed to actually fill up the internal buffer full enough to trigger the problem. I always had this problem since the stream filters got introduced into PHP, but now I could finally create a very much reduced test case explaining the problem. Reproduce code: --- Expected result: If I call the script with ./script.php blah and then use bzcat blah I expect the complete data output to the console. from BEGIN (0) to END () Actual result: -- bzcat outputs until somewhere around "END (9207)" and then bails out with bzcat: Compressed file ends unexpectedly; perhaps it is corrupted? *Possible* reason follows. bzcat: Unknown error: 0 Input file = blah, output file = (stdout) It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. and true enough - the file is not completely written. -- Edit bug report at http://bugs.php.net/?id=42117&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42117&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42117&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42117&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42117&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42117&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42117&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42117&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42117&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42117&r=support Expected behavior:http://bugs.php.net/fix.php?id=42117&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42117&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42117&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42117&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42117&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42117&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42117&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42117&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42117&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42117&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42117&r=mysqlcfg
