from:"d...@php.net"

Bug #65796 [Com]: mkdir creates folders with wrong permissions

2013-10-01 Thread d...@php.net

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

 ID: 65796
 Comment by:     d...@php.net
 Reported by:cmfcmf dot flach at gmail dot com
 Summary:mkdir creates folders with wrong permissions
 Status: Open
 Type:   Bug
 Package:Directory function related
 Operating System:   Linux/Ubuntu 13.4
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I get the same on PHP 5.5.3. chmod('test', 0777) then transforms the directory 
to 
the right chmod.


Previous Comments:

[2013-10-01 09:44:10] cmfcmf dot flach at gmail dot com

Description:

Creating a directory using mkdir() does not respect the permissions given.

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

[PHP-BUG] Bug #64457 [NEW]: HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing

2013-03-19 Thread d...@php.net

From: dm
Operating system: All
PHP version:  Irrelevant
Package:  Apache2 related
Bug Type: Bug
Bug description:HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing

Description:

`HTTP_HOST` is the value from `Host` header, which can, naturally, be
spoofed.
On the other hand, `SERVER_NAME` and `SERVER_PORT` should reflect real
values.
I've tested some configurations and on majority you can at least
change/spoof `SERVER_PORT`.
This can lead to security issues since these environment variables are
often trusted.

Test script:
---
http://smchiptuning.com/http_host.php');
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Host: 127.0.0.1:1337'));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
echo curl_exec($ch);
curl_close($ch);

/**
http_host.php

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

Bug #64457 [Com]: HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing

2013-03-19 Thread d...@php.net

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

 ID: 64457
 Comment by:     d...@php.net
 Reported by:    d...@php.net
 Summary:HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing
 Status: Analyzed
 Type:   Bug
 Package:Apache2 related
 Operating System:   All
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Indeed, it's not a PHP issue per se, and I'm glad, thank you.

I'm aware that $_SERVER['HTTP_*'] are passed on, but what about 
$_SERVER['SERVER_*'] (or you meant everything web server related)?
Why would Apache not know what is the hostname and which port is it serving 
through?

Nginx and some variations of Apache (haven't tried sending HTTP 1.0 request) 
settings don't have this "problem".
RFC 2616 states that 1.1 requests specifying a hostname not in use by the 
server should receive a 400 Bad Request response, which is sometimes (I don't 
know when exactly) is not the case.

Thanks.


Previous Comments:

[2013-03-19 19:16:48] ras...@php.net

But how is this a PHP issue? PHP doesn't set the $_SERVER['HTTP_*"] variables 
at 
all. They are inherited directly from the web server and are the same variables 
that the web server would set for CGI scripts that might get executed. So while 
we could try to do some analysis and filtering at the PHP level, anything else 
the web server invokes would still be getting the spoofed port. The fix should 
be 
at the web server level.

----
[2013-03-19 19:03:42] d...@php.net

Description:

`HTTP_HOST` is the value from `Host` header, which can, naturally, be spoofed.
On the other hand, `SERVER_NAME` and `SERVER_PORT` should reflect real values.
I've tested some configurations and on majority you can at least change/spoof 
`SERVER_PORT`.
This can lead to security issues since these environment variables are often 
trusted.

Test script:
---
http://smchiptuning.com/http_host.php');
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Host: 127.0.0.1:1337'));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
echo curl_exec($ch);
curl_close($ch);

/**
http_host.php

https://bugs.php.net/bug.php?id=64457&edit=1

Bug #64457 [Com]: HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing

2013-03-22 Thread d...@php.net

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

 ID: 64457
 Comment by:     d...@php.net
 Reported by:    d...@php.net
 Summary:HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing
 Status: Analyzed
 Type:   Bug
 Package:Apache2 related
 Operating System:   All
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

With the help of thumbs from #httpd, I was directed to:
http://httpd.apache.org/docs/current/mod/core.html#usecanonicalphysicalport

It was pointed out:
http://httpd.apache.org/docs/2.4/mod/core.html#comment_1000

So, PHP is kept in the dark if these directives are Off.

On our side, docs should be updated to advise that values are not be trusted if 
aforementioned directives are Off.


Previous Comments:

[2013-03-19 20:58:07] ras...@php.net

I have no idea why it is filling in the wrong SERVER_PORT, but it is. This 
doesn't come from PHP and it isn't PHP's job to second-guess what the web 
server 
is telling us here. Try to reproduce it with a straight CGI script without any 
PHP involvement.


[2013-03-19 19:38:43] d...@php.net

Indeed, it's not a PHP issue per se, and I'm glad, thank you.

I'm aware that $_SERVER['HTTP_*'] are passed on, but what about 
$_SERVER['SERVER_*'] (or you meant everything web server related)?
Why would Apache not know what is the hostname and which port is it serving 
through?

Nginx and some variations of Apache (haven't tried sending HTTP 1.0 request) 
settings don't have this "problem".
RFC 2616 states that 1.1 requests specifying a hostname not in use by the 
server should receive a 400 Bad Request response, which is sometimes (I don't 
know when exactly) is not the case.

Thanks.


[2013-03-19 19:16:48] ras...@php.net

But how is this a PHP issue? PHP doesn't set the $_SERVER['HTTP_*"] variables 
at 
all. They are inherited directly from the web server and are the same variables 
that the web server would set for CGI scripts that might get executed. So while 
we could try to do some analysis and filtering at the PHP level, anything else 
the web server invokes would still be getting the spoofed port. The fix should 
be 
at the web server level.

--------
[2013-03-19 19:03:42] d...@php.net

Description:

`HTTP_HOST` is the value from `Host` header, which can, naturally, be spoofed.
On the other hand, `SERVER_NAME` and `SERVER_PORT` should reflect real values.
I've tested some configurations and on majority you can at least change/spoof 
`SERVER_PORT`.
This can lead to security issues since these environment variables are often 
trusted.

Test script:
---
http://smchiptuning.com/http_host.php');
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Host: 127.0.0.1:1337'));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
echo curl_exec($ch);
curl_close($ch);

/**
http_host.php

https://bugs.php.net/bug.php?id=64457&edit=1

[PHP-BUG] Bug #64523 [NEW]: php.ini error_reporting XOR

2013-03-26 Thread d...@php.net

From: dm
Operating system: 
PHP version:  5.4.13
Package:  PHP options/info functions
Bug Type: Bug
Bug description:php.ini error_reporting XOR

Description:

Setting php.ini error_reporting value to:
error_reporting = E_ALL ^ E_NOTICE ^ E_WARNING ^ E_STRICT ^ E_DEPRECATED

> php -i | grep error_reporting
> error_reporting => 32767 ^ 8 ^ 2 ^ 2048 ^ 8192

It is not the same as:
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_WARNING &
~E_DEPRECATED

> php -i | grep error_reporting
> error_reporting => 22517

Although, eval'd integer output is the same: http://3v4l.org/VuDBW#v540
(22517)

This works correctly when error reporting is set via script.

Default php.ini
https://github.com/php/php-src/blob/master/php.ini-development#L50 says XOR
is supported, but in fact, it's not behaving like that.


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

Bug #64523 [Com]: php.ini error_reporting XOR

2013-03-26 Thread d...@php.net

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

 ID: 64523
 Comment by:     d...@php.net
 Reported by:    d...@php.net
 Summary:php.ini error_reporting XOR
 Status: Open
 Type:   Bug
 Package:PHP options/info functions
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

Commit 
(https://github.com/php/php-src/commit/e0669bf1ab0892132bf6fe6f81587bfba45e7329#L0R50)
 when bitwise XOR added to php.ini.


Previous Comments:

[2013-03-26 19:17:29] d...@php.net

Description:

Setting php.ini error_reporting value to:
error_reporting = E_ALL ^ E_NOTICE ^ E_WARNING ^ E_STRICT ^ E_DEPRECATED

> php -i | grep error_reporting
> error_reporting => 32767 ^ 8 ^ 2 ^ 2048 ^ 8192

It is not the same as:
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_WARNING & ~E_DEPRECATED

> php -i | grep error_reporting
> error_reporting => 22517

Although, eval'd integer output is the same: http://3v4l.org/VuDBW#v540 (22517)

This works correctly when error reporting is set via script.

Default php.ini 
https://github.com/php/php-src/blob/master/php.ini-development#L50 says XOR is 
supported, but in fact, it's not behaving like that.







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

Bug #64523 [PATCH]: php.ini error_reporting XOR

2013-03-26 Thread d...@php.net

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

 ID: 64523
 Patch added by:     d...@php.net
 Reported by:    d...@php.net
 Summary:php.ini error_reporting XOR
 Status: Open
 Type:   Bug
 Package:PHP options/info functions
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: fix_zend_ini_do_op_xor
Revision:   1364338616
URL:
https://bugs.php.net/patch-display.php?bug=64523&patch=fix_zend_ini_do_op_xor&revision=1364338616


Previous Comments:

[2013-03-26 20:01:40] d...@php.net

XOR not parsed (thanks @ircmaxell)
http://lxr.php.net/xref/PHP_5_4/Zend/zend_ini_parser.y#63


[2013-03-26 19:27:53] d...@php.net

Commit 
(https://github.com/php/php-src/commit/e0669bf1ab0892132bf6fe6f81587bfba45e7329#L0R50)
 when bitwise XOR added to php.ini.


[2013-03-26 19:17:29] d...@php.net

Description:

Setting php.ini error_reporting value to:
error_reporting = E_ALL ^ E_NOTICE ^ E_WARNING ^ E_STRICT ^ E_DEPRECATED

> php -i | grep error_reporting
> error_reporting => 32767 ^ 8 ^ 2 ^ 2048 ^ 8192

It is not the same as:
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_WARNING & ~E_DEPRECATED

> php -i | grep error_reporting
> error_reporting => 22517

Although, eval'd integer output is the same: http://3v4l.org/VuDBW#v540 (22517)

This works correctly when error reporting is set via script.

Default php.ini 
https://github.com/php/php-src/blob/master/php.ini-development#L50 says XOR is 
supported, but in fact, it's not behaving like that.







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

Bug #62015 [Com]: Session auto-start issues

2013-08-10 Thread d...@php.net

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

 ID: 62015
 Comment by:     d...@php.net
 Reported by:    d...@php.net
 Summary:Session auto-start issues
 Status: Closed
 Type:   Bug
 Package:Session related
 PHP Version:5.3.13
 Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

Sorry if I made a mistake looking at the commit, but it looks like this was 
only 
applied to the 5.4 tree. As it's a bug fix, it should also be applied to 5.3


Previous Comments:

[2013-08-10 09:30:52] yohg...@php.net

Automatic comment on behalf of yohgaki
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e9b128c1bfb64e50c5e361959a1a7ccd176d1324
Log: Fixed Bug #62015 Changed session.auto_start to PHP_INI_PERDIR. It is 
simply wrong and never worked if the value is changed at runtime


[2013-08-10 09:30:46] yohg...@php.net

Automatic comment on behalf of yohgaki
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e9b128c1bfb64e50c5e361959a1a7ccd176d1324
Log: Fixed Bug #62015 Changed session.auto_start to PHP_INI_PERDIR. It is 
simply wrong and never worked if the value is changed at runtime


[2013-08-10 09:30:44] yohg...@php.net

Automatic comment on behalf of yohgaki
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e9b128c1bfb64e50c5e361959a1a7ccd176d1324
Log: Fixed Bug #62015 Changed session.auto_start to PHP_INI_PERDIR. It is 
simply wrong and never worked if the value is changed at runtime


[2012-05-15 06:04:30] yohg...@php.net

I think this is reasonable change, since it would not work as PHP_INI_ALL.


[2012-05-13 18:10:31] d...@php.net

Description:

session.auto_start can currently be set in PHP_INI_ALL - however this is 
illogical and confusing.

When session.auto_start = 1, a session is started when PHP initialises 
according 
to the session.save_handler and session.save_path settings PHP starts up with. 
This makes it impossible to configure custom save handlers since PHP will have 
already started the session before userland code is executed.

Furthermore, this ini value can be modified at runtime, in PHP_INI_USER context 
which makes no sense, since if it was 1 at start-time, sessions will have 
already 
started; and if the it was 0 at start-time, sessions will only be started when 
session_start() is explicitly called - the setting is pointless at runtime. 
Thus 
the context in which session.auto_start can be set should change to at least 
PHP_INI_PERDIR.







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

[PHP-BUG] Bug #62015 [NEW]: Session auto-start issues

2012-05-13 Thread d...@php.net

From: drak
Operating system: 
PHP version:  5.3.13
Package:  Session related
Bug Type: Bug
Bug description:Session auto-start issues

Description:

session.auto_start can currently be set in PHP_INI_ALL - however this is 
illogical and confusing.

When session.auto_start = 1, a session is started when PHP initialises
according 
to the session.save_handler and session.save_path settings PHP starts up
with. 
This makes it impossible to configure custom save handlers since PHP will
have 
already started the session before userland code is executed.

Furthermore, this ini value can be modified at runtime, in PHP_INI_USER
context 
which makes no sense, since if it was 1 at start-time, sessions will have
already 
started; and if the it was 0 at start-time, sessions will only be started
when 
session_start() is explicitly called - the setting is pointless at runtime.
Thus 
the context in which session.auto_start can be set should change to at
least 
PHP_INI_PERDIR.


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

#48665 [NEW]: class_alias allows impossible classes

2009-06-23 Thread d...@php.net

From: d...@php.net
Operating system: Mac OS X Server 10.5.6
PHP version:  5.3.0RC4
PHP Bug Type: Class/Object related
Bug description:  class_alias allows impossible classes

Description:

The original class is checked, but the checks a too lax on the alias 
itself. 

I suggest the alias's name should follow the same rules as the class 
itself.

Admittedly, the following may work in conjunction with the problem 
reported : 



Reproduce code:
---



Expected result:

bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)


Actual result:
--
bool(true)
bool(true)
bool(true)
PHP Warning:  Cannot redeclare class  in /Users/alterway/bin/php-
5.3.0RC4/Zend/tests/- on line 8

Warning: Cannot redeclare class  in /Users/alterway/bin/php-
5.3.0RC4/Zend/tests/- on line 8
bool(false)
PHP Warning:  Cannot redeclare class  in /Users/alterway/bin/php-
5.3.0RC4/Zend/tests/- on line 9

Warning: Cannot redeclare class  in /Users/alterway/bin/php-
5.3.0RC4/Zend/tests/- on line 9
bool(false)
bool(true)
bool(true)
bool(true)
bool(true)


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

#47249 [NEW]: ext/idn and ext/intl incompatible

2009-01-30 Thread d...@php.net

From: d...@php.net
Operating system: OSX 10.5
PHP version:  5.3.0beta1
PHP Bug Type: Compile Failure
Bug description:  ext/idn and ext/intl incompatible

Description:

When compiling PHP 5.3.0 beta1 with both libidn and intl, I get this 
error message : 

ld: duplicate symbol _zif_idn_to_ascii in ext/intl/idn/idn.o and 
ext/idn/idn.o
collect2: ld returned 1 exit status

PHP 5.3.0.beta1 compile nicely when only one of them is enabled. 

Reproduce code:
---
./configure --enable-intl --with-idn
make


Expected result:

Compilation successful.

Actual result:
--
ld: duplicate symbol _zif_idn_to_ascii in ext/intl/idn/idn.o and 
ext/idn/idn.o
collect2: ld returned 1 exit status




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

#47663 [NEW]: dncgettext crashs if count parameter is negative

2009-03-15 Thread d...@php.net

From: d...@php.net
Operating system: OpenSolaris 2009.11
PHP version:  5.2.9
PHP Bug Type: Gettext related
Bug description:  dncgettext crashs if count parameter is negative

Description:

Passing -1 to the count argument of dcngettext leads to a PHP core dump 
on OpenSolaris.






Reproduce code:
---
make test TESTS=ext/gettext/tests

will crash when testing dcngettext.phpt

Expected result:

no crash

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0xfedaaa76 in _real_gettext_u () from /lib/libc.so.1
(gdb) bt
#0  0xfedaaa76 in _real_gettext_u () from /lib/libc.so.1
#1  0xfeda8d7a in dcngettext () from /lib/libc.so.1
#2  0x080f8692 in zif_dcngettext (ht=5, return_value=0x83d4b0c, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /export/home/dsp/dev/c/php52/ext/gettext/gettext.c:356
#3  0x08275389 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x8047320) at zend_vm_execute.h:200
#4  0x08274b39 in execute (op_array=0x83d5090) at zend_vm_execute.h:92
#5  0x0825b469 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /export/home/dsp/dev/c/php52/Zend/zend.c:1134
#6  0x08223079 in php_execute_script (primary_file=0x8047a94) at 
/export/home/dsp/dev/c/php52/main/main.c:2023
#7  0x082d7a09 in main (argc=2, argv=0x8047b18) at 
/export/home/dsp/dev/c/php52/sapi/cli/php_cli.c:1133





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

[PHP-BUG] Bug #51870 [NEW]: PDO::fetchAll after a PDO::execute with bindings lead to a segv.

2010-05-20 Thread d...@php.net

From: 
Operating system: Mac OS X
PHP version:  6SVN-2010-05-20 (SVN)
Package:  PDO related
Bug Type: Bug
Bug description:PDO::fetchAll after a PDO::execute with bindings lead to a segv.

Description:

#0  0x7fff83c74886 in __kill ()

#1  0x7fff83d14eae in abort ()

#2  0x7fff83c2ca75 in free ()

#3  0x0001001b8328 in pdo_mysql_stmt_fetch (stmt=0x100d3ef18, 

ori=PDO_FETCH_ORI_NEXT, offset=0) at 

/Users/dsp/dev/c/php/trunk/ext/pdo_mysql/mysql_statement.c:655

#4  0x0001001ac47a in do_fetch_common (stmt=0x100d3ef18, 

ori=PDO_FETCH_ORI_NEXT, offset=0, do_bind=1) at 

/Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:694

#5  0x0001001adaa1 in do_fetch (stmt=0x100d3ef18, do_bind=1, 

return_value=0x100d4eff8, how=PDO_FETCH_BOTH, ori=PDO_FETCH_ORI_NEXT,
offset=0, 

return_all=0x0) at /Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:861

#6  0x0001001b0388 in zim_PDOStatement_fetchAll (ht=0, 

return_value=0x100d3f888, return_value_ptr=0x0, this_ptr=0x100d3a120, 

return_value_used=0) at 

/Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:1560

#7  0x000100465e48 in execute_internal (execute_data_ptr=0x101b2a080, 

return_value_used=0) at
/Users/dsp/dev/c/php/trunk/Zend/zend_execute.c:1468

#8  0x0001004176d7 in dtrace_execute_internal
(execute_data_ptr=0x101b2a080, 

return_value_used=0) at /Users/dsp/dev/c/php/trunk/Zend/zend_dtrace.c:99

#9  0x000100467b04 in zend_do_fcall_common_helper_SPEC 

(execute_data=0x101b2a080) at zend_vm_execute.h:359

#10 0x000100468eeb in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 

(execute_data=0x101b2a080) at zend_vm_execute.h:467

#11 0x0001004663af in execute (op_array=0x100d3c030) at 

zend_vm_execute.h:129

#12 0x0001004175e2 in dtrace_execute (op_array=0x100d3c030) at 

/Users/dsp/dev/c/php/trunk/Zend/zend_dtrace.c:75

#13 0x00010042fb2d in zend_execute_scripts (type=8, retval=0x0, 

file_count=3) at /Users/dsp/dev/c/php/trunk/Zend/zend.c:1210

#14 0x0001003a31fd in php_execute_script (primary_file=0x7fff5fbfe9f0)
at 

/Users/dsp/dev/c/php/trunk/main/main.c:2324

#15 0x00010056caf4 in main (argc=2, argv=0x7fff5fbfeb98) at 

/Users/dsp/dev/c/php/trunk/sapi/cli/php_cli.c:1200

Test script:
---
prepare('SELECT * FROM user WHERE host = ?');

$stm->execute(array('localhost'));

$stm->fetchAll();

Actual result:
--
php(63324) malloc: *** error for object 0x101c849a8: pointer being freed
was not 

allocated

*** set a breakpoint in malloc_error_break to debug

[1]63324 abort  php test.php

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

Bug #60218 [PATCH]: dir() is missing

2011-11-12 Thread d...@php.net

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

 ID: 60218
 Patch added by:     d...@php.net
 Reported by:yohgaki at ohgaki dot net
 Summary:dir() is missing
 Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux x86_64
 PHP Version:5.4SVN-2011-11-04 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: 60218-try-catch-efree-op-array
Revision:   1321115944
URL:
https://bugs.php.net/patch-display.php?bug=60218&patch=60218-try-catch-efree-op-array&revision=1321115944


Previous Comments:

[2011-11-12 16:38:41] d...@php.net

I added a patch that fixes it for me


[2011-11-05 00:32:16] yohgaki at ohgaki dot net

> 1. The documentation examples don't use 'new'.  This works:
> php -r '$o = dir(".");'

It should always raise error for it, I suppose. 
Strange thing is 'It works' sometimes.

If leak and other problem(works for sometimes) are specific to dir(), I think 
dropping dir() is an option.


[2011-11-04 18:08:58] s...@php.net

1. The documentation examples don't use 'new'.  This works:
  php -r '$o = dir(".");'
2. SPL might have better alternatives, e.g.:
  http://www.php.net/manual/en/class.recursivedirectoryiterator.php
3. I'll leave the bug open to track the memleak


[2011-11-04 14:10:53] yohgaki at ohgaki dot net

dir is ancient class in PHP, so it may be the first one. It may be related. 
Just 
my guess.


[2011-11-04 14:06:43] yohgaki at ohgaki dot net

s/I support dir()/I suppose dir()/




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


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

Bug #60218 [PATCH]: dir() is missing

2011-11-12 Thread d...@php.net

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

 ID: 60218
 Patch added by:     d...@php.net
 Reported by:yohgaki at ohgaki dot net
 Summary:dir() is missing
 Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux x86_64
 PHP Version:5.4SVN-2011-11-04 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: ensure-efree-of-oparray
Revision:   1321116048
URL:
https://bugs.php.net/patch-display.php?bug=60218&patch=ensure-efree-of-oparray&revision=1321116048


Previous Comments:

[2011-11-12 16:39:04] d...@php.net

The following patch has been added/updated:

Patch Name: 60218-try-catch-efree-op-array
Revision:   1321115944
URL:
https://bugs.php.net/patch-display.php?bug=60218&patch=60218-try-catch-efree-op-array&revision=1321115944


[2011-11-12 16:38:41] d...@php.net

I added a patch that fixes it for me


[2011-11-05 00:32:16] yohgaki at ohgaki dot net

> 1. The documentation examples don't use 'new'.  This works:
> php -r '$o = dir(".");'

It should always raise error for it, I suppose. 
Strange thing is 'It works' sometimes.

If leak and other problem(works for sometimes) are specific to dir(), I think 
dropping dir() is an option.


[2011-11-04 18:08:58] s...@php.net

1. The documentation examples don't use 'new'.  This works:
  php -r '$o = dir(".");'
2. SPL might have better alternatives, e.g.:
  http://www.php.net/manual/en/class.recursivedirectoryiterator.php
3. I'll leave the bug open to track the memleak


[2011-11-04 14:10:53] yohgaki at ohgaki dot net

dir is ancient class in PHP, so it may be the first one. It may be related. 
Just 
my guess.




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


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

[PHP-BUG] Bug #63686 [NEW]: Build with --enable-dtrace fails

2012-12-04 Thread d...@php.net

From: d...@php.net
Operating system: Solaris
PHP version:  5.5Git-2012-12-04 (Git)
Package:  *General Issues
Bug Type: Bug
Bug description:Build with --enable-dtrace fails

Description:

building with --enable-dtrace results in 

Zend/zend.c:686:20: error: âdtrace_execute_exâ undeclared (first use in
this 
function)

which was introduced in

commit 70f83f35d089d0cafae12ae231a38541f5c8e41c
Author: Dmitry Stogov 
Date:   Fri Nov 30 13:39:23 2012 +0400


Test script:
---
./buildconf
./configure --enable-dtrace
make

Expected result:

build complete

Actual result:
--
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function 
âdtrace_get_executed_filenameâ:
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:30:3: warning: return discards

âconstâ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:32:3: warning: return discards

âconstâ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function
âdtrace_executeâ:
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:3: warning: passing
argument 1 
of âget_active_class_nameâ from incompatible pointer type [enabled by
default]
In file included from /home/dsp/dev/php/src/5.5/Zend/zend_API.h:30:0,
 from /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:22:
/home/dsp/dev/php/src/5.5/Zend/zend_execute.h:348:53: note: expected
âconst char 
**â but argument is of type âchar **â
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:13: warning: assignment
discards 
âconstâ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:63:12: warning: assignment
discards 
âconstâ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend.c: In function âzend_startupâ:
/home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: error:
âdtrace_execute_exâ 
undeclared (first use in this function)
/home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: note: each undeclared
identifier 
is reported only once for each function it appears in
make: *** [Zend/zend.lo] Error 1
make: *** Waiting for unfinished jobs


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

[PHP-BUG] Bug #63695 [NEW]: PHP doesn't build with shared extensions and dtrace enabled

2012-12-05 Thread d...@php.net

From: d...@php.net
Operating system: Solaris 11
PHP version:  5.5.0alpha1
Package:  *General Issues
Bug Type: Bug
Bug description:PHP doesn't build with shared extensions and dtrace enabled

Description:

PHP doesn't build if an extension is to build shared and --enable-dtrace is

enabled.

Test script:
---
./configure --enable-calendar=shared --enable-dtrace

Expected result:

build complete

Actual result:
--
__dtrace_php___request__shutdownmain/.libs/main.o
__dtrace_php___exception__caughtZend/.libs/zend_execute.o
__dtrace_php___execute__return  Zend/.libs/zend_dtrace.o
__dtrace_php___request__startup main/.libs/main.o
__dtraceenabled_php___exception__caught Zend/.libs/zend_execute.o
__dtrace_php___compile__file__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___function__entry Zend/.libs/zend_dtrace.o
$dtrace15765465.ZEND_CATCH_SPEC_CONST_CV_HANDLER Zend/zend_dtrace.d.o
__dtrace_php___execute__entry   Zend/.libs/zend_dtrace.o
__dtraceenabled_php___error Zend/.libs/zend.o
__dtraceenabled_php___function__return Zend/.libs/zend_dtrace.o
/fastcgi.lo -lresolv -lrt -lm -lnsl -lsocket -lgcc  -o sapi/cgi/php-cgi
UndefinedUndefined  first referenced
 symbol in  firstfile
 __dtraceenabled_php___execute__entryreferenced Zend/.libs
/zend_dtrace.o
 symbol__dtraceenabled_php___execute__return  Zend/ .libs/ 
zend_dtrace.o
__dtrace_php___compile__file__return Zend/ .libs/
zend_dtrace.o
 __dtrace_php___exception__thrown Zendin/.libs/ zend_exceptions.o
file__dtrace_php___error
 __dtraceenabled_php___execute__entry  Zend/.libs/zend_dtrace.o
__dtraceenabled_php___execute__return Zend/.libs/zend_dtrace.o
__dtrace_php___compile__file__return Zend/.libs/zend_dtrace.o
__dtrace_php___exception__thrownZend/.libs/zend_exceptions.o
__dtrace_php___errorZend/.libs/zend.o

__dtraceenabled_php___exception__thrown Zend/.libs/zend_exceptions.o
ld: fatal: symbol referencing errors. No output written to sapi/cli/php
   collect2: ld returned 1 exit status
   Zend/.libs/zend.o
__dtrace_php___function__entry  Zend/.libs/zend_dtrace.o
__dtrace_php___function__return Zend/.libs/zend_dtrace.o
__dtrace_php___request__shutdownmain/.libs/main.o
__dtrace_php___exception__caughtZend/.libs/zend_execute.o
__dtrace_php___execute__return  Zend/.libs/zend_dtrace.o
__dtrace_php___request__startup main/.libs/main.o
__dtraceenabled_php___exception__caught Zend/.libs/zend_execute.o
__dtrace_php___compile__file__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___function__entry Zend/.libs/zend_dtrace.o
$dtrace15765465.ZEND_CATCH_SPEC_CONST_CV_HANDLER Zend/zend_dtrace.d.o
__dtrace_php___execute__entry   Zend/.libs/zend_dtrace.o
__dtraceenabled_php___error Zend/.libs/zend.o
__dtraceenabled_php___function__return Zend/.libs/zend_dtrace.o
__dtraceenabled_php___exception__thrown Zend/.libs/zend_exceptions.o
ld: fatal: symbol referencing errors. No output written to
sapi/cgi/php-cgi
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
make: *** Waiting for unfinished jobs
make: *** [sapi/cgi/php-cgi] Error 1


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

Bug #62692 [Com]: PHP fails to build with dtrace

2012-12-06 Thread d...@php.net

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

 ID: 62692
 Comment by:     d...@php.net
 Reported by:eugene at zhegan dot in
 Summary:PHP fails to build with dtrace
 Status: Assigned
 Type:   Bug
 Package:*General Issues
 Operating System:   Solaris 10 x86
 PHP Version:5.4.5
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

Did you build any module as shared?


Previous Comments:

[2012-12-06 21:41:17] d...@php.net

This bug is about the dtrace probes in core not the PECL package.


[2012-09-14 15:46:48] eugene at zhegan dot in

Okay. Here are a bit more detailed instruction about how to actually and 
successfully build php with dtrace on Solaris. On Solaris Solaris, not on a 
dead body of Opensolaris or on shiny and rare Openindiana.

- Run configure with --enable-dtrace.

- You will probably need to use bundled gd, not system or installed from 
source, so use --with-gd, whithout a directory.

- It should work fine (actually, there are plenty of ways for it to fail 
depending on the various options, but let's assume you know how to build php on 
Solaris from sources and you're trying to build it with dtrace for now).

- Now you need to patch the Makefile the configure just created for you. Why ? 
Because Solaris sed doesn't have an -i switch. You can patch the Makefile as 
described here: https://bugs.php.net/bug.php?id=62691 or you can just install 
the GNU sed and make it appear in the PATH before the system sed.

- Now you can actually start building php, but read first this: 
https://bugs.php.net/bug.php?id=61268 . I'll make it easier: due to the fact 
that building will crash (see below) twice (see below :) ) you will need to 
prevent the zend_dtrace.d probe file from clobbering, due to the nature of 
gmake and some issues in the Makefile. :) This is done by using the '-r' 
switch, which prevents the make builtin rules from firing.

- Use gmake, it will make your life even more easier.

- Thus, you can run 'gmake -r' now and wait for it to crash.

- It will crash somewhere around making pfp-fpm (if you ordered this sapi) and 
the crash lines won't be similar the initial error in this report. The crash 
lines from the start of this report are caused by some clobbering and not using 
'gmake -r'. You should see a crash like this:

Undefined   first referenced
 symbol in file
__dtraceenabled_php___execute__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___execute__return Zend/.libs/zend_dtrace.o
__dtrace_php___compile__file__return Zend/.libs/zend_dtrace.o
__dtrace_php___exception__thrownZend/.libs/zend_exceptions.o
__dtrace_php___errorZend/.libs/zend.o
__dtrace_php___function__entry  Zend/.libs/zend_dtrace.o
__dtrace_php___function__return Zend/.libs/zend_dtrace.o
__dtrace_php___request__shutdownmain/.libs/main.o
__dtrace_php___exception__caughtZend/.libs/zend_execute.o
__dtrace_php___execute__return  Zend/.libs/zend_dtrace.o
__dtrace_php___request__startup main/.libs/main.o
__dtraceenabled_php___exception__caught Zend/.libs/zend_execute.o
__dtrace_php___compile__file__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___function__entry Zend/.libs/zend_dtrace.o
__dtrace_php___execute__entry   Zend/.libs/zend_dtrace.o
__dtraceenabled_php___error Zend/.libs/zend.o
__dtraceenabled_php___function__return Zend/.libs/zend_dtrace.o
$dtrace18058.ZEND_CATCH_SPEC_CONST_CV_HANDLER Zend/zend_dtrace.d.o
__dtraceenabled_php___exception__thrown Zend/.libs/zend_exceptions.o
ld: fatal: Symbol referencing errors. No output written to sapi/cli/php
collect2: ld returned 1 exit status
gmake: *** [sapi/cli/php] Error 1

- lets discuss what is it and how to fix it. Somewhere over 9000 lines above 
the building process made this: 

dtrace -G -o Zend/zend_dtrace.d.o -s /home/emz/src/php-5.4.5/Zend/zend_dtrace.d 
main/main.o Zend/zend_API.o Zend/zend_execute.o Zend/zend_exceptions.o 
Zend/zend_dtrace.o Zend/zend.o

What is this ? This is the creation of the ELF binary with dtrace probes AND 
updating of the source object files. This is important. But these source object 
files at this point are already copied in the .libs directory, which linker is 
using at the final stage and where it does crash. They should be updated after 
running dtrace -G but they are not. In order to fix the building you should do 
it by hand:

- copy the files:

Zend/zend_API.o
Zend/zend_execute.o
Zend/zend_exceptions.o
Zend/zend_dtrace.o
Zend/zend.o

to the Zend/.libs

- copy the file

main/main.o

to the main/.libs. They should differ by the way fromthe targets you have in 
.libs.

- issue a 'gmake -r

Bug #63963 [Com]: Session save does not always happen.

2013-01-21 Thread d...@php.net

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

 ID: 63963
 Comment by:     d...@php.net
 Reported by:jkm9000+php at gmail dot com
 Summary:Session save does not always happen.
 Status: Assigned
 Type:   Bug
 Package:Session related
 Operating System:   OSX/Linux
 PHP Version:5.4.10
 Assigned To:arpad
 Block user comment: N
 Private report: N

 New Comment:

It's been reported that calling session_write_close() before the  
fastcgi_finish_request(); call fixes it. Seems like a PHP bug. Reference: 
https://github.com/symfony/symfony/issues/6417#issuecomment-12513993


Previous Comments:

[2013-01-11 00:01:02] jkm9000+php at gmail dot com

Sorry, originally tried with 5.4.4 and apache.


[2013-01-10 23:56:17] jkm9000+php at gmail dot com

Description:

There is an issue open in the Symfony codebase that seems to actually be a 
problem 
with PHP. 

https://github.com/symfony/symfony/issues/6417#issuecomment-11878369

I was encouraged to open a ticket here and let Arpad know, but I don't see a 
way 
to do that here.

Basically when anything other than the default filesystem sessions are used I 
have 
a reproducible way where session data is lost. When I use the filesytem 
sessions 
with the same code, it works.

Originally I tried with 5.4.10 via apache / mod_php. The problem persists with 
5.4.10 under nginx/php-fpm.

Test script:
---
There is some code mention here - 
https://github.com/symfony/symfony/issues/6417#issuecomment-11878369

as well as where I opened my ticket originally - 
https://github.com/FriendsOfSymfony/FOSUserBundle/issues/921

Expected result:

The expected result would be the session data is present.

Actual result:
--
Session data is lost.






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

Bug #65796 [Com]: mkdir creates folders with wrong permissions

[PHP-BUG] Bug #64457 [NEW]: HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing

Bug #64457 [Com]: HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing

Bug #64457 [Com]: HTTP_HOST, SERVER_NAME, SERVER_PORT spoofing

[PHP-BUG] Bug #64523 [NEW]: php.ini error_reporting XOR

Bug #64523 [Com]: php.ini error_reporting XOR

Bug #64523 [PATCH]: php.ini error_reporting XOR

Bug #62015 [Com]: Session auto-start issues

[PHP-BUG] Bug #62015 [NEW]: Session auto-start issues

#48665 [NEW]: class_alias allows impossible classes

#47249 [NEW]: ext/idn and ext/intl incompatible

#47663 [NEW]: dncgettext crashs if count parameter is negative

[PHP-BUG] Bug #51870 [NEW]: PDO::fetchAll after a PDO::execute with bindings lead to a segv.

Bug #60218 [PATCH]: dir() is missing

Bug #60218 [PATCH]: dir() is missing

[PHP-BUG] Bug #63686 [NEW]: Build with --enable-dtrace fails

[PHP-BUG] Bug #63695 [NEW]: PHP doesn't build with shared extensions and dtrace enabled

Bug #62692 [Com]: PHP fails to build with dtrace

Bug #63963 [Com]: Session save does not always happen.

19 matches

Site Navigation

Mail list logo

Footer information