date:20121008

Bug #63236 [Opn->Csd]: Executable permission on various source files

2012-10-08 Thread laruence

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

 ID: 63236
 Updated by: larue...@php.net
 Reported by:r...@php.net
 Summary:Executable permission on various source files
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   GNU/Linux
 PHP Version:5.4Git-2012-10-08 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=6284ef112ef870b791b8dfab36a39c4664744cc5
Log: Fixed bug #63236 (Executable permission on various source files)


Previous Comments:

[2012-10-08 07:55:14] r...@php.net

Description:

Not a big issue, but easy to fix one.

This raises some warnings (rpmlint) for packaging on the "debuginfo" package.

Test script:
---
find . -name \*.[ch] -executable 

Expected result:

empty result

Actual result:
--
./Zend/zend_iterators.c
./Zend/zend_build.h
./Zend/zend_interfaces.h
./Zend/zend_interfaces.c
./Zend/zend_iterators.h
./ext/sqlite/libsqlite/src/config_static.w32.h
./ext/pcntl/pcntl.c
./ext/interbase/php_ibase_includes.h
./ext/com_dotnet/com_persist.c
./ext/enchant/enchant.c
./ext/pdo_oci/php_pdo_oci_int.h
./ext/pdo_oci/php_pdo_oci.h
./ext/pdo_oci/oci_statement.c
./ext/pdo_oci/oci_driver.c
./ext/pdo_oci/pdo_oci.c
./ext/mbstring/libmbfl/filters/mbfilter_iso8859_16.h
./ext/mbstring/libmbfl/filters/mbfilter_iso8859_16.c
./ext/mbstring/libmbfl/mbfl/mbfl_defs.h
./ext/mbstring/oniguruma/enc/utf32_le.c
./ext/mbstring/oniguruma/enc/utf32_be.c
./ext/mbstring/oniguruma/enc/utf16_be.c
./ext/mbstring/oniguruma/enc/utf16_le.c
./ext/mbstring/oniguruma/regext.c
./ext/pdo_mysql/pdo_mysql.c
./ext/pdo_mysql/mysql_statement.c
./ext/pdo_mysql/mysql_driver.c
./ext/pdo_mysql/php_pdo_mysql.h
./ext/pdo_mysql/php_pdo_mysql_int.h
./ext/pdo/php_pdo.h
./ext/pdo/php_pdo_int.h
./ext/pdo/pdo_stmt.c
./ext/pdo/pdo.c
./ext/pdo/php_pdo_driver.h
./ext/pdo/pdo_dbh.c
./ext/spl/spl_exceptions.c
./ext/spl/spl_functions.h
./ext/spl/spl_exceptions.h
./ext/spl/spl_functions.c
./ext/spl/spl_array.h
./ext/spl/spl_observer.c
./ext/spl/spl_directory.h
./ext/spl/spl_directory.c
./ext/spl/spl_array.c
./ext/spl/php_spl.c
./ext/spl/spl_engine.h
./ext/spl/spl_iterators.c
./ext/spl/php_spl.h
./ext/spl/spl_iterators.h
./ext/spl/spl_observer.h
./ext/spl/spl_engine.c
./ext/simplexml/sxe.h
./ext/simplexml/php_simplexml_exports.h
./ext/simplexml/sxe.c
./ext/dba/php_db1.h
./ext/dba/dba_db1.c
./ext/dba/dba_qdbm.c
./ext/pdo_odbc/odbc_stmt.c
./ext/pdo_odbc/php_pdo_odbc_int.h
./ext/pdo_odbc/pdo_odbc.c
./ext/pdo_odbc/odbc_driver.c
./ext/standard/winver.h
./main/streams/glob_wrapper.c
./main/streams/php_stream_glob_wrapper.h
./main/streams/streams.c
./main/php_streams.h
./win32/globals.c
./win32/php_win32_globals.h







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

Bug #63235 [Opn->Csd]: buffer overflow in use of SQLGetDiagRec

2012-10-08 Thread laruence

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

 ID: 63235
 Updated by: larue...@php.net
 Reported by:r...@php.net
 Summary:buffer overflow in use of SQLGetDiagRec
-Status: Open
+Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   GNU/Linux
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=45e0d452c5c369f0141fde780a6cbdd35d8f55b4
Log: Fixed bug #63235 (buffer overflow in use of SQLGetDiagRec)


Previous Comments:

[2012-10-09 04:58:21] r...@php.net

@laruence: thanks, but I don't have commit right on php-src (only on pecl)


[2012-10-09 02:12:59] larue...@php.net

yeah, I think you can commit that patch. thanks


[2012-10-08 18:14:02] r...@php.net

@laruence, I agree, but is this case should rather be SQL_MAX_MESSAGE_LENGTH+1 
as used in unixODBC source code.

But this have no risk as this is (mostly) protected by the buffer_length arg.

>From extract_sql_error_rec function source code
(unixODBC-2.3.1/DriverManager/SQLGetDiagRec.c)

if ( sqlstate )
strcpy((char*) sqlstate, "0" );

Here is the buffer overflow issue (no length protection).


[2012-10-08 15:35:02] larue...@php.net

maybe the discard_buf should also be consistent with struct 
pdo_odbc_errinfo.last_err_msg 

which is "char last_err_msg[SQL_MAX_MESSAGE_LENGTH];"

diff is:

diff --git a/ext/pdo_odbc/odbc_driver.c b/ext/pdo_odbc/odbc_driver.c
index 84a147b..2176051 100755
--- a/ext/pdo_odbc/odbc_driver.c
+++ b/ext/pdo_odbc/odbc_driver.c
@@ -114,8 +114,8 @@ void pdo_odbc_error(pdo_dbh_t *dbh, pdo_stmt_t *stmt, 
PDO_ODBC_HSTMT statement,
 * diagnostic records (which can be generated by PRINT statements
 * in the query, for instance). */
while (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO) {
-   char discard_state[5];
-   char discard_buf[1024];
+   char discard_state[6];
+   char discard_buf[SQL_MAX_MESSAGE_LENGTH];
SQLINTEGER code;
rc = SQLGetDiagRec(htype, eh, recno++, discard_state, &code,
discard_buf, sizeof(discard_buf)-1, 
&errmsgsize);


[2012-10-08 07:37:02] r...@php.net

The following patch has been added/updated:

Patch Name: php-5.3.3-pdo-overflow.patch
Revision:   1349681821
URL:
https://bugs.php.net/patch-display.php?bug=63235&patch=php-5.3.3-pdo-overflow.patch&revision=1349681821




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=63235


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

Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css

2012-10-08 Thread reeze

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

 ID: 63242
 Updated by: re...@php.net
 Reported by:pascal dot chevrel at free dot fr
 Summary:Default error page in PHP built-in web server uses
 outdated html/css
 Status: Open
 Type:   Feature/Change Request
 Package:Built-in web server
 Operating System:   Linux
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

It's nice to have modern, but the appearance should be consist on PHP 
itself(VI).

PHP use the BLUE a lot, kind of the color of PHP.

as the color yellow, It looks like an error page of django :) 

and the built-in server is just for testing purpose, If possible, I'd PHP
redesign its Visual Identity System to be more modern.

And, yes there is a PHP.net alpha there: http://www.php.net/my.php (enable it 
at 
the bottom).  but seems didn't active for a long time.


Previous Comments:

[2012-10-08 17:53:00] pascal dot chevrel at free dot fr

Here is a after/before screenshot:

http://chevrel.org/images/phpbugs/bug63242.png

Note that I chose yellow for the error header instead of blue because this is 
the color used in the terminal for such errors, blue is not usually an error 
associated to errors.


[2012-10-08 17:41:00] pascal dot chevrel at free dot fr

Description:

The default error page in the built-in webserver is very ugly. Looking at the 
history of the file in the git repository, these styles and html were copied 
from the phpinfo styling created in 2002 with CSS selectors that had Netscape 
4/IE4 compatibility in mind.

Appearances matter :) It makes this new PHP feature look already outdated.

I am going to attach a patch that:
* will make it look a bit more modern and works in responsive mode too
* will remove unused css rules from the code
* will add an html5 doctype to the error page
* will remove unnecesary html attributes in html5

(I noticed that there are 2 tests in the sapi/cli/tests folder that reproduce 
some of this html, I don't know how tests work for php but I can give a shot at 
updating the expected results of the tests in the patch if required)







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

Bug #63235 [Opn]: buffer overflow in use of SQLGetDiagRec

2012-10-08 Thread remi

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

 ID: 63235
 Updated by: r...@php.net
 Reported by:r...@php.net
 Summary:buffer overflow in use of SQLGetDiagRec
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   GNU/Linux
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

@laruence: thanks, but I don't have commit right on php-src (only on pecl)


Previous Comments:

[2012-10-09 02:12:59] larue...@php.net

yeah, I think you can commit that patch. thanks


[2012-10-08 18:14:02] r...@php.net

@laruence, I agree, but is this case should rather be SQL_MAX_MESSAGE_LENGTH+1 
as used in unixODBC source code.

But this have no risk as this is (mostly) protected by the buffer_length arg.

>From extract_sql_error_rec function source code
(unixODBC-2.3.1/DriverManager/SQLGetDiagRec.c)

if ( sqlstate )
strcpy((char*) sqlstate, "0" );

Here is the buffer overflow issue (no length protection).


[2012-10-08 15:35:02] larue...@php.net

maybe the discard_buf should also be consistent with struct 
pdo_odbc_errinfo.last_err_msg 

which is "char last_err_msg[SQL_MAX_MESSAGE_LENGTH];"

diff is:

diff --git a/ext/pdo_odbc/odbc_driver.c b/ext/pdo_odbc/odbc_driver.c
index 84a147b..2176051 100755
--- a/ext/pdo_odbc/odbc_driver.c
+++ b/ext/pdo_odbc/odbc_driver.c
@@ -114,8 +114,8 @@ void pdo_odbc_error(pdo_dbh_t *dbh, pdo_stmt_t *stmt, 
PDO_ODBC_HSTMT statement,
 * diagnostic records (which can be generated by PRINT statements
 * in the query, for instance). */
while (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO) {
-   char discard_state[5];
-   char discard_buf[1024];
+   char discard_state[6];
+   char discard_buf[SQL_MAX_MESSAGE_LENGTH];
SQLINTEGER code;
rc = SQLGetDiagRec(htype, eh, recno++, discard_state, &code,
discard_buf, sizeof(discard_buf)-1, 
&errmsgsize);


[2012-10-08 07:37:02] r...@php.net

The following patch has been added/updated:

Patch Name: php-5.3.3-pdo-overflow.patch
Revision:   1349681821
URL:
https://bugs.php.net/patch-display.php?bug=63235&patch=php-5.3.3-pdo-overflow.patch&revision=1349681821


[2012-10-08 07:36:51] r...@php.net

Description:

Already report on internals http://marc.info/?t=13426268866&r=1&w=2

Discard state is 5 char long, so buffer must be 6.

Trivial fix attached.
(could apply in all branches)








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

Bug #63240 [Opn]: stream_get_line return contains delimiter string

2012-10-08 Thread datibbaw

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

 ID: 63240
 Updated by: datib...@php.net
 Reported by:scope at planetavent dot de
 Summary:stream_get_line return contains delimiter string
 Status: Open
 Type:   Bug
 Package:Streams related
 Operating System:   Windows Server 2008 / RHEL 6.2
 PHP Version:5.3.17
 Block user comment: N
 Private report: N

 New Comment:

Reduced test:

  $file = __DIR__ . '/input_dummy.txt';
  $data = str_repeat( '.', 8189 ) . '';
  file_put_contents( $file, $data );
  $fh = fopen( $file, "rb" );
  $delimiter = "MM";

  stream_get_line($fh, 4096, $delimiter);
  stream_get_line($fh, 4096, $delimiter);
  if ($delimiter === stream_get_line($fh, 4096, $delimiter)) {
echo "BROKEN";
  } else {
echo "OK";
  }
  fclose($fh);
  unlink($file);

The amount of dots seems to be related to the used buffer length:

( + 3) % ( x 2) == 0

The length of the delimiter also seems to play a role, but I'm not sure what 
that would be.


Previous Comments:

[2012-10-08 16:03:38] scope at planetavent dot de

Description:

On specific file input stream_get_line returns a "line" that actually contains 
the delimiter.

PHP 5.3.10 does not show this problem, PHP versions from 5.3.11 to 5.3.17 do. 
PHP 5.4.7 seems to be affected as well.

Bug #44607 seems to be related, but was fixed long time ago.

Test script:
---
https://bugs.php.net/bug.php?id=63240&edit=1

Bug #63235 [Opn]: buffer overflow in use of SQLGetDiagRec

2012-10-08 Thread laruence

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

 ID: 63235
 Updated by: larue...@php.net
 Reported by:r...@php.net
 Summary:buffer overflow in use of SQLGetDiagRec
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   GNU/Linux
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

yeah, I think you can commit that patch. thanks


Previous Comments:

[2012-10-08 18:14:02] r...@php.net

@laruence, I agree, but is this case should rather be SQL_MAX_MESSAGE_LENGTH+1 
as used in unixODBC source code.

But this have no risk as this is (mostly) protected by the buffer_length arg.

>From extract_sql_error_rec function source code
(unixODBC-2.3.1/DriverManager/SQLGetDiagRec.c)

if ( sqlstate )
strcpy((char*) sqlstate, "0" );

Here is the buffer overflow issue (no length protection).


[2012-10-08 15:35:02] larue...@php.net

maybe the discard_buf should also be consistent with struct 
pdo_odbc_errinfo.last_err_msg 

which is "char last_err_msg[SQL_MAX_MESSAGE_LENGTH];"

diff is:

diff --git a/ext/pdo_odbc/odbc_driver.c b/ext/pdo_odbc/odbc_driver.c
index 84a147b..2176051 100755
--- a/ext/pdo_odbc/odbc_driver.c
+++ b/ext/pdo_odbc/odbc_driver.c
@@ -114,8 +114,8 @@ void pdo_odbc_error(pdo_dbh_t *dbh, pdo_stmt_t *stmt, 
PDO_ODBC_HSTMT statement,
 * diagnostic records (which can be generated by PRINT statements
 * in the query, for instance). */
while (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO) {
-   char discard_state[5];
-   char discard_buf[1024];
+   char discard_state[6];
+   char discard_buf[SQL_MAX_MESSAGE_LENGTH];
SQLINTEGER code;
rc = SQLGetDiagRec(htype, eh, recno++, discard_state, &code,
discard_buf, sizeof(discard_buf)-1, 
&errmsgsize);


[2012-10-08 07:37:02] r...@php.net

The following patch has been added/updated:

Patch Name: php-5.3.3-pdo-overflow.patch
Revision:   1349681821
URL:
https://bugs.php.net/patch-display.php?bug=63235&patch=php-5.3.3-pdo-overflow.patch&revision=1349681821


[2012-10-08 07:36:51] r...@php.net

Description:

Already report on internals http://marc.info/?t=13426268866&r=1&w=2

Discard state is 5 char long, so buffer must be 6.

Trivial fix attached.
(could apply in all branches)








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

[PHP-BUG] Bug #63244 [NEW]: PDO fetch is inconsistent with MySQL's bit column

2012-10-08 Thread juzna dot cz at gmail dot com

From: juzna dot cz at gmail dot com
Operating system: Ubuntu
PHP version:  5.3.17
Package:  PDO related
Bug Type: Bug
Bug description:PDO fetch is inconsistent with MySQL's bit column

Description:

Suppose MySQL database with a column of type bit(1).

Then fetching value from this column gives a binary string ("\0", "\1") in
PHP5.3 
and numeric string ("0", "1") in 5.4.

I'd expect to obtain a boolean, but numeric string would be a good enough.
But it 
must be consistent in both PHP versions.

Test script:
---
$res = $connection->query("SELECT * FROM bittest");
$row = $res->fetch();
dump($row);
Assert::same(0, $row->id);
Assert::same(false, $row->flag);

$row = $res->fetch();
dump($row);
Assert::same(1, $row->id);
Assert::same(true, $row->flag);


Expected result:

// 5.3.17
Nette\Database\Row(2) {
   id => 0
   flag => "\00"
}

Nette\Database\Row(2) {
   id => 1
   flag => "\01"
}


// PHP 5.4.7
Nette\Database\Row(2) {
   id => 0
   flag => "0"
}

Nette\Database\Row(2) {
   id => 1
   flag => "1"
}

Actual result:
--
Both PHP versions the same.

-- 
Edit bug report at https://bugs.php.net/bug.php?id=63244&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=63244&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=63244&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=63244&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=63244&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=63244&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63244&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=63244&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=63244&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63244&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=63244&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63244&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63244&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=63244&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63244&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=63244&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=63244&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63244&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63244&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63244&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=63244&r=mysqlcfg

Bug #63235 [Opn]: buffer overflow in use of SQLGetDiagRec

2012-10-08 Thread remi

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

 ID: 63235
 Updated by: r...@php.net
 Reported by:r...@php.net
 Summary:buffer overflow in use of SQLGetDiagRec
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   GNU/Linux
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

@laruence, I agree, but is this case should rather be SQL_MAX_MESSAGE_LENGTH+1 
as used in unixODBC source code.

But this have no risk as this is (mostly) protected by the buffer_length arg.

>From extract_sql_error_rec function source code
(unixODBC-2.3.1/DriverManager/SQLGetDiagRec.c)

if ( sqlstate )
strcpy((char*) sqlstate, "0" );

Here is the buffer overflow issue (no length protection).


Previous Comments:

[2012-10-08 15:35:02] larue...@php.net

maybe the discard_buf should also be consistent with struct 
pdo_odbc_errinfo.last_err_msg 

which is "char last_err_msg[SQL_MAX_MESSAGE_LENGTH];"

diff is:

diff --git a/ext/pdo_odbc/odbc_driver.c b/ext/pdo_odbc/odbc_driver.c
index 84a147b..2176051 100755
--- a/ext/pdo_odbc/odbc_driver.c
+++ b/ext/pdo_odbc/odbc_driver.c
@@ -114,8 +114,8 @@ void pdo_odbc_error(pdo_dbh_t *dbh, pdo_stmt_t *stmt, 
PDO_ODBC_HSTMT statement,
 * diagnostic records (which can be generated by PRINT statements
 * in the query, for instance). */
while (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO) {
-   char discard_state[5];
-   char discard_buf[1024];
+   char discard_state[6];
+   char discard_buf[SQL_MAX_MESSAGE_LENGTH];
SQLINTEGER code;
rc = SQLGetDiagRec(htype, eh, recno++, discard_state, &code,
discard_buf, sizeof(discard_buf)-1, 
&errmsgsize);


[2012-10-08 07:37:02] r...@php.net

The following patch has been added/updated:

Patch Name: php-5.3.3-pdo-overflow.patch
Revision:   1349681821
URL:
https://bugs.php.net/patch-display.php?bug=63235&patch=php-5.3.3-pdo-overflow.patch&revision=1349681821


[2012-10-08 07:36:51] r...@php.net

Description:

Already report on internals http://marc.info/?t=13426268866&r=1&w=2

Discard state is 5 char long, so buffer must be 6.

Trivial fix attached.
(could apply in all branches)








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

Req #63242 [Com]: Default error page in PHP built-in web server uses outdated html/css

2012-10-08 Thread pascal dot chevrel at free dot fr

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

 ID: 63242
 Comment by: pascal dot chevrel at free dot fr
 Reported by:pascal dot chevrel at free dot fr
 Summary:Default error page in PHP built-in web server uses
 outdated html/css
 Status: Open
 Type:   Feature/Change Request
 Package:Built-in web server
 Operating System:   Linux
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

Here is a after/before screenshot:

http://chevrel.org/images/phpbugs/bug63242.png

Note that I chose yellow for the error header instead of blue because this is 
the color used in the terminal for such errors, blue is not usually an error 
associated to errors.


Previous Comments:

[2012-10-08 17:41:00] pascal dot chevrel at free dot fr

Description:

The default error page in the built-in webserver is very ugly. Looking at the 
history of the file in the git repository, these styles and html were copied 
from the phpinfo styling created in 2002 with CSS selectors that had Netscape 
4/IE4 compatibility in mind.

Appearances matter :) It makes this new PHP feature look already outdated.

I am going to attach a patch that:
* will make it look a bit more modern and works in responsive mode too
* will remove unused css rules from the code
* will add an html5 doctype to the error page
* will remove unnecesary html attributes in html5

(I noticed that there are 2 tests in the sapi/cli/tests folder that reproduce 
some of this html, I don't know how tests work for php but I can give a shot at 
updating the expected results of the tests in the patch if required)







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

[PHP-BUG] Req #63242 [NEW]: Default error page in PHP built-in web server uses outdated html/css

2012-10-08 Thread pascal dot chevrel at free dot fr

From: pascal dot chevrel at free dot fr
Operating system: Linux
PHP version:  5.4.7
Package:  Built-in web server
Bug Type: Feature/Change Request
Bug description:Default error page in PHP built-in web server uses outdated 
html/css

Description:

The default error page in the built-in webserver is very ugly. Looking at
the history of the file in the git repository, these styles and html were
copied from the phpinfo styling created in 2002 with CSS selectors that had
Netscape 4/IE4 compatibility in mind.

Appearances matter :) It makes this new PHP feature look already outdated.

I am going to attach a patch that:
* will make it look a bit more modern and works in responsive mode too
* will remove unused css rules from the code
* will add an html5 doctype to the error page
* will remove unnecesary html attributes in html5

(I noticed that there are 2 tests in the sapi/cli/tests folder that
reproduce some of this html, I don't know how tests work for php but I can
give a shot at updating the expected results of the tests in the patch if
required)


-- 
Edit bug report at https://bugs.php.net/bug.php?id=63242&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=63242&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=63242&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=63242&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=63242&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=63242&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63242&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=63242&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=63242&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63242&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=63242&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63242&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63242&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=63242&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63242&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=63242&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=63242&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63242&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63242&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63242&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=63242&r=mysqlcfg

Req #62968 [Opn->Nab]: Unable to Run PHP with IIS 7.X

2012-10-08 Thread mattficken

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

ID: 62968
Updated by: mattfic...@php.net
Reported by:bankim dot rana at strixsystems dot com
Summary:Unable to Run PHP with IIS 7.X
-Status: Open
+Status: Not a bug
Type: Feature/Change Request
Package:IIS related
Operating System: windows 2008 64 bit R2 sp1
PHP Version:5.4.6
Block user comment: N
Private report: N

New Comment:

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

Thank you for your interest in PHP.

ISAPI is not supported by PHP. You should not use it.

You should use FastCGI instead. If instructions, tutorials, etc... weren't
clear on this, then let us know because that will need to be fixed.

For instructions on how to setup PHP with IIS, see this link:
http://www.iis.net/learn/application-frameworks/install-and-configure-php-applications-on-iis/using-fastcgi-to-host-php-applications-on-iis.

You can also try WebPI and PHP Manager, both available on iis.net.

Previous Comments:

[2012-08-29 13:31:17] bankim dot rana at strixsystems dot com

Description:

We are getting "HTTP Error 500.0 - Internal Server Error" while run any php
file on IIS 7 and above on windows 2008 R2 sp1 OS with 64 bit.
Details about error
Module IsapiModule -> Requested URL http://localhost:80/phpinfo.php

Notification ExecuteRequestHandler - Physical Path
C:\inetpub\wwwroot\phpinfo.php

Handler PHP-ISPAI - Logon Method Anonymous
Error Code 0x8007007e - Logon User Anonymous

Test script:
---

Expected result:

it shuld display php.ini configuration

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

[PHP-BUG] Bug #63241 [NEW]: PHP fails to open Windows deduplicated files

2012-10-08 Thread daniel dot stelter-gliese at innogames dot de

From: daniel dot stelter-gliese at innogames dot de
Operating system: Windows Server 2012
PHP version:  5.4.7
Package:  Win32API related
Bug Type: Bug
Bug description:PHP fails to open Windows deduplicated files

Description:

Opening a file that was deduplicated by Windows Server 2012 deduplication
fails 
with "No such file or directory".
The behavior can be reproduced locally and through SMB shares (on Win7 and
Win8 
clients). I've tried 5.3.15 and 5.4.7 - judging from the code latest
snapshots are 
affected, too.

I could trace this to a problem with reparse points: deduplication adds the
new 
reparse tag  IO_REPARSE_TAG_DEDUP. There seems to be no documentation on
this tag, 
so I could only interpret it as a flag to be ignored.
The attached patch simply treats a IO_REPARSE_TAG_DEDUP file as a
substitute on 
the same path, which worked well.

Test script:
---
$path = 'S:\\test.exe';
var_dump(filesize($path));
var_dump(realpath($path));
var_dump(strlen(file_get_contents($path)));
var_dump(fopen($path, 'rb'));

Expected result:

int(5448704)
string(50) "S:\test.exe"
int(5448704)
resource(6) of type (stream)

Actual result:
--
int(5448704)
bool(false)

Warning: file_get_contents(S:\test.exe):
failed to open stream: No such file or directory in
C:\php-sdk\php54dev\vc9\x64\
php-5.4.7-src\x64\Release\test.php on line 6
int(0)

Warning: fopen(S:\test.exe): failed to op
en stream: No such file or directory in
C:\php-sdk\php54dev\vc9\x64\php-5.4.7-sr
c\x64\Release\test.php on line 7
bool(false)


-- 
Edit bug report at https://bugs.php.net/bug.php?id=63241&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=63241&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=63241&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=63241&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=63241&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=63241&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63241&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=63241&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=63241&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63241&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=63241&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63241&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63241&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=63241&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63241&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=63241&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=63241&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63241&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63241&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63241&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=63241&r=mysqlcfg

[PHP-BUG] Bug #63240 [NEW]: stream_get_line return contains delimiter string

2012-10-08 Thread scope at planetavent dot de

From: scope at planetavent dot de
Operating system: Windows Server 2008 / RHEL 6.2
PHP version:  5.3.17
Package:  Streams related
Bug Type: Bug
Bug description:stream_get_line return contains delimiter string

Description:

On specific file input stream_get_line returns a "line" that actually
contains the delimiter.

PHP 5.3.10 does not show this problem, PHP versions from 5.3.11 to 5.3.17
do. PHP 5.4.7 seems to be affected as well.

Bug #44607 seems to be related, but was fixed long time ago.

Test script:
---
https://bugs.php.net/bug.php?id=63240&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=63240&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=63240&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=63240&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=63240&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=63240&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63240&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=63240&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=63240&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63240&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=63240&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63240&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63240&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=63240&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63240&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=63240&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=63240&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63240&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63240&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63240&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=63240&r=mysqlcfg

Bug #63235 [Opn]: buffer overflow in use of SQLGetDiagRec

2012-10-08 Thread laruence

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

 ID: 63235
 Updated by: larue...@php.net
 Reported by:r...@php.net
 Summary:buffer overflow in use of SQLGetDiagRec
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   GNU/Linux
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

maybe the discard_buf should also be consistent with struct 
pdo_odbc_errinfo.last_err_msg 

which is "char last_err_msg[SQL_MAX_MESSAGE_LENGTH];"

diff is:

diff --git a/ext/pdo_odbc/odbc_driver.c b/ext/pdo_odbc/odbc_driver.c
index 84a147b..2176051 100755
--- a/ext/pdo_odbc/odbc_driver.c
+++ b/ext/pdo_odbc/odbc_driver.c
@@ -114,8 +114,8 @@ void pdo_odbc_error(pdo_dbh_t *dbh, pdo_stmt_t *stmt, 
PDO_ODBC_HSTMT statement,
 * diagnostic records (which can be generated by PRINT statements
 * in the query, for instance). */
while (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO) {
-   char discard_state[5];
-   char discard_buf[1024];
+   char discard_state[6];
+   char discard_buf[SQL_MAX_MESSAGE_LENGTH];
SQLINTEGER code;
rc = SQLGetDiagRec(htype, eh, recno++, discard_state, &code,
discard_buf, sizeof(discard_buf)-1, 
&errmsgsize);


Previous Comments:

[2012-10-08 07:37:02] r...@php.net

The following patch has been added/updated:

Patch Name: php-5.3.3-pdo-overflow.patch
Revision:   1349681821
URL:
https://bugs.php.net/patch-display.php?bug=63235&patch=php-5.3.3-pdo-overflow.patch&revision=1349681821


[2012-10-08 07:36:51] r...@php.net

Description:

Already report on internals http://marc.info/?t=13426268866&r=1&w=2

Discard state is 5 char long, so buffer must be 6.

Trivial fix attached.
(could apply in all branches)








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

Bug #63219 [Asn->Csd]: Segfault when aliasing trait method when autoloader throws excpetion

2012-10-08 Thread laruence

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

 ID: 63219
 Updated by: larue...@php.net
 Reported by:maciej dot sz at gmail dot com
 Summary:Segfault when aliasing trait method when autoloader
 throws excpetion
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   3.2.0-31-generic #50-Ubuntu
 PHP Version:5.4Git-2012-10-04 (snap)
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=67611c67fa5a3b2c199d41ef7df3307308c56faa
Log: Fixed bug #63219 (Segfault when aliasing trait method when autoloader 
throws excpetion)


Previous Comments:

[2012-10-08 07:06:14] dmi...@php.net

I think you patch is OK. Please commit it.


[2012-10-05 01:57:57] larue...@php.net

I think there is no need to call autoload in USE block, and it should check the 
fetch result, I have attached a patch, 

but I am not sure what the warning message should be...


[2012-10-05 01:56:09] larue...@php.net

The following patch has been added/updated:

Patch Name: bug63219.patch
Revision:   1349402169
URL:
https://bugs.php.net/patch-display.php?bug=63219&patch=bug63219.patch&revision=1349402169


[2012-10-04 18:43:59] maciej dot sz at gmail dot com

Description:

Class contains "use" statement of a trait. Method alias statement for that 
trait contains a typo in the trait name. The autoloader throws exception and 
then the segfault occurs.

(gdb) p zend_fetch_class(cur_method_ref->class_name, cur_method_ref->cname_len, 
14)
$5 = (zend_class_entry *) 0x0

Test script:
---
---
file TFoo.php

inconsistent==HT_OK) {



(gdb) bt
#0  0x009863c8 in _zend_is_inconsistent (ht=0x28, 
file=0xfb0948 "/home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c", line=969)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c:54
#1  0x009890f5 in zend_hash_exists (ht=0x28, arKey=0x77fc5aa0 
"foomethodd", nKeyLength=11)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c:969
#2  0x00952839 in zend_traits_init_trait_structures (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compile.c:4037
#3  0x00953a4a in zend_do_bind_traits (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compile.c:4370
#4  0x009b79ee in ZEND_BIND_TRAITS_SPEC_HANDLER 
(execute_data=0x77f88500)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:1027
#5  0x009b42f6 in execute (op_array=0x77fc0da8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:410
#6  0x009639b8 in zend_call_function (fci=0x7fffa1a0, 
fci_cache=0x7fffa1f0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:958
#7  0x009956b5 in zend_call_method (object_pp=0x0, obj_ce=0x0, 
fn_proxy=0x77fc41e0, 
function_name=0x77fc17f8 "closure::__invoke\001", function_name_len=22, 
retval_ptr_ptr=0x7fffa2e0, param_count=1, arg1=0x77fbf5d0, arg2=0x0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_interfaces.c:97
#8  0x007a087c in zif_spl_autoload_call (ht=1, 
return_value=0x77fc40d8, 
return_value_ptr=0x7fffa728, this_ptr=0x0, return_value_used=1)
at /home/maciek/Downloads/php-5.4.7/ext/spl/php_spl.c:436
#9  0x00963b92 in zend_call_function (fci=0x7fffa670, 
fci_cache=0x7fffa6c0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:980
#10 0x00964520 in zend_lookup_class_ex (name=0x77eb72f8 "bar\\C", 
name_length=5, 
key=0x77fc24d8, use_autoload=1, ce=0x7fffa7c0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:1127
#11 0x00965230 in zend_fetch_class_by_name (class_name=0x77eb72f8 
"bar\\C", 
class_name_len=5, key=0x77fc24d8, fetch_type=4)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:1607
#12 0x009b8690 in ZEND_FETCH_CLASS_SPEC_CONST_HANDLER 
(execute_data=0x77f880e8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:1173
#13 0x009b42f6 in execute (op_array=0x77fc04c8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:410
#14 0x00976e13 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3)
at /home/maciek/Downloads/php-5.4.7/Zend/zend.c:1286
#15 0x008e9732 in php_execute_script (primary_file=0x7fffce40)
at /home/maciek/Downloads/php-5.4.7/main/main.c:2473
#16 0x00abfa95 in do_cli (argc=2, argv=0x7f

Bug #61579 [Com]: Segfault preg_replace "/'(\\\\'|\\\\{2}|[^'])*'/" with a long string

2012-10-08 Thread serge dot rivest at gmail dot com

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

 ID: 61579
 Comment by: serge dot rivest at gmail dot com
 Reported by:robin at byte dot nl
 Summary:Segfault  preg_replace "/'('|{2}|[^'])*'/"
 with a long string
 Status: Feedback
 Type:   Bug
 Package:PCRE related
 Operating System:   Debian 2.6.
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

I guess that's a question for the people in charge of Zend DB, where this 
pattern 
originates.

I'm just a user ;)


Previous Comments:

[2012-10-08 10:00:31] ni...@php.net

I don't know what exactly the problem is you're facing, but there is a good 
chance that it's just a stack overflow or similar caused by a very inefficient 
regex.

You might be able to fix it simply by using "/'('|{2}|[^']+)*'/".

The right approach though would be "/'[^']*(?:.[^']*)*'/".


[2012-10-08 09:46:09] serge dot rivest at gmail dot com

It does appear to be failing on this line:

foreach ($db->fetchAll($sql) as $a)

Very very likely it's just running out of memory. Although every time it 
crashes 
we also get this in /var/log/syslog:

Oct  8 20:01:39 dev kernel: [726784.383723] php5-fpm[8644]: segfault at 
7fff6b8a2f00 ip 7f6607c80a7a sp 7fff6b8a2e90 error 6 in 
libpcre.so.3.12.1[7f6607c6e000+3c000]

Which is bizarre. Might just be a regexp in the DB driver which is being run 
when 
the process runs out of memory... Hrm, time to try Serges idea of using xdebug. 
And we see:

0.8160   12868128   -> PDO->quote() 
/www/studyladder.dev222/zendframework/Zend/Db/Adapter/Pdo/Abstract.php:296
0.8160   12868344   -> substr() 
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:198
0.8160   12868456   -> str_replace() 
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:199
0.8160   12868472   -> preg_replace() 
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:204

So, probably not running out of memory. This is the code it's crashing on:

// get a version of the SQL statement with all quoted   
  
// values and delimited identifiers stripped out
  
// remove "foo\"bar"
  
$sql = preg_replace("/$q($qe|{2}|[^$q])*$q/", '', $sql);

Don't really know what it is doing, but the regexp looks like this:

/'(\\'|\\{2}|[^'])*'/

And the query it is crashing on does have a long literal string in it with 
single 
quotes. Tried changing the query to use a long literal string with double 
quotes 
and that fixes it. Phew.


[2012-03-31 18:24:38] yohg...@php.net

Cannot reproduce. Could you download source and test against it?
It seems your system's pcrelib problem.


[2012-03-31 11:18:42] robin at byte dot nl

Looked a bit deeper/cleaner:

The preg_replace failes when the string between single quotes is equal or 
longer than 3399 bytes including quotes... 3487 already did seem like an odd 
number ;)

cleaner would be if you take $string = "'...3397chars...'";
then it fails with segfault, 

$string = "'...less than 3397 chars...'";  works fine.


[2012-03-31 10:53:49] robin at byte dot nl

Description:

When i use this preg_replace with a long string (3487+ bytes) and single quotes 
it ends up with a segfault...

$str = preg_replace("/'('|{2}|[^'])*'/", '', $string);

with a string longer than 3487 bytes containing multiple quotes.

results in:

php[26779]: segfault at bf737da8 ip b73e4d43 sp bf737c30 error 6 in 
libpcre.so.3.12.1[b73d4000+28000]


Test script:
---



Expected result:

Remove everything between single quotes.

Actual result:
--
Segmentation fault

[25236001.27] php[29917]: segfault at bf37ddc8 ip b744cd43 sp bf37dc50 
error 6 in libpcre.so.3.12.1[b743c000+28000]







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

Bug #63108 [Csd->Nab]: ZipArchive uncompress bug

2012-10-08 Thread pajoye

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

 ID: 63108
 Updated by: paj...@php.net
 Reported by:sharqgm at gmail dot com
 Summary:ZipArchive uncompress bug
-Status: Closed
+Status: Not a bug
 Type:   Bug
 Package:Zip Related
 Operating System:   windows 7
 PHP Version:5.3.17
 Assigned To:ab
 Block user comment: N
 Private report: N



Previous Comments:

[2012-10-07 22:42:35] sharqgm at gmail dot com

OK. Thanks for your help. The problem caused by different things. I dont know 
yet 
what, but it related to joomla and not PHP. :)


[2012-10-02 07:31:14] sharqgm at gmail dot com

- extratched and zipped on local server
 - The zip compression is checked: OK. (filesize same)
 - After upload, the filesize is: OK.
 - After unzip, the filesize is: DIFFERENT...

Server: 25,822,309 Files: 4854 Dirs: 1131

Local : 18,258,381 Files: 4854 Dirs: 1131
Size on Disk: 30,134,453

File: Joomla_2.5.6-Stable-Full_Package.zip

Intresting... :S


[2012-10-01 08:02:15] a...@php.net

I don't get exactly - is a zip file damaged after upload? Does zip ext extract 
it locally?

Were it possible you to post that zip file (or another one which causes the zip 
ext to work wrong)?


[2012-09-18 08:26:30] sharqgm at gmail dot com

Description:

Some info: I use ziparchive because in my project (joomla) have a lot of small 
files and the upload time is too long (50-120 minute) 

What I did: 

 - Zipped a fresh copy of joomla
 - uploaded to the server
 - extratched by ZipArchive

My keywords and description metadatas are missing. It seems like there is a bug 
with the newline caracter, because when I see the source, there is just a mass 
of 
unformatted code, but on localhost OK. When I avoid this process and uploaded 
files directly everything ok. So the problem come from the ZipArchive.

(sorry for the poor description, I'm not prof, just wanted to notice :))

Test script:
---
 $zip = new ZipArchive;
 $res = $zip->open('un.zip');
 if ($res === TRUE) {
 $zip->extractTo('./');
 $zip->close();
 echo 'ok';
 } else {
 echo 'failed';
 }

Actual result:
--
Keyword and desc meta tag-s missing. 
New lines missing from the most part of the code.






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

Bug #61579 [Com]: Segfault preg_replace "/'(\\\\'|\\\\{2}|[^'])*'/" with a long string

2012-10-08 Thread ni...@php.net

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

 ID: 61579
 Comment by: ni...@php.net
 Reported by:robin at byte dot nl
 Summary:Segfault  preg_replace "/'('|{2}|[^'])*'/"
 with a long string
 Status: Feedback
 Type:   Bug
 Package:PCRE related
 Operating System:   Debian 2.6.
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

I don't know what exactly the problem is you're facing, but there is a good 
chance that it's just a stack overflow or similar caused by a very inefficient 
regex.

You might be able to fix it simply by using "/'('|{2}|[^']+)*'/".

The right approach though would be "/'[^']*(?:.[^']*)*'/".


Previous Comments:

[2012-10-08 09:46:09] serge dot rivest at gmail dot com

It does appear to be failing on this line:

foreach ($db->fetchAll($sql) as $a)

Very very likely it's just running out of memory. Although every time it 
crashes 
we also get this in /var/log/syslog:

Oct  8 20:01:39 dev kernel: [726784.383723] php5-fpm[8644]: segfault at 
7fff6b8a2f00 ip 7f6607c80a7a sp 7fff6b8a2e90 error 6 in 
libpcre.so.3.12.1[7f6607c6e000+3c000]

Which is bizarre. Might just be a regexp in the DB driver which is being run 
when 
the process runs out of memory... Hrm, time to try Serges idea of using xdebug. 
And we see:

0.8160   12868128   -> PDO->quote() 
/www/studyladder.dev222/zendframework/Zend/Db/Adapter/Pdo/Abstract.php:296
0.8160   12868344   -> substr() 
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:198
0.8160   12868456   -> str_replace() 
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:199
0.8160   12868472   -> preg_replace() 
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:204

So, probably not running out of memory. This is the code it's crashing on:

// get a version of the SQL statement with all quoted   
  
// values and delimited identifiers stripped out
  
// remove "foo\"bar"
  
$sql = preg_replace("/$q($qe|{2}|[^$q])*$q/", '', $sql);

Don't really know what it is doing, but the regexp looks like this:

/'(\\'|\\{2}|[^'])*'/

And the query it is crashing on does have a long literal string in it with 
single 
quotes. Tried changing the query to use a long literal string with double 
quotes 
and that fixes it. Phew.


[2012-03-31 18:24:38] yohg...@php.net

Cannot reproduce. Could you download source and test against it?
It seems your system's pcrelib problem.


[2012-03-31 11:18:42] robin at byte dot nl

Looked a bit deeper/cleaner:

The preg_replace failes when the string between single quotes is equal or 
longer than 3399 bytes including quotes... 3487 already did seem like an odd 
number ;)

cleaner would be if you take $string = "'...3397chars...'";
then it fails with segfault, 

$string = "'...less than 3397 chars...'";  works fine.


[2012-03-31 10:53:49] robin at byte dot nl

Description:

When i use this preg_replace with a long string (3487+ bytes) and single quotes 
it ends up with a segfault...

$str = preg_replace("/'('|{2}|[^'])*'/", '', $string);

with a string longer than 3487 bytes containing multiple quotes.

results in:

php[26779]: segfault at bf737da8 ip b73e4d43 sp bf737c30 error 6 in 
libpcre.so.3.12.1[b73d4000+28000]


Test script:
---



Expected result:

Remove everything between single quotes.

Actual result:
--
Segmentation fault

[25236001.27] php[29917]: segfault at bf37ddc8 ip b744cd43 sp bf37dc50 
error 6 in libpcre.so.3.12.1[b743c000+28000]







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

Bug #61579 [Com]: Segfault preg_replace "/'(\\\\'|\\\\{2}|[^'])*'/" with a long string

2012-10-08 Thread serge dot rivest at gmail dot com

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

 ID: 61579
 Comment by: serge dot rivest at gmail dot com
 Reported by:robin at byte dot nl
 Summary:Segfault  preg_replace "/'('|{2}|[^'])*'/"
 with a long string
 Status: Feedback
 Type:   Bug
 Package:PCRE related
 Operating System:   Debian 2.6.
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

It does appear to be failing on this line:

foreach ($db->fetchAll($sql) as $a)

Very very likely it's just running out of memory. Although every time it 
crashes 
we also get this in /var/log/syslog:

Oct  8 20:01:39 dev kernel: [726784.383723] php5-fpm[8644]: segfault at 
7fff6b8a2f00 ip 7f6607c80a7a sp 7fff6b8a2e90 error 6 in 
libpcre.so.3.12.1[7f6607c6e000+3c000]

Which is bizarre. Might just be a regexp in the DB driver which is being run 
when 
the process runs out of memory... Hrm, time to try Serges idea of using xdebug. 
And we see:

0.8160   12868128   -> PDO->quote() 
/www/studyladder.dev222/zendframework/Zend/Db/Adapter/Pdo/Abstract.php:296
0.8160   12868344   -> substr() 
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:198
0.8160   12868456   -> str_replace() 
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:199
0.8160   12868472   -> preg_replace() 
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:204

So, probably not running out of memory. This is the code it's crashing on:

// get a version of the SQL statement with all quoted   
  
// values and delimited identifiers stripped out
  
// remove "foo\"bar"
  
$sql = preg_replace("/$q($qe|{2}|[^$q])*$q/", '', $sql);

Don't really know what it is doing, but the regexp looks like this:

/'(\\'|\\{2}|[^'])*'/

And the query it is crashing on does have a long literal string in it with 
single 
quotes. Tried changing the query to use a long literal string with double 
quotes 
and that fixes it. Phew.


Previous Comments:

[2012-03-31 18:24:38] yohg...@php.net

Cannot reproduce. Could you download source and test against it?
It seems your system's pcrelib problem.


[2012-03-31 11:18:42] robin at byte dot nl

Looked a bit deeper/cleaner:

The preg_replace failes when the string between single quotes is equal or 
longer than 3399 bytes including quotes... 3487 already did seem like an odd 
number ;)

cleaner would be if you take $string = "'...3397chars...'";
then it fails with segfault, 

$string = "'...less than 3397 chars...'";  works fine.


[2012-03-31 10:53:49] robin at byte dot nl

Description:

When i use this preg_replace with a long string (3487+ bytes) and single quotes 
it ends up with a segfault...

$str = preg_replace("/'('|{2}|[^'])*'/", '', $string);

with a string longer than 3487 bytes containing multiple quotes.

results in:

php[26779]: segfault at bf737da8 ip b73e4d43 sp bf737c30 error 6 in 
libpcre.so.3.12.1[b73d4000+28000]


Test script:
---



Expected result:

Remove everything between single quotes.

Actual result:
--
Segmentation fault

[25236001.27] php[29917]: segfault at bf37ddc8 ip b744cd43 sp bf37dc50 
error 6 in libpcre.so.3.12.1[b743c000+28000]







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

Bug #63231 [Opn]: force-cgi-redirect does not works under FastCGI

2012-10-08 Thread phodur at zoznam dot sk

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

 ID: 63231
 User updated by:phodur at zoznam dot sk
 Reported by:phodur at zoznam dot sk
 Summary:force-cgi-redirect does not works under FastCGI
 Status: Open
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   FreeBSD (all UNIX like OS)
 PHP Version:5.3.17
 Block user comment: N
 Private report: N

 New Comment:

Just a quick followup to the original post.

I have discovered, that force cgi redirect mechanism does not works because 
another 
bug in mod_fastcgi.

Mod_fastcgi by defaul do not pass any env variables from PHP process when 
executing 
PHP (not only PHP). It clears ENV simillary to suexec wrapper. There is flag 
you can 
pass to FastCGIConfig directive, but it do not works as expected. By inspecting 
the 
source of mod_fastcgi, I can state, that when you pass ENV to FastCGI process 
using 
this directive, mod_fastcgi uses it's value as it is in the stage the Apache 
process 
was started (not when the request is actually executed).

Grrr


Previous Comments:

[2012-10-07 00:14:29] phodur at zoznam dot sk

Description:

This is same as #37157. But may be I will better describe the problem. Because 
Dmitry closed #37157 as NOT A BUG.

Ok, test environment is Apache 2.2.X with PHP 5.3.X. Base Apache config is:

--- CUT ---

Alias /php-bin//www/php-bin/php5



   Options ExecCGI
   SetHandler fastcgi-script



AddHandler  php5-script .php
Action  php5-script /php-bin/php5

--- CUT ---

FastCGI (mod_fastcgi) related config is (this is not important for reproducing 
this bug, it is provided only FYI):

--- CUT ---

FastCgiIpcDir   /var/run/apache22/fastcgi/
FastCgiWrapper  On
FastCgiConfig   -idle-timeout 30 -killInterval 300 
-maxClassProcesses 1 -maxProcesses 100 -minProcesses 0 -pass-header 
HTTP_AUTHORIZATION -restart-delay 2 -singleThreshold 100

--- CUT ---

PHP was compiled only with CGI SAPI support and is run with following wrapper 
(it's /www/php-bin/php5 file mentioned earlier):

--- CUT ---

#!/bin/sh

PHP_CGI=/usr/local/bin/php-cgi
PHP_FCGI_CHILDREN=4
PHP_FCGI_MAX_REQUESTS=500

export PHP_FCGI_CHILDREN
export PHP_FCGI_MAX_REQUESTS

exec $PHP_CGI

--- CUT ---

Ok, last but not least the PHP's FastCGI config:

--- CUT ---

;doc_root
;user_dir
cgi.force_redirect = 1
cgi.fix_pathinfo = 0

--- CUT ---


Ok, so when you hit:

http://[domain]/index.php

it works, the Apache translates this request according to Action directive to

http://[domain]/php-bin/php5/index.php

and you will see the results.

When you hit http://[domain]/php-bin/php5/index.php directly, it will also 
works (FastCGI PHP SAPI incorrectly does not check the REDIRECT_STATUS 
environmental variable for value of 200).

When you change PHP cgi.fix_pathinfo to 1 (so the environmental variables 
conforms to FastCGI/CGI specs), the last request incorrectly determine the 
/www/php-bin/php5 as the PHP script and executes it. This is because one of the 
main jobs of FastCGI/CGI SAPI is to determine WHAT to execute. When 
fix_pathinfo is set to 1, it uses also REDIRECT_URL env variable, which is not 
set when you access directly interpreter with passed script as PATH_INFO 
(http://[domain]/php-bin/php5/index.php).

The only workaround at this time is use mod_rewrite and disable access to the 
interpreter:

RewriteEngine on
RewriteCond %{ENV:REDIRECT_STATUS} !200
RewriteRule ^/php-bin/php5 - [F]


Conclusion, this is NOT actually mod_fastcgi and/or configuration issue, this 
is really bug in FastCGI/CGI SAPI of PHP (in opossite what Dmitry says in 
#37157)





Test script:
---
See above

Expected result:

See above

Actual result:
--
See above






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

[PHP-BUG] Bug #63236 [NEW]: Executable permission on various source files

2012-10-08 Thread r...@php.net

From: remi
Operating system: GNU/Linux
PHP version:  5.4Git-2012-10-08 (Git)
Package:  *General Issues
Bug Type: Bug
Bug description:Executable permission on various source files

Description:

Not a big issue, but easy to fix one.

This raises some warnings (rpmlint) for packaging on the "debuginfo"
package.

Test script:
---
find . -name \*.[ch] -executable 

Expected result:

empty result

Actual result:
--
./Zend/zend_iterators.c
./Zend/zend_build.h
./Zend/zend_interfaces.h
./Zend/zend_interfaces.c
./Zend/zend_iterators.h
./ext/sqlite/libsqlite/src/config_static.w32.h
./ext/pcntl/pcntl.c
./ext/interbase/php_ibase_includes.h
./ext/com_dotnet/com_persist.c
./ext/enchant/enchant.c
./ext/pdo_oci/php_pdo_oci_int.h
./ext/pdo_oci/php_pdo_oci.h
./ext/pdo_oci/oci_statement.c
./ext/pdo_oci/oci_driver.c
./ext/pdo_oci/pdo_oci.c
./ext/mbstring/libmbfl/filters/mbfilter_iso8859_16.h
./ext/mbstring/libmbfl/filters/mbfilter_iso8859_16.c
./ext/mbstring/libmbfl/mbfl/mbfl_defs.h
./ext/mbstring/oniguruma/enc/utf32_le.c
./ext/mbstring/oniguruma/enc/utf32_be.c
./ext/mbstring/oniguruma/enc/utf16_be.c
./ext/mbstring/oniguruma/enc/utf16_le.c
./ext/mbstring/oniguruma/regext.c
./ext/pdo_mysql/pdo_mysql.c
./ext/pdo_mysql/mysql_statement.c
./ext/pdo_mysql/mysql_driver.c
./ext/pdo_mysql/php_pdo_mysql.h
./ext/pdo_mysql/php_pdo_mysql_int.h
./ext/pdo/php_pdo.h
./ext/pdo/php_pdo_int.h
./ext/pdo/pdo_stmt.c
./ext/pdo/pdo.c
./ext/pdo/php_pdo_driver.h
./ext/pdo/pdo_dbh.c
./ext/spl/spl_exceptions.c
./ext/spl/spl_functions.h
./ext/spl/spl_exceptions.h
./ext/spl/spl_functions.c
./ext/spl/spl_array.h
./ext/spl/spl_observer.c
./ext/spl/spl_directory.h
./ext/spl/spl_directory.c
./ext/spl/spl_array.c
./ext/spl/php_spl.c
./ext/spl/spl_engine.h
./ext/spl/spl_iterators.c
./ext/spl/php_spl.h
./ext/spl/spl_iterators.h
./ext/spl/spl_observer.h
./ext/spl/spl_engine.c
./ext/simplexml/sxe.h
./ext/simplexml/php_simplexml_exports.h
./ext/simplexml/sxe.c
./ext/dba/php_db1.h
./ext/dba/dba_db1.c
./ext/dba/dba_qdbm.c
./ext/pdo_odbc/odbc_stmt.c
./ext/pdo_odbc/php_pdo_odbc_int.h
./ext/pdo_odbc/pdo_odbc.c
./ext/pdo_odbc/odbc_driver.c
./ext/standard/winver.h
./main/streams/glob_wrapper.c
./main/streams/php_stream_glob_wrapper.h
./main/streams/streams.c
./main/php_streams.h
./win32/globals.c
./win32/php_win32_globals.h


-- 
Edit bug report at https://bugs.php.net/bug.php?id=63236&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=63236&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=63236&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=63236&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=63236&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=63236&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63236&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=63236&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=63236&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63236&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=63236&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63236&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63236&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=63236&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63236&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=63236&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=63236&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63236&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63236&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63236&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=63236&r=mysqlcfg

Bug #63235 [PATCH]: buffer overflow in use of SQLGetDiagRec

2012-10-08 Thread r...@php.net

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

 ID: 63235
 Patch added by: r...@php.net
 Reported by:r...@php.net
 Summary:buffer overflow in use of SQLGetDiagRec
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   GNU/Linux
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: php-5.3.3-pdo-overflow.patch
Revision:   1349681821
URL:
https://bugs.php.net/patch-display.php?bug=63235&patch=php-5.3.3-pdo-overflow.patch&revision=1349681821


Previous Comments:

[2012-10-08 07:36:51] r...@php.net

Description:

Already report on internals http://marc.info/?t=13426268866&r=1&w=2

Discard state is 5 char long, so buffer must be 6.

Trivial fix attached.
(could apply in all branches)








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

[PHP-BUG] Bug #63235 [NEW]: buffer overflow in use of SQLGetDiagRec

2012-10-08 Thread r...@php.net

From: remi
Operating system: GNU/Linux
PHP version:  5.4.7
Package:  PDO related
Bug Type: Bug
Bug description:buffer overflow in use of SQLGetDiagRec

Description:

Already report on internals http://marc.info/?t=13426268866&r=1&w=2

Discard state is 5 char long, so buffer must be 6.

Trivial fix attached.
(could apply in all branches)



-- 
Edit bug report at https://bugs.php.net/bug.php?id=63235&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=63235&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=63235&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=63235&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=63235&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=63235&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63235&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=63235&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=63235&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63235&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=63235&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63235&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63235&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=63235&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63235&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=63235&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=63235&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63235&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63235&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63235&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=63235&r=mysqlcfg

Bug #63219 [Asn]: Segfault when aliasing trait method when autoloader throws excpetion

2012-10-08 Thread dmitry

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

 ID: 63219
 Updated by: dmi...@php.net
 Reported by:maciej dot sz at gmail dot com
 Summary:Segfault when aliasing trait method when autoloader
 throws excpetion
 Status: Assigned
 Type:   Bug
 Package:Reproducible crash
 Operating System:   3.2.0-31-generic #50-Ubuntu
 PHP Version:5.4Git-2012-10-04 (snap)
-Assigned To:dmitry
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

I think you patch is OK. Please commit it.


Previous Comments:

[2012-10-05 01:57:57] larue...@php.net

I think there is no need to call autoload in USE block, and it should check the 
fetch result, I have attached a patch, 

but I am not sure what the warning message should be...


[2012-10-05 01:56:09] larue...@php.net

The following patch has been added/updated:

Patch Name: bug63219.patch
Revision:   1349402169
URL:
https://bugs.php.net/patch-display.php?bug=63219&patch=bug63219.patch&revision=1349402169


[2012-10-04 18:43:59] maciej dot sz at gmail dot com

Description:

Class contains "use" statement of a trait. Method alias statement for that 
trait contains a typo in the trait name. The autoloader throws exception and 
then the segfault occurs.

(gdb) p zend_fetch_class(cur_method_ref->class_name, cur_method_ref->cname_len, 
14)
$5 = (zend_class_entry *) 0x0

Test script:
---
---
file TFoo.php

inconsistent==HT_OK) {



(gdb) bt
#0  0x009863c8 in _zend_is_inconsistent (ht=0x28, 
file=0xfb0948 "/home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c", line=969)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c:54
#1  0x009890f5 in zend_hash_exists (ht=0x28, arKey=0x77fc5aa0 
"foomethodd", nKeyLength=11)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c:969
#2  0x00952839 in zend_traits_init_trait_structures (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compile.c:4037
#3  0x00953a4a in zend_do_bind_traits (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compile.c:4370
#4  0x009b79ee in ZEND_BIND_TRAITS_SPEC_HANDLER 
(execute_data=0x77f88500)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:1027
#5  0x009b42f6 in execute (op_array=0x77fc0da8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:410
#6  0x009639b8 in zend_call_function (fci=0x7fffa1a0, 
fci_cache=0x7fffa1f0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:958
#7  0x009956b5 in zend_call_method (object_pp=0x0, obj_ce=0x0, 
fn_proxy=0x77fc41e0, 
function_name=0x77fc17f8 "closure::__invoke\001", function_name_len=22, 
retval_ptr_ptr=0x7fffa2e0, param_count=1, arg1=0x77fbf5d0, arg2=0x0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_interfaces.c:97
#8  0x007a087c in zif_spl_autoload_call (ht=1, 
return_value=0x77fc40d8, 
return_value_ptr=0x7fffa728, this_ptr=0x0, return_value_used=1)
at /home/maciek/Downloads/php-5.4.7/ext/spl/php_spl.c:436
#9  0x00963b92 in zend_call_function (fci=0x7fffa670, 
fci_cache=0x7fffa6c0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:980
#10 0x00964520 in zend_lookup_class_ex (name=0x77eb72f8 "bar\\C", 
name_length=5, 
key=0x77fc24d8, use_autoload=1, ce=0x7fffa7c0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:1127
#11 0x00965230 in zend_fetch_class_by_name (class_name=0x77eb72f8 
"bar\\C", 
class_name_len=5, key=0x77fc24d8, fetch_type=4)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:1607
#12 0x009b8690 in ZEND_FETCH_CLASS_SPEC_CONST_HANDLER 
(execute_data=0x77f880e8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:1173
#13 0x009b42f6 in execute (op_array=0x77fc04c8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:410
#14 0x00976e13 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3)
at /home/maciek/Downloads/php-5.4.7/Zend/zend.c:1286
#15 0x008e9732 in php_execute_script (primary_file=0x7fffce40)
at /home/maciek/Downloads/php-5.4.7/main/main.c:2473
#16 0x00abfa95 in do_cli (argc=2, argv=0x7fffe228)
at /home/maciek/Downloads/php-5.4.7/sapi/cli/php_cli.c:988
#17 0x00ac0bce in main (argc=2, argv=0x7fffe228)
at /home/maciek/Downloads/php-5.4.7/sapi/cli/php_cli.c:1364



(gdb) f 2
#2  0x00952839 in zend_traits_init_trait_structures (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compil

Bug #63236 [Opn->Csd]: Executable permission on various source files

Bug #63235 [Opn->Csd]: buffer overflow in use of SQLGetDiagRec

Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css

Bug #63235 [Opn]: buffer overflow in use of SQLGetDiagRec

Bug #63240 [Opn]: stream_get_line return contains delimiter string

Bug #63235 [Opn]: buffer overflow in use of SQLGetDiagRec

[PHP-BUG] Bug #63244 [NEW]: PDO fetch is inconsistent with MySQL's bit column

Bug #63235 [Opn]: buffer overflow in use of SQLGetDiagRec

Req #63242 [Com]: Default error page in PHP built-in web server uses outdated html/css

[PHP-BUG] Req #63242 [NEW]: Default error page in PHP built-in web server uses outdated html/css

Req #62968 [Opn->Nab]: Unable to Run PHP with IIS 7.X

[PHP-BUG] Bug #63241 [NEW]: PHP fails to open Windows deduplicated files

[PHP-BUG] Bug #63240 [NEW]: stream_get_line return contains delimiter string

Bug #63235 [Opn]: buffer overflow in use of SQLGetDiagRec

Bug #63219 [Asn->Csd]: Segfault when aliasing trait method when autoloader throws excpetion

Bug #61579 [Com]: Segfault preg_replace "/'(\\\\'|\\\\{2}|[^'])*'/" with a long string

Bug #63108 [Csd->Nab]: ZipArchive uncompress bug

Bug #61579 [Com]: Segfault preg_replace "/'(\\\\'|\\\\{2}|[^'])*'/" with a long string

Bug #61579 [Com]: Segfault preg_replace "/'(\\\\'|\\\\{2}|[^'])*'/" with a long string

Bug #63231 [Opn]: force-cgi-redirect does not works under FastCGI

[PHP-BUG] Bug #63236 [NEW]: Executable permission on various source files

Bug #63235 [PATCH]: buffer overflow in use of SQLGetDiagRec

[PHP-BUG] Bug #63235 [NEW]: buffer overflow in use of SQLGetDiagRec

Bug #63219 [Asn]: Segfault when aliasing trait method when autoloader throws excpetion

24 matches

Site Navigation

Mail list logo

Footer information