#47777 [NEW]: Can't compile the pcntl extension

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: FreeBSD 6.2
PHP version:  5.3CVS-2009-03-25 (CVS)
PHP Bug Type: Compile Failure
Bug description:  Can't compile the pcntl extension

Description:

Looks like PHP_5_3 doesn't compile on my FreeBSD 6.2 system if the pcntl
extension is enabled.

Reproduce code:
---
./configure --disable-cgi --enable-pcntl
make

Expected result:

No error :)

Actual result:
--
/usr/local/bin/bash /root/compile/php-5.3/libtool --silent
--preserve-dup-deps --mode=compile cc  -Iext/pcntl/
-I/root/compile/php-5.3/ext/pcntl/ -DPHP_ATOM_INC
-I/root/compile/php-5.3/include -I/root/compile/php-5.3/main
-I/root/compile/php-5.3 -I/root/compile/php-5.3/ext/ereg/regex
-I/usr/local/include/libxml2 -I/usr/local/include
-I/root/compile/php-5.3/ext/date/lib
-I/root/compile/php-5.3/ext/sqlite3/libsqlite -I/root/compile/php-5.3/TSRM
-I/root/compile/php-5.3/Zend-I/usr/local/include -g -O2  -c
/root/compile/php-5.3/ext/pcntl/pcntl.c -o ext/pcntl/pcntl.lo
/root/compile/php-5.3/ext/pcntl/pcntl.c: In function
`php_register_signal_constants':
/root/compile/php-5.3/ext/pcntl/pcntl.c:293: error: `CLD_EXITED'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:293: error: (Each undeclared
identifier is reported only once
/root/compile/php-5.3/ext/pcntl/pcntl.c:293: error: for each function it
appears in.)
/root/compile/php-5.3/ext/pcntl/pcntl.c:294: error: `CLD_KILLED'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:295: error: `CLD_DUMPED'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:296: error: `CLD_TRAPPED'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:297: error: `CLD_STOPPED'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:298: error: `CLD_CONTINUED'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:301: error: `TRAP_BRKPT'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:302: error: `TRAP_TRACE'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:305: error: `POLL_IN' undeclared
(first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:306: error: `POLL_OUT' undeclared
(first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:307: error: `POLL_MSG' undeclared
(first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:308: error: `POLL_ERR' undeclared
(first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:309: error: `POLL_PRI' undeclared
(first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:310: error: `POLL_HUP' undeclared
(first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:312: error: `ILL_ILLOPC'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:313: error: `ILL_ILLOPN'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:314: error: `ILL_ILLADR'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:315: error: `ILL_ILLTRP'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:316: error: `ILL_PRVOPC'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:317: error: `ILL_PRVREG'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:318: error: `ILL_COPROC'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:319: error: `ILL_BADSTK'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:330: error: `SEGV_MAPERR'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:331: error: `SEGV_ACCERR'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:333: error: `BUS_ADRALN'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:334: error: `BUS_ADRERR'
undeclared (first use in this function)
/root/compile/php-5.3/ext/pcntl/pcntl.c:335: error: `BUS_OBJERR'
undeclared (first use in this function)
*** Error code 1


-- 
Edit bug report at http://bugs.php.net/?id=4&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=4&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=4&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=4&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=4&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=4&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=4&r=alreadyfixed
Need backtrace:  
h

#44173 [Com]: PDO->query() parameter parsing/checking needs an update

[matteo at beccati dot com]

 ID:   44173
 Comment by:   matteo at beccati dot com
 Reported By:  uwendel at mysql dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.3CVS-2008-02-19 (CVS)
 New Comment:

The following patch also removes the goto from the function, as
suggested by Johannes:

http://www.beccati.com/misc/php/pdo_pgsql_bug44173_php_5.3_v2.patch


Previous Comments:


[2009-03-22 17:59:16] matteo at beccati dot com

Fix is available here:

http://www.beccati.com/misc/php/pdo_pgsql_bug44173_php_5.3.patch



[2008-02-19 16:25:01] uwendel at mysql dot com

And a last one...


[7] PDO->query('SELECT', PDO::FETCH_CLASS) -> proper error message

nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("sqlite:/tmp/foo.db");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT)");
$pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query("SELECT id FROM test", PDO::FETCH_CLASS,
"unknown"));'

Warning: PDO::query(): SQLSTATE[]: <> in Command line
code on line 1
bool(false)


I have not checked other error modes of PDO. I do not know if PDO shall
raise an exception for every warning it prints, if that's intended at
all.



[2008-02-19 16:21:04] uwendel at mysql dot com

[6] PDO->query("SELECT", PDO::FETCH_COLUMN) -> error message could be
better

nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("sqlite:/tmp/foo.db");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT)");
$pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query("SELECT id FROM test", PDO::FETCH_COLUMN));'

Warning: PDO::query(): SQLSTATE[]: <> in Command line
code on line 1
bool(false)



[2008-02-19 16:18:07] uwendel at mysql dot com

[5] PDO->query('SELECT ...', PDO::FETCH_INTO) -> no proper error
message

nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("sqlite:/tmp/foo.db");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT)");
$pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query("SELECT id FROM test", PDO::FETCH_INTO));'

Warning: PDO::query(): SQLSTATE[]: <> in Command line
code on line 1
bool(false)



[2008-02-19 15:52:27] uwendel at mysql dot com

Description:

Parameter parsing/checking by PDO->query() should be updated to todays
standards. I would like to see it be more strict and follow ideas from
new code, e.g. do not accept object/arrays for scalar (int) parameter.

[1] PDO->query() -> Warning: query(): could not obtain parameters for
parsing

[2] assert(PDO::FETCH_CLASS != 1); PDO->query("SELECT ...", 1, 1, 1) ->
four arguments make only sense for mode = PDO::FETCH_CLASS but 1 !=
PDO::FETCH_CLASS, I'd expect to see a warning

[3] $mode = new stdClass();
PDO->query('SELECT ...', $mode) -> Notice + PDOStatement returned
($mode cast to 1 I guess)

[4] PDO->query('SELECT ..., 2, 3, 4, 5) --> two many arguments in any
case according to http://de.php.net/manual/en/function.PDO-query.php





Reproduce code:
---
[1] nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("mysql:dbname=phptest;unix_socket=/tmp/mysql.sock", "root",
"root"); @$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE
test(id INT)"); $pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query());'

Warning: query(): could not obtain parameters for parsing in Command
line code on line 1
bool(false)

[2] nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("pgsql:host=localhost port=5432 dbname=phptest
user=postgres password="); @$pdo->exec("DROP TABLE test");
$pdo->exec("CREATE TABLE test(id INT)"); $pdo->exec("INSERT INTO
test(id) VALUES (1)"); $mode = new stdClass();
var_dump($pdo->query("SELECT id FROM test", 1, 1, 1));'
object(PDOStatement)#3 (1) {
  ["queryString"]=>
  string(19

#44173 [Com]: PDO->query() parameter parsing/checking needs an update

[matteo at beccati dot com]

 ID:   44173
 Comment by:   matteo at beccati dot com
 Reported By:  uwendel at mysql dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.3CVS-2008-02-19 (CVS)
 New Comment:

Fix is available here:

http://www.beccati.com/misc/php/pdo_pgsql_bug44173_php_5.3.patch


Previous Comments:


[2008-02-19 16:25:01] uwendel at mysql dot com

And a last one...


[7] PDO->query('SELECT', PDO::FETCH_CLASS) -> proper error message

nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("sqlite:/tmp/foo.db");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT)");
$pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query("SELECT id FROM test", PDO::FETCH_CLASS,
"unknown"));'

Warning: PDO::query(): SQLSTATE[]: <> in Command line
code on line 1
bool(false)


I have not checked other error modes of PDO. I do not know if PDO shall
raise an exception for every warning it prints, if that's intended at
all.



[2008-02-19 16:21:04] uwendel at mysql dot com

[6] PDO->query("SELECT", PDO::FETCH_COLUMN) -> error message could be
better

nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("sqlite:/tmp/foo.db");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT)");
$pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query("SELECT id FROM test", PDO::FETCH_COLUMN));'

Warning: PDO::query(): SQLSTATE[]: <> in Command line
code on line 1
bool(false)



[2008-02-19 16:18:07] uwendel at mysql dot com

[5] PDO->query('SELECT ...', PDO::FETCH_INTO) -> no proper error
message

nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("sqlite:/tmp/foo.db");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT)");
$pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query("SELECT id FROM test", PDO::FETCH_INTO));'

Warning: PDO::query(): SQLSTATE[]: <> in Command line
code on line 1
bool(false)



[2008-02-19 15:52:27] uwendel at mysql dot com

Description:

Parameter parsing/checking by PDO->query() should be updated to todays
standards. I would like to see it be more strict and follow ideas from
new code, e.g. do not accept object/arrays for scalar (int) parameter.

[1] PDO->query() -> Warning: query(): could not obtain parameters for
parsing

[2] assert(PDO::FETCH_CLASS != 1); PDO->query("SELECT ...", 1, 1, 1) ->
four arguments make only sense for mode = PDO::FETCH_CLASS but 1 !=
PDO::FETCH_CLASS, I'd expect to see a warning

[3] $mode = new stdClass();
PDO->query('SELECT ...', $mode) -> Notice + PDOStatement returned
($mode cast to 1 I guess)

[4] PDO->query('SELECT ..., 2, 3, 4, 5) --> two many arguments in any
case according to http://de.php.net/manual/en/function.PDO-query.php





Reproduce code:
---
[1] nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("mysql:dbname=phptest;unix_socket=/tmp/mysql.sock", "root",
"root"); @$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE
test(id INT)"); $pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query());'

Warning: query(): could not obtain parameters for parsing in Command
line code on line 1
bool(false)

[2] nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("pgsql:host=localhost port=5432 dbname=phptest
user=postgres password="); @$pdo->exec("DROP TABLE test");
$pdo->exec("CREATE TABLE test(id INT)"); $pdo->exec("INSERT INTO
test(id) VALUES (1)"); $mode = new stdClass();
var_dump($pdo->query("SELECT id FROM test", 1, 1, 1));'
object(PDOStatement)#3 (1) {
  ["queryString"]=>
  string(19) "SELECT id FROM test"
}

[2] nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("pgsql:host=localhost port=5432 dbname=phptest
user=postgres password="); @$pdo->exec("DROP TABLE test");
$pdo->exec("

#44409 [Com]: PDO::FETCH_SERIALIZE calls __construct()

[matteo at beccati dot com]

 ID:   44409
 Comment by:   matteo at beccati dot com
 Reported By:  uwendel at mysql dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.3CVS-2008-03-11 (CVS)
 New Comment:

Fix available at:

http://www.beccati.com/misc/php/pdo_pgsql_bug44409_php_5_3.patch


Previous Comments:


[2009-02-15 21:11:16] dav...@php.net

Hmm is it supposed to say: PDO::FETCH_SERIZALIZE?



[2008-03-11 19:53:48] uwendel at mysql dot com

Description:

There seems to be very few documentation about PDO::FETCH_SERIALIZE in
the PHP manual but playing the guessing game from the code it seems that
this feature aims to support SPL/Serialize interface. As I'm not sure
about the purpose of PDO::FETCH_SERIALIZE I'm not sure if the following
is a bug or not. However, it seems to me that PDO::FETCH_SERIALIZE
unintentionally calls __construct().

One of the main ideas behind SPL/Serialize interface seems to be that
for unserialization the constructor of a class does not get called. The
constructor of a class has a different meaning than a helper function
like unserialize() and thus should not be called automatically. Let's
check:

class myclass implements Serialize {
  public function __construct() {
printf("%s()\n", __METHOD__);
  }
  public function serialize() {
printf("%s()\n", __METHOD__);
return "any data from serialize()";
  }
  public function unserialize($dat) {
printf("%s(%s)\n", __METHOD__, var_export($dat, true));
  }
}

$obj1 = new myclass() 
  ---> myclass::__construct()
$tmp  = serialize($obj1)
$obj2 = unserialize($tmp) 
  ---> myclass::unserialize('any data from serizalize()')

__construct() gets called only once for object creation but not again
during unserialization. Let's try that with PDO:

[...]
$stmt = $db->query("SELECT dat FROM test");
$rows = $stmt->fetchAll(PDO::FETCH_CLASS|PDO::FETCH_SERIZALIZE,
"myclass");
  --> myclass::unserialize("data from DB")
  --> myclass::__construct()
[...]

PDO first calls unserialize() as its supposed to do. But then it also
calls __construct() which is against the idea of the Serialize interface
not to call the constructor automatically during unserialization.

Reproduce code:
---
sapi/cli/php -r '$db = new PDO("sqlite:/tmp/foo"); $db->exec("DROP
TABLE test"); $db->exec("CREATE TABLE test(dat VARCHAR(100))");
$db->exec("INSERT INTO test(dat) VALUES (\"Data from DB\")"); class
myclass implements Serializable { public function __construct() {
printf("%s()\n", __METHOD__); } public function serialize() { return
"any data from serizalize()"; } public function unserialize($dat) {
printf("%s(%s)\n", __METHOD__, var_export($dat, true)); }} $stmt =
$db->query("SELECT * FROM test");
var_dump($stmt->fetchAll(PDO::FETCH_CLASS|PDO::FETCH_SERIALIZE,
"myclass")); $obj = new myclass();
var_dump(unserialize(serialize($obj)));'
myclass::unserialize('Data from DB')
myclass::__construct()
array(1) {
  [0]=>
  object(myclass)#3 (0) {
  }
}
myclass::__construct()
myclass::unserialize('any data from serizalize()')
object(myclass)#4 (0) {
}







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

#47311 [Csd]: PDO::PARAM_LOB columns need to be bound before execute() on PgSQL

[matteo at beccati dot com]

 ID:   47311
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Closed
 Bug Type: PDO related
 Operating System: Any
 PHP Version:  5.3.0beta1
 New Comment:

Thanks for that. I've also created a patch for the documentation. You
might want to check the wording and fixing it before applying:

http://www.beccati.com/misc/pdo_pgsql_bug47311_phpdoc.patch


Previous Comments:


[2009-02-11 10:44:56] fel...@php.net

This bug has been fixed in CVS.

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.





[2009-02-04 18:31:55] matteo at beccati dot com

Patch is available here:

http://www.beccati.com/misc/pdo_pgsql_bug47311_php_5.3.patch

It fixes another small problem in the phpt and adds one more test case.
Plus adds a note to the code.



[2009-02-04 18:29:09] matteo at beccati dot com

Description:

I was trying to investigate a test failure in the pdo_pgsql extension,
namely the large_objects.phpt.

The failure is caused by the fact that the LOB parameter is bound after
calling execute, which seems to be unsupported. Moving the call to
bindColumn() before execute() fixes the test.

I've also tried to fix it, but no matter how hard I tried I couldn't
find a suitable solution that also kept backwards compatibility (i.e.
returning the large object OID as int if the parameter is not explicitly
bound as PDO::PARAM_LOB).

Therefore I think that the best solution would be to document such
behaviour and fix the test accordingly.

Note: it doesn't look like a duplicate of #40913, as mysql and sqlite
do not seem to have custom code to retrieve data as a stream.

Reproduce code:
---
$stmt = $db->prepare("SELECT * from test");
$stmt->bindColumn('bloboid', $lob, PDO::PARAM_LOB);
$stmt->execute();
$stmt->fetch(PDO::FETCH_ASSOC);
var_dump(is_resource($lob));

$stmt = $db->prepare("SELECT * from test");
$stmt->execute();
$stmt->bindColumn('bloboid', $lob, PDO::PARAM_LOB);
$stmt->fetch(PDO::FETCH_ASSOC);
var_dump(is_resource($lob));


Expected result:

bool(true)
bool(true)

Actual result:
--
bool(true)
bool(false)





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

#47311 [Opn]: PDO::PARAM_LOB columns need to be bound before execute() on PgSQL

[matteo at beccati dot com]

 ID:   47311
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Any
 PHP Version:  5.3.0beta1
 New Comment:

Patch is available here:

http://www.beccati.com/misc/pdo_pgsql_bug47311_php_5.3.patch

It fixes another small problem in the phpt and adds one more test case.
Plus adds a note to the code.


Previous Comments:


[2009-02-04 18:29:09] matteo at beccati dot com

Description:

I was trying to investigate a test failure in the pdo_pgsql extension,
namely the large_objects.phpt.

The failure is caused by the fact that the LOB parameter is bound after
calling execute, which seems to be unsupported. Moving the call to
bindColumn() before execute() fixes the test.

I've also tried to fix it, but no matter how hard I tried I couldn't
find a suitable solution that also kept backwards compatibility (i.e.
returning the large object OID as int if the parameter is not explicitly
bound as PDO::PARAM_LOB).

Therefore I think that the best solution would be to document such
behaviour and fix the test accordingly.

Note: it doesn't look like a duplicate of #40913, as mysql and sqlite
do not seem to have custom code to retrieve data as a stream.

Reproduce code:
---
$stmt = $db->prepare("SELECT * from test");
$stmt->bindColumn('bloboid', $lob, PDO::PARAM_LOB);
$stmt->execute();
$stmt->fetch(PDO::FETCH_ASSOC);
var_dump(is_resource($lob));

$stmt = $db->prepare("SELECT * from test");
$stmt->execute();
$stmt->bindColumn('bloboid', $lob, PDO::PARAM_LOB);
$stmt->fetch(PDO::FETCH_ASSOC);
var_dump(is_resource($lob));


Expected result:

bool(true)
bool(true)

Actual result:
--
bool(true)
bool(false)





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

#47311 [NEW]: PDO::PARAM_LOB columns need to be bound before execute() on PgSQL

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: Any
PHP version:  5.3.0beta1
PHP Bug Type: PDO related
Bug description:  PDO::PARAM_LOB columns need to be bound before execute() on 
PgSQL

Description:

I was trying to investigate a test failure in the pdo_pgsql extension,
namely the large_objects.phpt.

The failure is caused by the fact that the LOB parameter is bound after
calling execute, which seems to be unsupported. Moving the call to
bindColumn() before execute() fixes the test.

I've also tried to fix it, but no matter how hard I tried I couldn't find
a suitable solution that also kept backwards compatibility (i.e. returning
the large object OID as int if the parameter is not explicitly bound as
PDO::PARAM_LOB).

Therefore I think that the best solution would be to document such
behaviour and fix the test accordingly.

Note: it doesn't look like a duplicate of #40913, as mysql and sqlite do
not seem to have custom code to retrieve data as a stream.

Reproduce code:
---
$stmt = $db->prepare("SELECT * from test");
$stmt->bindColumn('bloboid', $lob, PDO::PARAM_LOB);
$stmt->execute();
$stmt->fetch(PDO::FETCH_ASSOC);
var_dump(is_resource($lob));

$stmt = $db->prepare("SELECT * from test");
$stmt->execute();
$stmt->bindColumn('bloboid', $lob, PDO::PARAM_LOB);
$stmt->fetch(PDO::FETCH_ASSOC);
var_dump(is_resource($lob));


Expected result:

bool(true)
bool(true)

Actual result:
--
bool(true)
bool(false)

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

#47297 [Opn]: pdo_033.phpt fails on PgSQL

[matteo at beccati dot com]

 ID:   47297
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Any
 PHP Version:  5.3.0beta1
 New Comment:

Here's a patch:
http://www.beccati.com/misc/pdo_pgsql_bug47297_php_5.3.patch


Previous Comments:


[2009-02-04 07:24:58] matteo at beccati dot com

Description:

The common test pdo_033.phpt fails on PgSQL because it's using a
char(100) field, which will be right padded with spaces once retrieved,
even though the actual output doesn't show that.

Using a char field with the correct size fixes the issue, while surely
remaining compatible with other database type.

Reproduce code:
---
php -n run-tests.php --show-diff ext/pdo_pgsql/tests/common.phpt

Expected result:

PASS Postgres PDO Common: PDO::quote()
[ext/pdo_pgsql/tests/pdo_033.phpt]


Actual result:
--
TEST 49/55 [ext/pdo/tests/pdo_033.phpt]
DIFF
005+ [t] => 
!"#$%&'()*+,-./0123456789:;<=>?...@abcdefghijklmnopqrstuvwxyz[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

005- [t] => 
!"#$%&'()*+,-./0123456789:;<=>?...@abcdefghijklmnopqrstuvwxyz[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

DONE
FAIL Postgres PDO Common: PDO::quote()
[ext/pdo_pgsql/tests/pdo_033.phpt]






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

#47297 [NEW]: pdo_033.phpt fails on PgSQL

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: Any
PHP version:  5.3.0beta1
PHP Bug Type: PDO related
Bug description:  pdo_033.phpt fails on PgSQL

Description:

The common test pdo_033.phpt fails on PgSQL because it's using a char(100)
field, which will be right padded with spaces once retrieved, even though
the actual output doesn't show that.

Using a char field with the correct size fixes the issue, while surely
remaining compatible with other database type.

Reproduce code:
---
php -n run-tests.php --show-diff ext/pdo_pgsql/tests/common.phpt

Expected result:

PASS Postgres PDO Common: PDO::quote() [ext/pdo_pgsql/tests/pdo_033.phpt]


Actual result:
--
TEST 49/55 [ext/pdo/tests/pdo_033.phpt]
DIFF
005+ [t] => 
!"#$%&'()*+,-./0123456789:;<=>?...@abcdefghijklmnopqrstuvwxyz[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

005- [t] => 
!"#$%&'()*+,-./0123456789:;<=>?...@abcdefghijklmnopqrstuvwxyz[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

DONE
FAIL Postgres PDO Common: PDO::quote() [ext/pdo_pgsql/tests/pdo_033.phpt]


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

#44861 [Com]: scrollable cursor don't work with pgsql

[matteo at beccati dot com]

 ID:   44861
 Comment by:   matteo at beccati dot com
 Reported By:  php at benjaminschulz dot com
 Status:   Verified
 Bug Type: PDO related
 Operating System: osx
 PHP Version:  5.3CVS-2008-04-29 (CVS)
 New Comment:

Here's the patch, including a phpt file:

http://www.beccati.com/misc/pdo_pgsql_bug44861_php_5.3.patch

A bit of explanations... I've changed the ordering when executing the
query so that if a cursor is needed, it's created before any preparation
happens.

The cursor is now declared as SCROLL-able and WITH HOLD to ensure it
can be used even outside transactions. I was previously trying to avoid
WITH HOLD and enforce requirement for a transaction, but things were
going very bad when the destructor was called after the transaction was
closed, which is a common situation when calling commit() without
previusly unsetting the statement variable.

One thing I'm not really sure about is the behaviour of ORI_ABS and
ORI_REL: ORI_ABS will work for offsets >= 1, while ORI_REL can work
with negative numbers as well. I'm sorry, but it's impossible for me to
guess how they should work just by reading the pdo_oci code or the
Oracle documentation of OCIStmtFetch2.


Previous Comments:


[2009-01-15 22:30:21] andrew at rook dot ca

Same problem.
PHP 5.2.8 on Fedora 8 (2.6.21.7-5.fc8xen) && PostgreSQL 8.2.11



[2008-12-12 11:36:07] denis at edistar dot com

Same problem also in PHP 5.2.6.

I think this is a very serious bug.



[2008-04-29 16:13:24] php at benjaminschulz dot com

Description:

I don't see how to use scrollable cursors with pdo_pgsql

Reproduce code:
---
$db = new Pdo("pgsql:...");
$db->setAttribute(Pdo::ATTR_ERRMODE, Pdo::ERRMODE_EXCEPTION);
$res = $db->prepare("SELECT 'row1' UNION SELECT 'row2' UNION SELECT
'row3' UNION SELECT 'row4'", array(PDO::ATTR_CURSOR =>
PDO::CURSOR_SCROLL));
$res->execute();
var_dump($res->fetch());
// $res->fetch(Pdo::FETCH_NUM, PDO::FETCH_ORI_ABS, 2) won't throw an
exception but return false

Expected result:

array('row1')

Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[34000]: Invalid cursor name: 7 ERROR: cursor
"pdo_pgsql_cursor_00d78a0c" does not exist' in ...





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

#42614 [Com]: (feature request) pg_get_notify in pdo_pgsql

[matteo at beccati dot com]

 ID:  42614
 Comment by:  matteo at beccati dot com
 Reported By: b...@php.net
 Status:  Open
 Bug Type:Feature/Change Request
 PHP Version: 5.2.4
 New Comment:

Following a post on php-dev and a catch-up with Lukas K. Smith, here's
an updated patch for PHP 5.3 HEAD that mimics the behaviour of
David/Wez's patch, that unfortunately was lost:

http://www.beccati.com/misc/pdo_pgsql_getnotify_php5_3.patch

The patch adds two methods:

int PDO::pgsqlGetPid()

Returns the PID of the connected backend

mixed PDO::pgsqlGetNotify( [ $result_type = PDO::FETCH_USE_DEFAULT [,
[int $ms_timeout = 0 ]])

Returns an array or false, just like pg_get_notify()

$result_type can either be:
  - PDO::FETCH_USE_DEFAULT
  - PDO::FETCH_BOTH
  - PDO::FETCH_NUM
  - PDO::FETCH_ASSOC

$ms_timeout is the timeout in milliseconds that the function will wait
before returning if no NOTIFY was received

Thanks go to:
Lukas Kahwe Smith for the support
Wez Fufrlong for the feedback and suggestions
David Begley who is the author of a similar patch


Previous Comments:


[2008-02-02 08:25:04] d dot begley at uws dot edu dot au

Support for PostgreSQL's LISTEN/NOTIFY in PDO has been written since
PHP 5.1, it just needs to be integrated with the latest code by one of
the core developers - see:

http://netevil.org/blog/2006/oct/background-batch-workflow-processing-with-pdo-pgsql



[2007-09-10 17:12:04] b...@php.net

Description:

Hi,
sorry that i post this as a bug, there is no other way to specify a
feature request per extension.
Support for PGnotifies() would be great in PDO. ext/pgsql has it
already with pg_get_notify().

Docs are at
http://www.postgresql.org/docs/8.2/interactive/libpq-notify.html and a
sample at
http://www.postgresql.org/docs/8.2/interactive/libpq-example.html#LIBPQ-EXAMPLE-2






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

#43387 [Fbk->Opn]: Segmentation fault during shutdown in _zend_mm_free_int()

[matteo at beccati dot com]

 ID:   43387
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: GNU/Linux 2.6.18 x86_64
 PHP Version:  5.2.5
 New Comment:

We'll try to reproduce it again with either 5.2.4 or 5.2.5 and see if
the snapshot fixes it.

Thanks for the feedback, we really appreciate it!


Previous Comments:


[2007-12-04 12:50:54] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi





[2007-12-03 10:54:13] [EMAIL PROTECTED]

Note for developers: See bug #43476 (crash in same place)



[2007-11-30 06:24:01] [EMAIL PROTECTED]

Note for developers: See bug #43459 (crash in same place)




[2007-11-25 17:55:44] matteo at beccati dot com

If I was able to understand what is causing the issue, I would happily
create a short reproduce script. Unfortunately the bug only shows
randomly during shutdown after a very complex script. The best I could
do is to give you access to my machine in case the crash happens again,
but I'm afraid I can't do much more right now.



[2007-11-25 17:31:26] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





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/43387

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

#43387 [Fbk->Opn]: Segmentation fault during shutdown

[matteo at beccati dot com]

 ID:   43387
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: GNU/Linux 2.6.18 x86_64
 PHP Version:  5.2.5
 New Comment:

If I was able to understand what is causing the issue, I would happily
create a short reproduce script. Unfortunately the bug only shows
randomly during shutdown after a very complex script. The best I could
do is to give you access to my machine in case the crash happens again,
but I'm afraid I can't do much more right now.


Previous Comments:


[2007-11-25 17:31:26] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2007-11-24 15:20:57] matteo at beccati dot com

FreeBSD, PHP 5.2.4:

./configure  --with-apxs2=/usr/local/sbin/apxs --with-mysql=/usr/local
--with-pgsql=/usr/local/pgsql --with-zlib --with-iconv=/usr/local
--enable-bcmath --enable-ftp --enable-mbstring --with-mcrypt=/usr/local
--with-mhash=/usr/local --with-curl=/usr/local --with-xml --with-xmlrpc
--with-gettext --with-gd --enable-gd-native-ttf --with-png
--with-png-dir=/usr/local --with-jpeg --with-jpeg-dir=/usr/local
--with-freetype-dir=/usr/local --with-ttf=/usr/local --enable-pcntl
--enable-sockets --enable-sigchild --enable-shmop --enable-sysvmsg
--enable-sysvsem --enable-sysvshm

No extensions loaded in php.ini. Nothing has changed, but I'm unable to
reproduce it ATM.

Linux, PHP 5.2.5:

./configure  --prefix=/usr/local/php-5.2.5
--with-apxs2=/usr/local/apache2/bin/apxs
--with-mysql=/usr/local/mysql-5.0 --with-pgsql=/usr/local/pgsql-8.2
--enable-mbstring --with-gd --enable-gd-native-ttf --with-freetype-dir
--with-jpeg-dir --with-png-dir --with-curl --with-openssl --with-zlib
--enable-pcntl

No extensions loaded in php.ini. Another CriuseControl build failed for
that very reason the last night.



[2007-11-24 12:14:54] [EMAIL PROTECTED]

What configure line was used when building PHP? Are you loading some
extensions in php.ini? Did you disable all zend extensions (like caches,
optimizers..etc.) ?



[2007-11-23 10:57:32] matteo at beccati dot com

Description:

PHP 5.2.5 sometimes crashes with a segmentation fault after running a
specific unit test suite. Unfortunately the issue isn't easily
replicable and seems to happen randomly.

We have CruiseControl running dozens of builds with different PHP
versions back to 4.3 and it just happens that sometimes one of the
builds using PHP 5.2.5 fails on a particular test. 
So far it happened when running tests with PostgreSQL 8.0, 8.1 and
MySQL 5.0.

I've just tried to replicate the issue on another server and I finally
did it. It crashes also on FreeBSD 6.2/amd64 using PHP 5.2.4 and MySQL
5.1. Surprisingly a similarily compiled 5.2.5 doesn't crash on this
server.

Reproduce code:
---
svn export -r12748 https://svn.openads.org/openads/trunk OA-trunk
cd OA-trunk
cp etc/test.conf var/

; edit var/test.conf.php and set the db parameters

cd tests

php run.php --type=unit --level=file --layer=dal
--folder=lib/OA/Dal/Delivery --file=DeliveryDB.dal.test.php
--format=text --host=test


Expected result:

UNIT: Data Abstraction Layer (DB):
lib/OA/Dal/Delivery/DeliveryDB.dal.test.php
OK
Test cases run: 1/1, Passes: 302, Failures: 0, Exceptions: 0


Actual result:
--
UNIT: Data Abstraction Layer (DB):
lib/OA/Dal/Delivery/DeliveryDB.dal.test.php
OK
Test cases run: 1/1, Passes: 302, Failures: 0, Exceptions: 0
Segmentation fault: 11 (core dumped)

gdb output on Linux / PHP 5.2.5
===
GNU gdb Red Hat Linux (6.5-16.el5rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/libthread_db.so.1".

Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading sym

#43387 [Fbk->Opn]: Segmentation fault during shutdown

[matteo at beccati dot com]

 ID:   43387
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: GNU/Linux 2.6.18 x86_64
 PHP Version:  5.2.5
 New Comment:

FreeBSD, PHP 5.2.4:

./configure  --with-apxs2=/usr/local/sbin/apxs --with-mysql=/usr/local
--with-pgsql=/usr/local/pgsql --with-zlib --with-iconv=/usr/local
--enable-bcmath --enable-ftp --enable-mbstring --with-mcrypt=/usr/local
--with-mhash=/usr/local --with-curl=/usr/local --with-xml --with-xmlrpc
--with-gettext --with-gd --enable-gd-native-ttf --with-png
--with-png-dir=/usr/local --with-jpeg --with-jpeg-dir=/usr/local
--with-freetype-dir=/usr/local --with-ttf=/usr/local --enable-pcntl
--enable-sockets --enable-sigchild --enable-shmop --enable-sysvmsg
--enable-sysvsem --enable-sysvshm

No extensions loaded in php.ini. Nothing has changed, but I'm unable to
reproduce it ATM.

Linux, PHP 5.2.5:

./configure  --prefix=/usr/local/php-5.2.5
--with-apxs2=/usr/local/apache2/bin/apxs
--with-mysql=/usr/local/mysql-5.0 --with-pgsql=/usr/local/pgsql-8.2
--enable-mbstring --with-gd --enable-gd-native-ttf --with-freetype-dir
--with-jpeg-dir --with-png-dir --with-curl --with-openssl --with-zlib
--enable-pcntl

No extensions loaded in php.ini. Another CriuseControl build failed for
that very reason the last night.


Previous Comments:


[2007-11-24 12:14:54] [EMAIL PROTECTED]

What configure line was used when building PHP? Are you loading some
extensions in php.ini? Did you disable all zend extensions (like caches,
optimizers..etc.) ?



[2007-11-23 10:57:32] matteo at beccati dot com

Description:

PHP 5.2.5 sometimes crashes with a segmentation fault after running a
specific unit test suite. Unfortunately the issue isn't easily
replicable and seems to happen randomly.

We have CruiseControl running dozens of builds with different PHP
versions back to 4.3 and it just happens that sometimes one of the
builds using PHP 5.2.5 fails on a particular test. 
So far it happened when running tests with PostgreSQL 8.0, 8.1 and
MySQL 5.0.

I've just tried to replicate the issue on another server and I finally
did it. It crashes also on FreeBSD 6.2/amd64 using PHP 5.2.4 and MySQL
5.1. Surprisingly a similarily compiled 5.2.5 doesn't crash on this
server.

Reproduce code:
---
svn export -r12748 https://svn.openads.org/openads/trunk OA-trunk
cd OA-trunk
cp etc/test.conf var/

; edit var/test.conf.php and set the db parameters

cd tests

php run.php --type=unit --level=file --layer=dal
--folder=lib/OA/Dal/Delivery --file=DeliveryDB.dal.test.php
--format=text --host=test


Expected result:

UNIT: Data Abstraction Layer (DB):
lib/OA/Dal/Delivery/DeliveryDB.dal.test.php
OK
Test cases run: 1/1, Passes: 302, Failures: 0, Exceptions: 0


Actual result:
--
UNIT: Data Abstraction Layer (DB):
lib/OA/Dal/Delivery/DeliveryDB.dal.test.php
OK
Test cases run: 1/1, Passes: 302, Failures: 0, Exceptions: 0
Segmentation fault: 11 (core dumped)

gdb output on Linux / PHP 5.2.5
===
GNU gdb Red Hat Linux (6.5-16.el5rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/libthread_db.so.1".

Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /usr/local/pgsql-8.2.5/lib/libpq.so.5...done.
Loaded symbols for /usr/local/pgsql-8.2.5/lib/libpq.so.5
Reading symbols from /lib64/librt.so.1...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from
/usr/local/mysql-5.0.45-linux-x86_64-glibc23/lib/libmysqlclient.so.15...done.
Loaded symbols for /usr/local/mysql-5.0/lib/libmysqlclient.so.15
Reading symbols from /usr/lib64/libfreetype.so.6...done.
Loaded symbols for /usr/lib64/libfreetype.so.6
Reading symbols from /usr/lib64/libpng12.so.0...done.
Loaded symbols for /usr/lib64/libpng12.so.0
Reading symbols from /usr/lib64/libjpeg.so.62...done.
Loaded symbols for /usr/lib64/libjpeg.so.62
Reading symbols from /usr/lib64/libcurl.so.3...done.
Loaded symbols for /usr/lib64/libcurl.so.3
Reading symbols from /lib64/libresolv.so.2...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/libm.so.6...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libnsl.so.1..

#43387 [NEW]: Segmentation fault during shutdown

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: GNU/Linux 2.6.18 x86_64
PHP version:  5.2.5
PHP Bug Type: Reproducible crash
Bug description:  Segmentation fault during shutdown

Description:

PHP 5.2.5 sometimes crashes with a segmentation fault after running a
specific unit test suite. Unfortunately the issue isn't easily replicable
and seems to happen randomly.

We have CruiseControl running dozens of builds with different PHP versions
back to 4.3 and it just happens that sometimes one of the builds using PHP
5.2.5 fails on a particular test. 
So far it happened when running tests with PostgreSQL 8.0, 8.1 and MySQL
5.0.

I've just tried to replicate the issue on another server and I finally did
it. It crashes also on FreeBSD 6.2/amd64 using PHP 5.2.4 and MySQL 5.1.
Surprisingly a similarily compiled 5.2.5 doesn't crash on this server.

Reproduce code:
---
svn export -r12748 https://svn.openads.org/openads/trunk OA-trunk
cd OA-trunk
cp etc/test.conf var/

; edit var/test.conf.php and set the db parameters

cd tests

php run.php --type=unit --level=file --layer=dal
--folder=lib/OA/Dal/Delivery --file=DeliveryDB.dal.test.php --format=text
--host=test


Expected result:

UNIT: Data Abstraction Layer (DB):
lib/OA/Dal/Delivery/DeliveryDB.dal.test.php
OK
Test cases run: 1/1, Passes: 302, Failures: 0, Exceptions: 0


Actual result:
--
UNIT: Data Abstraction Layer (DB):
lib/OA/Dal/Delivery/DeliveryDB.dal.test.php
OK
Test cases run: 1/1, Passes: 302, Failures: 0, Exceptions: 0
Segmentation fault: 11 (core dumped)

gdb output on Linux / PHP 5.2.5
===
GNU gdb Red Hat Linux (6.5-16.el5rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/libthread_db.so.1".

Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /usr/local/pgsql-8.2.5/lib/libpq.so.5...done.
Loaded symbols for /usr/local/pgsql-8.2.5/lib/libpq.so.5
Reading symbols from /lib64/librt.so.1...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from
/usr/local/mysql-5.0.45-linux-x86_64-glibc23/lib/libmysqlclient.so.15...done.
Loaded symbols for /usr/local/mysql-5.0/lib/libmysqlclient.so.15
Reading symbols from /usr/lib64/libfreetype.so.6...done.
Loaded symbols for /usr/lib64/libfreetype.so.6
Reading symbols from /usr/lib64/libpng12.so.0...done.
Loaded symbols for /usr/lib64/libpng12.so.0
Reading symbols from /usr/lib64/libjpeg.so.62...done.
Loaded symbols for /usr/lib64/libjpeg.so.62
Reading symbols from /usr/lib64/libcurl.so.3...done.
Loaded symbols for /usr/lib64/libcurl.so.3
Reading symbols from /lib64/libresolv.so.2...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/libm.so.6...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libnsl.so.1...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /usr/lib64/libxml2.so.2...done.
Loaded symbols for /usr/lib64/libxml2.so.2
Reading symbols from /lib64/libssl.so.6...done.
Loaded symbols for /lib64/libssl.so.6
Reading symbols from /lib64/libcrypto.so.6...done.
Loaded symbols for /lib64/libcrypto.so.6
Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
Reading symbols from /usr/lib64/libkrb5.so.3...done.
Loaded symbols for /usr/lib64/libkrb5.so.3
Reading symbols from /usr/lib64/libk5crypto.so.3...done.
Loaded symbols for /usr/lib64/libk5crypto.so.3
Reading symbols from /lib64/libcom_err.so.2...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /usr/lib64/libidn.so.11...done.
Loaded symbols for /usr/lib64/libidn.so.11
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libpthread.so.0...done.
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib64/libz.so.1...done.
Loaded symbols for /usr/lib64/libz.so.1
Reading symbols from /usr/lib64/libkrb5support.so.0...done.
Loaded symbols for /usr/lib64/libkrb5support.so.0
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
Core was generated by `/usr/local/php-5.2/bin/php run.php --type=unit
--level=file --layer=dal --folde'.
Program terminated with signal 11, Segmentation fault.
#0  0x0069f095 in _zend_mm_free_int (heap=0x129eb330,
p=0x13b898d

#40031 [NEW]: $_SERVER['HTTPS'] never empty on IIS

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: Windows 2003 Server
PHP version:  5.2.0
PHP Bug Type: IIS related
Bug description:  $_SERVER['HTTPS'] never empty on IIS

Description:

When using isapi with IIS6 the variable seems to be always set to either
"on" or "off", but the manual states that $_SERVER['HTTPS'] has a
non-empty value when SSL is enabled (true on Apache, but either wrong or
misleading) 

Feel free to mark this bug as a documentation problem: I don't know if
it's really a wrong behaviour of php-isapi.

Also replicated on IIS5.1/WinXP Pro

Reproduce code:
---
var_dump($_SERVER['HTTPS']);

Expected result:

NULL

Actual result:
--
string(3) "off"


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

#39819 [Opn]: Using $this not in object context can cause segfaults

[matteo at beccati dot com]

 ID:   39819
 User updated by:  matteo at beccati dot com
-Summary:  PHP always segfaults with --without-sqlite
 Reported By:  matteo at beccati dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: NetBSD
 PHP Version:  4.4.4
 New Comment:

Sorry, Firefox replaced the bug summary :(


Previous Comments:


[2006-12-13 16:21:22] matteo at beccati dot com

Description:

Using $this outside of an object context doesn't throw a fatal error
(it does on PHP 5.2.0). Subsequent static method calls throw warnings
or exit with SIGSEGV if a custom error handler is set.

The bug was also reproduced on Linux and on previous versions (4.4.3,
4.3.11).



Reproduce code:
---
http://beccati.com/php-this-bug.phps

Expected result:

Calling Foo::bar(): BAR
Setting $this->test = 1

Fatal error: Using $this when not in object context in /www/- on line
22


Actual result:
--
Calling Foo::bar(): BAR
Setting $this->test = 1
Calling Foo::bar():
Warning: Problem with method call - please report this bug in
/tmp/php-this-bug.phps on line 25
BAR
Setting a custom error handler
Calling Foo::bar(): Segmentation fault (core dumped)


-- Backtrace --

#0  0x081fa452 in zval_add_ref (p=0x846cb30)
at /root/compile/php-4.4.4/Zend/zend_variables.c:85
No locals.
#1  0x0820224c in zend_hash_copy (target=0x846ca24, source=0x846c124,
pCopyConstructor=0x81fa44a , tmp=0xbfbfcbcc, size=4)
at /root/compile/php-4.4.4/Zend/zend_hash.c:804
p = (Bucket *) 0x846c324
new_entry = (void *) 0x846cb30
#2  0x081fa5b1 in _zval_copy_ctor (zvalue=0x8469c64,
__zend_filename=0x8395ca0
"/root/compile/php-4.4.4/Zend/zend_builtin_functions.c",
__zend_lineno=246) at
/root/compile/php-4.4.4/Zend/zend_variables.c:125
tmp = (zval *) 0x82047fd
original_ht = (HashTable *) 0x846c124
tmp_ht = (HashTable *) 0x846ca24
tmp = (zval *) 0x846ca24
original_ht = (HashTable *) 0x846c124
tmp_ht = (HashTable *) 0x8c
#3  0x08204841 in zif_func_get_args (ht=0, return_value=0x8469ae4,
this_ptr=0x0, return_value_used=1)
at /root/compile/php-4.4.4/Zend/zend_builtin_functions.c:246
element = (zval *) 0x8469c64
p = (void **) 0x845d240
arg_count = 5
i = 4
#4  0x0820fd46 in execute (op_array=0x846c080)
at /root/compile/php-4.4.4/Zend/zend_execute.c:1675
original_return_value = (zval **) 0x846b21c
return_value_used = 1
execute_data = {opline = 0x846b204, function_state = {
function_symbol_table = 0x0, function = 0x83f3280, reserved =
{0x8200292,
  0x8, 0x4, 0x8395720}}, fbc = 0x0, ce = 0x0, object = {ptr =
0x0},
  Ts = 0xbfbfcc20, original_in_execution = 1 '\001', op_array =
0x846c080,
  prev_execute_data = 0xbfbfcf30}
#5  0x081f21bd in call_user_function_ex (function_table=0x83f0040,
object_pp=0x0, function_name=0x84699a4, retval_ptr_ptr=0xbfbfd010,
param_count=5, params=0x8469aa4, no_separation=1,
symbol_table=0x0)
at /root/compile/php-4.4.4/Zend/zend_execute_API.c:570
i = 5
original_return_value = (zval **) 0xbfbfd2bc
calling_symbol_table = (HashTable *) 0x846c124
original_function_state_ptr = 
original_op_array = (zend_op_array *) 0x84629a4
original_opline_ptr = 
orig_free_op1 = 0
orig_free_op2 = 0
orig_unary_op = 
orig_binary_op = 
function_name_copy = {value = {lval = 138844900,
dval = 2.765454338803e-313, str = {val = 0x8469ae4 "¤ÆF\b", len
= 13},
ht = 0x8469ae4, obj = {ce = 0x8469ae4, properties = 0xd}},
  type = 3 '\003', is_ref = 0 '\0', refcount = 1}
execute_data = {opline = 0x0, function_state = {
function_symbol_table = 0x40, function = 0x846c080, reserved = {
  0xbd6d7713, 0x40, 0x83d7554, 0x4}}, fbc = 0x0, ce = 0x0, object =
{
ptr = 0x0}, Ts = 0x0, original_in_execution = 36 '$', op_array =
0x0,
  prev_execute_data = 0xbfbfd240}
#6  0x081fbe2d in zend_error (type=2,
format=0x83968e0 "Problem with method call - please report this
bug")
at /root/compile/php-4.4.4/Zend/zend.c:846
args = 0xbfbfd038 "\001"
usr_copy = 0xbfbfd038 "\001"
params = (zval ***) 0x8469aa4
retval = (zval *) 0x0
z_error_type = (zval *) 0x8469924
z_error_message = (zval *) 0x84698e4
z_error_filename = (zval *) 0x8469964
z_error_lineno = (zval *) 0x8469a24
z_context = (zval *) 0x8469a64
error_filename = 0x8460f64 "/tmp/php-this-bug.phps"
error_lineno = 31
orig_user_error_handler = (zval *) 0x84699a4
#7  0x0820ff13 in execute (op_array=0x84629a4)
at /root/compile/php-4.4.4/Zend/zend_execute.c:1710
this_p

#39819 [NEW]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: NetBSD
PHP version:  4.4.4
PHP Bug Type: Reproducible crash
Bug description:  PHP always segfaults with --without-sqlite

Description:

Using $this outside of an object context doesn't throw a fatal error (it
does on PHP 5.2.0). Subsequent static method calls throw warnings or exit
with SIGSEGV if a custom error handler is set.

The bug was also reproduced on Linux and on previous versions (4.4.3,
4.3.11).



Reproduce code:
---
http://beccati.com/php-this-bug.phps

Expected result:

Calling Foo::bar(): BAR
Setting $this->test = 1

Fatal error: Using $this when not in object context in /www/- on line 22


Actual result:
--
Calling Foo::bar(): BAR
Setting $this->test = 1
Calling Foo::bar():
Warning: Problem with method call - please report this bug in
/tmp/php-this-bug.phps on line 25
BAR
Setting a custom error handler
Calling Foo::bar(): Segmentation fault (core dumped)


-- Backtrace --

#0  0x081fa452 in zval_add_ref (p=0x846cb30)
at /root/compile/php-4.4.4/Zend/zend_variables.c:85
No locals.
#1  0x0820224c in zend_hash_copy (target=0x846ca24, source=0x846c124,
pCopyConstructor=0x81fa44a , tmp=0xbfbfcbcc, size=4)
at /root/compile/php-4.4.4/Zend/zend_hash.c:804
p = (Bucket *) 0x846c324
new_entry = (void *) 0x846cb30
#2  0x081fa5b1 in _zval_copy_ctor (zvalue=0x8469c64,
__zend_filename=0x8395ca0
"/root/compile/php-4.4.4/Zend/zend_builtin_functions.c",
__zend_lineno=246) at /root/compile/php-4.4.4/Zend/zend_variables.c:125
tmp = (zval *) 0x82047fd
original_ht = (HashTable *) 0x846c124
tmp_ht = (HashTable *) 0x846ca24
tmp = (zval *) 0x846ca24
original_ht = (HashTable *) 0x846c124
tmp_ht = (HashTable *) 0x8c
#3  0x08204841 in zif_func_get_args (ht=0, return_value=0x8469ae4,
this_ptr=0x0, return_value_used=1)
at /root/compile/php-4.4.4/Zend/zend_builtin_functions.c:246
element = (zval *) 0x8469c64
p = (void **) 0x845d240
arg_count = 5
i = 4
#4  0x0820fd46 in execute (op_array=0x846c080)
at /root/compile/php-4.4.4/Zend/zend_execute.c:1675
original_return_value = (zval **) 0x846b21c
return_value_used = 1
execute_data = {opline = 0x846b204, function_state = {
function_symbol_table = 0x0, function = 0x83f3280, reserved =
{0x8200292,
  0x8, 0x4, 0x8395720}}, fbc = 0x0, ce = 0x0, object = {ptr = 0x0},
  Ts = 0xbfbfcc20, original_in_execution = 1 '\001', op_array =
0x846c080,
  prev_execute_data = 0xbfbfcf30}
#5  0x081f21bd in call_user_function_ex (function_table=0x83f0040,
object_pp=0x0, function_name=0x84699a4, retval_ptr_ptr=0xbfbfd010,
param_count=5, params=0x8469aa4, no_separation=1, symbol_table=0x0)
at /root/compile/php-4.4.4/Zend/zend_execute_API.c:570
i = 5
original_return_value = (zval **) 0xbfbfd2bc
calling_symbol_table = (HashTable *) 0x846c124
original_function_state_ptr = 
original_op_array = (zend_op_array *) 0x84629a4
original_opline_ptr = 
orig_free_op1 = 0
orig_free_op2 = 0
orig_unary_op = 
orig_binary_op = 
function_name_copy = {value = {lval = 138844900,
dval = 2.765454338803e-313, str = {val = 0x8469ae4 "¤ÆF\b", len =
13},
ht = 0x8469ae4, obj = {ce = 0x8469ae4, properties = 0xd}},
  type = 3 '\003', is_ref = 0 '\0', refcount = 1}
execute_data = {opline = 0x0, function_state = {
function_symbol_table = 0x40, function = 0x846c080, reserved = {
  0xbd6d7713, 0x40, 0x83d7554, 0x4}}, fbc = 0x0, ce = 0x0, object = {
ptr = 0x0}, Ts = 0x0, original_in_execution = 36 '$', op_array = 0x0,
  prev_execute_data = 0xbfbfd240}
#6  0x081fbe2d in zend_error (type=2,
format=0x83968e0 "Problem with method call - please report this bug")
at /root/compile/php-4.4.4/Zend/zend.c:846
args = 0xbfbfd038 "\001"
usr_copy = 0xbfbfd038 "\001"
params = (zval ***) 0x8469aa4
retval = (zval *) 0x0
z_error_type = (zval *) 0x8469924
z_error_message = (zval *) 0x84698e4
z_error_filename = (zval *) 0x8469964
z_error_lineno = (zval *) 0x8469a24
z_context = (zval *) 0x8469a64
error_filename = 0x8460f64 "/tmp/php-this-bug.phps"
error_lineno = 31
orig_user_error_handler = (zval *) 0x84699a4
#7  0x0820ff13 in execute (op_array=0x84629a4)
at /root/compile/php-4.4.4/Zend/zend_execute.c:1710
this_ptr = (zval **) 0x846c330
null_ptr = (zval *) 0x0
calling_symbol_table = (HashTable *) 0x83ee7cc
original_return_value = (zval **) 0x846c1b0
return_value_used = 0
execute_data = {opline = 0x8468420, function_state = {
function_symbol_table = 0x846c124, function = 0x8462e24, rese

#39663 [NEW]: Memory leak in pg_get_notify

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: *
PHP version:  5.2.0
PHP Bug Type: PostgreSQL related
Bug description:  Memory leak in pg_get_notify

Description:

While toying with the pgsql extesion I found that the  pgsql_notify struct
is not freed as pointed out in the PostgreSQL documentation: "After
processing a PGnotify object returned by PQnotifies, be sure to free it
with PQfreemem." (see:
http://www.postgresql.org/docs/8.1/interactive/libpq-notify.html ). This
could lead to memory leaks as far as I can see.

Reproduce code:
---
Here is the patch:

--- ext/pgsql/pgsql.c   2006-10-06 23:45:10.0 +0200
+++ ext/pgsql/pgsql_new.c   2006-11-28 18:21:40.0 +0100
@@ -4347,6 +4347,8 @@
add_assoc_string(return_value, "message",
pgsql_notify->relname, 1);
add_assoc_long(return_value, "pid",
pgsql_notify->be_pid);
}
+
+   PQfreemem(pgsql_notify);
 }
 /* }}} */


BTW, pg_*_bytea functions should use PQfreemem too, even if it is simply a
wrapper.


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

#36846 [NEW]: pdf_setcolor() claims `float c4' (7th parameter) when in RGB mode is not needed

[matteo dot rinaudo at gmail dot com]

From: matteo dot rinaudo at gmail dot com
Operating system: Fedora 1-PHP compil.from sources
PHP version:  4.4.2
PHP Bug Type: PDF related
Bug description:  pdf_setcolor() claims `float c4' (7th parameter) when in RGB 
mode is not needed

Description:

We know that `pdf_setcolor()' currently accepts 7 parameters:

bool pdf_setcolor ( resource p, string fstype, string colorspace, float
c1, float c2, float c3, float c4 )

If I pass 'rgb' as colorspace (3rd parameter), the function asks for
`float c4' (7th parameter) which is not needed.
It seems that this bug reappeared *after* php-4.3.11.

Reproduce code:
---
pdf_setcolor($pdf, 'both', 'rgb', 0.7, 0.7, 0.7);

Expected result:

The code above does not work.

This code works:

pdf_setcolor($pdf, 'both', 'rgb', 0.7, 0.7, 0.7, 0.7);


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

#35711 [Csd->Opn]: [PATCH] ISO-8859 charset not correctly detected

[matteo at beccati dot com]

 ID:   35711
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Closed
+Status:   Open
 Bug Type: mbstring related
 Operating System: Debian GNU/Linux
 PHP Version:  5.1-dev
 Assigned To:  hirokawa
 New Comment:

I've made a patch which adds an mbstring.strict_detection php.ini flag
that specifies the default behaviour (defaults to off). I just started
taking a look to PHP internals so I could have made mistakes; make test
passes the mbstring related checks, I'll do more tests later.

http://beccati.com/download/mbstring-patch-20051224.txt


Previous Comments:


[2005-12-24 12:30:08] matteo at beccati dot com

These are great news and I'm really thankful for your help. Now
mb_detect_encoding is correctly working when the strict flag is set,
but...

- There's no way to set the strict flag in mb_convert_encoding; however
one could use mb_detect_encoding with the strict flag as source
charset.

- There's no way to set the strict flag for http_input translation,
which indeed would be much more useful (that's how I found the problem
described here).



[2005-12-24 02:23:06] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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.

The character-end detection was introduced in the strict mode
(mb_detect_encoding ($s,$list,TRUE)).
Please try the strict mode.







[2005-12-24 01:03:21] [EMAIL PROTECTED]

Have you ever tried the strict mode (default:FALSE) ?

string mb_detect_encoding ( string str [, mixed encoding_list [, bool
strict]] )


----

[2005-12-20 17:10:56] matteo at beccati dot com

Of course, I agree that 0xe8 is a valid if taken as part of a multibyte
character, but I don't think it could be considered valid it the next
bytes are missing (because the string ends prematurely). The iconv
extension raises notices when it finds illegal or incomplete multibyte
characters, I don't see why mbstring should accept as a valid UTF-8 a
string which indeed isn't.

The same should apply to other multibyte encodings.



[2005-12-20 15:44:31] [EMAIL PROTECTED]

Please note that encoding detection is not always perfect.
Especially, when the string is too short, the wrong detection might be
caused.
In your case, it is not a bug, but it is the specification.
UTF-8 is a variable length multibyte encoding format,
the length of a character in UTF-8 is from one to six.
Please look at ext/mbstring/libmbfl/filter/mbfilter_utf8.c:about 249L.
0xe8 is a valid byte sequence as the 1st character of 3 byte code.
We cannot detect 0xe8 is ISO-8859-1 or UTF-8,
because this byte is valid in both encodings.
In this case, the response will be choose 
from the order defined by mb_detect_order().
I suggest to use the sufficient length of string
for the reliable encoding detection.













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/35711

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

#35711 [Csd]: [PATCH] ISO-8859 charset not correctly detected

[matteo at beccati dot com]

 ID:   35711
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Closed
 Bug Type: mbstring related
 Operating System: Debian GNU/Linux
-PHP Version:  5.1.1
+PHP Version:  5.1-dev
 Assigned To:  hirokawa
 New Comment:

These are great news and I'm really thankful for your help. Now
mb_detect_encoding is correctly working when the strict flag is set,
but...

- There's no way to set the strict flag in mb_convert_encoding; however
one could use mb_detect_encoding with the strict flag as source
charset.

- There's no way to set the strict flag for http_input translation,
which indeed would be much more useful (that's how I found the problem
described here).


Previous Comments:


[2005-12-24 02:23:06] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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.

The character-end detection was introduced in the strict mode
(mb_detect_encoding ($s,$list,TRUE)).
Please try the strict mode.







[2005-12-24 01:03:21] [EMAIL PROTECTED]

Have you ever tried the strict mode (default:FALSE) ?

string mb_detect_encoding ( string str [, mixed encoding_list [, bool
strict]] )




[2005-12-20 17:10:56] matteo at beccati dot com

Of course, I agree that 0xe8 is a valid if taken as part of a multibyte
character, but I don't think it could be considered valid it the next
bytes are missing (because the string ends prematurely). The iconv
extension raises notices when it finds illegal or incomplete multibyte
characters, I don't see why mbstring should accept as a valid UTF-8 a
string which indeed isn't.

The same should apply to other multibyte encodings.



[2005-12-20 15:44:31] [EMAIL PROTECTED]

Please note that encoding detection is not always perfect.
Especially, when the string is too short, the wrong detection might be
caused.
In your case, it is not a bug, but it is the specification.
UTF-8 is a variable length multibyte encoding format,
the length of a character in UTF-8 is from one to six.
Please look at ext/mbstring/libmbfl/filter/mbfilter_utf8.c:about 249L.
0xe8 is a valid byte sequence as the 1st character of 3 byte code.
We cannot detect 0xe8 is ISO-8859-1 or UTF-8,
because this byte is valid in both encodings.
In this case, the response will be choose 
from the order defined by mb_detect_order().
I suggest to use the sufficient length of string
for the reliable encoding detection.













[2005-12-19 09:03:36] [EMAIL PROTECTED]

Rui, can you check this out please?



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/35711

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

#35711 [WFx]: [PATCH] ISO-8859 charset not correctly detected

[matteo at beccati dot com]

 ID:   35711
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Wont fix
 Bug Type: mbstring related
 Operating System: Debian GNU/Linux
 PHP Version:  5.1.1
 Assigned To:  hirokawa
 New Comment:

Of course, I agree that 0xe8 is a valid if taken as part of a multibyte
character, but I don't think it could be considered valid it the next
bytes are missing (because the string ends prematurely). The iconv
extension raises notices when it finds illegal or incomplete multibyte
characters, I don't see why mbstring should accept as a valid UTF-8 a
string which indeed isn't.

The same should apply to other multibyte encodings.


Previous Comments:


[2005-12-20 15:44:31] [EMAIL PROTECTED]

Please note that encoding detection is not always perfect.
Especially, when the string is too short, the wrong detection might be
caused.
In your case, it is not a bug, but it is the specification.
UTF-8 is a variable length multibyte encoding format,
the length of a character in UTF-8 is from one to six.
Please look at ext/mbstring/libmbfl/filter/mbfilter_utf8.c:about 249L.
0xe8 is a valid byte sequence as the 1st character of 3 byte code.
We cannot detect 0xe8 is ISO-8859-1 or UTF-8,
because this byte is valid in both encodings.
In this case, the response will be choose 
from the order defined by mb_detect_order().
I suggest to use the sufficient length of string
for the reliable encoding detection.













[2005-12-19 09:03:36] [EMAIL PROTECTED]

Rui, can you check this out please?



[2005-12-19 09:00:50] matteo at beccati dot com

Oops, I just realized that I forgot the -u flag :)

Here is the downlaodable patch:

http://beccati.com/download/mbstring-patch-20051219.txt



[2005-12-19 08:48:47] [EMAIL PROTECTED]

Please provide any patches in unified diff format. (like the first
one). And downloadable somewhere.



[2005-12-16 23:50:13] matteo at beccati dot com

I've made a patch which seems to fix the issue. It basicly checks
filter status during judgement. Status seems to be != 0 only when it is
matching a multibyte character. I added anyway a fallback to the old
judgement routine, just in case no matching encoding is found.

Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 mbfilter.c
--- ext/mbstring/libmbfl/mbfl/mbfilter.c5 Nov 2005 04:49:57
-  1.7.2.1
+++ ext/mbstring/libmbfl/mbfl/mbfilter.c16 Dec 2005 22:46:26
-
@@ -575,12 +575,22 @@

for (i = 0; i < num; i++) {
filter = &flist[i];
-   if (!filter->flag) {
+   if (!filter->flag && !filter->status) {
encoding = filter->encoding;
break;
}
}

+   if (!encoding) {
+   for (i = 0; i < num; i++) {
+   filter = &flist[i];
+   if (!filter->flag) {
+   encoding = filter->encoding;
+   break;
+   }
+   }
+   }
+
/* cleanup */
/* dtors should be called in reverse order */
i = num; while (--i >= 0) {



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/35711

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

#35711 [Fbk->Opn]: [PATCH] ISO-8859 charset not correctly detected

[matteo at beccati dot com]

 ID:   35711
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: mbstring related
 Operating System: Debian GNU/Linux
 PHP Version:  5.1.1
 Assigned To:  moriyoshi
 New Comment:

Oops, I just realized that I forgot the -u flag :)

Here is the downlaodable patch:

http://beccati.com/download/mbstring-patch-20051219.txt


Previous Comments:


[2005-12-19 08:48:47] [EMAIL PROTECTED]

Please provide any patches in unified diff format. (like the first
one). And downloadable somewhere.



[2005-12-17 10:13:11] matteo at beccati dot com

Improved patch to also work with mbstring.encoding_translation
enabled.


Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -r1.7.2.1 mbfilter.c
443c443
<   if (!filter->flag) {
---
>   if (!filter->flag && !filter->status) {
447a448,458
>
>   if (encoding == mbfl_no_encoding_invalid) {
>   n = identd->filter_list_size - 1;
>   while (n >= 0) {
>   filter = identd->filter_list[n];
>   if (!filter->flag) {
>   encoding =
filter->encoding->no_encoding;
>   }
>   n--;
>   }
>   }
578c589
<   if (!filter->flag) {
---
>   if (!filter->flag && !filter->status) {
583a595,604
>   if (!encoding) {
>   for (i = 0; i < num; i++) {
>   filter = &flist[i];
>   if (!filter->flag) {
>   encoding = filter->encoding;
>   break;
>   }
>   }
>   }
>



[2005-12-16 23:50:13] matteo at beccati dot com

I've made a patch which seems to fix the issue. It basicly checks
filter status during judgement. Status seems to be != 0 only when it is
matching a multibyte character. I added anyway a fallback to the old
judgement routine, just in case no matching encoding is found.

Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 mbfilter.c
--- ext/mbstring/libmbfl/mbfl/mbfilter.c5 Nov 2005 04:49:57
-  1.7.2.1
+++ ext/mbstring/libmbfl/mbfl/mbfilter.c16 Dec 2005 22:46:26
-
@@ -575,12 +575,22 @@

for (i = 0; i < num; i++) {
filter = &flist[i];
-   if (!filter->flag) {
+   if (!filter->flag && !filter->status) {
encoding = filter->encoding;
break;
}
}

+   if (!encoding) {
+   for (i = 0; i < num; i++) {
+   filter = &flist[i];
+   if (!filter->flag) {
+   encoding = filter->encoding;
+   break;
+   }
+   }
+   }
+
/* cleanup */
/* dtors should be called in reverse order */
i = num; while (--i >= 0) {



[2005-12-16 17:51:13] [EMAIL PROTECTED]

Moriyoshi, if ext/mbstring is not maintained anymore, please let us
know.



[2005-12-16 17:18:27] matteo at beccati dot com

Description:

I was evaluating the mbstring extension because of its capabilities to
filter and convert input parameter to the correct encoding. During my
test I found out that an ISO-8859-1 string which ends with an an
accented character is wrongly detected as UTF-8, even if it ends with
an incomplete multibyte character (using iconv to convert the string
raises such notice).

Also reproduced with PHP 4.3.11 on FreeBSD 4 and 5.0.2 on Win32.


Reproduce code:
---


Expected result:

Trying: string(7) "Test: à"

Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(8) "Test: Ã "

Trying: string(8) "Test: àa"

Notice: iconv(): Detected an 

#35711 [Asn]: [PATCH] ISO-8859 charset not correctly detected

[matteo at beccati dot com]

 ID:   35711
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Assigned
 Bug Type: mbstring related
 Operating System: Debian GNU/Linux
 PHP Version:  5.1.1
 Assigned To:  moriyoshi
 New Comment:

Improved patch to also work with mbstring.encoding_translation
enabled.


Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -r1.7.2.1 mbfilter.c
443c443
<   if (!filter->flag) {
---
>   if (!filter->flag && !filter->status) {
447a448,458
>
>   if (encoding == mbfl_no_encoding_invalid) {
>   n = identd->filter_list_size - 1;
>   while (n >= 0) {
>   filter = identd->filter_list[n];
>   if (!filter->flag) {
>   encoding =
filter->encoding->no_encoding;
>   }
>   n--;
>   }
>   }
578c589
<   if (!filter->flag) {
---
>   if (!filter->flag && !filter->status) {
583a595,604
>   if (!encoding) {
>   for (i = 0; i < num; i++) {
>   filter = &flist[i];
>   if (!filter->flag) {
>   encoding = filter->encoding;
>   break;
>   }
>   }
>   }
>


Previous Comments:


[2005-12-16 23:50:13] matteo at beccati dot com

I've made a patch which seems to fix the issue. It basicly checks
filter status during judgement. Status seems to be != 0 only when it is
matching a multibyte character. I added anyway a fallback to the old
judgement routine, just in case no matching encoding is found.

Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 mbfilter.c
--- ext/mbstring/libmbfl/mbfl/mbfilter.c5 Nov 2005 04:49:57
-  1.7.2.1
+++ ext/mbstring/libmbfl/mbfl/mbfilter.c16 Dec 2005 22:46:26
-
@@ -575,12 +575,22 @@

for (i = 0; i < num; i++) {
filter = &flist[i];
-   if (!filter->flag) {
+   if (!filter->flag && !filter->status) {
encoding = filter->encoding;
break;
}
}

+   if (!encoding) {
+   for (i = 0; i < num; i++) {
+   filter = &flist[i];
+   if (!filter->flag) {
+   encoding = filter->encoding;
+   break;
+   }
+   }
+   }
+
/* cleanup */
/* dtors should be called in reverse order */
i = num; while (--i >= 0) {



[2005-12-16 17:51:13] [EMAIL PROTECTED]

Moriyoshi, if ext/mbstring is not maintained anymore, please let us
know.



[2005-12-16 17:18:27] matteo at beccati dot com

Description:

I was evaluating the mbstring extension because of its capabilities to
filter and convert input parameter to the correct encoding. During my
test I found out that an ISO-8859-1 string which ends with an an
accented character is wrongly detected as UTF-8, even if it ends with
an incomplete multibyte character (using iconv to convert the string
raises such notice).

Also reproduced with PHP 4.3.11 on FreeBSD 4 and 5.0.2 on Win32.


Reproduce code:
---


Expected result:

Trying: string(7) "Test: à"

Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(8) "Test: Ã "

Trying: string(8) "Test: àa"

Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"


Actual result:
--
Trying: string(7) "Test: à"

Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: UTF-8
Converted string:string(6) "Test: "

Trying: string(8) "Test: àa"

Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"






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

#35711 [Asn]: ISO-8859 charset not correctly detected when

[matteo at beccati dot com]

 ID:   35711
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Assigned
 Bug Type: mbstring related
 Operating System: Debian GNU/Linux
 PHP Version:  5.1.1
 Assigned To:  moriyoshi
 New Comment:

I've made a patch which seems to fix the issue. It basicly checks
filter status during judgement. Status seems to be != 0 only when it is
matching a multibyte character. I added anyway a fallback to the old
judgement routine, just in case no matching encoding is found.

Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 mbfilter.c
--- ext/mbstring/libmbfl/mbfl/mbfilter.c5 Nov 2005 04:49:57
-  1.7.2.1
+++ ext/mbstring/libmbfl/mbfl/mbfilter.c16 Dec 2005 22:46:26
-
@@ -575,12 +575,22 @@

for (i = 0; i < num; i++) {
filter = &flist[i];
-   if (!filter->flag) {
+   if (!filter->flag && !filter->status) {
encoding = filter->encoding;
break;
}
}

+   if (!encoding) {
+   for (i = 0; i < num; i++) {
+   filter = &flist[i];
+   if (!filter->flag) {
+   encoding = filter->encoding;
+   break;
+   }
+   }
+   }
+
/* cleanup */
/* dtors should be called in reverse order */
i = num; while (--i >= 0) {


Previous Comments:


[2005-12-16 17:51:13] [EMAIL PROTECTED]

Moriyoshi, if ext/mbstring is not maintained anymore, please let us
know.

----

[2005-12-16 17:18:27] matteo at beccati dot com

Description:

I was evaluating the mbstring extension because of its capabilities to
filter and convert input parameter to the correct encoding. During my
test I found out that an ISO-8859-1 string which ends with an an
accented character is wrongly detected as UTF-8, even if it ends with
an incomplete multibyte character (using iconv to convert the string
raises such notice).

Also reproduced with PHP 4.3.11 on FreeBSD 4 and 5.0.2 on Win32.


Reproduce code:
---


Expected result:

Trying: string(7) "Test: à"

Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(8) "Test: Ã "

Trying: string(8) "Test: àa"

Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"


Actual result:
--
Trying: string(7) "Test: à"

Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: UTF-8
Converted string:string(6) "Test: "

Trying: string(8) "Test: àa"

Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"






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

#35711 [NEW]: ISO-8859 charset not correctly detected when

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: Debian GNU/Linux
PHP version:  5.1.1
PHP Bug Type: mbstring related
Bug description:  ISO-8859 charset not correctly detected when 

Description:

I was evaluating the mbstring extension because of its capabilities to
filter and convert input parameter to the correct encoding. During my test
I found out that an ISO-8859-1 string which ends with an an accented
character is wrongly detected as UTF-8, even if it ends with an incomplete
multibyte character (using iconv to convert the string raises such
notice).

Also reproduced with PHP 4.3.11 on FreeBSD 4 and 5.0.2 on Win32.


Reproduce code:
---


Expected result:

Trying: string(7) "Test: à"

Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(8) "Test: Ã "

Trying: string(8) "Test: àa"

Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"


Actual result:
--
Trying: string(7) "Test: à"

Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: UTF-8
Converted string:string(6) "Test: "

Trying: string(8) "Test: àa"

Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"


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

#35371 [Opn]: Wrong Values retriving Object with SNMP

[matteo dot bertato at hiport dot it]

 ID:   35371
 User updated by:  matteo dot bertato at hiport dot it
-Summary:  Wrong Values retriving Object
 Reported By:  matteo dot bertato at hiport dot it
 Status:   Open
 Bug Type: SNMP related
 Operating System: Fedora Core 2,4
 PHP Version:  4.4.1
 New Comment:

Changed Summary


Previous Comments:


[2005-11-24 16:44:39] matteo dot bertato at hiport dot it

Description:

Retriving SNMP Object value in SNMP_VALUE_OBJECT mode,
give me wrong result, despite using default mode gives correct result.

(Tested with Net_SNMP 5.2.1.2 on FC4)
(Tested with Net_SNMP 5.1.1 on FC2)
PHP compiled with --with-snmp --enable-ucd-snmp-hack


Reproduce code:
---



Expected result:

STRING: 0:50:e8:1:46:e6
stdClass Object
(
[type] => 4
[value] => 0:50:e8:1:46:e6
)



Actual result:
--
stdClass Object
(
[type] => 4
[value] => PèFæ
)

STRING: 0:50:e8:1:46:e6








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

#35371 [NEW]: Wrong Values retriving Object

[matteo dot bertato at hiport dot it]

From: matteo dot bertato at hiport dot it
Operating system: Fedora Core 2,4
PHP version:  4.4.1
PHP Bug Type: SNMP related
Bug description:  Wrong Values retriving Object 

Description:

Retriving SNMP Object value in SNMP_VALUE_OBJECT mode,
give me wrong result, despite using default mode gives correct result.

(Tested with Net_SNMP 5.2.1.2 on FC4)
(Tested with Net_SNMP 5.1.1 on FC2)
PHP compiled with --with-snmp --enable-ucd-snmp-hack


Reproduce code:
---



Expected result:

STRING: 0:50:e8:1:46:e6
stdClass Object
(
[type] => 4
[value] => 0:50:e8:1:46:e6
)



Actual result:
--
stdClass Object
(
[type] => 4
[value] => PèFæ
)

STRING: 0:50:e8:1:46:e6




-- 
Edit bug report at http://bugs.php.net/?id=35371&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=35371&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=35371&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=35371&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35371&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35371&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=35371&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=35371&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=35371&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35371&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=35371&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=35371&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=35371&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35371&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=35371&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35371&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=35371&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35371&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=35371&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=35371&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=35371&r=mysqlcfg

#35304 [Bgs]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Bogus
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

This is the awk related configure output:

checking for gawk... no
checking for nawk... nawk
checking if nawk is broken... no


And these are the only warnings printed to stderr:

configure: warning: You will need re2c 0.98 or later if you want to
regenerate PHP parsers.
configure: warning: flex versions supported for regeneration of the
Zend/PHP parsers: 2.5.4  (found: 2.5.31).


Previous Comments:


[2005-11-23 01:08:21] [EMAIL PROTECTED]

There is already a warning being output when mawk is used.



[2005-11-23 01:01:39] matteo at beccati dot com

I agree, but shouldn't configure fail in this case?



[2005-11-23 00:55:20] [EMAIL PROTECTED]

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 are using an unsupported version on awk (please use GNU Awk) that
fails to generate a proper module dependancy list.



[2005-11-23 00:54:43] matteo at beccati dot com

In fact, after installing gawk, the php_builtin_extensions array looks
quite different:

zend_module_entry *php_builtin_extensions[] = {
phpext_libxml_ptr,
phpext_xml_ptr,
phpext_tokenizer_ptr,
phpext_standard_ptr,
phpext_spl_ptr,
phpext_simplexml_ptr,
phpext_session_ptr,
phpext_posix_ptr,
phpext_pdo_ptr,
phpext_pdo_sqlite_ptr,
phpext_iconv_ptr,
phpext_dom_ptr,
phpext_date_ptr,
phpext_ctype_ptr,
phpext_pcre_ptr,

};



[2005-11-23 00:49:41] matteo at beccati dot com

# awk -W version
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan

compiled limits:
max NF 32767
sprintf buffer  1020



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/35304

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

#35304 [Bgs]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Bogus
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

I agree, but shouldn't configure fail in this case?


Previous Comments:


[2005-11-23 00:55:20] [EMAIL PROTECTED]

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 are using an unsupported version on awk (please use GNU Awk) that
fails to generate a proper module dependancy list.



[2005-11-23 00:54:43] matteo at beccati dot com

In fact, after installing gawk, the php_builtin_extensions array looks
quite different:

zend_module_entry *php_builtin_extensions[] = {
phpext_libxml_ptr,
phpext_xml_ptr,
phpext_tokenizer_ptr,
phpext_standard_ptr,
phpext_spl_ptr,
phpext_simplexml_ptr,
phpext_session_ptr,
phpext_posix_ptr,
phpext_pdo_ptr,
phpext_pdo_sqlite_ptr,
phpext_iconv_ptr,
phpext_dom_ptr,
phpext_date_ptr,
phpext_ctype_ptr,
phpext_pcre_ptr,

};



[2005-11-23 00:49:41] matteo at beccati dot com

# awk -W version
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan

compiled limits:
max NF 32767
sprintf buffer  1020



[2005-11-23 00:40:28] [EMAIL PROTECTED]

What version of awk are you using?



[2005-11-22 16:19:56] matteo at beccati dot com

good-ol:~/compile/php5-200511220530# sapi/cli/php -m
Segmentation fault

This is what main/internal_functions.c contains (initial and ending
comments were stripped):

/* $Id: internal_functions.c.in,v 1.30 2005/08/03 14:08:29 sniper Exp $
*/

#include "php.h"
#include "php_main.h"
#include "zend_modules.h"
#include "zend_compile.h"
#include 
#include 
#include 

#include "ext/libxml/php_libxml.h"
#include "ext/pcre/php_pcre.h"
#include "ext/ctype/php_ctype.h"
#include "ext/date/php_date.h"
#include "ext/dom/php_dom.h"
#include "ext/iconv/php_iconv.h"
#include "ext/pdo/php_pdo.h"
#include "ext/pdo_sqlite/php_pdo_sqlite.h"
#include "ext/posix/php_posix.h"
#include "ext/session/php_session.h"
#include "ext/simplexml/php_simplexml.h"
#include "ext/spl/php_spl.h"
#include "ext/standard/php_standard.h"
#include "ext/tokenizer/php_tokenizer.h"
#include "ext/xml/php_xml.h"


zend_module_entry *php_builtin_extensions[] = {
phpext_xml_ptr,
phpext_tokenizer_ptr,
phpext_standard_ptr,
phpext_spl_ptr,
phpext_simplexml_ptr,
phpext_session_ptr,
phpext_posix_ptr,
phpext_pdo_sqlite_ptr,
phpext_pdo_ptr,
phpext_iconv_ptr,
phpext_dom_ptr,
phpext_date_ptr,
phpext_ctype_ptr,
phpext_pcre_ptr,
phpext_libxml_ptr,

};

#define EXTCOUNT
(sizeof(php_builtin_extensions)/sizeof(zend_module_entry *))


int php_register_internal_extensions(TSRMLS_D)
{
return php_register_extensions(php_builtin_extensions, EXTCOUNT
TSRMLS_CC);
}



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/35304

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

#35304 [Opn]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

In fact, after installing gawk, the php_builtin_extensions array looks
quite different:

zend_module_entry *php_builtin_extensions[] = {
phpext_libxml_ptr,
phpext_xml_ptr,
phpext_tokenizer_ptr,
phpext_standard_ptr,
phpext_spl_ptr,
phpext_simplexml_ptr,
phpext_session_ptr,
phpext_posix_ptr,
phpext_pdo_ptr,
phpext_pdo_sqlite_ptr,
phpext_iconv_ptr,
phpext_dom_ptr,
phpext_date_ptr,
phpext_ctype_ptr,
phpext_pcre_ptr,

};


Previous Comments:


[2005-11-23 00:49:41] matteo at beccati dot com

# awk -W version
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan

compiled limits:
max NF 32767
sprintf buffer  1020



[2005-11-23 00:40:28] [EMAIL PROTECTED]

What version of awk are you using?



[2005-11-22 16:19:56] matteo at beccati dot com

good-ol:~/compile/php5-200511220530# sapi/cli/php -m
Segmentation fault

This is what main/internal_functions.c contains (initial and ending
comments were stripped):

/* $Id: internal_functions.c.in,v 1.30 2005/08/03 14:08:29 sniper Exp $
*/

#include "php.h"
#include "php_main.h"
#include "zend_modules.h"
#include "zend_compile.h"
#include 
#include 
#include 

#include "ext/libxml/php_libxml.h"
#include "ext/pcre/php_pcre.h"
#include "ext/ctype/php_ctype.h"
#include "ext/date/php_date.h"
#include "ext/dom/php_dom.h"
#include "ext/iconv/php_iconv.h"
#include "ext/pdo/php_pdo.h"
#include "ext/pdo_sqlite/php_pdo_sqlite.h"
#include "ext/posix/php_posix.h"
#include "ext/session/php_session.h"
#include "ext/simplexml/php_simplexml.h"
#include "ext/spl/php_spl.h"
#include "ext/standard/php_standard.h"
#include "ext/tokenizer/php_tokenizer.h"
#include "ext/xml/php_xml.h"


zend_module_entry *php_builtin_extensions[] = {
phpext_xml_ptr,
phpext_tokenizer_ptr,
phpext_standard_ptr,
phpext_spl_ptr,
phpext_simplexml_ptr,
phpext_session_ptr,
phpext_posix_ptr,
phpext_pdo_sqlite_ptr,
phpext_pdo_ptr,
phpext_iconv_ptr,
phpext_dom_ptr,
phpext_date_ptr,
phpext_ctype_ptr,
phpext_pcre_ptr,
phpext_libxml_ptr,

};

#define EXTCOUNT
(sizeof(php_builtin_extensions)/sizeof(zend_module_entry *))


int php_register_internal_extensions(TSRMLS_D)
{
return php_register_extensions(php_builtin_extensions, EXTCOUNT
TSRMLS_CC);
}



[2005-11-22 16:14:03] [EMAIL PROTECTED]

The initial trace sounds like a problem with the order in which the
extensions are loaded.
What does your main/internal_functions_cli.c file contain?



[2005-11-22 16:06:26] [EMAIL PROTECTED]

I still cannot replicate the problem, what does php -m show?



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/35304

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

#35304 [Fbk->Opn]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

# awk -W version
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan

compiled limits:
max NF 32767
sprintf buffer  1020


Previous Comments:


[2005-11-23 00:40:28] [EMAIL PROTECTED]

What version of awk are you using?



[2005-11-22 16:19:56] matteo at beccati dot com

good-ol:~/compile/php5-200511220530# sapi/cli/php -m
Segmentation fault

This is what main/internal_functions.c contains (initial and ending
comments were stripped):

/* $Id: internal_functions.c.in,v 1.30 2005/08/03 14:08:29 sniper Exp $
*/

#include "php.h"
#include "php_main.h"
#include "zend_modules.h"
#include "zend_compile.h"
#include 
#include 
#include 

#include "ext/libxml/php_libxml.h"
#include "ext/pcre/php_pcre.h"
#include "ext/ctype/php_ctype.h"
#include "ext/date/php_date.h"
#include "ext/dom/php_dom.h"
#include "ext/iconv/php_iconv.h"
#include "ext/pdo/php_pdo.h"
#include "ext/pdo_sqlite/php_pdo_sqlite.h"
#include "ext/posix/php_posix.h"
#include "ext/session/php_session.h"
#include "ext/simplexml/php_simplexml.h"
#include "ext/spl/php_spl.h"
#include "ext/standard/php_standard.h"
#include "ext/tokenizer/php_tokenizer.h"
#include "ext/xml/php_xml.h"


zend_module_entry *php_builtin_extensions[] = {
phpext_xml_ptr,
phpext_tokenizer_ptr,
phpext_standard_ptr,
phpext_spl_ptr,
phpext_simplexml_ptr,
phpext_session_ptr,
phpext_posix_ptr,
phpext_pdo_sqlite_ptr,
phpext_pdo_ptr,
phpext_iconv_ptr,
phpext_dom_ptr,
phpext_date_ptr,
phpext_ctype_ptr,
phpext_pcre_ptr,
phpext_libxml_ptr,

};

#define EXTCOUNT
(sizeof(php_builtin_extensions)/sizeof(zend_module_entry *))


int php_register_internal_extensions(TSRMLS_D)
{
return php_register_extensions(php_builtin_extensions, EXTCOUNT
TSRMLS_CC);
}



[2005-11-22 16:14:03] [EMAIL PROTECTED]

The initial trace sounds like a problem with the order in which the
extensions are loaded.
What does your main/internal_functions_cli.c file contain?



[2005-11-22 16:06:26] [EMAIL PROTECTED]

I still cannot replicate the problem, what does php -m show?



[2005-11-22 12:12:58] matteo at beccati dot com

good-ol:~/compile/php5-200511220530# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit
--enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release
i486-linux-gnu
Thread model: posix
gcc version 4.0.2 (Debian 4.0.2-2)


I've replicated the issue on another machine:
roast:~/compile/php5-200511220930# gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls
--without-included-gettext --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-13)



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/35304

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

#35304 [Fbk->Opn]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

good-ol:~/compile/php5-200511220530# sapi/cli/php -m
Segmentation fault

This is what main/internal_functions.c contains (initial and ending
comments were stripped):

/* $Id: internal_functions.c.in,v 1.30 2005/08/03 14:08:29 sniper Exp $
*/

#include "php.h"
#include "php_main.h"
#include "zend_modules.h"
#include "zend_compile.h"
#include 
#include 
#include 

#include "ext/libxml/php_libxml.h"
#include "ext/pcre/php_pcre.h"
#include "ext/ctype/php_ctype.h"
#include "ext/date/php_date.h"
#include "ext/dom/php_dom.h"
#include "ext/iconv/php_iconv.h"
#include "ext/pdo/php_pdo.h"
#include "ext/pdo_sqlite/php_pdo_sqlite.h"
#include "ext/posix/php_posix.h"
#include "ext/session/php_session.h"
#include "ext/simplexml/php_simplexml.h"
#include "ext/spl/php_spl.h"
#include "ext/standard/php_standard.h"
#include "ext/tokenizer/php_tokenizer.h"
#include "ext/xml/php_xml.h"


zend_module_entry *php_builtin_extensions[] = {
phpext_xml_ptr,
phpext_tokenizer_ptr,
phpext_standard_ptr,
phpext_spl_ptr,
phpext_simplexml_ptr,
phpext_session_ptr,
phpext_posix_ptr,
phpext_pdo_sqlite_ptr,
phpext_pdo_ptr,
phpext_iconv_ptr,
phpext_dom_ptr,
phpext_date_ptr,
phpext_ctype_ptr,
phpext_pcre_ptr,
phpext_libxml_ptr,

};

#define EXTCOUNT
(sizeof(php_builtin_extensions)/sizeof(zend_module_entry *))


int php_register_internal_extensions(TSRMLS_D)
{
return php_register_extensions(php_builtin_extensions, EXTCOUNT
TSRMLS_CC);
}


Previous Comments:


[2005-11-22 16:14:03] [EMAIL PROTECTED]

The initial trace sounds like a problem with the order in which the
extensions are loaded.
What does your main/internal_functions_cli.c file contain?



[2005-11-22 16:06:26] [EMAIL PROTECTED]

I still cannot replicate the problem, what does php -m show?



[2005-11-22 12:12:58] matteo at beccati dot com

good-ol:~/compile/php5-200511220530# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit
--enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release
i486-linux-gnu
Thread model: posix
gcc version 4.0.2 (Debian 4.0.2-2)


I've replicated the issue on another machine:
roast:~/compile/php5-200511220930# gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls
--without-included-gettext --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-13)



[2005-11-22 10:47:03] [EMAIL PROTECTED]

Since neither me or Ilia can even reproduce this, you need to give us
more information:

1) What compiler are you using?
2) Can you reproduce this on some other machine?




[2005-11-22 09:41:11] matteo at beccati dot com

Still segfaulting. This is the valgrind output:

good-ol:~/compile/php5-200511220530# valgrind sapi/cli/php
==12191== Memcheck, a memory error detector for x86-linux.
==12191== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et
al.
==12191== Using valgrind-2.4.0, a program supervision framework for
x86-linux.
==12191== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et
al.
==12191== For more details, rerun with: -v
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8ECB13: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E631C: (within /lib/ld-2.3.5.so)
==12191==   

#35304 [Fbk->Opn]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

good-ol:~/compile/php5-200511220530# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit
--enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release
i486-linux-gnu
Thread model: posix
gcc version 4.0.2 (Debian 4.0.2-2)


I've replicated the issue on another machine:
roast:~/compile/php5-200511220930# gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls
--without-included-gettext --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-13)


Previous Comments:


[2005-11-22 10:47:03] [EMAIL PROTECTED]

Since neither me or Ilia can even reproduce this, you need to give us
more information:

1) What compiler are you using?
2) Can you reproduce this on some other machine?




[2005-11-22 09:41:11] matteo at beccati dot com

Still segfaulting. This is the valgrind output:

good-ol:~/compile/php5-200511220530# valgrind sapi/cli/php
==12191== Memcheck, a memory error detector for x86-linux.
==12191== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et
al.
==12191== Using valgrind-2.4.0, a program supervision framework for
x86-linux.
==12191== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et
al.
==12191== For more details, rerun with: -v
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8ECB13: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E631C: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E7675: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E47C6: (within /lib/ld-2.3.5.so)
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8EC7D3: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E631C: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E7675: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E47C6: (within /lib/ld-2.3.5.so)
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8EC6B6: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E6376: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E7675: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E47C6: (within /lib/ld-2.3.5.so)
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8EC6C2: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E6376: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E7675: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E47C6: (within /lib/ld-2.3.5.so)
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8EC7D3: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E6376: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E7675: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E47C6: (within /lib/ld-2.3.5.so)
==12191==
==12191== Invalid read of size 4
==12191==at 0x8200BA3: _zend_hash_add_or_update (zend_hash.c:213)
==12191==by 0x80CE8E3: php_pdo_register_driver (pdo.c:170)
==12191==by 0x80D8FF2: zm_startup_pdo_sqlite (pdo_sqlite.c:80)
==12191==by 0x81FCDEA: zend_startup_module_ex (zend_API.c:1320)
==12191==by 0x820210A: zend_hash_apply (zend_hash.c:664)
==12191==by 0x81FCF79: zend_startup_modules (zend_API.c:1367)
==12191==by 0x81BA459: php_module_startup (main.c:1533)
==12191==by 0x82675A0: main (php_cli.c:655)
==12191==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==12191==
==12191== Process terminating with default action of signal 11
(SIGSEGV)
==12191==  Access not within mapped region 

#35304 [Fbk->Opn]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

Still segfaulting. This is the valgrind output:

good-ol:~/compile/php5-200511220530# valgrind sapi/cli/php
==12191== Memcheck, a memory error detector for x86-linux.
==12191== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et
al.
==12191== Using valgrind-2.4.0, a program supervision framework for
x86-linux.
==12191== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et
al.
==12191== For more details, rerun with: -v
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8ECB13: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E631C: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E7675: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E47C6: (within /lib/ld-2.3.5.so)
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8EC7D3: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E631C: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E7675: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E47C6: (within /lib/ld-2.3.5.so)
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8EC6B6: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E6376: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E7675: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E47C6: (within /lib/ld-2.3.5.so)
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8EC6C2: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E6376: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E7675: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E47C6: (within /lib/ld-2.3.5.so)
==12191==
==12191== Conditional jump or move depends on uninitialised value(s)
==12191==at 0x1B8EC7D3: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E6376: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E7675: (within /lib/ld-2.3.5.so)
==12191==by 0x1B8E47C6: (within /lib/ld-2.3.5.so)
==12191==
==12191== Invalid read of size 4
==12191==at 0x8200BA3: _zend_hash_add_or_update (zend_hash.c:213)
==12191==by 0x80CE8E3: php_pdo_register_driver (pdo.c:170)
==12191==by 0x80D8FF2: zm_startup_pdo_sqlite (pdo_sqlite.c:80)
==12191==by 0x81FCDEA: zend_startup_module_ex (zend_API.c:1320)
==12191==by 0x820210A: zend_hash_apply (zend_hash.c:664)
==12191==by 0x81FCF79: zend_startup_modules (zend_API.c:1367)
==12191==by 0x81BA459: php_module_startup (main.c:1533)
==12191==by 0x82675A0: main (php_cli.c:655)
==12191==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==12191==
==12191== Process terminating with default action of signal 11
(SIGSEGV)
==12191==  Access not within mapped region at address 0x0
==12191==at 0x8200BA3: _zend_hash_add_or_update (zend_hash.c:213)
==12191==by 0x80CE8E3: php_pdo_register_driver (pdo.c:170)
==12191==by 0x80D8FF2: zm_startup_pdo_sqlite (pdo_sqlite.c:80)
==12191==by 0x81FCDEA: zend_startup_module_ex (zend_API.c:1320)
==12191==by 0x820210A: zend_hash_apply (zend_hash.c:664)
==12191==by 0x81FCF79: zend_startup_modules (zend_API.c:1367)
==12191==by 0x81BA459: php_module_startup (main.c:1533)
==12191==by 0x82675A0: main (php_cli.c:655)
==12191==
==12191== ERROR SUMMARY: 26 errors from 6 contexts (suppressed: 0 from
0)
==12191== malloc/free: in use at exit: 372210 bytes in 5550 blocks.
==12191== malloc/free: 5768 allocs, 218 frees, 409794 bytes allocated.
==12191== For counts of detected errors, rerun with: -v
==12191== searching for pointers to 5550 not-freed blocks.
==12191== checked 1145848 bytes.
==12191==
==12191== LEAK SUMMARY:
==12191==definitely lost: 0 bytes in 0 blocks.
==12191==  possibly lost: 0 bytes in 0 blocks.
==12191==still reachable: 372210 bytes in 5550 blocks.
==12191== suppressed: 0 bytes in 0 blocks.
==12191== Reachable blocks (those to which a pointer was found) are not
shown.
==12191== To see them, rerun with: --show-reachable=yes
Segmentation fault


Previous Comments:


[2005-11-22 04:21:22] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

Compiled with your flags and things work fine, no crashes. Even
valgrind does not point to any problems...

---

#35304 [Opn]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

Also without CFLAGS:

good-ol:~/compile/php5-200511211330# sapi/cli/php -n -r 'echo 1;'
Segmentation fault
good-ol:~/compile/php5-200511211330# sapi/cli/php -n somefile.php
Segmentation fault


Previous Comments:


[2005-11-21 17:27:02] matteo at beccati dot com

This was without recompiling. I'll recompile without CFLAGS and let you
know.



[2005-11-21 17:25:43] matteo at beccati dot com

good-ol:~/compile/php5-200511211330# sapi/cli/php -n -r 'echo 1;'
Segmentation fault
good-ol:~/compile/php5-200511211330# touch somefile.php
good-ol:~/compile/php5-200511211330# sapi/cli/php -n somefile.php
Segmentation fault
good-ol:~/compile/php5-200511211330#



[2005-11-21 17:24:07] [EMAIL PROTECTED]

Try without setting those CFLAGS. And try running PHP like this after
compile:

# sapi/cli/php -n -r 'echo 1;'

Does that crash? Or this:

# sapi/cli/php -n somefile.php


----

[2005-11-21 16:51:33] matteo at beccati dot com

No php.ini is present in /usr/local/lib. this was the configure line:

CFLAGS='-O0 -g' ./configure --disable-cgi --without-sqlite

which leads to the segfault on php start (I was probabily wrong saying
that it was working on start).

If you need I can give you ssh access on the machine.



[2005-11-21 14:25:56] [EMAIL PROTECTED]

Was this really with that configure line? As I tried the same and can't
get it to segfault. Do you happen to load any extensions in the used
php.ini (or php-cli.ini) file?




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/35304

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

#35304 [Opn]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

This was without recompiling. I'll recompile without CFLAGS and let you
know.


Previous Comments:


[2005-11-21 17:25:43] matteo at beccati dot com

good-ol:~/compile/php5-200511211330# sapi/cli/php -n -r 'echo 1;'
Segmentation fault
good-ol:~/compile/php5-200511211330# touch somefile.php
good-ol:~/compile/php5-200511211330# sapi/cli/php -n somefile.php
Segmentation fault
good-ol:~/compile/php5-200511211330#



[2005-11-21 17:24:07] [EMAIL PROTECTED]

Try without setting those CFLAGS. And try running PHP like this after
compile:

# sapi/cli/php -n -r 'echo 1;'

Does that crash? Or this:

# sapi/cli/php -n somefile.php


----

[2005-11-21 16:51:33] matteo at beccati dot com

No php.ini is present in /usr/local/lib. this was the configure line:

CFLAGS='-O0 -g' ./configure --disable-cgi --without-sqlite

which leads to the segfault on php start (I was probabily wrong saying
that it was working on start).

If you need I can give you ssh access on the machine.



[2005-11-21 14:25:56] [EMAIL PROTECTED]

Was this really with that configure line? As I tried the same and can't
get it to segfault. Do you happen to load any extensions in the used
php.ini (or php-cli.ini) file?


----

[2005-11-20 22:39:04] matteo at beccati dot com

The snap doesn't segfault at start, but does on make test:

(gdb) set args -d 'open_basedir=' -d 'safe_mode=0' -d
'output_buffering=0' -d 'memory_limit=-1'
/root/compile/php5-200511201930/run-tests.php
(gdb) run
Starting program: /root/compile/php5-200511201930/sapi/cli/php -d
'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' -d
'memory_limit=-1' /root/compile/php5-200511201930/run-tests.php

Program received signal SIGSEGV, Segmentation fault.
0x08200adf in _zend_hash_add_or_update (ht=0x8322160,
arKey=0x827ab2c "sqlite", nKeyLength=6, pData=0xb960,
nDataSize=4,
pDest=0x0, flag=2) at
/root/compile/php5-200511201930/Zend/zend_hash.c:213
213 p = ht->arBuckets[nIndex];
(gdb) bt full
#0  0x08200adf in _zend_hash_add_or_update (ht=0x8322160,
arKey=0x827ab2c "sqlite", nKeyLength=6, pData=0xb960,
nDataSize=4,
pDest=0x0, flag=2) at
/root/compile/php5-200511201930/Zend/zend_hash.c:213
h = 475667703
nIndex = 0
p = (Bucket *) 0x1
#1  0x080ce8c4 in php_pdo_register_driver (driver=0x8312438)
at /root/compile/php5-200511201930/ext/pdo/pdo.c:170
No locals.
#2  0x080d8fc7 in zm_startup_pdo_sqlite (type=1, module_number=8)
at /root/compile/php5-200511201930/ext/pdo_sqlite/pdo_sqlite.c:80
No locals.
#3  0x081fcd27 in zend_startup_module_ex (module=0x835cc30)
at /root/compile/php5-200511201930/Zend/zend_API.c:1320
name_len = 9
lcname = 0x832c084 "splsubject"
#4  0x08202047 in zend_hash_apply (ht=0x8327780,
apply_func=0x81fcbe8 )
at /root/compile/php5-200511201930/Zend/zend_hash.c:664
p = (Bucket *) 0x835cbf8
#5  0x081fceb6 in zend_startup_modules ()
at /root/compile/php5-200511201930/Zend/zend_API.c:1367
No locals.
#6  0x081ba3c2 in php_module_startup (sf=0x8320620,
additional_modules=0x0,
num_additional_modules=0)
at /root/compile/php5-200511201930/main/main.c:1533
zuf = {error_function = 0x81b89f6 ,
  printf_function = 0x81b8351 ,
  write_function = 0x81b9e34 ,
  fopen_function = 0x81b907c ,
  message_handler = 0x81b91a9 ,
  block_interruptions = 0, unblock_interruptions = 0,
  get_configuration_directive = 0x81b9159
, ticks_function = 0x81c61db
,
  on_timeout = 0x81b931b ,
  stream_open_function = 0x81b90cc ,
  vspprintf_function = 0x81bd903 ,
  getenv_function = 0x81c135c }
zuv = {import_use_extension = 0x8296dc8 ".php",
  import_use_extension_length = 137475840, html_errors = 1 '\001'}
module_number = 0
php_os = 0x8296d4f "Linux"
#7  0x082674dd in main (argc=10, argv=0xbca4)
at /root/compile/php5-200511201930/sapi/cli/php_cli.c:655
exit_status = 0
c = -1
file_handle = {type = 0 '\0',
  filename = 0x1 , opened_path = 0xbbdc
"",
  handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, reader = 0,
  closer = 0xbc50, fteller = 0x400167f8, interactive =
134602782}},
  free_filename = 142 

#35304 [Fbk->Opn]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

good-ol:~/compile/php5-200511211330# sapi/cli/php -n -r 'echo 1;'
Segmentation fault
good-ol:~/compile/php5-200511211330# touch somefile.php
good-ol:~/compile/php5-200511211330# sapi/cli/php -n somefile.php
Segmentation fault
good-ol:~/compile/php5-200511211330#


Previous Comments:


[2005-11-21 17:24:07] [EMAIL PROTECTED]

Try without setting those CFLAGS. And try running PHP like this after
compile:

# sapi/cli/php -n -r 'echo 1;'

Does that crash? Or this:

# sapi/cli/php -n somefile.php




[2005-11-21 16:51:33] matteo at beccati dot com

No php.ini is present in /usr/local/lib. this was the configure line:

CFLAGS='-O0 -g' ./configure --disable-cgi --without-sqlite

which leads to the segfault on php start (I was probabily wrong saying
that it was working on start).

If you need I can give you ssh access on the machine.



[2005-11-21 14:25:56] [EMAIL PROTECTED]

Was this really with that configure line? As I tried the same and can't
get it to segfault. Do you happen to load any extensions in the used
php.ini (or php-cli.ini) file?


----

[2005-11-20 22:39:04] matteo at beccati dot com

The snap doesn't segfault at start, but does on make test:

(gdb) set args -d 'open_basedir=' -d 'safe_mode=0' -d
'output_buffering=0' -d 'memory_limit=-1'
/root/compile/php5-200511201930/run-tests.php
(gdb) run
Starting program: /root/compile/php5-200511201930/sapi/cli/php -d
'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' -d
'memory_limit=-1' /root/compile/php5-200511201930/run-tests.php

Program received signal SIGSEGV, Segmentation fault.
0x08200adf in _zend_hash_add_or_update (ht=0x8322160,
arKey=0x827ab2c "sqlite", nKeyLength=6, pData=0xb960,
nDataSize=4,
pDest=0x0, flag=2) at
/root/compile/php5-200511201930/Zend/zend_hash.c:213
213 p = ht->arBuckets[nIndex];
(gdb) bt full
#0  0x08200adf in _zend_hash_add_or_update (ht=0x8322160,
arKey=0x827ab2c "sqlite", nKeyLength=6, pData=0xb960,
nDataSize=4,
pDest=0x0, flag=2) at
/root/compile/php5-200511201930/Zend/zend_hash.c:213
h = 475667703
nIndex = 0
p = (Bucket *) 0x1
#1  0x080ce8c4 in php_pdo_register_driver (driver=0x8312438)
at /root/compile/php5-200511201930/ext/pdo/pdo.c:170
No locals.
#2  0x080d8fc7 in zm_startup_pdo_sqlite (type=1, module_number=8)
at /root/compile/php5-200511201930/ext/pdo_sqlite/pdo_sqlite.c:80
No locals.
#3  0x081fcd27 in zend_startup_module_ex (module=0x835cc30)
at /root/compile/php5-200511201930/Zend/zend_API.c:1320
name_len = 9
lcname = 0x832c084 "splsubject"
#4  0x08202047 in zend_hash_apply (ht=0x8327780,
apply_func=0x81fcbe8 )
at /root/compile/php5-200511201930/Zend/zend_hash.c:664
p = (Bucket *) 0x835cbf8
#5  0x081fceb6 in zend_startup_modules ()
at /root/compile/php5-200511201930/Zend/zend_API.c:1367
No locals.
#6  0x081ba3c2 in php_module_startup (sf=0x8320620,
additional_modules=0x0,
num_additional_modules=0)
at /root/compile/php5-200511201930/main/main.c:1533
zuf = {error_function = 0x81b89f6 ,
  printf_function = 0x81b8351 ,
  write_function = 0x81b9e34 ,
  fopen_function = 0x81b907c ,
  message_handler = 0x81b91a9 ,
  block_interruptions = 0, unblock_interruptions = 0,
  get_configuration_directive = 0x81b9159
, ticks_function = 0x81c61db
,
  on_timeout = 0x81b931b ,
  stream_open_function = 0x81b90cc ,
  vspprintf_function = 0x81bd903 ,
  getenv_function = 0x81c135c }
zuv = {import_use_extension = 0x8296dc8 ".php",
  import_use_extension_length = 137475840, html_errors = 1 '\001'}
module_number = 0
php_os = 0x8296d4f "Linux"
#7  0x082674dd in main (argc=10, argv=0xbca4)
at /root/compile/php5-200511201930/sapi/cli/php_cli.c:655
exit_status = 0
c = -1
file_handle = {type = 0 '\0',
  filename = 0x1 , opened_path = 0xbbdc
"",
  handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, reader = 0,
  closer = 0xbc50, fteller = 0x400167f8, interactive =
134602782}},
  free_filename = 142 '\216'}
behavior = 1
orig_optind = 1
orig_optarg = 0x0
arg_free = 0x0
arg_excp = (char **) 0xbb9c
   

#35304 [Fbk->Opn]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5CVS-2005-11-20 (snap)
 New Comment:

No php.ini is present in /usr/local/lib. this was the configure line:

CFLAGS='-O0 -g' ./configure --disable-cgi --without-sqlite

which leads to the segfault on php start (I was probabily wrong saying
that it was working on start).

If you need I can give you ssh access on the machine.


Previous Comments:


[2005-11-21 14:25:56] [EMAIL PROTECTED]

Was this really with that configure line? As I tried the same and can't
get it to segfault. Do you happen to load any extensions in the used
php.ini (or php-cli.ini) file?




[2005-11-20 22:39:04] matteo at beccati dot com

The snap doesn't segfault at start, but does on make test:

(gdb) set args -d 'open_basedir=' -d 'safe_mode=0' -d
'output_buffering=0' -d 'memory_limit=-1'
/root/compile/php5-200511201930/run-tests.php
(gdb) run
Starting program: /root/compile/php5-200511201930/sapi/cli/php -d
'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' -d
'memory_limit=-1' /root/compile/php5-200511201930/run-tests.php

Program received signal SIGSEGV, Segmentation fault.
0x08200adf in _zend_hash_add_or_update (ht=0x8322160,
arKey=0x827ab2c "sqlite", nKeyLength=6, pData=0xb960,
nDataSize=4,
pDest=0x0, flag=2) at
/root/compile/php5-200511201930/Zend/zend_hash.c:213
213 p = ht->arBuckets[nIndex];
(gdb) bt full
#0  0x08200adf in _zend_hash_add_or_update (ht=0x8322160,
arKey=0x827ab2c "sqlite", nKeyLength=6, pData=0xb960,
nDataSize=4,
pDest=0x0, flag=2) at
/root/compile/php5-200511201930/Zend/zend_hash.c:213
h = 475667703
nIndex = 0
p = (Bucket *) 0x1
#1  0x080ce8c4 in php_pdo_register_driver (driver=0x8312438)
at /root/compile/php5-200511201930/ext/pdo/pdo.c:170
No locals.
#2  0x080d8fc7 in zm_startup_pdo_sqlite (type=1, module_number=8)
at /root/compile/php5-200511201930/ext/pdo_sqlite/pdo_sqlite.c:80
No locals.
#3  0x081fcd27 in zend_startup_module_ex (module=0x835cc30)
at /root/compile/php5-200511201930/Zend/zend_API.c:1320
name_len = 9
lcname = 0x832c084 "splsubject"
#4  0x08202047 in zend_hash_apply (ht=0x8327780,
apply_func=0x81fcbe8 )
at /root/compile/php5-200511201930/Zend/zend_hash.c:664
p = (Bucket *) 0x835cbf8
#5  0x081fceb6 in zend_startup_modules ()
at /root/compile/php5-200511201930/Zend/zend_API.c:1367
No locals.
#6  0x081ba3c2 in php_module_startup (sf=0x8320620,
additional_modules=0x0,
num_additional_modules=0)
at /root/compile/php5-200511201930/main/main.c:1533
zuf = {error_function = 0x81b89f6 ,
  printf_function = 0x81b8351 ,
  write_function = 0x81b9e34 ,
  fopen_function = 0x81b907c ,
  message_handler = 0x81b91a9 ,
  block_interruptions = 0, unblock_interruptions = 0,
  get_configuration_directive = 0x81b9159
, ticks_function = 0x81c61db
,
  on_timeout = 0x81b931b ,
  stream_open_function = 0x81b90cc ,
  vspprintf_function = 0x81bd903 ,
  getenv_function = 0x81c135c }
zuv = {import_use_extension = 0x8296dc8 ".php",
  import_use_extension_length = 137475840, html_errors = 1 '\001'}
module_number = 0
php_os = 0x8296d4f "Linux"
#7  0x082674dd in main (argc=10, argv=0xbca4)
at /root/compile/php5-200511201930/sapi/cli/php_cli.c:655
exit_status = 0
c = -1
file_handle = {type = 0 '\0',
  filename = 0x1 , opened_path = 0xbbdc
"",
  handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, reader = 0,
  closer = 0xbc50, fteller = 0x400167f8, interactive =
134602782}},
  free_filename = 142 '\216'}
behavior = 1
orig_optind = 1
orig_optarg = 0x0
arg_free = 0x0
arg_excp = (char **) 0xbb9c
script_file = 0x0
global_vars = {head = 0xbc14, tail = 0xbc28,
  count = 1073772579, size = 3221224468, dtor = 0x40016950,
  persistent = 8 '\b', traverse_ptr = 0x400ae6a8}
interactive = 0
module_started = 0
lineno = 0
exec_direct = 0x0
exec_run = 0x0
exec_begin = 0x0
exec_end = 0x0
param_error = 0x0
hide_argv = 0



[2005-11-20 18:55:45] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip



-

#35304 [Fbk->Opn]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

 ID:   35304
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Debian GNU/Linux testing/etch
 PHP Version:  5.1.0RC6
 New Comment:

The snap doesn't segfault at start, but does on make test:

(gdb) set args -d 'open_basedir=' -d 'safe_mode=0' -d
'output_buffering=0' -d 'memory_limit=-1'
/root/compile/php5-200511201930/run-tests.php
(gdb) run
Starting program: /root/compile/php5-200511201930/sapi/cli/php -d
'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' -d
'memory_limit=-1' /root/compile/php5-200511201930/run-tests.php

Program received signal SIGSEGV, Segmentation fault.
0x08200adf in _zend_hash_add_or_update (ht=0x8322160,
arKey=0x827ab2c "sqlite", nKeyLength=6, pData=0xb960,
nDataSize=4,
pDest=0x0, flag=2) at
/root/compile/php5-200511201930/Zend/zend_hash.c:213
213 p = ht->arBuckets[nIndex];
(gdb) bt full
#0  0x08200adf in _zend_hash_add_or_update (ht=0x8322160,
arKey=0x827ab2c "sqlite", nKeyLength=6, pData=0xb960,
nDataSize=4,
pDest=0x0, flag=2) at
/root/compile/php5-200511201930/Zend/zend_hash.c:213
h = 475667703
nIndex = 0
p = (Bucket *) 0x1
#1  0x080ce8c4 in php_pdo_register_driver (driver=0x8312438)
at /root/compile/php5-200511201930/ext/pdo/pdo.c:170
No locals.
#2  0x080d8fc7 in zm_startup_pdo_sqlite (type=1, module_number=8)
at /root/compile/php5-200511201930/ext/pdo_sqlite/pdo_sqlite.c:80
No locals.
#3  0x081fcd27 in zend_startup_module_ex (module=0x835cc30)
at /root/compile/php5-200511201930/Zend/zend_API.c:1320
name_len = 9
lcname = 0x832c084 "splsubject"
#4  0x08202047 in zend_hash_apply (ht=0x8327780,
apply_func=0x81fcbe8 )
at /root/compile/php5-200511201930/Zend/zend_hash.c:664
p = (Bucket *) 0x835cbf8
#5  0x081fceb6 in zend_startup_modules ()
at /root/compile/php5-200511201930/Zend/zend_API.c:1367
No locals.
#6  0x081ba3c2 in php_module_startup (sf=0x8320620,
additional_modules=0x0,
num_additional_modules=0)
at /root/compile/php5-200511201930/main/main.c:1533
zuf = {error_function = 0x81b89f6 ,
  printf_function = 0x81b8351 ,
  write_function = 0x81b9e34 ,
  fopen_function = 0x81b907c ,
  message_handler = 0x81b91a9 ,
  block_interruptions = 0, unblock_interruptions = 0,
  get_configuration_directive = 0x81b9159
, ticks_function = 0x81c61db
,
  on_timeout = 0x81b931b ,
  stream_open_function = 0x81b90cc ,
  vspprintf_function = 0x81bd903 ,
  getenv_function = 0x81c135c }
zuv = {import_use_extension = 0x8296dc8 ".php",
  import_use_extension_length = 137475840, html_errors = 1 '\001'}
module_number = 0
php_os = 0x8296d4f "Linux"
#7  0x082674dd in main (argc=10, argv=0xbca4)
at /root/compile/php5-200511201930/sapi/cli/php_cli.c:655
exit_status = 0
c = -1
file_handle = {type = 0 '\0',
  filename = 0x1 , opened_path = 0xbbdc
"",
  handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, reader = 0,
  closer = 0xbc50, fteller = 0x400167f8, interactive =
134602782}},
  free_filename = 142 '\216'}
behavior = 1
orig_optind = 1
orig_optarg = 0x0
arg_free = 0x0
arg_excp = (char **) 0xbb9c
script_file = 0x0
global_vars = {head = 0xbc14, tail = 0xbc28,
  count = 1073772579, size = 3221224468, dtor = 0x40016950,
  persistent = 8 '\b', traverse_ptr = 0x400ae6a8}
interactive = 0
module_started = 0
lineno = 0
exec_direct = 0x0
exec_run = 0x0
exec_begin = 0x0
exec_end = 0x0
param_error = 0x0
hide_argv = 0


Previous Comments:


[2005-11-20 18:55:45] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip





[2005-11-20 12:57:15] matteo at beccati dot com

Description:

I was starting to test PHP5.1.0RC6.

make install was exiting with a segmentation fault, because running php
from command line always exit with a segfault. I tracked down that the
problem depends by the fact I used --without-sqlite in the configure
options.

Using the php5-200511200930 snapshot also leads to the same result.

Configure line used for the backtrace:
CFLAGS=-O0 ./configure --disable-cgi --without-sqlite


Actual result:
--
(gdb) run
Starting program: /root/compile/php5-200511200930/sapi/cli/php

Program received signal SIGSEGV, Segmentation fault.
0x08200adf in _zend_h

#35304 [NEW]: PHP always segfaults with --without-sqlite

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: Debian GNU/Linux testing/etch
PHP version:  5.1.0RC6
PHP Bug Type: Scripting Engine problem
Bug description:  PHP always segfaults with --without-sqlite

Description:

I was starting to test PHP5.1.0RC6.

make install was exiting with a segmentation fault, because running php
from command line always exit with a segfault. I tracked down that the
problem depends by the fact I used --without-sqlite in the configure
options.

Using the php5-200511200930 snapshot also leads to the same result.

Configure line used for the backtrace:
CFLAGS=-O0 ./configure --disable-cgi --without-sqlite


Actual result:
--
(gdb) run
Starting program: /root/compile/php5-200511200930/sapi/cli/php

Program received signal SIGSEGV, Segmentation fault.
0x08200adf in _zend_hash_add_or_update ()
(gdb) bt full
#0  0x08200adf in _zend_hash_add_or_update ()
No symbol table info available.
#1  0x080ce8c4 in php_pdo_register_driver ()
No symbol table info available.
#2  0x080d8fc7 in zm_startup_pdo_sqlite ()
No symbol table info available.
#3  0x081fcd27 in zend_startup_module_ex ()
No symbol table info available.
#4  0x08202047 in zend_hash_apply ()
No symbol table info available.
#5  0x081fceb6 in zend_startup_modules ()
No symbol table info available.
#6  0x081ba3c2 in php_module_startup ()
No symbol table info available.
#7  0x082674dd in main ()
No symbol table info available.


-- 
Edit bug report at http://bugs.php.net/?id=35304&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=35304&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=35304&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=35304&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35304&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35304&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=35304&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=35304&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=35304&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35304&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=35304&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=35304&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=35304&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35304&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=35304&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35304&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=35304&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35304&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=35304&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=35304&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=35304&r=mysqlcfg

#32810 [NEW]: fread after tmpfile() reads only 8192 bytes

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: Any
PHP version:  4.3.10
PHP Bug Type: Filesystem function related
Bug description:  fread after tmpfile() reads only 8192 bytes

Description:

In recent PHP versions, fread only reads 8192 bytes from a file generated
with tmpfile().

I've already seen bug reports #29023 and #30936 which seem strongly
related to this issue. From what I can see, fread on local files isn't
limited to the PHP chunk size of 8192, while a fread on a tmpfile acts
like it was i.e. a network stream, breaking backwards compatibility. I
found out this issue investigating a recently reported bug for phpAdsNew,
which uses this function to deal with remote ftp-stored files.

IMVHO this can be considered a bug in in the tmpfile() implementation. If
you don't agree, well... I suggest to mark it as a documentation bug,
because I couldn't find nothing related to the 8192 bytes limit in the
manual.


Versions/OS tested and affected:
PHP 4.3.10 Linux
PHP 4.3.11 FreeBSD and Windows
PHP 5.0.4  Windows

Versions/OS tested and unaffected:
PHP 4.3.4  Windows


Reproduce code:
---


Expected result:

Bytes written: 10
Bytes read:10


Actual result:
--
Bytes written: 10
Bytes read:8192


-- 
Edit bug report at http://bugs.php.net/?id=32810&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32810&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32810&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32810&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32810&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32810&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32810&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32810&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32810&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32810&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32810&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=32810&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=32810&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32810&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32810&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32810&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=32810&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32810&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32810&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=32810&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32810&r=mysqlcfg

#27341 [Csd]: CURLOPT_CUSTOMREQUEST 'HEAD' misbehaves?

[matteo at beccati dot com]

 ID:   27341
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Closed
 Bug Type: cURL related
 Operating System: *
 PHP Version:  4CVS, 5CVS (2004-02-23)
 New Comment:

Downloaded the latest snap: I can confirm that the bug was fixed.



Great work :)


Previous Comments:


[2004-02-23 14:43:29] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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.





[2004-02-23 14:37:33] [EMAIL PROTECTED]

When you run the script, it hangs a while here:

curl.c:1021  error = curl_easy_perform(ch->cp);



And finally it returns:

  CURLE_PARTIAL_FILE



The error string it gives is: "transfer closed with 6484 bytes
remaining to read"



Test script:



http://bugs.php.net/gifs/logo-bug.gif'); 

curl_setopt($ch, CURLOPT_HEADER, true); 

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD'); 

var_dump(curl_exec($ch)); 

?>



(notice: not using CURLOPT_RETURNTRANSFER :)



----

[2004-02-23 14:08:08] matteo at beccati dot com

Just downloaded the latest win32 snapshot (STABLE-200402231730), and
tried the code with http://bugs.php.net/ (which is a PHP script) and an
image file (http://bugs.php.net/gifs/logo-bug.gif).



The issue still exists when doing HEAD requests to static files.



[2004-02-21 12:19:57] [EMAIL PROTECTED]

Works just fine with latest CVS. 

http://bugs.php.net/'); 

 

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); 

curl_setopt($ch, CURLOPT_HEADER, true); 

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD'); 

 

var_dump(curl_exec($ch)); 

?> 

 

Results in: 

 

tring(154) "HTTP/1.1 200 OK 

Date: Sat, 21 Feb 2004 17:19:33 GMT 

Server: Apache/1.3.28 (Unix) PHP/4.3.4-dev 

X-Powered-By: PHP/4.3.4-dev 

Content-Type: text/html 

 

" 

 



[2004-02-21 08:30:19] daniel at haxx dot se

I beg to differ.



CURLOPT_RETURNTRANSFER is not an option that libcurl provides, it is an
option that the PHP/CURL layer has invented and uses. 



Thus, we cannot fix this in the curl project. It is not a curl bug!



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/27341

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

#27341 [Csd->Opn]: CURLOPT_RETURNTRANSFER and CURLOPT_CUSTOMREQUEST incompatibility?

[matteo at beccati dot com]

 ID:   27341
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
-Status:   Closed
+Status:   Open
 Bug Type: cURL related
 Operating System: Win32 - Linux
-PHP Version:  4.3.4
+PHP Version:  4.3.5-dev
 New Comment:

Just downloaded the latest win32 snapshot (STABLE-200402231730), and
tried the code with http://bugs.php.net/ (which is a PHP script) and an
image file (http://bugs.php.net/gifs/logo-bug.gif).



The issue still exists when doing HEAD requests to static files.


Previous Comments:


[2004-02-21 12:19:57] [EMAIL PROTECTED]

Works just fine with latest CVS. 

http://bugs.php.net/'); 

 

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); 

curl_setopt($ch, CURLOPT_HEADER, true); 

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD'); 

 

var_dump(curl_exec($ch)); 

?> 

 

Results in: 

 

tring(154) "HTTP/1.1 200 OK 

Date: Sat, 21 Feb 2004 17:19:33 GMT 

Server: Apache/1.3.28 (Unix) PHP/4.3.4-dev 

X-Powered-By: PHP/4.3.4-dev 

Content-Type: text/html 

 

" 

 



[2004-02-21 10:15:24] [EMAIL PROTECTED]

Interesting :)



[2004-02-21 08:30:19] daniel at haxx dot se

I beg to differ.



CURLOPT_RETURNTRANSFER is not an option that libcurl provides, it is an
option that the PHP/CURL layer has invented and uses. 



Thus, we cannot fix this in the curl project. It is not a curl bug!



[2004-02-21 04:10:55] matteo at beccati dot com

> Ask the curl author(s).



Done.

http://sourceforge.net/tracker/index.php?func=detail&aid=901648&group_id=976&atid=100976



> Not PHP bug (if it even is a bug which I doubt).



You're probabiliy correct saying that it's not a PHP bug, but it really
seems a wrong cURL behaviour to me.

When setting CURLOPT_RETURNTRANSFER I'm asking curl_exec to return the
result instead that outputting it, but result isn't returned, neither
printed out.



Thank you for your help.



[2004-02-21 02:57:08] [EMAIL PROTECTED]

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. 

Thank you for your interest in PHP.

Not PHP bug (if it even is a bug which I doubt).

Ask the curl author(s).





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/27341

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

#27341 [Bgs]: CURLOPT_RETURNTRANSFER and CURLOPT_CUSTOMREQUEST incompatibility?

[matteo at beccati dot com]

 ID:   27341
 User updated by:  matteo at beccati dot com
 Reported By:  matteo at beccati dot com
 Status:   Bogus
 Bug Type: cURL related
-Operating System: Win32 (WinXP)
+Operating System: Win32 - Linux
 PHP Version:  4.3.4
 New Comment:

> Ask the curl author(s).



Done.

http://sourceforge.net/tracker/index.php?func=detail&aid=901648&group_id=976&atid=100976



> Not PHP bug (if it even is a bug which I doubt).



You're probabiliy correct saying that it's not a PHP bug, but it really
seems a wrong cURL behaviour to me.

When setting CURLOPT_RETURNTRANSFER I'm asking curl_exec to return the
result instead that outputting it, but result isn't returned, neither
printed out.



Thank you for your help.


Previous Comments:


[2004-02-21 02:57:08] [EMAIL PROTECTED]

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. 

Thank you for your interest in PHP.

Not PHP bug (if it even is a bug which I doubt).

Ask the curl author(s).



----

[2004-02-21 02:41:18] matteo at beccati dot com

Description:

Trying to help a friend which wanted to do a curl HEAD request with php
(just like the shell curl -I does), I wrote down this code, without
much checking:



$ch = curl_init('http://foo/bar.html');



curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

curl_setopt($ch, CURLOPT_HEADER, true);

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');



var_dump(curl_exec($ch));



In fact he tried it and told me it doesn't work, while this does:



$ch = curl_init('http://foo/bar.html');



//curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

curl_setopt($ch, CURLOPT_HEADER, true);

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');



ob_start();

curl_exec($ch);

var_dump(ob_get_clean());





phpinfo() tels me that I'm running:

libcurl/7.10.5 OpenSSL/0.9.7b zlib/1.1.4



I've also seen bug #15279, but it was marked as documentation problem,
and didn't explain this weird issue.



Reproduce code:
---
$ch = curl_init('http://beccati.com/img/adv.png');



curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

curl_setopt($ch, CURLOPT_HEADER, true);

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');



var_dump(curl_exec($ch));

Expected result:

string(214) "HTTP/1.1 200 OK

Date: Sat, 21 Feb 2004 07:39:06 GMT

Server: Apache

Last-Modified: Wed, 06 Aug 2003 12:35:16 GMT

ETag: "27c64-204-3f30f604"

Accept-Ranges: bytes

Content-Length: 516

Content-Type: image/png



"

Actual result:
--
bool(false)





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

#27341 [NEW]: CURLOPT_RETURNTRANSFER and CURLOPT_CUSTOMREQUEST incompatibility?

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: Win32 (WinXP)
PHP version:  4.3.4
PHP Bug Type: cURL related
Bug description:  CURLOPT_RETURNTRANSFER and CURLOPT_CUSTOMREQUEST incompatibility?

Description:

Trying to help a friend which wanted to do a curl HEAD request with php
(just like the shell curl -I does), I wrote down this code, without much
checking:



$ch = curl_init('http://foo/bar.html');



curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

curl_setopt($ch, CURLOPT_HEADER, true);

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');



var_dump(curl_exec($ch));



In fact he tried it and told me it doesn't work, while this does:



$ch = curl_init('http://foo/bar.html');



//curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

curl_setopt($ch, CURLOPT_HEADER, true);

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');



ob_start();

curl_exec($ch);

var_dump(ob_get_clean());





phpinfo() tels me that I'm running:

libcurl/7.10.5 OpenSSL/0.9.7b zlib/1.1.4



I've also seen bug #15279, but it was marked as documentation problem, and
didn't explain this weird issue.



Reproduce code:
---
$ch = curl_init('http://beccati.com/img/adv.png');



curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

curl_setopt($ch, CURLOPT_HEADER, true);

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');



var_dump(curl_exec($ch));

Expected result:

string(214) "HTTP/1.1 200 OK

Date: Sat, 21 Feb 2004 07:39:06 GMT

Server: Apache

Last-Modified: Wed, 06 Aug 2003 12:35:16 GMT

ETag: "27c64-204-3f30f604"

Accept-Ranges: bytes

Content-Length: 516

Content-Type: image/png



"

Actual result:
--
bool(false)

-- 
Edit bug report at http://bugs.php.net/?id=27341&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27341&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27341&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27341&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27341&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27341&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27341&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27341&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27341&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27341&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27341&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27341&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27341&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27341&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27341&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27341&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27341&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27341&r=float

#26314 [Bgs->Opn]: Decimal numbers starting with 0 always treated as octals, even when invalid

[matteo at beccati dot com]

 ID:   26314
 User updated by:  matteo at beccati dot com
-Summary:  Decimal numbers starting with 0 wrongly treated as
   octals, even when invalid
 Reported By:  matteo at beccati dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Debian GNU/Linux 3.0
 PHP Version:  4.3.4
 New Comment:

Fixed summary...


Previous Comments:


[2003-11-19 06:39:40] [EMAIL PROTECTED]

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

This is exactly as it should be. If you prefix the 0 on a non-octal
number, PHP still treats it as an octal number as is described in the
manual. 



[2003-11-19 06:37:32] matteo at beccati dot com

Description:

According to the manual, integers can be specified in the octal
notation preceding the number with a zero. Some lines below I can see
this regexp:

octal   : 0[0-7]+


What I don't understand is why an invalid octal number preceded by a 0
is treated as an octal, having a value of 0.

I know that you'll probably answer that it's a feature and not a bug,
but I think that this behaviour should be highlighted in the manual :)

Also checked on PHP 4.1.2, 4.3.0 and 4.3.3

Reproduce code:
---




Expected result:

int(7)
int(8)
int(8)


Actual result:
--
int(7)
int(8)
int(0)






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

#26314 [NEW]: Decimal numbers starting with 0 wrongly treated as octals, even when invalid

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: Debian GNU/Linux 3.0
PHP version:  4.3.4
PHP Bug Type: Scripting Engine problem
Bug description:  Decimal numbers starting with 0 wrongly treated as octals, even when 
invalid

Description:

According to the manual, integers can be specified in the octal notation
preceding the number with a zero. Some lines below I can see this regexp:

octal   : 0[0-7]+


What I don't understand is why an invalid octal number preceded by a 0 is
treated as an octal, having a value of 0.

I know that you'll probably answer that it's a feature and not a bug, but
I think that this behaviour should be highlighted in the manual :)

Also checked on PHP 4.1.2, 4.3.0 and 4.3.3

Reproduce code:
---




Expected result:

int(7)
int(8)
int(8)


Actual result:
--
int(7)
int(8)
int(0)


-- 
Edit bug report at http://bugs.php.net/?id=26314&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26314&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26314&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26314&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26314&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26314&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=26314&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26314&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26314&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26314&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26314&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26314&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26314&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26314&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26314&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26314&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26314&r=float

#22592 [NEW]: Cascading assignments to strings with curly braces broken

[matteo at beccati dot com]

From: matteo at beccati dot com
Operating system: Debian GNU/Linux 3.0
PHP version:  4.3.1
PHP Bug Type: Strings related
Bug description:  Cascading assignments to strings with curly braces broken

When using cascading assignments to strings and curly braces, to change
characters within strings, only the last character is changed to the right
value. Other characters become NUL (0x00).




The resulting output is:

a*c*e*
ace*

a%2Ac%2Ae%2A
a%00c%00e%2A


I also tested it on a old PHP 4.2.0-dev, and it gives the same result.
-- 
Edit bug report at http://bugs.php.net/?id=22592&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22592&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22592&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22592&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22592&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22592&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22592&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22592&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22592&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22592&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22592&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22592&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22592&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22592&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22592&r=gnused

#21659 [Bgs->Opn]: sprintf

[matteo]

 ID:   21659
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: *General Issues
-Operating System: 
+Operating System: linux
 PHP Version:  4.3.0
 New Comment:

Error with sprintf i obtain conversion from numbner in not printable
caracter.
various numebr of my application don't work now

see above


Previous Comments:


[2003-01-15 08:09:57] [EMAIL PROTECTED]

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.



[2003-01-15 08:08:41] [EMAIL PROTECTED]

I obtain from php 4.30 and error using sprintf

My  php code generate
a result file in which is it possible to see the bug:


example:



sprintf(%.3f,2.04204204204) = 0.0�0
sprintf(%.3f,2.1981981982) = 000.000
sprintf(%.3f,1.07507507508) = 1.000
sprintf(%.3f,1.98498498498) = 0.000
sprintf(%.3f,0.318318318318) = 0.000
sprintf(%.3f,0.90990990991) = 1.000
sprintf(%.3f,0.660660660661) = 0.000
sprintf(%.3f,2.27327327327) = 00.000


sprintf generate strange non visible alfanumeric caracter 






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

#21659 [NEW]: sprintf

[matteo]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.3.0
PHP Bug Type: *General Issues
Bug description:  sprintf

I obtain from php 4.30 and error using sprintf

My  php code generate
a result file in which is it possible to see the bug:


example:



sprintf(%.3f,2.04204204204) = 0.0�0
sprintf(%.3f,2.1981981982) = 000.000
sprintf(%.3f,1.07507507508) = 1.000
sprintf(%.3f,1.98498498498) = 0.000
sprintf(%.3f,0.318318318318) = 0.000
sprintf(%.3f,0.90990990991) = 1.000
sprintf(%.3f,0.660660660661) = 0.000
sprintf(%.3f,2.27327327327) = 00.000


sprintf generate strange non visible alfanumeric caracter 


-- 
Edit bug report at http://bugs.php.net/?id=21659&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21659&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21659&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21659&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21659&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21659&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21659&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21659&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21659&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21659&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21659&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21659&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21659&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21659&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21659&r=gnused

#16272 [Com]: SegFault in MySQL

[matteo]

 ID:   16272
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: MySQL related
 Operating System: Linux 2.4.x
 PHP Version:  4.1.2
 New Comment:

Same problem:
PHP 4.2.3 compiled from php.net sources
Distro Red Hat 7.3
Dual Intel XEON 1.8GHz
...tons of Segmentation Faults SIG(11)... :(

Any news?
Please, contact me if you have!!!
Everyone of you!

Thank you!


Previous Comments:


[2002-10-20 17:59:30] [EMAIL PROTECTED]

hi people,

i cant get a rest .. this issue just took me weeks for now .. is there
some new knowledge around about this BUG? well ist it one .. is it just
bad php-code .. i am totally lost in this issue .. plz anybody gives
more info and a status about this .. i touched this problem using
latest version am xams(.sourgeforge.net) .. its annoying



[2002-10-02 01:12:50] [EMAIL PROTECTED]

Getting the same problems as the last poster - lots of SIGSEGVs then
the apache processes seem to hang - can't get any data out of them.



[2002-08-12 06:37:18] [EMAIL PROTECTED]

Please change the status of this bug..

This bug is really bothering me, all my users are affected by this bug
because it gives them empty pages :\

Here's a snippet from my errorlog:

[Mon Aug 12 12:01:16 2002] [notice] child pid 20887 exit signal
Segmentation fault (11)
[Mon Aug 12 12:03:09 2002] [notice] child pid 20929 exit signal
Segmentation fault (11)
[Mon Aug 12 12:03:28 2002] [notice] child pid 20938 exit signal
Segmentation fault (11)
[Mon Aug 12 12:05:09 2002] [notice] child pid 20562 exit signal
Segmentation fault (11)
[Mon Aug 12 12:05:18 2002] [notice] child pid 21044 exit signal
Segmentation fault (11)
[Mon Aug 12 12:06:30 2002] [notice] child pid 20925 exit signal
Segmentation fault (11)
[Mon Aug 12 12:07:07 2002] [notice] child pid 21078 exit signal
Segmentation fault (11)
[Mon Aug 12 12:07:13 2002] [notice] child pid 21086 exit signal
Segmentation fault (11)
[Mon Aug 12 12:07:17 2002] [notice] child pid 20559 exit signal
Segmentation fault (11)
[Mon Aug 12 12:07:29 2002] [notice] child pid 21091 exit signal
Segmentation fault (11)
[Mon Aug 12 12:07:37 2002] [notice] child pid 21094 exit signal
Segmentation fault (11)
[Mon Aug 12 12:10:19 2002] [notice] child pid 21237 exit signal
Segmentation fault (11)
[Mon Aug 12 12:10:26 2002] [notice] child pid 21240 exit signal
Segmentation fault (11)
[Mon Aug 12 12:10:57 2002] [notice] child pid 21249 exit signal
Segmentation fault (11)


Mainly using phpBB 2.0.1 on that site. Furthermore I'm using PHP
version 4.2.2 on Linux 2.4.18-5, Apache/1.3.26 with MySQL 3.23.47.
See http://www.bokt.nl/klad/info.php for phpinfo().



[2002-08-07 13:42:16] [EMAIL PROTECTED]

I don't know if my uneducated comment will really contribute to the
understanding of this bug, but I'll offer it up anyway:

I encountered the same problem with the exact same Apache/PHP/MySQL
setup as [EMAIL PROTECTED] When I changed the connection type from
persistent (using mysql_pconnect) to a regular MySQL connection (using
mysql_connect), the problem went away--the script worked fine and no
further segfaults appeared in the http error log.

If others find the same results, then it may be safe to assume the
problem is limited to persistent connections only.



[2002-07-26 01:00:10] [EMAIL PROTECTED]

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



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/16272

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