Bug #51723 [Asn]: Content-length header is limited to 32bit integer
Edit report at http://bugs.php.net/bug.php?id=51723&edit=1
ID: 51723
User updated by: anatoli at adt dot ee
Reported by: anatoli at adt dot ee
Summary: Content-length header is limited to 32bit integer
Status: Assigned
Type: Bug
Package: Apache2 related
Operating System: vista 32
PHP Version: 5.2.13
Assigned To: pajoye
New Comment:
Ok, now i got the point. Yes i really missed that long in windows is
always 32bit by default and as i remember in 64bit windows it is also
limited to 32bit. There must be used long long type, but i am not sure
that this is possible.
But anyway thanks.
Previous Comments:
[2010-05-03 02:33:51] paj...@php.net
"Do i must provide here code that allow downloads for files till 8Gb
with multiple threads and resume support, witch is working under unix
cgi, and not under win32 sapi?"
No, thanks.
Does it work with apache on unix as well? If yes, is it a 64bit or 32bit
machine?
The problem could be still the 32bit limitation as the apache2 SAPI
replaces the headers with the correct length using strtol, which
converts a string to a long. A long is always 32bit on Windows.
I will check that code, needs some tweak on Windows (no luck I think on
unix 32bit).
[2010-05-03 01:50:11] anatoli at adt dot ee
The problem is not in the filesize. Headers was checked with the latest
wireshark. Under the cgi i receive correct header. Under sapi not. Do i
must provide here code that allow downloads for files till 8Gb with
multiple threads and resume support, witch is working under unix cgi,
and not under win32 sapi? I redused test case to exactly minimum amount
of code needed to reproduce error.
[2010-05-03 01:41:29] paj...@php.net
The header is correctly sent without modification (you can verify that
using cgi in the console). However PHP does not support large file
support and only 2^31 bytes are read and sent.
There is already a feature request for LFS > mark this one as duplicated
(bogus).
[2010-05-03 00:58:57] anatoli at adt dot ee
Description:
Content-length header is limited to 32bit integer on wista 32 systems
under apache 2 sapi.
header("Content-Length: 2967901695");
Expected on client - Content-Length: 2967901695
Actual - Content-Length: 2147483647
Test script:
---
Expected result:
Content-Length: 2967901695
Actual result:
--
Content-Length: 2147483647
--
Edit this bug report at http://bugs.php.net/bug.php?id=51723&edit=1
Bug #49490 [Opn->Asn]: XPath namespace prefix conflict
Edit report at http://bugs.php.net/bug.php?id=49490&edit=1
ID: 49490
Updated by: johan...@php.net
Reported by: olav dot morken at uninett dot no
Summary: XPath namespace prefix conflict
-Status: Open
+Status: Assigned
Type: Bug
Package: DOM XML related
Operating System: Linux (Debian)
PHP Version: 5.3.0
-Assigned To:
+Assigned To: rrichards
Previous Comments:
[2010-04-17 11:14:50] thomas at weinert dot info
It looks like DOMXPath->evaluate()/DOMXPath->query() registers the
namespace prefixes of the given context and overrides any definition
from DOMXPath->registerNamespace(). PHP should not register any
namespaces from the context or at least prefer manual registrations over
automatic.
Reproduce code:
---
$dom = new DOMDocument();
$dom->loadXML(
''.
''.
''
);
$xpath = new DOMXPath($dom);
//get context node and check "a:foo"
$context = $dom->documentElement->firstChild;
var_dump($context->tagName);
// try to override the context node
$xpath->registerNamespace('a', 'urn:b');
var_dump(
$xpath->evaluate(
'descendant-or-self::a:*',
$context
)->item(0)->tagName
);
// use a prefix not used in context
$xpath->registerNamespace('prefix', 'urn:b');
var_dump(
$xpath->evaluate(
'descendant-or-self::prefix:*',
$context
)->item(0)->tagName
);
Expected result:
string(5) "a:foo"
string(5) "b:bar"
string(5) "b:bar"
Actual result:
string(5) "a:foo"
string(5) "a:foo"
string(5) "b:bar"
[2009-09-07 08:41:26] olav dot morken at uninett dot no
Description:
When processing an XML document with namespaces, an XPath query for a
node with a different namespace but the same namespace prefix fails.
This appears to be a conflict between the XPath namespaces and the
document namespaces. It works if either:
- The prefix in the query is replaced with a prefix that doesn't
exist in the document.
- If the prefix in the query matches the prefix in the document.
This was tested with:
- PHP 5.3 from debian experimental: 5.3.0-3
- libxml2 2.7.3.dfsg-2.1
Reproduce code:
---
$doc = new DOMDocument();
$doc->loadXML('');
$xp = new DOMXPath($doc);
$xp->registerNamespace('prefix', 'urn:b');
echo($xp->query('//prefix:root')->length . "\n");
Expected result:
It should not find the root node, since we ask for a node in a different
prefix. I.e. it should print '0'.
Actual result:
--
It finds the root node, i.e. it prints '1'.
--
Edit this bug report at http://bugs.php.net/bug.php?id=49490&edit=1
Bug #51723 [Asn]: Content-length header is limited to 32bit integer
Edit report at http://bugs.php.net/bug.php?id=51723&edit=1
ID: 51723
User updated by: anatoli at adt dot ee
Reported by: anatoli at adt dot ee
Summary: Content-length header is limited to 32bit integer
Status: Assigned
Type: Bug
Package: Apache2 related
Operating System: vista 32
PHP Version: 5.2.13
Assigned To: pajoye
New Comment:
Was not able to find 32bit unix/linux system.
Tested on 64bit both cgi and apache sapi - working, content-type header
data is correct.
Previous Comments:
[2010-05-03 10:31:39] anatoli at adt dot ee
Ok, now i got the point. Yes i really missed that long in windows is
always 32bit by default and as i remember in 64bit windows it is also
limited to 32bit. There must be used long long type, but i am not sure
that this is possible.
But anyway thanks.
[2010-05-03 02:33:51] paj...@php.net
"Do i must provide here code that allow downloads for files till 8Gb
with multiple threads and resume support, witch is working under unix
cgi, and not under win32 sapi?"
No, thanks.
Does it work with apache on unix as well? If yes, is it a 64bit or 32bit
machine?
The problem could be still the 32bit limitation as the apache2 SAPI
replaces the headers with the correct length using strtol, which
converts a string to a long. A long is always 32bit on Windows.
I will check that code, needs some tweak on Windows (no luck I think on
unix 32bit).
[2010-05-03 01:50:11] anatoli at adt dot ee
The problem is not in the filesize. Headers was checked with the latest
wireshark. Under the cgi i receive correct header. Under sapi not. Do i
must provide here code that allow downloads for files till 8Gb with
multiple threads and resume support, witch is working under unix cgi,
and not under win32 sapi? I redused test case to exactly minimum amount
of code needed to reproduce error.
[2010-05-03 01:41:29] paj...@php.net
The header is correctly sent without modification (you can verify that
using cgi in the console). However PHP does not support large file
support and only 2^31 bytes are read and sent.
There is already a feature request for LFS > mark this one as duplicated
(bogus).
[2010-05-03 00:58:57] anatoli at adt dot ee
Description:
Content-length header is limited to 32bit integer on wista 32 systems
under apache 2 sapi.
header("Content-Length: 2967901695");
Expected on client - Content-Length: 2967901695
Actual - Content-Length: 2147483647
Test script:
---
Expected result:
Content-Length: 2967901695
Actual result:
--
Content-Length: 2147483647
--
Edit this bug report at http://bugs.php.net/bug.php?id=51723&edit=1
Bug #51723 [Asn]: Content-length header is limited to 32bit integer
Edit report at http://bugs.php.net/bug.php?id=51723&edit=1 ID: 51723 Updated by: paj...@php.net Reported by: anatoli at adt dot ee Summary: Content-length header is limited to 32bit integer Status: Assigned Type: Bug Package: Apache2 related Operating System: vista 32 PHP Version: 5.2.13 Assigned To: pajoye New Comment: Windows 64bit is not always limited to 32bit if the correct type are used (__int64 & co). About unix, that's the same reason. Long is 64bit on 64bit linux while being 32bit on 32bit linux. As I will fix this problem on windows, it won't ever work on 32bit linux, but that's not really an issue as it never worked on these old systems. Previous Comments: [2010-05-03 10:40:54] anatoli at adt dot ee Was not able to find 32bit unix/linux system. Tested on 64bit both cgi and apache sapi - working, content-type header data is correct. [2010-05-03 10:31:39] anatoli at adt dot ee Ok, now i got the point. Yes i really missed that long in windows is always 32bit by default and as i remember in 64bit windows it is also limited to 32bit. There must be used long long type, but i am not sure that this is possible. But anyway thanks. [2010-05-03 02:33:51] paj...@php.net "Do i must provide here code that allow downloads for files till 8Gb with multiple threads and resume support, witch is working under unix cgi, and not under win32 sapi?" No, thanks. Does it work with apache on unix as well? If yes, is it a 64bit or 32bit machine? The problem could be still the 32bit limitation as the apache2 SAPI replaces the headers with the correct length using strtol, which converts a string to a long. A long is always 32bit on Windows. I will check that code, needs some tweak on Windows (no luck I think on unix 32bit). [2010-05-03 01:50:11] anatoli at adt dot ee The problem is not in the filesize. Headers was checked with the latest wireshark. Under the cgi i receive correct header. Under sapi not. Do i must provide here code that allow downloads for files till 8Gb with multiple threads and resume support, witch is working under unix cgi, and not under win32 sapi? I redused test case to exactly minimum amount of code needed to reproduce error. [2010-05-03 01:41:29] paj...@php.net The header is correctly sent without modification (you can verify that using cgi in the console). However PHP does not support large file support and only 2^31 bytes are read and sent. There is already a feature request for LFS > mark this one as duplicated (bogus). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51723 -- Edit this bug report at http://bugs.php.net/bug.php?id=51723&edit=1
[PHP-BUG] Bug #51726 [NEW]: Segmentation fault: 11 (core dumped)
From: Operating system: FreeBSD 7.2 and 8.0 PHP version: 5.3.2 Package: InterBase related Bug Type: Bug Bug description:Segmentation fault: 11 (core dumped) Description: The bug appears everywhere using interbase extension, also running make test in the build directory, producing a core dump php.core. The valgrind output is: ==94843== Jump to the invalid address stated on the next line ==94843==at 0x1243810: ??? ==94843==by 0x375079: exit (in /lib/libc.so.7) ==94843==by 0x81FE1FE: main (in /usr/local/bin/php) ==94843== Address 0x1243810 is not stack'd, malloc'd or (recently) free'd Further more, running make test, the test #7 FAILS. Firebird installed from ports is: firebird-client-2.0.3_3 Firebird-2 database client firebird-server-2.0.3_3 Firebird-2 relational database (server) # php -v PHP 5.3.2 with Suhosin-Patch (cli) (built: May 3 2010 11:02:58) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies Test script: --- Every script involving interbase. i.e. -- Edit bug report at http://bugs.php.net/bug.php?id=51726&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51726&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51726&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51726&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51726&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51726&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51726&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51726&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51726&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51726&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51726&r=support Expected behavior: http://bugs.php.net/fix.php?id=51726&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51726&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51726&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51726&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51726&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51726&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51726&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51726&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51726&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51726&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51726&r=mysqlcfg
Req #20656 [Opn->Bgs]: Feature Request: mysql_fetch_object as user defined class
Edit report at http://bugs.php.net/bug.php?id=20656&edit=1 ID: 20656 Updated by: johan...@php.net Reported by: publicNO at SPAM dot itsminimal dot com Summary: Feature Request: mysql_fetch_object as user defined class -Status: Open +Status: Bogus Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: * PHP Version: 5* Assigned To: helly New Comment: The mysql extension won't get new features. Use mysqli or PDO or such. Previous Comments: [2004-01-11 19:39:19] he...@php.net pgsql, SQLite, mysqli and pdo support the following function in PHP5: object mysqli_fetch_object (object result [, string class_name [, NULL|array ctor_params]]) I will adatpt this to mysql for completeness. Anyway there will be no new functionality in PHP4.3.x [2004-01-10 12:11:55] php at thekid dot de Sybase-CT supports this: http://php.net/manual/en/function.sybase-fetch-object.php Porting this to MySQL should be no problem. [2002-11-26 13:02:31] publicNO at SPAM dot itsminimal dot com I think it would be very useful to be able to specify the class of the object returned by mysql_fetch_object. So perhaps the syntax would be mysql_fetch_object ( resource result, classname ) and the object returned would have all the properties and methods of the user defined class, in addition to having properties that correspond to the fetched row -- Edit this bug report at http://bugs.php.net/bug.php?id=20656&edit=1
Bug #51725 [Opn]: xmlrpc_get_type() returns true on invalid dates
Edit report at http://bugs.php.net/bug.php?id=51725&edit=1 ID: 51725 Updated by: fel...@php.net Reported by: geiss...@php.net Summary: xmlrpc_get_type() returns true on invalid dates Status: Open Type: Bug Package: XMLRPC-EPI related Operating System: linux/kfreebsd ia64/x86_64 PHP Version: 5.3.2 New Comment: I cannot reproduce it on Linux using: libexpat1-dev --- 2.0.1-4+lenny3 libxml2-dev--- 2.7.3.dfsg-2.1 Previous Comments: [2010-05-03 05:40:35] geiss...@php.net Description: ext/xmlrpc/tests/bug42189.phpt fails consistently on 64 bits architectures such as ia64 and x86_64. I modified the test a bit to show what's going on. From a quick look at the code it appears to be a bug in the XMLRPC-EPI lib and not in the module itself. Test script: --- Expected result: bool(false) Done Actual result: -- bool(true) ~~ Done -- Edit this bug report at http://bugs.php.net/bug.php?id=51725&edit=1
Bug #51725 [Opn]: xmlrpc_get_type() returns true on invalid dates
Edit report at http://bugs.php.net/bug.php?id=51725&edit=1 ID: 51725 Updated by: fel...@php.net Reported by: geiss...@php.net Summary: xmlrpc_get_type() returns true on invalid dates Status: Open Type: Bug Package: XMLRPC-EPI related Operating System: linux/kfreebsd ia64/x86_64 PHP Version: 5.3.2 New Comment: (I tested on 32bit though) Previous Comments: [2010-05-03 14:20:36] fel...@php.net I cannot reproduce it on Linux using: libexpat1-dev --- 2.0.1-4+lenny3 libxml2-dev--- 2.7.3.dfsg-2.1 [2010-05-03 05:40:35] geiss...@php.net Description: ext/xmlrpc/tests/bug42189.phpt fails consistently on 64 bits architectures such as ia64 and x86_64. I modified the test a bit to show what's going on. From a quick look at the code it appears to be a bug in the XMLRPC-EPI lib and not in the module itself. Test script: --- Expected result: bool(false) Done Actual result: -- bool(true) ~~ Done -- Edit this bug report at http://bugs.php.net/bug.php?id=51725&edit=1
Bug #51724 [Opn->Fbk]: int PDO::exec ( string $statement )
Edit report at http://bugs.php.net/bug.php?id=51724&edit=1 ID: 51724 Updated by: pierr...@php.net Reported by: jerck at rocware dot com Summary: int PDO::exec ( string $statement ) -Status: Open +Status: Feedback Type: Bug Package: PDO related Operating System: Mac OS X 10.5.8 PHP Version: 5.2SVN-2010-05-03 (SVN) New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. It seems to work properly. Could you try to execute the following statement before executing your script to make sure that the row you're trying to modify will really be affected by your query. UPDATE `Business` SET `Business`.`Phone` = '' WHERE `Business`.`BusinessID` = 1 Previous Comments: [2010-05-03 03:26:32] jerck at rocware dot com Description: Explained succinctly in "test script" text area below... exec($sql); // Singleton PDO DB handle echo($count); // prints 0 of type integer /** * $count should evaluate to the integer 1, not to 0. * Thoughts? **/ ?> Test script: --- exec($sql); // Singleton PDO DB handle echo($count); // prints 0 of type integer /** * $count should evaluate to the integer 1, not to 0. * Thoughts? **/ ?> Expected result: echo($count); // Should print the integer 1 Actual result: -- echo($count); // Currently prints the integer 0 even though the database is successfully updating 1 record -- Edit this bug report at http://bugs.php.net/bug.php?id=51724&edit=1
Bug #51725 [Opn->Ver]: xmlrpc_get_type() returns true on invalid dates
Edit report at http://bugs.php.net/bug.php?id=51725&edit=1 ID: 51725 Updated by: il...@php.net Reported by: geiss...@php.net Summary: xmlrpc_get_type() returns true on invalid dates -Status: Open +Status: Verified Type: Bug Package: XMLRPC-EPI related Operating System: linux/kfreebsd ia64/x86_64 PHP Version: 5.3.2 New Comment: IT happens on 64bit systems only. The reason has to do with date extension, which is used to validate the date string (on 64 bit machines this results in a very small negative #), not -1 and thus passed validation. Previous Comments: [2010-05-03 14:23:18] fel...@php.net (I tested on 32bit though) [2010-05-03 14:20:36] fel...@php.net I cannot reproduce it on Linux using: libexpat1-dev --- 2.0.1-4+lenny3 libxml2-dev--- 2.7.3.dfsg-2.1 [2010-05-03 05:40:35] geiss...@php.net Description: ext/xmlrpc/tests/bug42189.phpt fails consistently on 64 bits architectures such as ia64 and x86_64. I modified the test a bit to show what's going on. From a quick look at the code it appears to be a bug in the XMLRPC-EPI lib and not in the module itself. Test script: --- Expected result: bool(false) Done Actual result: -- bool(true) ~~ Done -- Edit this bug report at http://bugs.php.net/bug.php?id=51725&edit=1
Bug #51708 [Opn->Bgs]: imap_open() improperly trimming spaces from username
Edit report at http://bugs.php.net/bug.php?id=51708&edit=1 ID: 51708 Updated by: il...@php.net Reported by: slusarz at curecanti dot org Summary: imap_open() improperly trimming spaces from username -Status: Open +Status: Bogus Type: Bug Package: IMAP related Operating System: Linux PHP Version: 5.3.2 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. The trimming (if it happens) is done by c-client lib, not PHP. Previous Comments: [2010-04-30 21:05:59] slusarz at curecanti dot org Description: Per RFC 3501 [9], spaces are valid characters in a username. Thus, 'username' != ' username '. However, imap_open() appears to be stripping leading/trailing whitespace from the username. Test script: --- http://bugs.php.net/bug.php?id=51708&edit=1
Bug #51696 [Asn->Bgs]: Bug #49800 is not a bug - must be rolled back
Edit report at http://bugs.php.net/bug.php?id=51696&edit=1
ID: 51696
Updated by: il...@php.net
Reported by: david dot coleman at globant dot com
Summary: Bug #49800 is not a bug - must be rolled back
-Status: Assigned
+Status: Bogus
Type: Bug
Package: SimpleXML related
Operating System: all
PHP Version: 5.3.2
Assigned To: iliaa
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You cannot serialize SimpleXML objects.
Previous Comments:
[2010-04-29 18:28:41] david dot coleman at globant dot com
Description:
Bug #49800 SimpleXML allow serialize() calls without warning
This bug is not a bug. The "fix" that has been put in place for PHP
5.3.2 breaks memcached horribly.
please see (censored) stack trace as posted in the "actual result" box
on this form.
This functionality MUST be allowed to maintain compatibility with
existing systems.
Thank you in advance for un-"fixing" this.
David Coleman
david.cole...@globant.com
david_coleman_...@hotmail.com
{"error":{"code":500,"message":"Serialization of 'SimpleXMLElement' is
not allowed","debug":{"name":"Exception","message":"Serialization of
'SimpleXMLElement' is not allowed","traces":["at () in
\/opt\/workspace\/NDA_DOMAIN.COM\/NDA_MODULE_LOCATION\/0.99.2.1\/lib\/memcache\/NDA_PREFIX_Memcache.class.php
line n\/a","at Memcache->set() in
\/opt\/workspace\/NDA_DOMAIN.COM\/NDA_MODULE_LOCATION\/0.99.2.1\/lib\/memcache\/NDA_PREFIX_Memcache.class.php
line 0","at
NDA_PREFIX_Memcache->set('NDA_REQUEST::a9f15d6cc587244cf26106655829de64edf1ae74',
object('NDA_PREFIX_FuzzyMemcacheValueWrapper'), '1', '1') in
\/opt\/workspace\/NDA_DOMAIN.COM\/NDA_MODULE_LOCATION\/0.99.2.1\/lib\/memcache\/NDA_PREFIX_FuzzyMemcache.class.php
line 162","at
NDA_PREFIX_FuzzyMemcache->set('NDA_REQUEST::a9f15d6cc587244cf26106655829de64edf1ae74',
array(object<\/em>('NDA_OBJECT'), object<\/em>('NDA_OBJECT'),
object<\/em>('NDA_OBJECT'), object<\/em>('NDA_OBJECT'),
object<\/em>('NDA_OBJECT'), object<\/em>('NDA_OBJECT'),
object<\/em>('NDA_OBJECT'), object<\/em>('NDA_OBJECT'),
object<\/em>('NDA_OBJECT'), object<\/em>('NDA_OBJECT'),
object<\/em>('NDA_OBJECT'), object<\/em>('NDA_OBJECT'),
object<\/em>('NDA_OBJECT'), object<\/em>('NDA_OBJECT'),
object<\/em>('NDA_OBJECT')), '1', '1') in
\/opt\/workspace\/NDA_DOMAIN.COM\/NDA_MODULE_LOCATION\/0.99.2.1\/lib\/rest\/common\/NDA_REQUEST.class.php
line 878","at NDA_REQUEST->createAndCacheResponseValue(null) in
\/opt\/workspace\/NDA_DOMAIN.COM\/NDA_MODULE_LOCATION\/0.99.2.1\/lib\/rest\/common\/NDA_REQUEST.class.php
line 819","at NDA_REQUEST->call(null) in
\/opt\/workspace\/NDA_DOMAIN.COM\/NDA_MODULE_LOCATION\/0.99.2.1\/lib\/rest\/common\/NDA_REQUEST.class.php
line 706","at NDA_REQUEST->get() in
\/opt\/workspace\/NDA_DOMAIN.com\/plugins\/NDA_PREFIX_WorkoutGroupPlugin\/lib\/NDA_PREFIX_WorkoutGroupPeer.class.php
line 241","at NDA_PREFIX_WorkoutGroupPeer::getResults('693A0001',
'382129543', '127008', '1272585600') in
\/opt\/workspace\/NDA_DOMAIN.com\/plugins\/NDA_PREFIX_JournalHubPlugin\/lib\/models\/NDA_PREFIX_CalendarMonth.model.php
line 74","at NDA_PREFIX_CalendarMonth->buildDayDataArray() in
\/opt\/workspace\/NDA_DOMAIN.com\/plugins\/NDA_PREFIX_JournalHubPlugin\/lib\/models\/NDA_PREFIX_CalendarMonth.model.php
line 166","at
NDA_PREFIX_CalendarMonth->setReferenceTimestamp('1272549514') in
\/opt\/workspace\/NDA_DOMAIN.com\/plugins\/NDA_PREFIX_JournalHubPlugin\/lib\/models\/NDA_PREFIX_CalendarMonth.model.php
line 54","at NDA_PREFIX_CalendarMonth->__construct('1272549514') in
\/opt\/workspace\/NDA_DOMAIN.com\/plugins\/NDA_PREFIX_JournalHubPlugin\/lib\/helpers\/NDA_PREFIX_JournalHubMainCalendarHelper.class.php
line 50","at
NDA_PREFIX_JournalHubMainCalendarHelper::buildDomJson('1272549514') in
\/opt\/workspace\/NDA_DOMAIN.com\/plugins\/NDA_PREFIX_WorkoutGroupPlugin\/modules\/NDA_PREFIX_WorkoutGroupServices\/actions\/actions.class.php
line 109","at
NDA_PREFIX_WorkoutGroupServicesActions->getMainCalendarData('1272549514')
in
\/opt\/workspace\/NDA_DOMAIN.com\/plugins\/NDA_PREFIX_WorkoutGroupPlugin\/modules\/NDA_PREFIX_WorkoutGroupServices\/actions\/actions.class.php
line 104","at
NDA_PREFIX_WorkoutGroupServicesActions->executeWorkoutGroupResults(object('sfWebRequest'))
in SF_SYMFONY_LIB_DIR\/action\/sfActions.class.php line 53","at
sfActions->execute(object('sfWebRequest')) in
SF_SYMFONY_LIB_DIR\/filter\/sfExecutionFilter.class.php line 90","at
sfExecutionFilter->executeAction(object('NDA_PREFIX_WorkoutGroupServicesActions'))
in SF_SYMFONY_LIB_DIR\/filter\/sfExecutionFilter.class.php line 76","at
sfExecutionFilter->handleAction(object('sfFilterChain'),
object('NDA_PREFIX_Workou
Req #38913 [Asn->Fbk]: dba_open crash for db4
Edit report at http://bugs.php.net/bug.php?id=38913&edit=1 ID: 38913 Updated by: johan...@php.net Reported by: nemesis at home dot ro Summary: dba_open crash for db4 -Status: Assigned +Status: Feedback Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: Linux kernel 2.6.16 PHP Version: 5.1.6 -Assigned To: helly +Assigned To: New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2006-10-11 18:46:51] he...@php.net Currently we do not support 4.4 simply because we haven't checked that. [2006-10-04 17:18:19] nomail at nodomain dot net PHP 4.4.4 seems to be affected by this bug too. [2006-10-04 11:49:38] nemesis at home dot ro Hi, It appears that the configure does not check for the headers/libraries for libdb-4.4 and if there is libdb-4.3 also installed, it finds libdb-4.3 shared libraries first, and links with them (and uses headers for libdb-4.4). You can find more info on the debian bug report on the same problem here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388601 [2006-09-25 13:34:50] nemesis at home dot ro It appears that I spoke too soon. When compiling against libdb4.4 (4.4.20-3) fails with the mentioned error. (with both enable-dba and enable-dba=shared) [2006-09-23 17:00:41] nemesis at home dot ro Yes, it works (the linux version, the windows version does not have db4 built in (only db3)) Is there any time table for backporting this fix to the 5.1 series ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=38913 -- Edit this bug report at http://bugs.php.net/bug.php?id=38913&edit=1
Req #31342 [Opn->Bgs]: SQLite OO interface with Exceptions (patch included)
Edit report at http://bugs.php.net/bug.php?id=31342&edit=1 ID: 31342 Updated by: johan...@php.net Reported by: hugo dot pl at gmail dot com Summary: SQLite OO interface with Exceptions (patch included) -Status: Open +Status: Bogus Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: * PHP Version: 5.1.0-dev Assigned To: helly New Comment: Upstream won't do any more work on SQLite 2. For SQLite 3 we have a different extension so we won't do such changes for SQLite 2 anymore. Previous Comments: [2005-01-11 04:27:09] hugo dot pl at gmail dot com Maybe adding another paramater in the constructor to set this flag? SQLiteDatabase( file, mode, errmsg, flags ) [2005-01-10 08:46:31] he...@php.net We cannot easily do this because it would change the api compared to 5.0. So what we need to do is adding a method set_throw_exceptions(bool) or adding a flag SQLITE_THROW_EXCEPTIONS for the result type parameter. Once we have this we could easily extend all yout 'if (object)' checks to test for that flag also. But we must not extend the checks in the ctors because there we MUST throw exceptions. [2005-01-10 00:25:33] hugo dot pl at gmail dot com Sorry for the delay, I was travelling. The patch generated with "diff -u orig_file mod_file" http://sqlitefront.sourceforge.net/temp/patch.diff [2005-01-01 14:27:44] he...@php.net unified diff == diff -u [2004-12-31 01:31:59] il...@php.net Please provide a unified patch, thanks. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=31342 -- Edit this bug report at http://bugs.php.net/bug.php?id=31342&edit=1
Bug #51726 [Opn->Fbk]: Segmentation fault: 11 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=51726&edit=1 ID: 51726 Updated by: ka...@php.net Reported by: l dot iania at sintrade dot org Summary: Segmentation fault: 11 (core dumped) -Status: Open +Status: Feedback Type: Bug Package: InterBase related Operating System: FreeBSD 7.2 and 8.0 PHP Version: 5.3.2 New Comment: Could you compile PHP without Suhosin and compile with --enable-debug to export the symbols and then post a backtrace from gdb here? Previous Comments: [2010-05-03 13:20:33] l dot iania at sintrade dot org Description: The bug appears everywhere using interbase extension, also running make test in the build directory, producing a core dump php.core. The valgrind output is: ==94843== Jump to the invalid address stated on the next line ==94843==at 0x1243810: ??? ==94843==by 0x375079: exit (in /lib/libc.so.7) ==94843==by 0x81FE1FE: main (in /usr/local/bin/php) ==94843== Address 0x1243810 is not stack'd, malloc'd or (recently) free'd Further more, running make test, the test #7 FAILS. Firebird installed from ports is: firebird-client-2.0.3_3 Firebird-2 database client firebird-server-2.0.3_3 Firebird-2 relational database (server) # php -v PHP 5.3.2 with Suhosin-Patch (cli) (built: May 3 2010 11:02:58) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies Test script: --- Every script involving interbase. i.e. -- Edit this bug report at http://bugs.php.net/bug.php?id=51726&edit=1
Bug #51690 [Ver->Csd]: Phar::setStub looks for case-sensitive __HALT_COMPILER()
Edit report at http://bugs.php.net/bug.php?id=51690&edit=1
ID: 51690
Updated by: il...@php.net
Reported by: vr...@php.net
Summary: Phar::setStub looks for case-sensitive
__HALT_COMPILER()
-Status: Verified
+Status: Closed
Type: Bug
Package: PHAR related
Operating System: Any
PHP Version: 5.3.2
-Assigned To:
+Assigned To: iliaa
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-05-03 16:41:42] il...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=298908
Log: Fixed bug #51690 (Phar::setStub looks for case-sensitive
__HALT_COMPILER())
[2010-04-29 06:27:36] vr...@php.net
Description:
Functions in PHP are case-insensitive. This is valid also for
__HALT_COMPILER(). Phar::setStub however looks for case-sensitive
variant.
Test script:
---
$phar = new Phar("resource.phar");
try {
$phar->setStub("getMessage() . "\n";
}
Expected result:
Nothing
Actual result:
--
PharException: illegal stub for phar "C:/Download/resource.phar"
--
Edit this bug report at http://bugs.php.net/bug.php?id=51690&edit=1
Bug #51726 [Fbk->Opn]: Segmentation fault: 11 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=51726&edit=1 ID: 51726 User updated by: l dot iania at sintrade dot org Reported by: l dot iania at sintrade dot org Summary: Segmentation fault: 11 (core dumped) -Status: Feedback +Status: Open Type: Bug Package: InterBase related Operating System: FreeBSD 7.2 and 8.0 PHP Version: 5.3.2 New Comment: Solved. I have compiled it outside the ports without Suhosin and now it seems OK. Thank you! So I think that the FreeBSD ports tree should be updated. Previous Comments: [2010-05-03 16:04:50] ka...@php.net Could you compile PHP without Suhosin and compile with --enable-debug to export the symbols and then post a backtrace from gdb here? [2010-05-03 13:20:33] l dot iania at sintrade dot org Description: The bug appears everywhere using interbase extension, also running make test in the build directory, producing a core dump php.core. The valgrind output is: ==94843== Jump to the invalid address stated on the next line ==94843==at 0x1243810: ??? ==94843==by 0x375079: exit (in /lib/libc.so.7) ==94843==by 0x81FE1FE: main (in /usr/local/bin/php) ==94843== Address 0x1243810 is not stack'd, malloc'd or (recently) free'd Further more, running make test, the test #7 FAILS. Firebird installed from ports is: firebird-client-2.0.3_3 Firebird-2 database client firebird-server-2.0.3_3 Firebird-2 relational database (server) # php -v PHP 5.3.2 with Suhosin-Patch (cli) (built: May 3 2010 11:02:58) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies Test script: --- Every script involving interbase. i.e. -- Edit this bug report at http://bugs.php.net/bug.php?id=51726&edit=1
Bug #51726 [Opn->Bgs]: Segmentation fault: 11 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=51726&edit=1 ID: 51726 Updated by: paj...@php.net Reported by: l dot iania at sintrade dot org Summary: Segmentation fault: 11 (core dumped) -Status: Open +Status: Bogus Type: Bug Package: InterBase related Operating System: FreeBSD 7.2 and 8.0 PHP Version: 5.3.2 New Comment: Not a php bug > bogus. Previous Comments: [2010-05-03 17:06:04] l dot iania at sintrade dot org Solved. I have compiled it outside the ports without Suhosin and now it seems OK. Thank you! So I think that the FreeBSD ports tree should be updated. [2010-05-03 16:04:50] ka...@php.net Could you compile PHP without Suhosin and compile with --enable-debug to export the symbols and then post a backtrace from gdb here? [2010-05-03 13:20:33] l dot iania at sintrade dot org Description: The bug appears everywhere using interbase extension, also running make test in the build directory, producing a core dump php.core. The valgrind output is: ==94843== Jump to the invalid address stated on the next line ==94843==at 0x1243810: ??? ==94843==by 0x375079: exit (in /lib/libc.so.7) ==94843==by 0x81FE1FE: main (in /usr/local/bin/php) ==94843== Address 0x1243810 is not stack'd, malloc'd or (recently) free'd Further more, running make test, the test #7 FAILS. Firebird installed from ports is: firebird-client-2.0.3_3 Firebird-2 database client firebird-server-2.0.3_3 Firebird-2 relational database (server) # php -v PHP 5.3.2 with Suhosin-Patch (cli) (built: May 3 2010 11:02:58) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies Test script: --- Every script involving interbase. i.e. -- Edit this bug report at http://bugs.php.net/bug.php?id=51726&edit=1
Bug #51726 [Bgs]: Segmentation fault: 11 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=51726&edit=1 ID: 51726 User updated by: l dot iania at sintrade dot org Reported by: l dot iania at sintrade dot org Summary: Segmentation fault: 11 (core dumped) Status: Bogus Type: Bug Package: InterBase related Operating System: FreeBSD 7.2 and 8.0 PHP Version: 5.3.2 New Comment: Yes, it's true, but I tried to rebuild the port from the port tree excluding Suhosin-Patch and the resulting code was always wrong. So probably the fact is that the scripts for building PHP in FreeBSD ports are wrong. The bogus is not in Suhosin-Patch but elsewhere. Previous Comments: [2010-05-03 17:09:08] paj...@php.net Not a php bug > bogus. [2010-05-03 17:06:04] l dot iania at sintrade dot org Solved. I have compiled it outside the ports without Suhosin and now it seems OK. Thank you! So I think that the FreeBSD ports tree should be updated. [2010-05-03 16:04:50] ka...@php.net Could you compile PHP without Suhosin and compile with --enable-debug to export the symbols and then post a backtrace from gdb here? [2010-05-03 13:20:33] l dot iania at sintrade dot org Description: The bug appears everywhere using interbase extension, also running make test in the build directory, producing a core dump php.core. The valgrind output is: ==94843== Jump to the invalid address stated on the next line ==94843==at 0x1243810: ??? ==94843==by 0x375079: exit (in /lib/libc.so.7) ==94843==by 0x81FE1FE: main (in /usr/local/bin/php) ==94843== Address 0x1243810 is not stack'd, malloc'd or (recently) free'd Further more, running make test, the test #7 FAILS. Firebird installed from ports is: firebird-client-2.0.3_3 Firebird-2 database client firebird-server-2.0.3_3 Firebird-2 relational database (server) # php -v PHP 5.3.2 with Suhosin-Patch (cli) (built: May 3 2010 11:02:58) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies Test script: --- Every script involving interbase. i.e. -- Edit this bug report at http://bugs.php.net/bug.php?id=51726&edit=1
Bug #51723 [Asn->Csd]: Content-length header is limited to 32bit integer
Edit report at http://bugs.php.net/bug.php?id=51723&edit=1 ID: 51723 Updated by: paj...@php.net Reported by: anatoli at adt dot ee Summary: Content-length header is limited to 32bit integer -Status: Assigned +Status: Closed Type: Bug Package: Apache2 related Operating System: vista 32 PHP Version: 5.2.13 Assigned To: pajoye New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-05-03 10:46:33] paj...@php.net Windows 64bit is not always limited to 32bit if the correct type are used (__int64 & co). About unix, that's the same reason. Long is 64bit on 64bit linux while being 32bit on 32bit linux. As I will fix this problem on windows, it won't ever work on 32bit linux, but that's not really an issue as it never worked on these old systems. [2010-05-03 10:40:54] anatoli at adt dot ee Was not able to find 32bit unix/linux system. Tested on 64bit both cgi and apache sapi - working, content-type header data is correct. [2010-05-03 10:31:39] anatoli at adt dot ee Ok, now i got the point. Yes i really missed that long in windows is always 32bit by default and as i remember in 64bit windows it is also limited to 32bit. There must be used long long type, but i am not sure that this is possible. But anyway thanks. [2010-05-03 02:33:51] paj...@php.net "Do i must provide here code that allow downloads for files till 8Gb with multiple threads and resume support, witch is working under unix cgi, and not under win32 sapi?" No, thanks. Does it work with apache on unix as well? If yes, is it a 64bit or 32bit machine? The problem could be still the 32bit limitation as the apache2 SAPI replaces the headers with the correct length using strtol, which converts a string to a long. A long is always 32bit on Windows. I will check that code, needs some tweak on Windows (no luck I think on unix 32bit). [2010-05-03 01:50:11] anatoli at adt dot ee The problem is not in the filesize. Headers was checked with the latest wireshark. Under the cgi i receive correct header. Under sapi not. Do i must provide here code that allow downloads for files till 8Gb with multiple threads and resume support, witch is working under unix cgi, and not under win32 sapi? I redused test case to exactly minimum amount of code needed to reproduce error. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51723 -- Edit this bug report at http://bugs.php.net/bug.php?id=51723&edit=1
[PHP-BUG] Bug #51729 [NEW]: bitwiseShift* tests fail
From: geissert Operating system: Linux ia64 PHP version: 5.3.2 Package: Scripting Engine problem Bug Type: Bug Bug description:bitwiseShift* tests fail Description: On ia64 the following tests (test names relative t tests/lang/operators/) fail: bitwiseShiftLeft_basiclong_64bit.phpt bitwiseShiftLeft_variationStr_64bit.phpt bitwiseShiftRight_basiclong_64bit.phpt bitwiseShiftRight_variationStr.phpt The contents of the .log files can be found at (first is run-tests.php's output, later followed by the content of each .log file): http://alioth.debian.org/~geissert/php/5.3.2-1_ia64.tests.log.gz gcc's version and optimisation level are irrelevant. Actual result: -- For example, the diff of bitwiseShiftRight_variationStr.phpt: 032+ string(2) "30" 032- string(4) "3332" 060+ string(4) "2d31" 060- string(6) "2d3232" 116+ string(4) "2d31" 116- string(4) "2d34" 172+ string(2) "30" 172- string(4) "3631" 200+ string(2) "30" 200- string(4) "3631" 228+ string(2) "30" 228- string(4) "3631" 256+ string(2) "30" 256- string(4) "3631" 284+ string(2) "30" 284- string(4) "3631" 312+ string(2) "30" 312- string(4) "3631" 340+ string(2) "30" 340- string(2) "31" -- Edit bug report at http://bugs.php.net/bug.php?id=51729&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51729&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51729&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51729&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51729&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51729&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51729&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51729&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51729&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51729&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51729&r=support Expected behavior: http://bugs.php.net/fix.php?id=51729&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51729&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51729&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51729&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51729&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51729&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51729&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51729&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51729&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51729&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51729&r=mysqlcfg
[PHP-BUG] Bug #51730 [NEW]: bitwiseShiftLeft_variationStr test fails
From: geissert
Operating system: Linux armel/powerpc/s390
PHP version: 5.3.2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:bitwiseShiftLeft_variationStr test fails
Description:
On armel (ARM EABI), powerpc, and s390 the
tests/lang/operators/bitwiseShiftLeft_variationStr.phpt test fails.
The contents of the .log files can be grepped on the following files:
http://alioth.debian.org/~geissert/php/5.3.2-1_{armel,powerpc,s390}.tests.log.gz
(first is run-tests.php's output, later followed by the content of each
.log file):
On armel the bitwiseShiftRight_variationStr.phpt test fails too.
--
Edit bug report at http://bugs.php.net/bug.php?id=51730&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51730&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51730&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51730&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51730&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51730&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51730&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51730&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51730&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51730&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51730&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51730&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51730&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51730&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51730&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51730&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51730&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51730&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51730&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51730&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51730&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51730&r=mysqlcfg
Bug #51726 [Bgs]: Segmentation fault: 11 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=51726&edit=1 ID: 51726 Updated by: paj...@php.net Reported by: l dot iania at sintrade dot org Summary: Segmentation fault: 11 (core dumped) Status: Bogus Type: Bug Package: InterBase related Operating System: FreeBSD 7.2 and 8.0 PHP Version: 5.3.2 New Comment: Does it work or not? Using the sources available at www.php.net? We do not maintain the FreeBSD (or any other packages), if you are experiencing issues only with the FreeBSD packages, then please report a bug to freebsd. Previous Comments: [2010-05-03 17:37:56] l dot iania at sintrade dot org Yes, it's true, but I tried to rebuild the port from the port tree excluding Suhosin-Patch and the resulting code was always wrong. So probably the fact is that the scripts for building PHP in FreeBSD ports are wrong. The bogus is not in Suhosin-Patch but elsewhere. [2010-05-03 17:09:08] paj...@php.net Not a php bug > bogus. [2010-05-03 17:06:04] l dot iania at sintrade dot org Solved. I have compiled it outside the ports without Suhosin and now it seems OK. Thank you! So I think that the FreeBSD ports tree should be updated. [2010-05-03 16:04:50] ka...@php.net Could you compile PHP without Suhosin and compile with --enable-debug to export the symbols and then post a backtrace from gdb here? [2010-05-03 13:20:33] l dot iania at sintrade dot org Description: The bug appears everywhere using interbase extension, also running make test in the build directory, producing a core dump php.core. The valgrind output is: ==94843== Jump to the invalid address stated on the next line ==94843==at 0x1243810: ??? ==94843==by 0x375079: exit (in /lib/libc.so.7) ==94843==by 0x81FE1FE: main (in /usr/local/bin/php) ==94843== Address 0x1243810 is not stack'd, malloc'd or (recently) free'd Further more, running make test, the test #7 FAILS. Firebird installed from ports is: firebird-client-2.0.3_3 Firebird-2 database client firebird-server-2.0.3_3 Firebird-2 relational database (server) # php -v PHP 5.3.2 with Suhosin-Patch (cli) (built: May 3 2010 11:02:58) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies Test script: --- Every script involving interbase. i.e. -- Edit this bug report at http://bugs.php.net/bug.php?id=51726&edit=1
[PHP-BUG] Bug #51731 [NEW]: every numbers modulo by 4294967296.* will become 'division by zero' error
From: Operating system: Windows XP SP3 PHP version: 5.3.2 Package: Scripting Engine problem Bug Type: Bug Bug description:every numbers modulo by 4294967296.* will become 'division by zero' error Description: every numbers modulo by 4294967296.* will become 'division by zero' error Test script: --- Expected result: 0 Actual result: -- PHP Warning: Division by zero -- Edit bug report at http://bugs.php.net/bug.php?id=51731&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51731&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51731&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51731&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51731&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51731&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51731&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51731&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51731&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51731&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51731&r=support Expected behavior: http://bugs.php.net/fix.php?id=51731&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51731&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51731&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51731&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51731&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51731&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51731&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51731&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51731&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51731&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51731&r=mysqlcfg
Bug #51731 [Opn]: every numbers modulo by 4294967296.* will become 'division by zero' error
Edit report at http://bugs.php.net/bug.php?id=51731&edit=1 ID: 51731 User updated by: orangejasmine at hotmail dot com Reported by: orangejasmine at hotmail dot com Summary: every numbers modulo by 4294967296.* will become 'division by zero' error Status: Open Type: Bug Package: Scripting Engine problem Operating System: Windows XP SP3 PHP Version: 5.3.2 New Comment: sorry for a mistake Expected result: 1 Previous Comments: [2010-05-03 21:29:01] orangejasmine at hotmail dot com Description: every numbers modulo by 4294967296.* will become 'division by zero' error Test script: --- Expected result: 0 Actual result: -- PHP Warning: Division by zero -- Edit this bug report at http://bugs.php.net/bug.php?id=51731&edit=1
Bug #51731 [Opn->Bgs]: every numbers modulo by 4294967296.* will become 'division by zero' error
Edit report at http://bugs.php.net/bug.php?id=51731&edit=1 ID: 51731 Updated by: paj...@php.net Reported by: orangejasmine at hotmail dot com Summary: every numbers modulo by 4294967296.* will become 'division by zero' error -Status: Open +Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Windows XP SP3 PHP Version: 5.3.2 New Comment: 2^31 is the largest integer you can get on Windows. Previous Comments: [2010-05-03 21:36:01] orangejasmine at hotmail dot com sorry for a mistake Expected result: 1 [2010-05-03 21:29:01] orangejasmine at hotmail dot com Description: every numbers modulo by 4294967296.* will become 'division by zero' error Test script: --- Expected result: 0 Actual result: -- PHP Warning: Division by zero -- Edit this bug report at http://bugs.php.net/bug.php?id=51731&edit=1
[PHP-BUG] Bug #51733 [NEW]: SQLite3::exec() fails with disk I/O error
From:
Operating system: Ubuntu 10.04, FreeBSD 8
PHP version: 5.3.2
Package: SQLite related
Bug Type: Bug
Bug description:SQLite3::exec() fails with disk I/O error
Description:
I've tested this problem and it is duplicable on Ubuntu 10.04 and FreeBSD
8, both with 5.3.2 installed (from apt-get/ports). I also did a build of
5.3.2 from source to test this and it failed in the same way.
The problem comes when you try to create a table in a newly created
database when using the SQLite3 class. The empty db is created without
error and when you then try to create a table, you get the following
error:
PHP Warning: SQLite3::exec(): disk I/O error in php shell code on line 1
This is the same error in all builds on all OSes.
Test script:
---
$ php -a
php > $s = new SQLite3('/home/jdeiman/tmp/php.db', SQLITE3_OPEN_CREATE);
php > $ret = $s->exec('CREATE table testing (id integer)');
PHP Warning: SQLite3::exec(): disk I/O error in php shell code on line 1
--
Edit bug report at http://bugs.php.net/bug.php?id=51733&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51733&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51733&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51733&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51733&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51733&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51733&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51733&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51733&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51733&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51733&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51733&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51733&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51733&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51733&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51733&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51733&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51733&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51733&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51733&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51733&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51733&r=mysqlcfg
Bug #51731 [Com]: every numbers modulo by 4294967296.* will become 'division by zero' error
Edit report at http://bugs.php.net/bug.php?id=51731&edit=1 ID: 51731 Comment by: orangejasmine at hotmail dot com Reported by: orangejasmine at hotmail dot com Summary: every numbers modulo by 4294967296.* will become 'division by zero' error Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Windows XP SP3 PHP Version: 5.3.2 New Comment: oh i see... % operator converts operands to int sorry for my misunderstanding Previous Comments: [2010-05-03 21:39:37] paj...@php.net 2^31 is the largest integer you can get on Windows. [2010-05-03 21:36:01] orangejasmine at hotmail dot com sorry for a mistake Expected result: 1 [2010-05-03 21:29:01] orangejasmine at hotmail dot com Description: every numbers modulo by 4294967296.* will become 'division by zero' error Test script: --- Expected result: 0 Actual result: -- PHP Warning: Division by zero -- Edit this bug report at http://bugs.php.net/bug.php?id=51731&edit=1
Bug #51733 [Opn->Bgs]: SQLite3::exec() fails with disk I/O error
Edit report at http://bugs.php.net/bug.php?id=51733&edit=1
ID: 51733
Updated by: dtajchre...@php.net
Reported by: jay at splitstreams dot com
Summary: SQLite3::exec() fails with disk I/O error
-Status: Open
+Status: Bogus
Type: Bug
Package: SQLite related
Operating System: Ubuntu 10.04, FreeBSD 8
PHP Version: 5.3.2
New Comment:
You need to pass SQLITE3_OPEN_READWRITE | SQLITE3_OPEN_CREATE to the
ctor if you intend on writing to the database after creating it... or
you can leave the flags parameter blank and it will default to that.
Previous Comments:
[2010-05-03 22:02:49] jay at splitstreams dot com
Description:
I've tested this problem and it is duplicable on Ubuntu 10.04 and
FreeBSD 8, both with 5.3.2 installed (from apt-get/ports). I also did a
build of 5.3.2 from source to test this and it failed in the same way.
The problem comes when you try to create a table in a newly created
database when using the SQLite3 class. The empty db is created without
error and when you then try to create a table, you get the following
error:
PHP Warning: SQLite3::exec(): disk I/O error in php shell code on line
1
This is the same error in all builds on all OSes.
Test script:
---
$ php -a
php > $s = new SQLite3('/home/jdeiman/tmp/php.db',
SQLITE3_OPEN_CREATE);
php > $ret = $s->exec('CREATE table testing (id integer)');
PHP Warning: SQLite3::exec(): disk I/O error in php shell code on line
1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51733&edit=1
Bug #51516 [Com]: Apache 2.2 won't start after I install PHP (Using .MSI)
Edit report at http://bugs.php.net/bug.php?id=51516&edit=1 ID: 51516 Comment by: sensui at sohu dot com Reported by: sfoulk526 at gmail dot com Summary: Apache 2.2 won't start after I install PHP (Using .MSI) Status: Feedback Type: Bug Package: Apache2 related Operating System: Windows 7 PHP Version: 5.2.13 New Comment: To paj...@php.net In my case, when i installed php just with mysql entension, apache will be unable to start. Previous Comments: [2010-04-30 23:23:31] paj...@php.net Please check your error log. Also disable the extensions in php.ini to figure out which could cause problems. [2010-04-30 23:06:37] nick at vastms dot com I have this same problem, with the Windows .MSI. Upgraded from 5.2.9 and got the same error as the reporter describes. Tried reinstalling Apache 2.2 and PHP 5.2.13 completely from scratch and still got the same error. I know that the problem isn't with setting up the httpd.conf configuration, because I tried manually setting it up and got the same error. Also, the error doesn't leave any information in the Apache error logs. Just crashes Apache. Downgraded to 5.2.10 and it Apache starts again. [2010-04-09 01:35:28] sfoulk526 at gmail dot com Description: After running the downloaded file, php-5.2.13-win32-installer.msi, my Apache no longer will start. The error message I get is "The requested operation has failed." I have uninstalled PHP and Apache 2.2 works again. ??? -- Edit this bug report at http://bugs.php.net/bug.php?id=51516&edit=1
Req #34044 [Com]: Support for friend classes
Edit report at http://bugs.php.net/bug.php?id=34044&edit=1
ID: 34044
Comment by: neel dot basu dot z at gmail dot com
Reported by: arendjr at gmail dot com
Summary: Support for friend classes
Status: Wont fix
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: *
PHP Version: *
New Comment:
Ya friend functions would be a nice thing.
as PHP doesn't support many interesting keys of OOPS like Template,
friend etc..
(I know Java doesn't support most of them too, But thats not a good
excuse, cause
in PHP some of this can be supported with minimum change in Code) Its
not
possible to maintain Proper Coding Standard. and Programmers are forced
code in a
bad way. designing patterns/idioms cannot be followed.
Previous Comments:
[2006-10-11 19:01:09] he...@php.net
Long ago we decided against 'friend' declarations.
[2006-10-11 12:22:24] goliath dot mailinglist at gmx dot de
I'm developing an OOP CMS, too. This feature is really elementary for
complex systems where you want to limit access to the internals.
Currently I developed a system to access protected methods from outside
(using one base-class, a list to control the access and some secure
handshake when accessing the method), but thats detouring. Would be nice
to see some friend-system (like C++, or package -systemlike Java) in
PHP6.
If someone is interested in the code I mentioned above, I can post it.
[2006-09-03 18:34:38] linus dot martensson at elplan-gm dot se
I'm developing an OOP CMS, and the lack of friend objects prevents me
from disallowing layouts access to unsafe internal variables. It's
actually a rather severe problem when you try writing an advanced
system.
[2006-06-16 21:34:45] tsteiner at nerdclub dot net
In PHP 5.1, it is possible to simulate the function of friend classes
with __get and __set (I think PHP 5.0 triggers an error when trying to
access private properties even with __get or __set):
class HasFriends
{
private $__friends = array('MyFriend', 'OtherFriend');
public function __get($key)
{
$trace = debug_backtrace();
if(isset($trace[1]['class']) && in_array($trace[1]['class'],
$this->__friends)) {
return $this->$key;
}
// normal __get() code here
trigger_error('Cannot access private property ' . __CLASS__ .
'::$' . $key, E_USER_ERROR);
}
public function __set($key, $value)
{
$trace = debug_backtrace();
if(isset($trace[1]['class']) && in_array($trace[1]['class'],
$this->__friends)) {
return $this->$key = $value;
}
// normal __set() code here
trigger_error('Cannot access private property ' . __CLASS__ .
'::$' . $key, E_USER_ERROR);
}
}
[2006-01-11 00:49:08] php at lost dot co dot nz
This would also be really useful for me writing unit tests so that I can
run 'white box' testing on internal private methods another class (like
I used to do back in the 'good' old days of PHP4... ;-)
Something like this:
class Util
{
friend class UtilTest;
private static function foo() {...}
}
class UtilTest
{
if( Util::foo() != $expected )
...
}
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=34044
--
Edit this bug report at http://bugs.php.net/bug.php?id=34044&edit=1
Req #16349 [Com]: no way to tell if a session exists without starting it
Edit report at http://bugs.php.net/bug.php?id=16349&edit=1
ID: 16349
Comment by: edwardmillen at aol dot com
Reported by: adam at adeptsoftware dot com
Summary: no way to tell if a session exists without starting it
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: WinXP
PHP Version: 4.1.2
New Comment:
I've just run into this issue myself (or one of the issues mentioned
here anyway, I wanted to only start a session if the user is already
logged in, or at the point of logging in with a correct
username/password, rather than starting a session for every
unauthenticated page request).
I've found one way round it which seems to work for me at least, which
is to check whether the session cookie is set, like so:
if(isset($_COOKIE[session_name()])){session_start();}
(the session name, and therefore the name of the cookie, is normally
PHPSESSID by default, and the value of that cookie should be the session
ID if you need it)
I then used the following code in the login page after successful
verification of the username/password, before starting to set session
variables:
if(session_id()==''){session_start();}
Obviously this method will only work with cookie-based sessions, I
haven't looked into how exactly PHP handles URL-based sessions, but I
expect it would just be a matter of checking $_GET as well as $_COOKIE.
Also, this obviously won't help if you need to check whether a given
session ID already exists on the server or not, which I think is a
slightly different issue.
Previous Comments:
[2009-07-20 09:46:34] schung at iboxweb dot com
I agree, a session_exists() is needed. There is no other good way to
check whether a session exists. This is still a needed feature.
[2006-08-30 07:50:48] stefan at stefankoopmanschap dot nl
I have a similar issue. I pass the session ID in XML communication
between a desktop application and my server. When a request comes in, I
want to ensure that a session with the passed session id exists before I
start it. It seems this is not possible at the moment. I am, by the way,
using PHP5, not PHP4.
An additional session_exists() feature would be great!
[2005-10-28 23:30:32] jon at fuck dot org
it would be great to be able to get the correct session_id() before
starting a session. currently, said function returns null if the session
has not started yet, whether or not there is an existing one. the
overhead of creating the session is the problem, though, so if doing so
is still necessary in order to retrieve the id, then some other means --
i.e., a session_exists() function -- would be sufficient for cutting the
overhead when managing ungodly amounts of sessions.
[2005-10-28 23:21:20] da...@php.net
powerblade's comment is incorrect, the point of this bug is to determine
whether the user has a session without creating a new one if they do
not. (session_id always returns a blank string prior to session_start(),
regardless of whether an actual session exists).
Example: a site wishes to print "Hello " at the top of every
page. Username is stored on a session. The site must therefore resume
the session to retrieve this username. But it is pointless to *create* a
session just for this purpose. A bunch of useless 0-byte sess_* files
are wastefully created.
In Java, one would do request.getSession(false) - the parameter 'start'
set to false causes this function to return null if no session already
exists.
In PHP, better semantics would be to add a function such as bool
session_exists()
This still needs to be addressed.
[2002-12-03 15:37:01] powerblade at mail dot dk
I had the same problem. I wanted to knew if the session was started or
not.
I found out i should do a session_id(); If it returns "null" then it's
not
started yet, else it returns the session id.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=16349
--
Edit this bug report at http://bugs.php.net/bug.php?id=16349&edit=1
Req #16349 [Com]: no way to tell if a session exists without starting it
Edit report at http://bugs.php.net/bug.php?id=16349&edit=1
ID: 16349
Comment by: edwardmillen at aol dot com
Reported by: adam at adeptsoftware dot com
Summary: no way to tell if a session exists without starting it
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: WinXP
PHP Version: 4.1.2
New Comment:
I've just found a potentially exploitable hole which is opened up by not
always starting the session (as described in my previous comment), if
your server has register_globals turned on.
So just in case, to close the hole and keep things properly secure, the
first line of code in my previous comment should be changed to this:
if(isset($_COOKIE[session_name()])){session_start();}else{unset($_SESSION);}
Previous Comments:
[2010-05-04 07:59:31] edwardmillen at aol dot com
I've just run into this issue myself (or one of the issues mentioned
here anyway, I wanted to only start a session if the user is already
logged in, or at the point of logging in with a correct
username/password, rather than starting a session for every
unauthenticated page request).
I've found one way round it which seems to work for me at least, which
is to check whether the session cookie is set, like so:
if(isset($_COOKIE[session_name()])){session_start();}
(the session name, and therefore the name of the cookie, is normally
PHPSESSID by default, and the value of that cookie should be the session
ID if you need it)
I then used the following code in the login page after successful
verification of the username/password, before starting to set session
variables:
if(session_id()==''){session_start();}
Obviously this method will only work with cookie-based sessions, I
haven't looked into how exactly PHP handles URL-based sessions, but I
expect it would just be a matter of checking $_GET as well as $_COOKIE.
Also, this obviously won't help if you need to check whether a given
session ID already exists on the server or not, which I think is a
slightly different issue.
[2009-07-20 09:46:34] schung at iboxweb dot com
I agree, a session_exists() is needed. There is no other good way to
check whether a session exists. This is still a needed feature.
[2006-08-30 07:50:48] stefan at stefankoopmanschap dot nl
I have a similar issue. I pass the session ID in XML communication
between a desktop application and my server. When a request comes in, I
want to ensure that a session with the passed session id exists before I
start it. It seems this is not possible at the moment. I am, by the way,
using PHP5, not PHP4.
An additional session_exists() feature would be great!
[2005-10-28 23:30:32] jon at fuck dot org
it would be great to be able to get the correct session_id() before
starting a session. currently, said function returns null if the session
has not started yet, whether or not there is an existing one. the
overhead of creating the session is the problem, though, so if doing so
is still necessary in order to retrieve the id, then some other means --
i.e., a session_exists() function -- would be sufficient for cutting the
overhead when managing ungodly amounts of sessions.
[2005-10-28 23:21:20] da...@php.net
powerblade's comment is incorrect, the point of this bug is to determine
whether the user has a session without creating a new one if they do
not. (session_id always returns a blank string prior to session_start(),
regardless of whether an actual session exists).
Example: a site wishes to print "Hello " at the top of every
page. Username is stored on a session. The site must therefore resume
the session to retrieve this username. But it is pointless to *create* a
session just for this purpose. A bunch of useless 0-byte sess_* files
are wastefully created.
In Java, one would do request.getSession(false) - the parameter 'start'
set to false causes this function to return null if no session already
exists.
In PHP, better semantics would be to add a function such as bool
session_exists()
This still needs to be addressed.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=16349
--
Edit this bug report at http://bugs.php.net/bug.php?id=16349&edit=1
