#22014 [NEW]: html_entity_decode with unset variable results in segfault
From: [EMAIL PROTECTED] Operating system: Debian Linux&FreeBSD 4.7-STABLE PHP version: 4.3.0 PHP Bug Type: Reproducible crash Bug description: html_entity_decode with unset variable results in segfault this results in a segfault, tested on Debian, FreeBSD 4.7-STABLE & and Gentoo with Apache/1.3.27 & PHP 4.3.0 -- Edit bug report at http://bugs.php.net/?id=22014&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22014&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22014&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22014&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22014&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22014&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22014&r=support Expected behavior: http://bugs.php.net/fix.php?id=22014&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22014&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22014&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22014&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22014&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22014&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22014&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22014&r=gnused
Bug #15371 Updated: corrupted/erroneous data output
ID: 15371 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Red Hat 7.2 PHP Version: 4.1.1 New Comment: I have experienced the same error using using FreeTDS 0.53 running 7.0 on Red Hat 7.2. The only difference is that I'm running PHP 4.1.2. It helped switching to FreeTDS version 4.2. Previous Comments: [2002-02-04 17:27:50] [EMAIL PROTECTED] ok, this only gets wierder and wierder. I tried simply reloading the page again and again. Output would be correct several times, then incorrect, then correct, etc. We rebooted the Linux server, and now it is only incorrect. Sorry for the multiple additions. /jte [2002-02-04 16:57:21] [EMAIL PROTECTED] Of course, right after submitting the report, I tried changing the FreeTDS version to 4.2. The data was output correctly. However, why did SQSH work at 7.0, when it sits on top of FreeTDS, and not PHP? [2002-02-04 16:49:47] [EMAIL PROTECTED] We are attempting to MSSQL using FreeTDS 0.53 running 7.0. I have successfully connected to the MSSQL 2000 database; however, when I output the results of a query, it appears as though trailing characters from the previous row are being added to the current row. This happens whether I output using the ADODB system, or use PHP's Sybase commands. However, when I use SQSH 2.1, it outputs the data correctly. This points to PHP and its Sybase functions, as far as I can tell. Here is what the native data look like in MSSQL: Education & Technical Products Marketing Management Membership Legislative Issues Links & Resources News & Calendar Career Center Inside WTCA Affiliates Control Panel/Options Site Map and here is the output from PHP: Education & Technical Products & Tech Marketing& Techi Management Techia Membership Techia Legislative Issuesa Links & Resourcesa News & Calendarsa Career Centerrsa Inside WTCArrsa Affiliatesrrsa Control Panel/Options Site Mapanel/Op As you can see, it's adding characters from the previous row. The pattern is not perfectly consistent, however. We are currently using the dblib, and trying to configure ctlib, but aren't successful yet. Thank you for your time and attention. Jay Edgar -- Edit this bug report at http://bugs.php.net/?id=15371&edit=1
Bug #16693 Updated: I Can't Read Japanese manual(html).
ID: 16693 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Documentation problem Operating System: WindowsME PHP Version: 4.1.2 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-04-19 02:49:40] [EMAIL PROTECTED] I don't have problem with the file. http://www.php.net/distributions/manual/php_manual_ja.tar.bz2 It's encoded by UTF8. If you are using personal web server or like, you may need to set correct Charset header, though. Or file was broken temporarily? Could you try it now? [2002-04-19 01:17:44] [EMAIL PROTECTED] http://www.php.net/distributions/manual/php_manual_ja.tar.bz2 also this manual too. html source tag & English codes I can read. Japanese codes I can't read too. [2002-04-19 01:05:34] [EMAIL PROTECTED] I download HTML Manual for Japanese. but I can't read this html. This file's Japanese code is not shift-JIS,JIS,EUC,Unicode... http://www.php.net/distributions/manual/php_manual_ja.html.bz2 -- Edit this bug report at http://bugs.php.net/?id=16693&edit=1
Bug #16738 Updated: confusing explanation of assigning by reference
ID: 16738 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: 4.2.0 Assigned To: alindeman New Comment: This bug has been fixed in CVS. Previous Comments: [2002-04-22 17:21:41] [EMAIL PROTECTED] assigned to myself [2002-04-22 16:59:24] [EMAIL PROTECTED] Why do '$bar = "My name is $bar";'? And then do 'echo $foo' *before* you 'echo $bar'? The point you're trying to make is surely expressed better like this: Clearer for the newcomer to programming, ne? -- Edit this bug report at http://bugs.php.net/?id=16738&edit=1
Bug #61266 [Wfx->ReO]: bs
Edit report at https://bugs.php.net/bug.php?id=61266&edit=1
ID: 61266
Updated by: b...@php.net
Reported by:ben dot pineau at gmail dot com
-Summary:pg_affected_rows inconsistent behavior (depends on
PostgreSQL server version)
+Summary: bs
-Status: Wont fix
+Status: Re-Opened
Type: Bug
Package:PostgreSQL related
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
It's actually possible that a writing command produces a result set (which can
differ in the number of affected / returned rows):
Simple example would be:
INSERT INTO foo (bar, baz)
VALUES (DEFAULT, 'bang')
RETURNING (bar);
Therefore i don't see this has having only a low impact.
Previous Comments:
[2012-03-08 08:31:22] cataphr...@php.net
I don't think PHP should apply compatibility shims on top of libpq, especially
when the new functionality has low impact and actually adds functionality. The
case for your PDO bug report, however, is much more compelling.
[2012-03-03 13:42:36] ben dot pineau at gmail dot com
Description:
According to the manual, pg_affected_rows should returns "the number of tuples
(instances/records/rows) affected by INSERT, UPDATE, and DELETE queries.". The
manual details : "The number of rows affected by the query. If no tuple is
affected, it will return 0.".
PHP pg_affected_rows uses libpq's PQcmdTuples() to implement this:
PHP_FUNCTION(pg_affected_rows)
{
php_pgsql_get_result_info(INTERNAL_FUNCTION_PARAM_PASSTHRU,PHP_PG_CMD_TUPLES);
}
static void php_pgsql_get_result_info(INTERNAL_FUNCTION_PARAMETERS, int
entry_type)
{
[...]
case PHP_PG_CMD_TUPLES:
Z_LVAL_P(return_value) = atoi(PQcmdTuples(pgsql_result));
But server's answers to PQcmdTuples() commands changed since PostgreSQL 9.0.
When executed after a SELECT, PostgreSQL < 9.0 returned 0 (as in "0 rows were
affected"); starting with PostgreSQL 9.0, the server returns the number of
SELECTed rows.
See how the PQcmdTuples documentation was updated after pg 9:
http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
http://www.postgresql.org/docs/9.1/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
PostgreSQL C API doesn't actually offers a "tell me how many rows were
written/modified" function. But we can restore the previous pg_affected_rows
behavior, and enjoy consistent results no matter which server version we run
against, by unconditionally returning 0 after a SELECT.
This is what the attached patch does, identifying the SELECT with
PQresultStatus() value (which returns PGRES_COMMAND_OK after a successful DML,
as opposed to PGRES_TUPLES_OK after a SELECT, etc).
If you ask so, I can also provide an alternative patch (which tests the string
returned by PQcmdStatus(), a bit ugly imo) and/or an unit test script for PHP's
test framework.
Test script:
---
// Bug on a PostgreSQL >= 9.0 server, ok on older versions.
$dbh = pg_pconnect("dbname=postgres host=localhost user=postgres port=5432");
$q = pg_query($dbh, "SELECT * from generate_series(1, 42);");
var_dump(pg_affected_rows($q));
Expected result:
int(0)
Actual result:
--
int(42)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61266&edit=1
#43216 [Opn->Asn]: stream_is_local() returns false on file://
ID: 43216
Updated by: [EMAIL PROTECTED]
Reported By: php at benjaminschulz dot com
-Status: Open
+Status: Assigned
Bug Type: Streams related
Operating System: linux
PHP Version: 5.3CVS-2007-11-08 (CVS)
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2007-11-08 08:17:43] php at benjaminschulz dot com
Description:
stream_is_local() should return true for "file://"
Reproduce code:
---
var_dump(stream_is_local("file://"));
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=43216&edit=1
#43312 [Opn->Asn]: php://filter URIs get mangled and make xinclude() fail
ID: 43312
Updated by: [EMAIL PROTECTED]
Reported By: php at benjaminschulz dot com
-Status: Open
+Status: Assigned
Bug Type:DOM XML related
PHP Version: 5.3CVS-2007-11-16 (CVS)
-Assigned To:
+Assigned To: chregu
Previous Comments:
[2007-11-16 13:42:49] php at benjaminschulz dot com
Description:
When using php://filter with xinclude an errornous file:// uri is
generated and let's the xinclude fail.
Reproduce code:
---
test.php
';
class TestFilter extends PHP_User_Filter {
public function filter($in, $out, &$consumed, $closing) {
while ($bucket = stream_bucket_make_writeable($in)) {
$consumed += $bucket->datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
stream_filter_register('testfilter', 'TestFilter');
$doc = new DomDocument;
$doc->load("php://filter/read=testfilter/resource=file://".dirname(__FILE__)."/test1.xml");
$doc->xinclude();
echo "works!";
test1.xml
-
http://www.w3.org/2001/XInclude"; />
test2.xml
-
baz
Expected result:
"works!"
Actual result:
--
Warning:
DOMDocument::xinclude(php://filter/read=testfilter/resource=file%3A/path
/to/test2.xml): failed to open stream: No such file or directory in
/path/to/test.php on line 18
^- should be ":" and there are two slashes missing
Warning: DOMDocument::xinclude(): I/O warning : failed to load external
entity
"php://filter/read=testfilter/resource=file%3A/path/to/test2.xml"
in /path/to/test.php on line 18
Warning: DOMDocument::xinclude(): could not load
php://filter/read=testfilter/resource=file%3A/path/to/test2.xml, and no
fallback was found in /path/to/test.php on line 18
--
Edit this bug report at http://bugs.php.net/?id=43312&edit=1
#42942 [Opn->Asn]: pdo_pgsql: segfault with multiple rows and prepared statements
ID: 42942
Updated by: [EMAIL PROTECTED]
Reported By: php at benjaminschulz dot com
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: linux
PHP Version: 5CVS-2007-10-12 (CVS)
-Assigned To:
+Assigned To: edin
Previous Comments:
[2007-10-12 09:14:08] php at benjaminschulz dot com
Description:
Hi,
i can't provide reproduce code. All i can say is that i use prepared
statements with multiple rows (INSERT .. VALUES (..), (...)) and on a
table with huge data php segfaults.
If executed with 100 rows per Statement PHP fails with "zend_mm_heap
corrupted", this core was created with 20 rows. The rows contain binary
data and are all about 1-3mb.
Here is the backtrace, i hope it helps:
Core was generated by `php -q index.php'.
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_free_int (heap=0x85971f8, p=) at
/usr/src/php5/Zend/zend_alloc.c:1932
1932if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 _zend_mm_free_int (heap=0x85971f8, p=) at
/usr/src/php5/Zend/zend_alloc.c:1932
#1 0x082cecac in zend_hash_destroy (ht=0x876b210) at
/usr/src/php5/Zend/zend_hash.c:531
#2 0x082c4ab7 in _zval_dtor_func (zvalue=0x86f6724) at
/usr/src/php5/Zend/zend_variables.c:43
#3 0x082b8e09 in _zval_ptr_dtor (zval_ptr=0xbfe86b94) at
/usr/src/php5/Zend/zend_variables.h:35
#4 0x082f101a in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe88cc0) at /usr/src/php5/Zend/zend_execute.h:155
#5 0x082e23a8 in execute (op_array=0x869c9e0) at
/usr/src/php5/Zend/zend_vm_execute.h:87
#6 0x082c4de4 in zend_execute_scripts (type=8, retval=, file_count=3) at /usr/src/php5/Zend/zend.c:1134
#7 0x08282d70 in php_execute_script (primary_file=0xbfe8b098) at
/usr/src/php5/main/main.c:2006
#8 0x083431d7 in main (argc=3, argv=0xbfe8b1b4) at
/usr/src/php5/sapi/cli/php_cli.c:1140
--
Edit this bug report at http://bugs.php.net/?id=42942&edit=1
#29206 [NEW]: DOMDocument::LoadXML: Strict Standards: DOMDocument::loadXML(); is not static
From: tommy at vandervorst-bs dot nl
Operating system: Windows Server 2003 Standard
PHP version: 5.0.0
PHP Bug Type: DOM XML related
Bug description: DOMDocument::LoadXML: Strict Standards: DOMDocument::loadXML(); is
not static
Description:
The following code:
$d = DOMDocument::loadXML("");
works perfectly well, but when setting PHP to report E_STRICT warnings:
error_reporting(E_ALL|E_STRICT);
It says:
Strict Standards: Non-static method DOMDocument::loadXML() should not be
called statically in [some script] on line [some line]
which I think is incorrect, since DOMDocument::loadXML is (even according
to the manual,
http://nl2.php.net/manual/en/function.dom-domdocument-loadxml.php) a
static function.
Reproduce code:
---
");
?>
Expected result:
No error, this code is (in my eyes) perfectly valid.
Actual result:
--
Strict Standards: Non-static method DOMDocument::loadXML() should not be
called statically in [some script] on line [some line]
--
Edit bug report at http://bugs.php.net/?id=29206&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29206&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29206&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29206&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29206&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29206&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29206&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29206&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29206&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29206&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29206&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29206&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29206&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29206&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29206&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29206&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29206&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29206&r=float
#24233 [NEW]: imap.so module broken
From: joerg dot ludwig at hvf-bs dot net
Operating system: RedHat 7.3 Linux
PHP version: 4.3.2
PHP Bug Type: *Compile Issues
Bug description: imap.so module broken
Description:
I built my php rpm with these options:
%configure \
--cache-file=../config.cache \
--with-config-file-path=%{_sysconfdir}/miniphp \
--enable-force-cgi-redirect \
--disable-debug \
--disable-rpath \
--enable-inline-optimization \
--with-exec-dir=%{_bindir} \
--disable-all \
--with-pcre-regex \
--enable-posix \
--enable-memory-limit \
--enable-mbstring \
--with-imap=shared \
--with-imap-ssl \
--with-kerberos=/usr/kerberos
I got no errors while building, but I couldn't load the imap module:
# php -r 'dl("imap.so");'
Warning: dl(): Unable to load dynamic library '/usr/lib/php4/imap.so' -
¨áB¨áB/php4/imap.so: shared object not open in Command line code on line
1
When I add "--with-openssl" to configure, everything works.
Expected result:
I expect configure to output an error instead of building a broken
module.
A notice in "configure --help" would be helpful too.
--
Edit bug report at http://bugs.php.net/?id=24233&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24233&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24233&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24233&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24233&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24233&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24233&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24233&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24233&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24233&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24233&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24233&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24233&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24233&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24233&r=gnused
#35996 [NEW]: pg_meta_data should take the schema into account
From: G dot Gersdorf at tu-bs dot de Operating system: Linux PHP version: 5.1.2 PHP Bug Type: PostgreSQL related Bug description: pg_meta_data should take the schema into account Description: If a database contains tables with the same name in different schemas, requesting the meta data for this table returns a mix for all fields in all that tables. The select statement use is something like SELECT a.attname, a.attnum, t.typname, a.attlen, a.attnotNULL, a.atthasdef, a.attndims FROM pg_class as c, pg_attribute a, pg_type t WHERE a.attnum > 0 AND a.attrelid = c.oid AND c.relname='$table' AND a.atttypid = t.oid ORDER BY a.attnum but should be something like SELECT a.attname, a.attnum, t.typname, a.attlen, a.attnotNULL, a.atthasdef, a.attndims FROM pg_class as c, pg_attribute a, pg_type t, pg_namespace n WHERE a.attnum > 0 AND a.attrelid = c.oid AND c.relname='$table' AND a.atttypid = t.oid AND c.relnamespace=n.oid AND n.nspname='$schema' ORDER BY a.attnum where $schema='public' as default -- Edit bug report at http://bugs.php.net/?id=35996&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35996&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35996&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35996&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35996&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35996&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35996&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35996&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35996&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35996&r=support Expected behavior:http://bugs.php.net/fix.php?id=35996&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35996&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35996&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35996&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35996&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35996&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35996&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35996&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35996&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35996&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35996&r=mysqlcfg
