#21859 [Com]: php cant compile/make

[james]

 ID:   21859
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: RedHat 7
 PHP Version:  4.3.0
 New Comment:

I found this problem too, and it took me a little while to work out not
only what's going on but also the 'right' way to fix it. I'm no expert,
but this seemed to be what's happening:

- That rogue unix.h has probably come from installing the imap
c-client.

Q: Ok, but what should we have there instead? Where's the 'right'
unix.h? Why are we trying to use it in building PHP? Is it important?

A: When you ./configure PHP, it looks to see if it can find a unix.h
lying around, and if it can, it decides it really ought to include it.
That means in our case, the 'rogue' unix.h is marked for inclusion.
Only when you come to 'make' does it discover it's not the expected
kind of unix.h at all, and things fall over.

Fix:
1. Shove the rogue unix.h out of the way 
   # cd /usr/local/include
   # mv unix.h unix_.h
2. Return to your php directory
   # cd /usr/local/lib/php-xxx  ( OR /usr/src/php-xxx OR wherever your
php install lives )
3. If you've already experienced the error, chances are the 'Yes we
should include a unix.h' information is cached, so we need to remove
that.
   # rm config.cache
4. Repeat your ./configure
   # ./configure --with-... --enable-... etc.
5. Do the make - now it won't be expecting to include the unix.h file
and so everything will run fine without it.
6. If you're in the mood, remember to move the unix_.h back to unix.h

HTH, it worked for me.

James
-- proudly sponsoring online youth support at tscnow.com --


Previous Comments:


[2003-01-24 06:14:58] [EMAIL PROTECTED]

./configure --with-apache=/usr/src/apache_1.3.26 --enable-track-vars
--enable-force-cgi --enable-ftp --enable-dbase --with-pear

i looked (searched) for unix.h but i dont have it in 
/usr/include or other dir



[2003-01-24 05:40:30] [EMAIL PROTECTED]

What was the configure line you used?

Also, check if you have more of them in your system:

# find /usr/include -name unix.h

This is caused by wrong install of c-client libs/headers,
you don't need unix.h there..check this manual page:

  http://www.php.net/manual/en/ref.imap.php





[2003-01-24 04:43:05] [EMAIL PROTECTED]

when i try to make "make" with php 4.3 then this comes..
on older versions there no problems with compiling / make


In file included from /usr/src/php-4.3.0/Zend/zend.h:59,
 from /usr/src/php-4.3.0/main/php.h:34,
 from /usr/src/php-4.3.0/ext/ctype/ctype.c:23:
/usr/local/include/unix.h:182: parse error before `MAILSTREAM'
/usr/local/include/unix.h:182: warning: no semicolon at end of struct
or union
/usr/local/include/unix.h:189: parse error before `}'
/usr/local/include/unix.h:189: warning: data definition has no type or
storage class
/usr/local/include/unix.h:193: parse error before `*'
/usr/local/include/unix.h:193: warning: data definition has no type or
storage class
/usr/local/include/unix.h:196: parse error before `*'
/usr/local/include/unix.h:197: parse error before `*'
/usr/local/include/unix.h:198: parse error before `*'
/usr/local/include/unix.h:199: parse error before `*'
/usr/local/include/unix.h:200: parse error before `*'
/usr/local/include/unix.h:201: parse error before `*'
/usr/local/include/unix.h:202: parse error before `*'
/usr/local/include/unix.h:202: parse error before `*'
/usr/local/include/unix.h:202: warning: data definition has no type or
storage class
/usr/local/include/unix.h:203: parse error before `*'
/usr/local/include/unix.h:204: parse error before `*'
/usr/local/include/unix.h:206: parse error before `*'
much more of the warnings then
.
.
.
make: *** [ext/ctype/ctype.lo] Error 1






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

#22217 [NEW]: trim() and ltrim() don't like M

[james]

From: [EMAIL PROTECTED]
Operating system: Debian GNU/Linux
PHP version:  4.2.3
PHP Bug Type: Strings related
Bug description:  trim() and ltrim() don't like M

I found what seems to be a bug with the trim functions, at least with
trim() and ltrim(). I am working with some data like "NAME=First Last"
where I have to trim off "NAME=". Every time a name occurs where the first
name starts with an 'M' then the 'M' would be trimmed off. Any other
character seems to be fine.
-- 
Edit bug report at http://bugs.php.net/?id=22217&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22217&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22217&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22217&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22217&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22217&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22217&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22217&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22217&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22217&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22217&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22217&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22217&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22217&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22217&r=gnused

#21155 [NEW]: Macro Request

[james]

From: [EMAIL PROTECTED]
Operating system: Slackware-current (12/22/02)
PHP version:  4.2.3
PHP Bug Type: Feature/Change Request
Bug description:  Macro Request

Hello,

I would like to request something along the lines of macros. It would help
a lot when you need to run __LINE__ and/or __FILE__ constants through a
function.

A simplified version of what I'd need them for. Currently I have:
errOut([severity], [message]);

Every time I use errOut I have __FILE__ and __LINE__ in the message:
define(FATAL, 7);
errOut(FATAL, __FILE__ . ": " . __LINE__ . ": Database error bla bla
bla");

It could be shortened up by something like this:
mdefine("DOERR", "errOut($1, __FILE__ . ': ' . __LINE__ . ': ' . $2)");
DOERR(FATAL,"Database Error bla bla bla");

This could be used for more vital things than that of course. Anything
along those lines would be great.

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

Bug #16536: Give me inconsisten results

[james]

From: [EMAIL PROTECTED]
Operating system: mac os x
PHP version:  4.1.2
PHP Bug Type: Date/time related
Bug description:  Give me inconsisten results

#get the numeric sunday
$today_var = getdate();
$today_sec = mktime(0,0,0,date("m"),date("d"),date("Y"));
$offset = $today_var[wday] * 86400 ;
$first_day = $today_sec - $offset;
$this_week_first_date = date("ymd", $first_day);
$path=$this_week_first_date;

this just won't get me Sunday this week.. 020407
suddenly at midnight on Monday the 8th it went to 06, this has been
running fine for many many weeks now.

Help
-- 
Edit bug report at http://bugs.php.net/?id=16536&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16536&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16536&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16536&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16536&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16536&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16536&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16536&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16536&r=submittedtwice

Bug #16536 Updated: Give me inconsisten results

[james]

 ID:   16536
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Date/time related
 Operating System: mac os x
 PHP Version:  4.1.2
 New Comment:

No, just trying to get a consistently working numeric date for the
Sunday of that week.  yymmdd

Though a previos algorithm I had:
echo "last sunday: ".date("ymd",
mktime(0,0,0,$mnth,$dy-date("w",mktime(0,0,0,$mnth,$dy,$yr)),$yr))."

Bug #16536 Updated: Give me inconsisten results

[james]

 ID:   16536
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Date/time related
 Operating System: mac os x
 PHP Version:  4.1.2
 New Comment:

OK - my apologies, I have wrapped up into one posting both a bug and a
support issue. I will post on the support area, but, I do believe this
is a bug.


Previous Comments:


[2002-04-11 14:34:58] [EMAIL PROTECTED]

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php





[2002-04-11 14:28:48] [EMAIL PROTECTED]

$today_var = getdate();
$today_sec =
mktime(0,0,0,date("m"),date("d"),date("Y"),1);
$offset = ($today_var['wday']-0) * 86400 ;
$first_day = $today_sec - $offset;
$this_week_first_date = date("ymd",
$first_day);
$path=$this_week_first_date;


Still gives the wrong result.. Doesn't anybody have a reliable piece of
code to Get the Sunday of the current week, this week it should be the
7th not the 6th!

Now this week however this code works:
date("ymd",
mktime(0,0,0,$mnth,$dy-date("w",mktime(0,0,0,$mnth,$dy,$yr)),$yr))

What gives? A real piece of code that works reliably still needed for
me and for sure everybody.



[2002-04-11 12:59:47] [EMAIL PROTECTED]

Guess it worked last week only due to the daylight saving switch which
compensated an off-by-one error in your code.

*Every* piece of code that uses mktime(0,0,0,...) and
addition or subtraction of multiples of 86400 has to
check for daylight saving time switches or use the optional 7th
parameter to mktime() to be correct

this database is full of user bugs related to this issue



[2002-04-11 11:36:14] [EMAIL PROTECTED]

No, just trying to get a consistently working numeric date for the
Sunday of that week.  yymmdd

Though a previos algorithm I had:
echo "last sunday: ".date("ymd",
mktime(0,0,0,$mnth,$dy-date("w",mktime(0,0,0,$mnth,$dy,$yr)),$yr))."

#19449 [NEW]: fork, multi-threading

[james]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.2.3
PHP Bug Type: Feature/Change Request
Bug description:  fork, multi-threading

Is there a chance we could get fork() working for the Windows platform. 

It is currently restricting Windows PHP development to move through in to
the broad field of multi-threaded programming, which would be a great
beneficiary.
-- 
Edit bug report at http://bugs.php.net/?id=19449&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19449&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19449&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19449&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19449&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19449&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19449&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19449&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19449&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19449&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19449&r=globals

Bug #15631: php4apache.dll don't work with Apache 2.0.32

[james]

From: [EMAIL PROTECTED]
Operating system: NT4.0
PHP version:  4.1.1
PHP Bug Type: Apache2 related
Bug description:  php4apache.dll don't work with Apache 2.0.32

php4apache2.dll doesn't work with Apache 2.0.32 (and Apache 2.0, in
general).  We are using PHP 4.1.1

Any timeframe for having this module available for Apache 2.0?

The CGI program does work with Apache 2.0

Thanx,
James Potts
[EMAIL PROTECTED]
-- 
Edit bug report at http://bugs.php.net/?id=15631&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15631&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15631&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15631&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15631&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15631&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15631&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15631&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15631&r=submittedtwice

Bug #15768: FastCgi not picking up envrionemnt variables

[james]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.20
PHP version:  4.1.1
PHP Bug Type: PHP options/info functions
Bug description:  FastCgi not picking up envrionemnt variables

The following script:

 $value) {
 echo $key.":".$value."";
  }
?>

Produces the following output:

PHP_SELF=/dump_globals.php4

Same script of PHP 4.0.x works fine.
Seems to be consistent with the 4.1.x branch.

Server: Zeus 3.4r2

Compile Options:

./configure --prefix=/usr/local/php4 --with-regex=system --enable-calendar
--with-iodbc --with-dom --with-curl --with-openssl --with-db2 --with-iconv
--enable-filepro --enable-ftp --with-gettext --enable-sysvsem
--enable-sysvshm --enable-track-vars --enable-trans-sid --disable-debug
--with-gd=/usr --with-imap=/usr --with-ldap=/usr --with-mm=/usr
--with-mysql=/usr --with-regex=system --with-pcre-regex=/usr
--with-pgsql=/usr --enable-sockets --with-ttf
--enable-freetype-4bit-antialias-hack --with-t1lib --with-zlib
--enable-memory-limit --with-fastcgi=/usr/local/fcgi/ --with-pear
--enable-mbstring --enable-shmop --enable-exif --enable-bcmath
--enable-safemode --with-jpeg-dir=/usr --with-png-dir=/usr
--with-xpm-dir=/usr --with-xslt --with-xslt-sablot --with-mhash
--with-mcrypt=/usr/local
--with-tsrm-pth --enable-wddx --enable-shared=false

Thx

-- 
Edit bug report at http://bugs.php.net/?id=15768&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15768&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15768&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15768&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15768&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15768&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15768&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15768&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15768&r=submittedtwice

Bug #15768 Updated: FastCgi not picking up envrionemnt variables

[james]

 ID:   15768
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: PHP options/info functions
 Operating System: Linux 2.2.20
 PHP Version:  4.1.1
 New Comment:

Sorry, typo, its HTTP_SERVER_VARS

Register globals is turned on so there is no reason why the script
should only return one key/value.

This seems to be a bug in the 4.1.x branch as the same script produces
the expected output in 4.0.x

Thx


Previous Comments:


[2002-02-28 02:07:13] [EMAIL PROTECTED]

I don't see how this is a support question.  In fact, there is no
question at all in this report.  Granted, his example code should
probably use $HTTP_SERVER_VARS, but if it actually behaves like he says
then it appears to be a bug.



[2002-02-28 02:06:32] [EMAIL PROTECTED]

oops..I clicked wrong link. Anyways, your example script
is pretty much bogus. There is no such variable as HTTP_SERV_VARS. Try
this instead:

 $value) {
 echo $key.":".$value."";
  }
?>




[2002-02-28 02:04:01] [EMAIL PROTECTED]

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php



[2002-02-27 19:03:17] [EMAIL PROTECTED]

The following script:

 $value) {
 echo $key.":".$value."";
  }
?>

Produces the following output:

PHP_SELF=/dump_globals.php4

Same script of PHP 4.0.x works fine.
Seems to be consistent with the 4.1.x branch.

Server: Zeus 3.4r2

Compile Options:

./configure --prefix=/usr/local/php4 --with-regex=system
--enable-calendar --with-iodbc --with-dom --with-curl --with-openssl
--with-db2 --with-iconv --enable-filepro --enable-ftp --with-gettext
--enable-sysvsem --enable-sysvshm --enable-track-vars
--enable-trans-sid --disable-debug --with-gd=/usr --with-imap=/usr
--with-ldap=/usr --with-mm=/usr --with-mysql=/usr --with-regex=system
--with-pcre-regex=/usr --with-pgsql=/usr --enable-sockets --with-ttf
--enable-freetype-4bit-antialias-hack --with-t1lib --with-zlib
--enable-memory-limit --with-fastcgi=/usr/local/fcgi/ --with-pear
--enable-mbstring --enable-shmop --enable-exif --enable-bcmath
--enable-safemode --with-jpeg-dir=/usr --with-png-dir=/usr
--with-xpm-dir=/usr --with-xslt --with-xslt-sablot --with-mhash
--with-mcrypt=/usr/local
--with-tsrm-pth --enable-wddx --enable-shared=false

Thx





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

#21614 [NEW]: Non-ASCII characters get entity escaped on input from MSIE only

[james . aylett]

From: [EMAIL PROTECTED]
Operating system: Various
PHP version:  4.2.3
PHP Bug Type: Unknown/Other Function
Bug description:  Non-ASCII characters get entity escaped on input from MSIE only

Entering non-ASCII data (eg in ISO-8859-1) using MSIE 6 and 5.5 (possibly
others) via an HTTP POST (multipart/form-data, perhaps others) request to
PHP 4.2.3 as a dynamically-loaded Apache (1.3 series) module causes the
non-ASCII characters to be HTML entity escaped. eg:

étan -> étan

This does not happen with Mozilla 1.2b (20021016), and did not happen with
PHP 4.1.2 (with mbstring enabled). It happens with both mbstring enabled
and disabled on PHP 4.2.3. It has been observed on Debian GNU/Linux,
FreeBSD and WinXP.
-- 
Edit bug report at http://bugs.php.net/?id=21614&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21614&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21614&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21614&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21614&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21614&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21614&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21614&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21614&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21614&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21614&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21614&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21614&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21614&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21614&r=gnused

#21614 [Bgs->Opn]: Non-ASCII characters get entity escaped on input from MSIE only

[james . aylett]

 ID:   21614
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Various
-PHP Version:  4.2.3
+PHP Version:  4.3.0
 New Comment:

Verified as still present in 4.3.0 without mbstring enabled running on
Solaris.


Previous Comments:


[2003-01-13 19:01:20] [EMAIL PROTECTED]

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.



[2003-01-13 07:29:01] [EMAIL PROTECTED]

Entering non-ASCII data (eg in ISO-8859-1) using MSIE 6 and 5.5
(possibly others) via an HTTP POST (multipart/form-data, perhaps
others) request to PHP 4.2.3 as a dynamically-loaded Apache (1.3
series) module causes the non-ASCII characters to be HTML entity
escaped. eg:

étan -> étan

This does not happen with Mozilla 1.2b (20021016), and did not happen
with PHP 4.1.2 (with mbstring enabled). It happens with both mbstring
enabled and disabled on PHP 4.2.3. It has been observed on Debian
GNU/Linux, FreeBSD and WinXP.




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

#21614 [Fbk->Csd]: Non-ASCII characters get entity escaped on input from MSIE only

[james . aylett]

 ID:   21614
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: *General Issues
 Operating System: Various
 PHP Version:  4.3.0
 New Comment:

With some embarrassment, I now discover that this is actually MSIE's
fault after all. I did test a minimal case before I submitted the bug,
but unfortunately missed out one crucial detail. I'm closing this bug
(mea culpa), but perhaps a hint could be added to documentation at some
point to prevent people falling foul of the same issue?

If you set the charset on your content-type in the _source_ document
(presumably via HTTP, and definitely using meta http-equiv in an HTML
document), MSIE will entity-escape any characters falling outside that
charset for any form submissions from within that document.
Mozilla/NSN6+ doesn't do this, and I don't think it's unreasonable to
assume this is just another weird MSIE bug. Presumably setting the
charset to UTF-8 will prevent IE from escaping any characters. (That
runs into difficulties with the most common configuration of PHP +
mysql, however.)

Apologies for pointing the finger in the wrong direction ... :-(


Previous Comments:


[2003-01-15 15:54:54] [EMAIL PROTECTED]

Does it only happen with multipart/form-data posts?
Can you give us a short, simple script?




[2003-01-15 05:06:09] [EMAIL PROTECTED]

Verified as still present in 4.3.0 without mbstring enabled running on
Solaris.



[2003-01-13 19:01:20] [EMAIL PROTECTED]

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.



[2003-01-13 07:29:01] [EMAIL PROTECTED]

Entering non-ASCII data (eg in ISO-8859-1) using MSIE 6 and 5.5
(possibly others) via an HTTP POST (multipart/form-data, perhaps
others) request to PHP 4.2.3 as a dynamically-loaded Apache (1.3
series) module causes the non-ASCII characters to be HTML entity
escaped. eg:

étan -> étan

This does not happen with Mozilla 1.2b (20021016), and did not happen
with PHP 4.1.2 (with mbstring enabled). It happens with both mbstring
enabled and disabled on PHP 4.2.3. It has been observed on Debian
GNU/Linux, FreeBSD and WinXP.




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

#19456 [NEW]: segfault using ODBC functions

[james . jones]

From: [EMAIL PROTECTED]
Operating system: Redhat Linux
PHP version:  4.2.3
PHP Bug Type: Reproducible crash
Bug description:  segfault using ODBC functions

I've been running PHP 4.2.1 for some time on a test machine with the
following configure options:

'./configure' \
'--with-apxs' \
'--with-ibm-db2=shared' \
'--with-ldap=shared' \
'--with-mcrypt=shared' \
'--with-mhash=shared' \
'--enable-ftp' \
'--with-config-file-path=/etc' \
'--enable-trans-sid' \
'--enable-debug' \
'--with-png-dir=/usr/local' \
'--with-jpeg-dir=/usr/local' \
'--with-zlib=/usr/local' \
'--with-gd=/usr/local' \

Worked fine under Apache 1.3.20. Then I started doing some upgrades,
upgrading Apache to 1.3.26 and OpenSSL to 0.9.6g. At this point, PHP
stopped working, generating a segfault (11) in my Apache log every time an
ODBC function was called. The following script would exhibit this
behavior:

,,);
?>

I was unable to get PHP to segfault with scripts that did not use ODBC
functions.

I then recompiled PHP as a CGI function to get a backtrace, which gives me
this:

#0  0x407173ac in ?? ()
#1  0x40117780 in __libc_start_main () from /lib/libc.so.6

I also stepped through the code while running the script given above. PHP
appears to complete processing entirely, but segfaults when exiting. The
exit_status variable was 0.

I then stepped through the code while running a script with no odbc code:



This appears to complete exactly the same way the ODBC script did, with an
exit_status of 0, but it does not segfault.

Note that I've also upgraded to PHP 4.2.3 and I get the exact same
problem. Here is a summary of my relevant versions:

Linux Kernel 2.2.16
Apache 1.3.26
OpenSSL 0.9.6g
mod_ssl 2.8.10-1.3.26
PHP 4.2.3
libc 2.2.3

Please let me know if I can supply any additional information.
-- 
Edit bug report at http://bugs.php.net/?id=19456&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19456&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19456&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19456&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19456&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19456&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19456&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19456&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19456&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19456&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19456&r=globals

#19456 [Opn]: segfault using ODBC functions

[james . jones]

 ID:   19456
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Redhat Linux
 PHP Version:  4.2.3
 New Comment:

I just recompiled PHP 4.0.6 with all the same options and ODBC works
there. So this seems to be unique to 4.2.x.

I noticed that I had an old version of apxs is /usr/sbin/apxs (which
shouldn't have mattered since I designated the correct apxs in my
configure script). Unfortunately, after changing that I still get the
same problem. So that's not it.


Previous Comments:


[2002-09-17 12:37:40] [EMAIL PROTECTED]

I've been running PHP 4.2.1 for some time on a test machine with the
following configure options:

'./configure' \
'--with-apxs' \
'--with-ibm-db2=shared' \
'--with-ldap=shared' \
'--with-mcrypt=shared' \
'--with-mhash=shared' \
'--enable-ftp' \
'--with-config-file-path=/etc' \
'--enable-trans-sid' \
'--enable-debug' \
'--with-png-dir=/usr/local' \
'--with-jpeg-dir=/usr/local' \
'--with-zlib=/usr/local' \
'--with-gd=/usr/local' \

Worked fine under Apache 1.3.20. Then I started doing some upgrades,
upgrading Apache to 1.3.26 and OpenSSL to 0.9.6g. At this point, PHP
stopped working, generating a segfault (11) in my Apache log every time
an ODBC function was called. The following script would exhibit this
behavior:

,,);
?>

I was unable to get PHP to segfault with scripts that did not use ODBC
functions.

I then recompiled PHP as a CGI function to get a backtrace, which gives
me this:

#0  0x407173ac in ?? ()
#1  0x40117780 in __libc_start_main () from /lib/libc.so.6

I also stepped through the code while running the script given above.
PHP appears to complete processing entirely, but segfaults when
exiting. The exit_status variable was 0.

I then stepped through the code while running a script with no odbc
code:



This appears to complete exactly the same way the ODBC script did, with
an exit_status of 0, but it does not segfault.

Note that I've also upgraded to PHP 4.2.3 and I get the exact same
problem. Here is a summary of my relevant versions:

Linux Kernel 2.2.16
Apache 1.3.26
OpenSSL 0.9.6g
mod_ssl 2.8.10-1.3.26
PHP 4.2.3
libc 2.2.3

Please let me know if I can supply any additional information.




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

#18044 [Com]: apache child segfaults on page using sessions

[james . jones]

 ID:   18044
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: Session related
 Operating System: RedHat Linux 7.2
 PHP Version:  4.2.1
 New Comment:

This appears to be similar to my submitted bug #19456, except that mine
occurs on ODBC calls. Is this still being looked at?


Previous Comments:


[2002-09-17 01:00:01] [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".



[2002-09-03 16:18:38] [EMAIL PROTECTED]

Yep.

Here's an update.

The segfaults are still happening.



[2002-08-30 15:58:10] [EMAIL PROTECTED]

Anybody have any updates on this? I was just wondering if there have
been any new developments regarding the seg faults when using mm_mod to
store session data?



[2002-08-23 13:04:00] [EMAIL PROTECTED]

With build "php4-200208130900" the seg faults are still occuring.



[2002-08-20 14:23:33] [EMAIL PROTECTED]

Which bug fixes is this? Where can I find the CVS "non-stable" build?
Incidentally, I have tried the PHP-Latest build dated
php4-200208131500, compiled using same configure parameters as above.

I recieved the same segmenation faults with this
build(php4-200208131500). Here is my bt of the apache core file:

(gdb) bt
#0  ps_sd_lookup (data=0x11efd0, 
key=0x2b1288 "cfb22d50a65ce80d4af8df54f837ea90", rw=0) at
mod_mm.c:187
#1  0xfe9a83cc in ps_read_mm (mod_data=0x11efd0, 
key=0x2b1288 "cfb22d50a65ce80d4af8df54f837ea90", val=0xffbfc7ac, 
vallen=0xffbfc7a8) at mod_mm.c:326
#2  0xfe9a4938 in php_session_initialize () at session.c:557
#3  0xfe9a5904 in php_session_start () at session.c:953
#4  0xfe9a70c4 in zif_session_start (ht=0, return_value=0x234da8, 
this_ptr=0x0, return_value_used=0) at session.c:1349
#5  0xfe944f38 in execute ()
   from /data2/www/e-webdev1/apache/libexec/libphp4.so
#6  0xfe9476ac in execute ()
   from /data2/www/e-webdev1/apache/libexec/libphp4.so
#7  0xfe954888 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:810
#8  0xfe963748 in php_execute_script (primary_file=0xffbff420) at
main.c:1381
#9  0xfe95ebb8 in apache_php_module_main (r=0x,
display_source_mode=0)
at sapi_apache.c:90
#10 0xfe95f6e8 in send_php (r=0x141ef8, display_source_mode=0,
filename=0x0)
at mod_php4.c:575
#11 0x1f780 in ap_invoke_handler ()
#12 0x3eae0 in process_request_internal ()
#13 0x3eb68 in ap_process_request ()
---Type  to continue, or q  to quit---
#14 0x31760 in child_main ()
#15 0x31b04 in make_child ()
#16 0x31c18 in startup_children ()
#17 0x3262c in standalone_main ()
#18 0x33278 in main ()


Please advise. Thanks in advance.



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

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

#19456 [Fbk->Opn]: segfault using ODBC functions

[james . jones]

 ID:   19456
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: ODBC related
 Operating System: Redhat Linux
 PHP Version:  4.2.3
 New Comment:

Please note that I *did* submit the backtrace. It's very short (only
two lines), presumably because the segfault occurs as the program is
exiting.

I'll try to get an ODBC trace, but again, note that the problem does
NOT occur during the connect, but only as the program exits.


Previous Comments:


[2002-09-17 15:13:01] [EMAIL PROTECTED]

1) Turn on your SQL Logging feature (it will require editing your
odbc.ini).  Add the results of said CONNECT logging to the bug report
if you can. 

2) Please post a backtrace of the segfault, it will help.  Honest.  :)

Also moving this over to ODBC



[2002-09-17 13:26:42] [EMAIL PROTECTED]

I just recompiled PHP 4.0.6 with all the same options and ODBC works
there. So this seems to be unique to 4.2.x.

I noticed that I had an old version of apxs is /usr/sbin/apxs (which
shouldn't have mattered since I designated the correct apxs in my
configure script). Unfortunately, after changing that I still get the
same problem. So that's not it.



[2002-09-17 12:37:40] [EMAIL PROTECTED]

I've been running PHP 4.2.1 for some time on a test machine with the
following configure options:

'./configure' \
'--with-apxs' \
'--with-ibm-db2=shared' \
'--with-ldap=shared' \
'--with-mcrypt=shared' \
'--with-mhash=shared' \
'--enable-ftp' \
'--with-config-file-path=/etc' \
'--enable-trans-sid' \
'--enable-debug' \
'--with-png-dir=/usr/local' \
'--with-jpeg-dir=/usr/local' \
'--with-zlib=/usr/local' \
'--with-gd=/usr/local' \

Worked fine under Apache 1.3.20. Then I started doing some upgrades,
upgrading Apache to 1.3.26 and OpenSSL to 0.9.6g. At this point, PHP
stopped working, generating a segfault (11) in my Apache log every time
an ODBC function was called. The following script would exhibit this
behavior:

,,);
?>

I was unable to get PHP to segfault with scripts that did not use ODBC
functions.

I then recompiled PHP as a CGI function to get a backtrace, which gives
me this:

#0  0x407173ac in ?? ()
#1  0x40117780 in __libc_start_main () from /lib/libc.so.6

I also stepped through the code while running the script given above.
PHP appears to complete processing entirely, but segfaults when
exiting. The exit_status variable was 0.

I then stepped through the code while running a script with no odbc
code:



This appears to complete exactly the same way the ODBC script did, with
an exit_status of 0, but it does not segfault.

Note that I've also upgraded to PHP 4.2.3 and I get the exact same
problem. Here is a summary of my relevant versions:

Linux Kernel 2.2.16
Apache 1.3.26
OpenSSL 0.9.6g
mod_ssl 2.8.10-1.3.26
PHP 4.2.3
libc 2.2.3

Please let me know if I can supply any additional information.




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

#19456 [Fbk->Opn]: segfault using ODBC functions

[james . jones]

 ID:   19456
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: ODBC related
 Operating System: Redhat Linux
 PHP Version:  4.2.3
 New Comment:

This morning I built PHP without using shared modules and it works.
I've noticed this with other modules, too: sometimes if I just link
them statically, they work fine, but if I share them, they don't work.

I was able to generate an ODBC trace (really a CLI trace, to be
pedantic) for a non-working CGI version of 4.2.1:

[ Process: 21425, Thread: 1024 ]
[ Date & Time:  09-18-2002 10:26:51.748775 ]
[ Product:  QDB2/LINUX 7.1.0.40 ]
[ Level Identifier: 03010105 ]
[ CLI Driver Version:   07.02. ]
[ Informational Tokens: "DB2 v7.1.0.40","s010415","U475381" ]



[021425 001024] [1032323211.748941 - 09-18-2002
10:26:51.748941] SQLAllocEnv( phEnv=&08200acc )
[021425 001024] [1032323211.749050 - 09-18-2002
10:26:51.749050] ---> Time elapsed - 0 seconds

[021425 001024] [1032323211.749343 - 09-18-2002
10:26:51.749343] SQLAllocEnv( phEnv=0:1 )
[021425 001024] [1032323211.749419 - 09-18-2002
10:26:51.749419] <--- SQL_SUCCESS   Time elapsed - +4.78E-004
seconds

[021425 001024] [1032323211.749508 - 09-18-2002
10:26:51.749508] SQLAllocConnect( hEnv=0:1, phDbc=&08200ad0 )
[021425 001024] [1032323211.749602 - 09-18-2002
10:26:51.749602] ---> Time elapsed - +8.90E-005 seconds

[021425 001024] [1032323211.749798 - 09-18-2002
10:26:51.749798] SQLAllocConnect( phDbc=0:1 )
[021425 001024] [1032323211.749889 - 09-18-2002
10:26:51.749889] <--- SQL_SUCCESS   Time elapsed - +3.81E-004
seconds

[021425 001024] [1032323211.749973 - 09-18-2002
10:26:51.749973] SQLConnect( hDbc=0:1, szDSN="", cbDSN=-3,
szUID="", cbUID=-3, szAuthStr="", cbAuthStr=-3 )
[021425 001024] [1032323211.750215 - 09-18-2002
10:26:51.750215] ---> Time elapsed - +8.40E-005 seconds
sqlccsend( ulBytes - 1622 )
sqlccsend( Handle - 1085627784 )
sqlccsend( ) - rc - 0, time elapsed - +1.55E-004
sqlccrecv( )
sqlccrecv( ulBytes - 1262 ) - rc - 0, time elapsed -
+4.329000E-003
sqlccsend( ulBytes - 611 )
sqlccsend( Handle - 1085627784 )
sqlccsend( ) - rc - 0, time elapsed - +7.00E-005
sqlccrecv( )
sqlccrecv( ulBytes - 237 ) - rc - 0, time elapsed - +1.099620E-001
[021425 001024] [1032323211.868023 - 09-18-2002
10:26:51.868023] ( DBMS NAME="DB2/SUN", Version="07.02.",
Fixpack="0x23010105" )
[021425 001024] [1032323211.868184 - 09-18-2002
10:26:51.868184] 
[021425 001024] [1032323211.868226 - 09-18-2002
10:26:51.868226] ( Application Codepage=819, Database  Codepage=1252,
Char Send/Recv Codepage=819, Graphic Send/Recv Codepage=819, iGraphic
Codepage=819 )
[021425 001024] [1032323211.868395 - 09-18-2002
10:26:51.868395] 

[021425 001024] [1032323211.868475 - 09-18-2002
10:26:51.868475] SQLConnect( )
[021425 001024] [1032323211.868520 - 09-18-2002
10:26:51.868520] <--- SQL_SUCCESS   Time elapsed - +1.185470E-001
seconds
[021425 001024] [1032323211.868576 - 09-18-2002
10:26:51.868576] ( DSN="""" )
[021425 001024] [1032323211.868644 - 09-18-2002
10:26:51.868644] 
[021425 001024] [1032323211.868685 - 09-18-2002
10:26:51.868685] ( UID="""" )
[021425 001024] [1032323211.868753 - 09-18-2002
10:26:51.868753] 
[021425 001024] [1032323211.868794 - 09-18-2002
10:26:51.868794] ( PWD="" )
[021425 001024] [1032323211.868861 - 09-18-2002
10:26:51.868861] 

[021425 001024] [1032323211.869275 - 09-18-2002
10:26:51.869275] SQLDisconnect( hDbc=0:1 )
[021425 001024] [1032323211.869378 - 09-18-2002
10:26:51.869378] ---> Time elapsed - +7.55E-004 seconds
sqlccsend( ulBytes - 72 )
sqlccsend( Handle - 1085627784 )
sqlccsend( ) - rc - 0, time elapsed - +8.80E-005
sqlccrecv( )
sqlccrecv( ulBytes - 27 ) - rc - 0, time elapsed - +5.39E-003

[021425 001024] [1032323211.875169 - 09-18-2002
10:26:51.875169] SQLDisconnect( )
[021425 001024] [1032323211.875226 - 09-18-2002
10:26:51.875226] <--- SQL_SUCCESS   Time elapsed - +5.951000E-003
seconds

[021425 001024] [1032323211.875325 - 09-18-2002
10:26:51.875325] SQLFreeConnect( hDbc=0:1 )
[021425 001024] [1032323211.875394 - 09-18-2002
10:26:51.875394] ---> Time elapsed - +9.90E-005 seconds

[021425 001024] [1032323211.875498 - 09-18-2002
10:26:51.875498] SQLFreeConnect( )
[021425 001024] [1032323211.875578 - 09-18-2002
10:26:51.875578] <--- SQL_SUCCESS   Time elapsed - +2.53E-004
seconds

[021425 001024] [1032323211.875650 - 09-18-2002
10:26:51.875650] SQLFreeEnv( hEnv=0:1 )
[021425 001024] [

#24590 [Opn]: True FastCGI support

[james at grickel dot org]

 ID:  24590
 User updated by: james at grickel dot org
 Reported By: james at grickel dot org
 Status:  Open
 Bug Type:Feature/Change Request
 PHP Version: Irrelevant
 New Comment:

Would it be possible to implement this easily through an extension?
It'd probably be a good idea to work on this in PHP5 since PHP5 is
almost out and it woudl be easier to integrate.

Who's interested in this?


Previous Comments:


[2003-08-09 15:23:33] dpenning at s0nix dot de

imho this should be implemented as an php-extension.
then the user would have to run the script via php-cli



[2003-07-10 10:19:33] james at grickel dot org

Description:

Currently PHP's FastCGI's code just keeps php loaded while the script
is executed over and over every time.

I'm proposing a system where fastcgi could be natively used by the php
script. Like how fastcgi is used in perl, or C.

The code could possibly look something like this:
--
#!/usr/bin/php-fastcgi

--

This would allow large scripts that load lots of data to keep them
loaded and serve many requests.

This would be very advantagous for performance. The script itself would
look like a fastcgi script to the server. Not the php executable. So
you wouldn't be able to use the apache Action directive. You'd just
need to have the hash-bang in every php file.

I'm not familiar enough with php's sapi, nor fastcgi. But from what I
know it should be possible if you don't use treat the php _script_ as a
cgi and use the hash-bang on every file.

Thanks,
James Harr






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

#32755 [NEW]: Segfault in replaceChild() when DocumentFragment has no children

[james at safesearching dot com]

From: james at safesearching dot com
Operating system: RedHat 7.3
PHP version:  5CVS-2005-04-18 (dev)
PHP Bug Type: DOM XML related
Bug description:  Segfault in replaceChild() when DocumentFragment has no 
children

Description:

Segfault occurs when calling DOMNode::replaceChild($newNode, $oldNode) if
$newNode is a DocumentFragment with no children.

The segfault occurs on line 62 of ext/dom/node.c:

dom_reconcile_ns (doc=0x81aff20, nodep=0x0)
at /home/james/php5-STABLE-200504182039/ext/dom/node.c:62
62  if (nodep->type == XML_ELEMENT_NODE) {

Code runs test against nodep->type when nodep is NULL.

Was tested on both 5.0.4 (w/ node.c,v 1.29.2.4) and 5.0.5-dev
(STABLE-200504182039).

Reproduce code:
---
\n";
$dom = new DomDocument;

$dom->loadXML($xml);

$root = $dom->documentElement;
$frag = $dom->createDocumentFragment();

$root->replaceChild($frag, $root->firstChild);

print_r($dom->saveXML());

?>


Expected result:

Not exactlly sure... perhaps issue a warning indicating that the
DocumentFragment object had no children and remove oldNode? Maybe generate
a fatal error?

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 27878)]
dom_reconcile_ns (doc=0x81d0540, nodep=0x0)
at /home/james/php5-STABLE-200504182039/ext/dom/node.c:62
62  if (nodep->type == NULL) {


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

#32755 [Opn]: Segfault in replaceChild() when DocumentFragment has no children

[james at safesearching dot com]

 ID:   32755
 User updated by:  james at safesearching dot com
 Reported By:  james at safesearching dot com
 Status:   Open
 Bug Type: DOM XML related
 Operating System: RedHat 7.3
 PHP Version:  5CVS-2005-04-18 (dev)
 New Comment:

Reproduce code didn't quite make it all the way in... full code is:

\n";
$dom = new DomDocument;

$dom->loadXML($xml);

$root = $dom->documentElement;
$frag = $dom->createDocumentFragment();

$root->replaceChild($frag, $root->firstChild);

print_r($dom->saveXML());

?>


Previous Comments:
----

[2005-04-19 00:09:33] james at safesearching dot com

Description:

Segfault occurs when calling DOMNode::replaceChild($newNode, $oldNode)
if $newNode is a DocumentFragment with no children.

The segfault occurs on line 62 of ext/dom/node.c:

dom_reconcile_ns (doc=0x81aff20, nodep=0x0)
at /home/james/php5-STABLE-200504182039/ext/dom/node.c:62
62  if (nodep->type == XML_ELEMENT_NODE) {

Code runs test against nodep->type when nodep is NULL.

Was tested on both 5.0.4 (w/ node.c,v 1.29.2.4) and 5.0.5-dev
(STABLE-200504182039).

Reproduce code:
---
\n";
$dom = new DomDocument;

$dom->loadXML($xml);

$root = $dom->documentElement;
$frag = $dom->createDocumentFragment();

$root->replaceChild($frag, $root->firstChild);

print_r($dom->saveXML());

?>


Expected result:

Not exactlly sure... perhaps issue a warning indicating that the
DocumentFragment object had no children and remove oldNode? Maybe
generate a fatal error?

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 27878)]
dom_reconcile_ns (doc=0x81d0540, nodep=0x0)
at /home/james/php5-STABLE-200504182039/ext/dom/node.c:62
62  if (nodep->type == NULL) {






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

#25876 [Com]: session_start(): Failed to initialize storage module

[james at westcoastbmx dot com]

 ID:   25876
 Comment by:   james at westcoastbmx dot com
 Reported By:  golden at riscom dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: freebsd 4.8
 PHP Version:  4.3.9-4.3.10
 Assigned To:  sniper
 New Comment:

i have this problem as well.

as long as:
   php_value session.save_handleruser
is in my .htaccess file

session_start(); 

will not work.


Previous Comments:


[2005-03-28 19:27:40] clix at theclixnetwork dot com

A client of mine is having the same problem. The script uses:

session_start();
session_register('susername');
session_register('spassword');
session_register('sreferer');
session_register('susecode');

No destroy or anything special. If $username is set, than it sets the
session $susername to $username. He tried accessing the page within a
short time period after me, both passing the same username. However
when I access it again it doesn't give me the error.



[2005-03-25 01:52:28] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2005-03-18 10:02:14] [EMAIL PROTECTED]

See bug #32330 for similar issue. Do you use session_destroy()
anywhere? Or session_decode()? 




[2003-10-17 04:39:19] golden at riscom dot com

/tmp is not a separate partition
/dev/da0s1a   4.7G   133M   4.2G 3%/



[2003-10-17 04:37:05] golden at riscom dot com

-bash-2.05b$ ls -l
drwxrwxrwt   4 root  wheel 2048 Oct 17 11:37 tmp



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

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

#33459 [NEW]: default behaviour of class_exists/__autoload() breaks PEAR classes (and others)

[james at safesearching dot com]

From: james at safesearching dot com
Operating system: redhat 7.3
PHP version:  5.0.4
PHP Bug Type: Dynamic loading
Bug description:  default behaviour of class_exists/__autoload() breaks PEAR 
classes (and others)

Description:

The default behaviour of class_exists calling __autoload breaks BC for end
user scripts which rely on other code outside that users control (ie PEAR
classes).

Many PEAR classes such as Calendar and DB_DataObject use class_exists to
load other classes...

Simply adding an __autoload function to a script using these classes
generates a Fatal error.

An option was added to allow a class_exists($name, FALSE) call to prevent
an __autoload call... but as end users don't have control over things like
PEAR classes, this isn't a viable fix to bug #28333.

Perhaps more reasonably, class_exists should not call __autoload by
default so as to maintain BC... and allow users to explicity request that
behaviour with a second parameter of TRUE.

Reproduce code:
---
require_once('Calendar/Calendar.php');

$cal = new Calendar();

function __autoload($name) {
require_once($name);
}

Expected result:

Expect no output (ie no errors).

Actual result:
--
Warning: __autoload(Calendar_Engine_UnixTS): failed to open stream: No
such file or directory in /home/james/test.php on line 8

Fatal error: __autoload(): Failed opening required
'Calendar_Engine_UnixTS' (include_path='.:/usr/local/lib/php') in
/home/test.php on line 8

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

#33459 [Opn]: default behaviour of class_exists/__autoload() breaks PEAR classes (and others)

[james at safesearching dot com]

 ID:   33459
 User updated by:  james at safesearching dot com
 Reported By:  james at safesearching dot com
 Status:   Open
-Bug Type: Dynamic loading
+Bug Type: Zend Engine 2 problem
 Operating System: redhat 7.3
 PHP Version:  5.0.4
 New Comment:

changing category


Previous Comments:


[2005-06-24 05:37:07] james at safesearching dot com

Description:

The default behaviour of class_exists calling __autoload breaks BC for
end user scripts which rely on other code outside that users control
(ie PEAR classes).

Many PEAR classes such as Calendar and DB_DataObject use class_exists
to load other classes...

Simply adding an __autoload function to a script using these classes
generates a Fatal error.

An option was added to allow a class_exists($name, FALSE) call to
prevent an __autoload call... but as end users don't have control over
things like PEAR classes, this isn't a viable fix to bug #28333.

Perhaps more reasonably, class_exists should not call __autoload by
default so as to maintain BC... and allow users to explicity request
that behaviour with a second parameter of TRUE.

Reproduce code:
---
require_once('Calendar/Calendar.php');

$cal = new Calendar();

function __autoload($name) {
require_once($name);
}

Expected result:

Expect no output (ie no errors).

Actual result:
--
Warning: __autoload(Calendar_Engine_UnixTS): failed to open stream: No
such file or directory in /home/james/test.php on line 8

Fatal error: __autoload(): Failed opening required
'Calendar_Engine_UnixTS' (include_path='.:/usr/local/lib/php') in
/home/test.php on line 8





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

#33459 [Bgs]: default behaviour of class_exists/__autoload() breaks PEAR classes (and others)

[james at safesearching dot com]

 ID:   33459
 User updated by:  james at safesearching dot com
 Reported By:  james at safesearching dot com
 Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.*
 New Comment:

I fail to see how a change (that doesn't really make sense in the first
place) implemented by the PHP group at the request of some outside
organization is the problem of said organization.

If the PHP group makes a change (regardless of whoever requested it)
that breaks BC with existing scripts, the problem falls squarely on the
PHP group.

If the current behvaiour is to be left in place, then the documentation
needs to clearly state that the use of __autoload in conjuction with
older scripts using class_exists can cause problems.

Alternatively (and perferably), the end user should be given some level
of greater control when using __autoload. Examples being: a) a php.ini
option to allow users to set the default behaviour of class_exists, b)
a way to return from __autoload that doesn't generate a fatal error:

function __autoload($name) {
  if (in_array($name, $ignoreList))
return true;
  require_once($name);
}

c) allow class_exists($name, TRUE) to call __autoload (as opposed to
FALSE)

When it gets down to it, it doesn't make sense to "throw a fatal error
when you're writing code to avoid a fatal error." Refer to
http://news.php.net/php.internals/16746 to see a discussion regarding a
very similar (same?) problem with instanceOf.


Previous Comments:


[2005-06-24 15:23:45] [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

That's not a problem of PHP but a problem of PEAR not taking care of
PHP 5 and their own requests for PHP 5.

----

[2005-06-24 05:37:07] james at safesearching dot com

Description:

The default behaviour of class_exists calling __autoload breaks BC for
end user scripts which rely on other code outside that users control
(ie PEAR classes).

Many PEAR classes such as Calendar and DB_DataObject use class_exists
to load other classes...

Simply adding an __autoload function to a script using these classes
generates a Fatal error.

An option was added to allow a class_exists($name, FALSE) call to
prevent an __autoload call... but as end users don't have control over
things like PEAR classes, this isn't a viable fix to bug #28333.

Perhaps more reasonably, class_exists should not call __autoload by
default so as to maintain BC... and allow users to explicity request
that behaviour with a second parameter of TRUE.

Reproduce code:
---
require_once('Calendar/Calendar.php');

$cal = new Calendar();

function __autoload($name) {
require_once($name);
}

Expected result:

Expect no output (ie no errors).

Actual result:
--
Warning: __autoload(Calendar_Engine_UnixTS): failed to open stream: No
such file or directory in /home/james/test.php on line 8

Fatal error: __autoload(): Failed opening required
'Calendar_Engine_UnixTS' (include_path='.:/usr/local/lib/php') in
/home/test.php on line 8





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

#33612 [NEW]: Uncaught exceptions do not always give an error

[james at academicsuperstore dot com]

From: james at academicsuperstore dot com
Operating system: Debian -stable
PHP version:  5.0.4
PHP Bug Type: Unknown/Other Function
Bug description:  Uncaught exceptions do not always give an error

Description:

In the event at run time an uncaught exception is found then there is a
fatal error.  However, in the event that there are uncaught exceptions
that are not executed such as in the reproduce code there is not even a
notice.

Reproduce code:
---


Expected result:

Fatal error: Uncaught exception 'Exception' with message 'foo' in
/home/james/html/live_web/test.php:5 Stack trace: #0

Actual result:
--
No messages at all.

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

#33612 [Bgs->Opn]: Uncaught exceptions do not always give an error

[james at academicsuperstore dot com]

 ID:   33612
 User updated by:  james at academicsuperstore dot com
 Reported By:  james at academicsuperstore dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Debian -stable
 PHP Version:  5.0.4
 New Comment:

I re-read the documentation.  This is non-obvious based on the docs. 
In fact it is exactly the opposite behavior from java and c++ which is
why I assume it is a bug.  If the programmer fails to catch exceptions
and a corner case doesn't come up until a site is deployed there is
nothing the programmer can do.  In the event that php always informed
you via a notice or some other method that you forgot to catch an
exception then this issue would not come up.


Previous Comments:


[2005-07-08 00:16:30] [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





[2005-07-08 00:01:04] james at academicsuperstore dot com

Description:

In the event at run time an uncaught exception is found then there is a
fatal error.  However, in the event that there are uncaught exceptions
that are not executed such as in the reproduce code there is not even a
notice.

Reproduce code:
---


Expected result:

Fatal error: Uncaught exception 'Exception' with message 'foo' in
/home/james/html/live_web/test.php:5 Stack trace: #0

Actual result:
--
No messages at all.





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

#33689 [NEW]: query() execute() and fetch() all return false on valid select queries

[james at safesearching dot com]

From: james at safesearching dot com
Operating system: *
PHP version:  5CVS-2005-07-14 (dev)
PHP Bug Type: PDO related
Bug description:  query() execute() and fetch() all return false on valid 
select queries

Description:

The code below works fine in 5.1.0b2 for me. In 5.1.0b3 and CVS, however,
the code produces an error and segfaults.

In b3/CVS the table is created and the value is inserted.

$db->query('SELECT * FROM foo') returns false and causes the invalid
argument error.

$stmt->execute() returns false.

Accessing $stmt->getColumnMeta() causes a segfault.

Throwing a $stmt->fetch() between execute() and getColumnMeta() produces
the correct results. (but query() obviously still returns false)

Reproduce code:
---
header('Content-type: text/plain');

$db = new PDO('mysql:dbname=test;host=localhost','**','**');

$db->query('CREATE TABLE `foo` ( `bar` INT NOT NULL );');
$db->query('INSERT INTO foo VALUES(1)');

var_dump($db->query('SELECT * FROM foo'));

foreach ($db->query('SELECT * FROM foo') as $row) {
print_r($row);
}

$stmt = $db->prepare('SELECT * FROM foo');
$stmt->execute();

print_r($stmt->getColumnMeta(0));

Expected result:

object(PDOStatement)#2 (1) {
  ["queryString"]=>
  string(17) "SELECT * FROM foo"
}
Array
(
[bar] => 1
[0] => 1
)
Array
(
[native_type] => LONG
[flags] => Array
(
[0] => not_null
)

[name] => bar
[len] => 11
[precision] => 0
[pdo_type] => 2
)

Actual result:
--
bool(false)

Warning:  Invalid argument supplied for foreach() in test.php on line 10

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 8530)]
zif_PDOStatement_getColumnMeta (ht=1, return_value=0x8173554,
return_value_ptr=0x0, this_ptr=0x816e6fc, return_value_used=1)
at /home/james/php5-200507140030/ext/pdo/pdo_stmt.c:1550
1550add_assoc_string(return_value, "name", col->name, 1);
(gdb) bt
#0  zif_PDOStatement_getColumnMeta (ht=1, return_value=0x8173554,
return_value_ptr=0x0, this_ptr=0x816e6fc, return_value_used=1)
at /home/james/php5-200507140030/ext/pdo/pdo_stmt.c:1550
#1  0x404e2e30 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffc9d0)
at /home/james/php5-200507140030/Zend/zend_vm_execute.h:184
#2  0x404e2a59 in execute (op_array=0x816e534)
at /home/james/php5-200507140030/Zend/zend_vm_execute.h:87
#3  0x404c576c in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /home/james/php5-200507140030/Zend/zend.c:1087
#4  0x404956ce in php_execute_script (primary_file=0xbfffed30)
at /home/james/php5-200507140030/main/main.c:1672
#5  0x40558eee in apache_php_module_main (r=0x8160f78,
display_source_mode=0)
at /home/james/php5-200507140030/sapi/apache/sapi_apache.c:53
#6  0x405598e0 in send_php (r=0x8160f78, display_source_mode=0,
filename=0x0)
at /home/james/php5-200507140030/sapi/apache/mod_php5.c:643
#7  0x4055992e in send_parsed_php (r=0x8160f78)
at /home/james/php5-200507140030/sapi/apache/mod_php5.c:658
#8  0x0805480d in ap_invoke_handler ()
#9  0x08067b0c in process_request_internal ()
#10 0x08067b83 in ap_process_request ()
#11 0x0805fc97 in child_main ()
#12 0x0805fe3a in make_child ()
#13 0x0805ff7d in startup_children ()
#14 0x080605d0 in standalone_main ()
#15 0x08060ed3 in main ()
#16 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

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

#26344 [NEW]: child pid xxxx exit signal Segmentation fault (11)

[james at vcv dot net]

From: james at vcv dot net
Operating system: redhat 9
PHP version:  4.3.4
PHP Bug Type: Reproducible crash
Bug description:  child pid  exit signal Segmentation fault (11)

Description:

./configure \
--with-apxs2=/usr/local/apache_ssl/bin/apxs \
--with-config-file-path=/usr/local/lib \
--enable-track-vars=yes \
--with-pdflib=/usr/local/ \
--with-zlib-dir=/usr/lib/ \
--with-gd=../gd-2.0.15 \
--enable-gd-imgstrttf \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--enable-gd-native-ttf \
--with-ming=/usr/local/src/ming-0.2a/php_ext \
--with-freetype-dir=/usr/local/include/freetype2/freetype/ \
--with-ttf=/usr/local/lib \
--enable-memory-limit \
--enable-debug \
--enable-sigchild

no change is made to the php.ini-dist 
phpinfo is at:
http://www.martysmom.com/phpinfo.php

tried gdb:

(gdb) run -X
Starting program: /usr/local/apache_ssl/bin/httpd -X
[New Thread 1075477920 (LWP 6941)]
Couldn't get registers: Operation not permitted.
(gdb) bt
Cannot fetch general-purpose registers for thread 1075477920: generic
error
(gdb)


Reproduce code:
---
 0.5));
Header("Content-type: image/png");
ImagePNG($image);
ImageDestroy($image);
?>

Expected result:

"Hello World!" on a png graphic 700x300

Actual result:
--
sometimes I get the expected result and sometimes I get
"child pid  exit signal Segmentation fault (11)"
from versions 4.3.2, 4.3.3, 4.3.4, php-5.0.0b2.

I always get the expected result from versions 4.3.1, 4.3.0


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

#26344 [Fbk->Opn]: child pid xxxx exit signal Segmentation fault (11)

[james at vcv dot net]

 ID:   26344
 User updated by:  james at vcv dot net
 Reported By:  james at vcv dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: redhat 9
 PHP Version:  4.3.4
 New Comment:

Thank you for your help.

I have tried to generate backtrace using various methods:
HTTPD -X, (gdb) run -X, and php_cli but failed to get any result except
what I provided in the first report 'Couldn't get registers: Operation
not permitted.'

I upgraded gdb to latest version 6. It did not help. Somewhere I read
that I need to upgrade the kernel for it to work. My current kernel is
2.4.20-8

Apache model:
httpd-2.0.48

./configure --prefix=/usr/local/apache_ssl \
--enable-modules="vhost_alias" \
--enable-ssl \
--with-ssl=/usr/local/openssl \
--enable-so


Previous Comments:


[2003-11-21 11:57:54] [EMAIL PROTECTED]

Please generate a backtrace of the crash. Also, which model is your
apache using?

----

[2003-11-21 04:06:35] james at vcv dot net

Description:

./configure \
--with-apxs2=/usr/local/apache_ssl/bin/apxs \
--with-config-file-path=/usr/local/lib \
--enable-track-vars=yes \
--with-pdflib=/usr/local/ \
--with-zlib-dir=/usr/lib/ \
--with-gd=../gd-2.0.15 \
--enable-gd-imgstrttf \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--enable-gd-native-ttf \
--with-ming=/usr/local/src/ming-0.2a/php_ext \
--with-freetype-dir=/usr/local/include/freetype2/freetype/ \
--with-ttf=/usr/local/lib \
--enable-memory-limit \
--enable-debug \
--enable-sigchild

no change is made to the php.ini-dist 
phpinfo is at:
http://www.martysmom.com/phpinfo.php

tried gdb:

(gdb) run -X
Starting program: /usr/local/apache_ssl/bin/httpd -X
[New Thread 1075477920 (LWP 6941)]
Couldn't get registers: Operation not permitted.
(gdb) bt
Cannot fetch general-purpose registers for thread 1075477920: generic
error
(gdb)


Reproduce code:
---
 0.5));
Header("Content-type: image/png");
ImagePNG($image);
ImageDestroy($image);
?>

Expected result:

"Hello World!" on a png graphic 700x300

Actual result:
--
sometimes I get the expected result and sometimes I get
"child pid  exit signal Segmentation fault (11)"
from versions 4.3.2, 4.3.3, 4.3.4, php-5.0.0b2.

I always get the expected result from versions 4.3.1, 4.3.0






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

#30144 [NEW]: values used in __set() overload don't remain consistent.

[james at grickle dot org]

From: james at grickle dot org
Operating system: Slackware Linux -current
PHP version:  5CVS-2004-09-18 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description:  values used in __set() overload don't remain consistent.

Description:

All the debugging output has been done on php-5.0.1, but it happens from
5.0.1 to the 5.1 CVS tree.

The class I'm using is available here: http://www.grickle.org/url.php.txt

I don't know what exactly is happening, but I think that php is using a
reference to a variable when it shouldn't be using a reference.

In the reproduce code, there is a var_dump in the set() function just
before it returns showing that in all scenarios that it did its job,
howevever the var_dump of the entire class afterwards shows that something
gets boched.

In the larger program that this is used in, it does survive the initial
urlencode() errors, however php segfaults after making only a few steps
further.

Here are my PHP compile flags (noting that this bug happens both through
apache2 and the cli, showing that it's not a problem with the sapi):
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--with-zlib \
--enable-sigchild \
--with-openssl \
--enable-bcmath \
--enable-calendar \
--enable-exif \
--with-fam \
--enable-ftp \
--with-mysql \
--with-gd \
--enable-gd-native-ttf \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--with-tsrm-pthreads \
--enable-force-cgi-redirect \
--enable-debug \
--with-apxs2=/usr/local/apache/bin/apxs

I don't have any backtraces because segfaults only happen when you
continue running code after this bug gets hit. I hope you find this useful
and find a fix for it because I spent about 3 hours weeding down the errors
and crashes of a fairly large cms to get to this point :)

Thanks,
James Harr


Reproduce code:
---
$n = 1;
var_dump($u);
print "\n".$u->getURL()."\n";

?>

Everything works if instead of:
$u->$n = 1;
I call one of these:
$u->__set($n,1);
$u->page = 1;
$u->set($n,1);


Expected result:

Inside set(): page -> 1
array(1) {
  [0]=>
  array(2) {
[0]=>
string(4) "page"
[1]=>
int(1)
  }
}
object(URL)#1 (2) {
  ["url:private"]=>
  string(0) ""
  ["params:private"]=>
  array(1) {
[0]=>
array(2) {
  [0]=>
  string(4) "page"
  [1]=>
  int(1)
}
  }
}

showpages.php?page=1

Actual result:
--
Inside set(): page -> 1
array(1) {
  [0]=>
  array(2) {
[0]=>
string(4) "page"
[1]=>
int(1)
  }
}
object(URL)#1 (2) {
  ["url:private"]=>
  string(0) ""
  ["params:private"]=>
  array(1) {
[0]=>
array(2) {
  [0]=>
  &UNKNOWN:0
  [1]=>
  int(1)
}
  }
}

Warning: urlencode() expects parameter 1 to be string, unknown given in
url.php on line 111
showpages.php?=1

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

#30202 [NEW]: $array[xyz] = xyz; doesn't work inside a class

[james at processit dot biz]

From: james at processit dot biz
Operating system: Windows Server 2003
PHP version:  5.0.0
PHP Bug Type: *General Issues
Bug description:  $array[xyz] = xyz; doesn't work inside a class

Description:

In a function inside a class, I can only set array elements through the
$xyz = array("key"=>"val") syntax. If I attempt to set with $xyz['key'] =
'val', the whole array is replaced with 'val' and it just becomes a normal
variable, not an array.

Reproduce code:
---
$array = array("key1"=>"val1", "key2"=>"val2");

print_r($this->$array);

$this->$array['key1'] = 'val3';

print_r($this->$array);
}
}


$class = new Test;

$class->arraytester();
?>

Expected result:

Array ( [key1] => val1 [key2] => val2 ) Array ( [key1] => val3 [key2] =>
val2 )

Actual result:
--
Array ( [key1] => val1 [key2] => val2 ) val3

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

#32615 [NEW]: Segfault in DOMNode::replaceChild() when previousSibling is NULL

[james at safesearching dot com]

From: james at safesearching dot com
Operating system: Redhat 7.3
PHP version:  5.0.4
PHP Bug Type: DOM XML related
Bug description:  Segfault in DOMNode::replaceChild() when previousSibling is 
NULL 

Description:

Segfaults occurs when calling DOMNode::replaceChild() if previousSibling
is NULL and nextSibling is not NULL.

The segfault occurs on line 1150 of ext/dom/node.c. The relevant code
being:

if (prevsib == NULL && nextsib == NULL) {
nodep->children = newchild;
nodep->last = fragment->last;
} else {
if (newchild) {
prevsib->next = newchild;<--- segfault is here
newchild->prev = prevsib;

fragment->last->next = nextsib;
if (nextsib) {
nextsib->prev = fragment->last;
} else {
nodep->last = fragment->last;
}
}
}

The code doesn't check for the possibility that prevsib == NULL and
nextsib != NULL.

Reproduce code:
---
\n";
$dom = new DomDocument;

$dom->loadXML($xml);

$root = $dom->documentElement;
$node = $dom->createElement('newfirst');
$frag = $dom->createDocumentFragment();

$frag->appendChild($node);
$root->replaceChild($frag, $root->firstChild);

print_r($dom->saveXML());

?>


Expected result:




Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4477)]
0x403490ac in zif_dom_node_replace_child (ht=2, return_value=0x814822c,
this_ptr=0x81452c4, return_value_used=0)
at /home/james/php-5.0.4/ext/dom/node.c:1150
1150prevsib->next = newchild;
(gdb) bt
#0  0x403490ac in zif_dom_node_replace_child (ht=2,
return_value=0x814822c,
this_ptr=0x81452c4, return_value_used=0)
at /home/james/php-5.0.4/ext/dom/node.c:1150
#1  0x4047ac3a in zend_do_fcall_common_helper (execute_data=0xbfffb4c0,
opline=0x814a310, op_array=0x81451cc)
at /home/james/php-5.0.4/Zend/zend_execute.c:2727
#2  0x4047b1a7 in zend_do_fcall_by_name_handler (execute_data=0xbfffb4c0,
opline=0x814a310, op_array=0x81451cc)
at /home/james/php-5.0.4/Zend/zend_execute.c:2841
#3  0x40477a55 in execute (op_array=0x81451cc)
at /home/james/php-5.0.4/Zend/zend_execute.c:1406
#4  0x404530e3 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /home/james/php-5.0.4/Zend/zend.c:1069
#5  0x404123b8 in php_execute_script (primary_file=0xbfffd820)
at /home/james/php-5.0.4/main/main.c:1632
#6  0x40482442 in apache_php_module_main (r=0x8138480,
display_source_mode=0)
at /home/james/php-5.0.4/sapi/apache/sapi_apache.c:54
#7  0x4048310c in send_php (r=0x8138480, display_source_mode=0,
filename=0x8139f88 "/var/www/html/test1.php")
at /home/james/php-5.0.4/sapi/apache/mod_php5.c:622
#8  0x40483165 in send_parsed_php (r=0x8138480)
at /home/james/php-5.0.4/sapi/apache/mod_php5.c:637
#9  0x0805480d in ap_invoke_handler ()
#10 0x08067b0c in process_request_internal ()
#11 0x08067b83 in ap_process_request ()
#12 0x0805fc97 in child_main ()
#13 0x0805fe3a in make_child ()
#14 0x0805ff7d in startup_children ()
#15 0x080605d0 in standalone_main ()
#16 0x08060ed3 in main ()
#17 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6


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

#24590 [NEW]: True FastCGI support

[james at grickel dot org]

From: james at grickel dot org
Operating system: 
PHP version:  Irrelevant
PHP Bug Type: Feature/Change Request
Bug description:  True FastCGI support

Description:

Currently PHP's FastCGI's code just keeps php loaded while the script is
executed over and over every time.

I'm proposing a system where fastcgi could be natively used by the php
script. Like how fastcgi is used in perl, or C.

The code could possibly look something like this:
--
#!/usr/bin/php-fastcgi

--

This would allow large scripts that load lots of data to keep them loaded
and serve many requests.

This would be very advantagous for performance. The script itself would
look like a fastcgi script to the server. Not the php executable. So you
wouldn't be able to use the apache Action directive. You'd just need to
have the hash-bang in every php file.

I'm not familiar enough with php's sapi, nor fastcgi. But from what I know
it should be possible if you don't use treat the php _script_ as a cgi and
use the hash-bang on every file.

Thanks,
James Harr


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

Bug #49625 [Com]: spl_autoload and case sensitivity

[james at jamestandy dot com]

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

 ID: 49625
 Comment by: james at jamestandy dot com
 Reported by:jo at feuersee dot de
 Summary:spl_autoload and case sensitivity
 Status: Not a bug
 Type:   Bug
 Package:SPL related
 Operating System:   Linux
 PHP Version:5.3.0
 Block user comment: N
 Private report: N

 New Comment:

Also add my support to
FIX THIS BUG!!!

Just tried adding the Ebay Trading API to my existing site, which is using 
spl_autoload.

Because the ebay team (like it seems every other sensible dev on the entire 
planet) uses CamelCased filenames, I now have 3 choices:

1:  Do not use spl_autoload  (Not an option because this would break our 
existing site).

2:  Do not use the Ebay Trading API, or write my own implementation of this 
from scratch. (Also not an option for obvious reasons).

3: Rename over 1000 files, and replace every CamelCase instance in each and 
every file with lower case names.

3 is looking to be my only option, which of course would need repeating each 
and every time Ebay update their API, so is really NOT a viable option.


Previous Comments:

[2013-01-30 09:41:30] jurchiks101 at gmail dot com

Bumping this bug, at least add a boolean parameter to it for case-sensitivity.
This should be literally a 5-minute job for the devs, why has nobody fixed it 
for 
3 years and counting? Have you no shame?


[2013-01-09 10:00:35] wim at asgc dot be

Since I have an extensive codebase relying on classes defined with uppercase 
starting letter and I saw the 'tip' in the documentation (see below) , I wanted 
to switch. To my surprise I bumped into this issue with spl_autoload_register 
(needless to say that it works on a Windows box as a charm and breaks terribly 
on a Linux box).

It definitely is a bug which should be mentioned clearly in the documentation. 
In addition I would strongly suggest the __autoload function will not be 
deprecated until this is fixed.
--
>From the documentation :
Tip
spl_autoload_register() provides a more flexible alternative for autoloading 
classes. For this reason, using __autoload() is discouraged and may be 
deprecated or removed in the future.
--


[2012-12-17 16:01:57] admin at tandyukservers dot co dot uk

Status: Not a bug
Bullshit.
IS A BUG.

When will this be recognised as such by you php devs and added to the list of 
bugs to be fixed!


[2012-06-15 19:59:25] jdornan at stanford dot edu

This seems like a 20 min fix to me, and I've never looked the sql_autoload code 
before. I spent a good deal of time spinning my wheels on this. I don't see why 
anyone should lose time of this very obvious bug. However it's better to patch 
that to bitch, as I always say. I'll submit my patch and see what happens. It's 
not big deal if this is not fixed, since it's so easy to fix I can keep fixing 
it with each release.

Here is a diff, I'll submit the patch with the "Add a Patch" link.


225d224
<   char *lc_class_file;
227d225
<   int lc_class_file_len;
229d226
<   int mixed_case = 0;
235,236c232
<   lc_class_file_len = spprintf(&lc_class_file, 0, "%s%s", lc_name, 
file_extension);
<   class_file_len = spprintf(&class_file, 0, "%s%s", class_name, 
file_extension);
---
>   class_file_len = spprintf(&class_file, 0, "%s%s", lc_name, 
file_extension);
252,261c248
<   mixed_case = 1;
<   }
< 
< /* fall back to lowercase file name. should issue deprecated warning. 
*/
< if (ret != SUCCESS) {
<   ret = php_stream_open_for_zend_ex(lc_class_file, &file_handle, 
ENFORCE_SAFE_MODE|USE_PATH|STREAM_OPEN_FOR_INCLUDE TSRMLS_CC);
< }
< 
<   if (ret == SUCCESS) {
<   if (!file_handle.opened_path && mixed_case == 1) {
---
>   if (!file_handle.opened_path) {
263,264d249
<   } else if(!file_handle.opened_path && mixed_case == 0) {
<   file_handle.opened_path = estrndup(lc_class_file, 
lc_class_file_len);
290d274
<   efree(lc_class_file);
295d278
<   efree(lc_class_file);
331d313
< 

PS: I really hate this bug with a passion.


[2012-06-01 23:10:39] mrex at interport dot net

After having lost 2 days over this, I agree, this should be fixed.  At the very 
least, it should be documented that spl_autoload lower cases filenames.  I 
spent hours trying to 

[PHP-BUG] Bug #61783 [NEW]: ZipArchive::getStream() crashes php-fcgi (5.3.10)

[james at jamesreno dot com]

From: 
Operating system: linux
PHP version:  5.3.10
Package:  Zip Related
Bug Type: Bug
Bug description:ZipArchive::getStream() crashes php-fcgi (5.3.10)

Description:

When php is running in fcgi mode ZipArchive::getStream() causes PHP to
crash.

Test script:
---
open("/tmp/test.zip",ZIPARCHIVE::CREATE);
 $zip->addFromString("test.txt","This is a test");
 $zip->close();
 unset($zip);

 $zip2 = new ZipArchive();
 $zip->open("/tmp/test.zip");
 $fd = $zip->getStream("test.txt");  // CRASH
?>



Expected result:

Zip to return file handle.

Actual result:
--
PHP Crashes (webserver reports *498 recv() failed (104: Connection reset by
peer) 
while reading response header from upstream) and returns 502 Bad Gateway...

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

Bug #61783 [Com]: ZipArchive::getStream() crashes php-fcgi (5.3.10)

[james at jamesreno dot com]

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

 ID: 61783
 Comment by: james at jamesreno dot com
 Reported by:james at jamesreno dot com
 Summary:ZipArchive::getStream() crashes php-fcgi (5.3.10)
 Status: Open
 Type:   Bug
 Package:Zip Related
 Operating System:   linux
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

the second two $zip->'s should have been $zip2->'s :( sorry its late (5am)...


Previous Comments:

[2012-04-20 09:08:21] james at jamesreno dot com

Description:

When php is running in fcgi mode ZipArchive::getStream() causes PHP to crash.

Test script:
---
open("/tmp/test.zip",ZIPARCHIVE::CREATE);
 $zip->addFromString("test.txt","This is a test");
 $zip->close();
 unset($zip);

 $zip2 = new ZipArchive();
 $zip->open("/tmp/test.zip");
 $fd = $zip->getStream("test.txt");  // CRASH
?>



Expected result:

Zip to return file handle.

Actual result:
--
PHP Crashes (webserver reports *498 recv() failed (104: Connection reset by 
peer) 
while reading response header from upstream) and returns 502 Bad Gateway...






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

Bug #61783 [Com]: ZipArchive::getStream() crashes php-fcgi (5.3.10)

[james at jamesreno dot com]

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

 ID: 61783
 Comment by: james at jamesreno dot com
 Reported by:james at jamesreno dot com
 Summary:ZipArchive::getStream() crashes php-fcgi (5.3.10)
 Status: Feedback
 Type:   Bug
 Package:Zip Related
 Operating System:   linux
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

This does seem to be fixed in PHP 5.3.11 - it no longer crashes however :( now 
dba_fetch() crashes --- yay. On to another bug fixing fiesta!

Regards,
~James


Previous Comments:

[2012-04-29 17:27:14] reeze dot xia at gmail dot com

I ever reproduce it in 5.3.10 but only several times. I can't reproduce it 
anymore.
   Can you provide more information about the bug? or try lastest version?


[2012-04-22 04:30:56] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.




[2012-04-20 09:14:57] james at jamesreno dot com

the second two $zip->'s should have been $zip2->'s :( sorry its late (5am)...

----
[2012-04-20 09:08:21] james at jamesreno dot com

Description:

When php is running in fcgi mode ZipArchive::getStream() causes PHP to crash.

Test script:
---
open("/tmp/test.zip",ZIPARCHIVE::CREATE);
 $zip->addFromString("test.txt","This is a test");
 $zip->close();
 unset($zip);

 $zip2 = new ZipArchive();
 $zip->open("/tmp/test.zip");
 $fd = $zip->getStream("test.txt");  // CRASH
?>



Expected result:

Zip to return file handle.

Actual result:
--
PHP Crashes (webserver reports *498 recv() failed (104: Connection reset by 
peer) 
while reading response header from upstream) and returns 502 Bad Gateway...






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

Bug #61783 [Fbk->Csd]: ZipArchive::getStream() crashes php-fcgi (5.3.10)

[james at jamesreno dot com]

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

 ID: 61783
 User updated by:james at jamesreno dot com
 Reported by:james at jamesreno dot com
 Summary:ZipArchive::getStream() crashes php-fcgi (5.3.10)
-Status: Feedback
+Status: Closed
 Type:   Bug
 Package:Zip Related
 Operating System:   linux
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Fixed in PHP 5.3.11 (no longer crashes).


Previous Comments:

[2012-05-01 02:26:47] james at jamesreno dot com

This does seem to be fixed in PHP 5.3.11 - it no longer crashes however :( now 
dba_fetch() crashes --- yay. On to another bug fixing fiesta!

Regards,
~James


[2012-04-29 17:27:14] reeze dot xia at gmail dot com

I ever reproduce it in 5.3.10 but only several times. I can't reproduce it 
anymore.
   Can you provide more information about the bug? or try lastest version?


[2012-04-22 04:30:56] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.




[2012-04-20 09:14:57] james at jamesreno dot com

the second two $zip->'s should have been $zip2->'s :( sorry its late (5am)...

----
[2012-04-20 09:08:21] james at jamesreno dot com

Description:

When php is running in fcgi mode ZipArchive::getStream() causes PHP to crash.

Test script:
---
open("/tmp/test.zip",ZIPARCHIVE::CREATE);
 $zip->addFromString("test.txt","This is a test");
 $zip->close();
 unset($zip);

 $zip2 = new ZipArchive();
 $zip->open("/tmp/test.zip");
 $fd = $zip->getStream("test.txt");  // CRASH
?>



Expected result:

Zip to return file handle.

Actual result:
--
PHP Crashes (webserver reports *498 recv() failed (104: Connection reset by 
peer) 
while reading response header from upstream) and returns 502 Bad Gateway...






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

[PHP-BUG] Bug #61885 [NEW]: dba_fetch() segfaults with db-4.8

[james at jamesreno dot com]

From: 
Operating system: Linux-2.6 / CentOS 5.8
PHP version:  5.3.11
Package:  DBM/DBA related
Bug Type: Bug
Bug description:dba_fetch() segfaults with db-4.8

Description:

When using dba_fetch with a db4 database a segfault is generated and php 
crashes.

Important Notes:
We use db48 rpm from ZeroC for IcePHP Support. At the time of testing we
did not 
have the IcePHP.so loaded to ensure that it was not a conflict with that
module.

dba.so is linked against this db4 rpm:
http://www.zeroc.com/download/Ice/3.4/rhel5/x86_64/db48-devel-4.8.30-
1ice.rhel5.x86_64.rpm
[root@web2 ~]# ldd /usr/local/php/lib/php/extensions/no-debug-non-zts-
20090626/dba.so 
linux-vdso.so.1 =>  (0x7fff62deb000)
libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x2b024cad9000)
libc.so.6 => /lib64/libc.so.6 (0x2b024ce43000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x2b024d19b000)
/lib64/ld-linux-x86-64.so.2 (0x2b024c6a3000)



Test script:
---

?>


Expected result:

PHP to return the fetched dba result

Actual result:
--
Segfault


Program received signal SIGSEGV, Segmentation fault.
0x0171f190 in ?? ()
(gdb) bt
#0  0x0171f190 in ?? ()
#1  0x2aaab1a347a6 in dba_exists_db4 (info=0x16ed090, key=, keylen=)
at /usr/src/redhat/BUILD/lsgphp-1.0.6/php-5.3.11/ext/dba/dba_db4.c:211
#2  0x2aaab1a33c48 in zif_dba_exists (ht=, 
return_value=0x16d1318, return_value_ptr=,
this_ptr=, return_value_used=)
at /usr/src/redhat/BUILD/lsgphp-1.0.6/php-5.3.11/ext/dba/dba.c:984
#3  0x006e9bf9 in zend_do_fcall_common_helper_SPEC ()
#4  0x006e8d4e in execute ()
#5  0x006c2459 in zend_execute_scripts ()
#6  0x0066f0c8 in php_execute_script ()
#7  0x0074b27e in main ()


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

Bug #61885 [Com]: dba_fetch() segfaults with db-4.8

[james at jamesreno dot com]

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

 ID: 61885
 Comment by: james at jamesreno dot com
 Reported by:james at jamesreno dot com
 Summary:dba_fetch() segfaults with db-4.8
 Status: Open
 Type:   Bug
 Package:DBM/DBA related
 Operating System:   Linux-2.6 / CentOS 5.8
 PHP Version:5.3.11
 Block user comment: N
 Private report: N

 New Comment:

dba_fetch() and dba_exists() are the same function under the hood, with 
different return values.  I noticed my example said dba_exists() while the 
subject said dba_fetch()... 

Both functions crash/segfault at the same code:
dba_fetch(): line 172: if (!dba->dbp->get(dba->dbp, NULL, &gkey, &gval, 0)) {
dba_exists():line 211: if (!dba->dbp->get(dba->dbp, NULL, &gkey, &gval, 0)) {

I am not sure how to debug this any further. would this indicate a problem in 
the db4 library or php?  I am (probably wrongfully) assuming it has something 
to 
do with the way the gkey and gval are passed by reference.

I am not sure what frame 0 is in the stack trace - gdb was not very useful here 
-- most likely its the actual dba->dbp "get"...

One additional note:
While we do use the rpm provided by ZeroC after further research it seems to 
simply be an UNMODIFIED version of the db-4.8.30.NC tarball provided by Oracle. 
Potentially the BDB API changed between 4.3 and 4.8 resulting in the segfult 
when get() is called?


Previous Comments:
----
[2012-05-01 03:41:07] james at jamesreno dot com

Description:

When using dba_fetch with a db4 database a segfault is generated and php 
crashes.

Important Notes:
We use db48 rpm from ZeroC for IcePHP Support. At the time of testing we did 
not 
have the IcePHP.so loaded to ensure that it was not a conflict with that module.

dba.so is linked against this db4 rpm:
http://www.zeroc.com/download/Ice/3.4/rhel5/x86_64/db48-devel-4.8.30-
1ice.rhel5.x86_64.rpm
[root@web2 ~]# ldd /usr/local/php/lib/php/extensions/no-debug-non-zts-
20090626/dba.so 
linux-vdso.so.1 =>  (0x7fff62deb000)
libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x2b024cad9000)
libc.so.6 => /lib64/libc.so.6 (0x2b024ce43000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x2b024d19b000)
/lib64/ld-linux-x86-64.so.2 (0x2b024c6a3000)



Test script:
---

?>


Expected result:

PHP to return the fetched dba result

Actual result:
--
Segfault


Program received signal SIGSEGV, Segmentation fault.
0x0171f190 in ?? ()
(gdb) bt
#0  0x0171f190 in ?? ()
#1  0x2aaab1a347a6 in dba_exists_db4 (info=0x16ed090, key=, keylen=)
at /usr/src/redhat/BUILD/lsgphp-1.0.6/php-5.3.11/ext/dba/dba_db4.c:211
#2  0x2aaab1a33c48 in zif_dba_exists (ht=, 
return_value=0x16d1318, return_value_ptr=,
this_ptr=, return_value_used=)
at /usr/src/redhat/BUILD/lsgphp-1.0.6/php-5.3.11/ext/dba/dba.c:984
#3  0x006e9bf9 in zend_do_fcall_common_helper_SPEC ()
#4  0x006e8d4e in execute ()
#5  0x006c2459 in zend_execute_scripts ()
#6  0x0066f0c8 in php_execute_script ()
#7  0x0074b27e in main ()







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

Bug #62836 [Com]: Seg fault or broken object references on unserialize()

[james at ifixit dot com]

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

 ID: 62836
 Comment by: james at ifixit dot com
 Reported by:daniel dot beardsley at gmail dot com
 Summary:Seg fault or broken object references on
 unserialize()
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   CentOS
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

I've just reproduced this on a build from master, at commit 
b5305d267b6c3b1b09ab0ba4ecf4f66edc5d4077 .

root 11:37:49 serialize > php --version
PHP 5.5.0-dev (cli) (built: Aug 16 2012 11:37:55)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
root 11:39:37 serialize > ./run_test.sh
./run_test.sh: line 3:  2267 Segmentation fault  php 
unserialize_autoload.php > after.out
Original ==
in autoload: A
in autoload: B
object(A)#1 (4) {
  ["b"]=>
  object(B)#2 (0) {
  }
  ["b1"]=>
  object(B)#2 (0) {
  }
  ["c"]=>
  object(B)#3 (0) {
  }
  ["c1"]=>
  object(B)#3 (0) {
  }
}

Unserialized ==
in autoload: A
in autoload: B
object(A)#1 (4) {
  ["b"]=>
  object(B)#2 (0) {
  }
  ["b1"]=>
  object(B)#2 (0) {
  }
  ["c"]=>
  object(B)#3 (0) {
  }
  ["c1"]=>
  NULL
}

Diff ==
14,15c14
<   object(B)#3 (0) {
<   }
---
>   NULL
FAILED 

I built php with the following configure line:

./configure  --host=i686-redhat-linux-gnu --build=i686-redhat-linux-gnu \
--target=i386-redhat-linux --program-prefix= --prefix=/usr --exec-prefix=/usr \
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share \
--includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec \
--localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man \
--infodir=/usr/share/info --with-libdir=lib64 --with-config-file-path=/etc \
--with-config-file-scan-dir=/etc/php.d --disable-debug --with-pic \
--disable-rpath --with-bz2 --with-curl --with-exec-dir=/usr/bin \
--with-freetype-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf \
--without-gdbm --with-gettext --with-gmp --with-iconv --with-jpeg-dir=/usr \
--with-openssl --with-pcre-regex=/usr --with-zlib --with-layout=GNU \
--enable-exif --enable-ftp --enable-magic-quotes --enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-wddx \
--with-kerberos  --enable-shmop --enable-calendar \
--without-sqlite --with-libxml-dir=/usr \
--enable-pcntl --with-imap=/usr/lib64 \
--with-imap-ssl=/usr/local/ssl/include/openssl --enable-mbstring \
--enable-mbregex --with-gd --enable-bcmath --with-xmlrpc=shared \
--with-mysql=mysqlnd --with-mysqli=mysqlnd \
--enable-dom --enable-soap=shared --with-xsl=shared,/usr \
--enable-xmlreader=shared --enable-xmlwriter=shared --with-readline \
--with-mcrypt=/usr/local/include/mcrypt --with-mhash --with-tidy=shared,/usr \
--enable-sigchild --enable-intl --with-apxs2=/usr/sbin/apxs \
--enable-fpm --with-fpm-user=apache --with-fpm-group=apache


Previous Comments:

[2012-08-16 08:59:19] daniel dot beardsley at gmail dot com

Description:

Occurs on php 5.4.0, but not on 5.3 (I'll try on other versions soon).
Please run this test from /tmp/serialize/run_tests.sh (see bottom for 
explanation)

## Description ##

If calling unserialize() somehow calls back into user code (i.e. autoloading a
class while unserializing it) and user code does another unserialize() (no 
matter what it is), object references in the outer unserialization process 
won't 
be restored correctly. Sometimes the outer call can result in a Segmentation 
Fault instead of just broken references.

In particular, object refrerences will often be replaced with a seemingly random
value from your serialized object graph (or NULL).

The call stack at the time of the problem looks like this:

  #0 /tmp/serialize/setup.php(6): unserialize('i:4');
  #1 [internal function]: __autoload('A')
  #2 /tmp/serialize/unserialize_autoload.php(4): unserialize('O:1:"A":4:
{s:1:...')
  #3 {main}

The unserialize call in frame #2 returns incorrect results because of the 
"recursive" unserialize call in frame #0.

Note:
For reasons that completely escape me, this code seems dependent on the literal 
path it's run from.  Some paths hide the bug, some cause failure, and some 
cause 
a SegFault.  It's consistent on a per-path basis, but I found no pattern.  

Test script:
---
https://gist.github.com/3353895

Expected result:

Before and After output should be the same. Last line of output should read: 
"Passed, no differences"

Before Serialization:
class A#1 (4) {
  public $b =>
  class B#2 (0)

#48104 [NEW]: PHP FD-Leak - FastCGI + auto_prepend

[james at jamesreno dot com]

From: james at jamesreno dot com
Operating system: Debian 5.0.1 (lenny); 2.6.26-2-a
PHP version:  5.2.9
PHP Bug Type: Unknown/Other Function
Bug description:  PHP FD-Leak - FastCGI + auto_prepend

Description:

PHP leaks file descriptors by not closing the requested file at the end of
request. 

See: http://pastebin.com/m3edccacf

*** REGARDLESS of suhosin being enabled/compiled or disable and NOT
patched, the same problem appears. I have removed suhosin from php and yet
the issue still appears. Please dont just "blame suhosin" and ignore this
fact.

No third-party modules are enabled - apc has been disabled & uninstalled
as well.

This seems like an off-by-one somewhere in relation to the auto_prepend.

removing the auto_prepend statement from the php.ini fixes the problem.

Reproduce code:
---
Request http://127.0.0.1/somescript.php

auto_prepend_file = "/tmp/test.php";

#/tmp/test.php


#/tmp/test2.php


#/var/www/html/somescript.php
echo " world";

Expected result:

Output of "hello World";

and PHP should close all of its files it opened.

Actual result:
--
Output is proper.

PHP opens:
1) /tmp/test.php
2) /tmp/test2.php
3) /var/www/html/somescript.php

however, php only closes:
1) /tmp/test.php
2) /tmp/test2.php

it does NOT close 3) /var/www/html/somescript.php


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

#48104 [Com]: PHP FD-Leak - FastCGI + auto_prepend

[james at jamesreno dot com]

 ID:   48104
 Comment by:   james at jamesreno dot com
 Reported By:  james at jamesreno dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Debian 5.0.1 (lenny); 2.6.26-2-a
 PHP Version:  5.2.9
 New Comment:

strace of the pid is also now included -- i forgot to include it in the
previous pastebin url.

http://pastebin.com/mc72a99b


Previous Comments:


[2009-04-29 07:59:49] james at jamesreno dot com

Description:

PHP leaks file descriptors by not closing the requested file at the end
of request. 

See: http://pastebin.com/m3edccacf

*** REGARDLESS of suhosin being enabled/compiled or disable and NOT
patched, the same problem appears. I have removed suhosin from php and
yet the issue still appears. Please dont just "blame suhosin" and ignore
this fact.

No third-party modules are enabled - apc has been disabled &
uninstalled as well.

This seems like an off-by-one somewhere in relation to the
auto_prepend.

removing the auto_prepend statement from the php.ini fixes the problem.

Reproduce code:
---
Request http://127.0.0.1/somescript.php

auto_prepend_file = "/tmp/test.php";

#/tmp/test.php


#/tmp/test2.php


#/var/www/html/somescript.php
echo " world";

Expected result:

Output of "hello World";

and PHP should close all of its files it opened.

Actual result:
--
Output is proper.

PHP opens:
1) /tmp/test.php
2) /tmp/test2.php
3) /var/www/html/somescript.php

however, php only closes:
1) /tmp/test.php
2) /tmp/test2.php

it does NOT close 3) /var/www/html/somescript.php






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

#48104 [Com]: PHP FD-Leak - FastCGI + auto_prepend

[james at jamesreno dot com]

 ID:   48104
 Comment by:   james at jamesreno dot com
 Reported By:  james at jamesreno dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Debian 5.0.1 (lenny); 2.6.26-2-a
 PHP Version:  5.2.9
 New Comment:

[*** NOT TESTED - DO NOT USE ***]

After spending countless hours trying to determine where php is leaking
the file descriptors as mentioned in the post. It looks like
zend_destroy_file_handle in Zend/zend_language_scanner.c is missing a
call to zend_file_handle_dtor on file_handler.

If you add zend_file_handle_dtor(file_handle); it would seem the issue
would be fixed.

Is this proper - or is there some reason that zend_destroy_file_handle
does not call the destructor zend_file_handle_dtor


Previous Comments:


[2009-04-29 08:18:06] james at jamesreno dot com

strace of the pid is also now included -- i forgot to include it in the
previous pastebin url.

http://pastebin.com/mc72a99b



[2009-04-29 07:59:49] james at jamesreno dot com

Description:

PHP leaks file descriptors by not closing the requested file at the end
of request. 

See: http://pastebin.com/m3edccacf

*** REGARDLESS of suhosin being enabled/compiled or disable and NOT
patched, the same problem appears. I have removed suhosin from php and
yet the issue still appears. Please dont just "blame suhosin" and ignore
this fact.

No third-party modules are enabled - apc has been disabled &
uninstalled as well.

This seems like an off-by-one somewhere in relation to the
auto_prepend.

removing the auto_prepend statement from the php.ini fixes the problem.

Reproduce code:
---
Request http://127.0.0.1/somescript.php

auto_prepend_file = "/tmp/test.php";

#/tmp/test.php


#/tmp/test2.php


#/var/www/html/somescript.php
echo " world";

Expected result:

Output of "hello World";

and PHP should close all of its files it opened.

Actual result:
--
Output is proper.

PHP opens:
1) /tmp/test.php
2) /tmp/test2.php
3) /var/www/html/somescript.php

however, php only closes:
1) /tmp/test.php
2) /tmp/test2.php

it does NOT close 3) /var/www/html/somescript.php






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

#48104 [Com]: PHP FD-Leak - FastCGI + auto_prepend

[james at jamesreno dot com]

 ID:   48104
 Comment by:   james at jamesreno dot com
 Reported By:  james at jamesreno dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Debian 5.0.1 (lenny); 2.6.26-2-a
 PHP Version:  5.2.9
 New Comment:

Problem still persists. I have not yet found solution to resolve this
problem.

More Information:

This leak only happens in fastCGI mode (-b).
It seems that the leak only happens in a subset of files on the server,
not every file, but i can not find anything in those files other than
the fact that they are larger than the rest (ie: more code). They do not
use any weird extensions or special crazy syntax.

I tried to compile with --disable-all --enable-fastcgi, and the problem
persists.

I was NOT able to re-produce with the "CGI" binary, stracing shows that
php does indeed close the file. Only with -b and running in fastCGI mode
does the PHP leak the FD's.


PHP-fcgi is started like so:

su -m -c "nohup env PHP_FCGI_CHILDREN=5 PHP_FCGI_MAX_REQUESTS=1000
bin/php-fcgi-spawn -b 127.0.0.1:8081 -d 'error_log=$PHP_ERRLOG' >>
$FCGI_LOG 2>&1 &" apache


Is there anything else you can think of trying? The suggestion i
provided in my previous comment, just causes glibc to segfault php with
"glibc detected !prev".

In what file is the original file FD closed when executing via FCGI. I
notice that the other included files are being closed properly, but just
not the main executed .php.


Previous Comments:
----

[2009-04-29 17:00:05] james at jamesreno dot com

[*** NOT TESTED - DO NOT USE ***]

After spending countless hours trying to determine where php is leaking
the file descriptors as mentioned in the post. It looks like
zend_destroy_file_handle in Zend/zend_language_scanner.c is missing a
call to zend_file_handle_dtor on file_handler.

If you add zend_file_handle_dtor(file_handle); it would seem the issue
would be fixed.

Is this proper - or is there some reason that zend_destroy_file_handle
does not call the destructor zend_file_handle_dtor

----

[2009-04-29 08:18:06] james at jamesreno dot com

strace of the pid is also now included -- i forgot to include it in the
previous pastebin url.

http://pastebin.com/mc72a99b

----

[2009-04-29 07:59:49] james at jamesreno dot com

Description:

PHP leaks file descriptors by not closing the requested file at the end
of request. 

See: http://pastebin.com/m3edccacf

*** REGARDLESS of suhosin being enabled/compiled or disable and NOT
patched, the same problem appears. I have removed suhosin from php and
yet the issue still appears. Please dont just "blame suhosin" and ignore
this fact.

No third-party modules are enabled - apc has been disabled &
uninstalled as well.

This seems like an off-by-one somewhere in relation to the
auto_prepend.

removing the auto_prepend statement from the php.ini fixes the problem.

Reproduce code:
---
Request http://127.0.0.1/somescript.php

auto_prepend_file = "/tmp/test.php";

#/tmp/test.php


#/tmp/test2.php


#/var/www/html/somescript.php
echo " world";

Expected result:

Output of "hello World";

and PHP should close all of its files it opened.

Actual result:
--
Output is proper.

PHP opens:
1) /tmp/test.php
2) /tmp/test2.php
3) /var/www/html/somescript.php

however, php only closes:
1) /tmp/test.php
2) /tmp/test2.php

it does NOT close 3) /var/www/html/somescript.php






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

#48104 [Com]: FD-Leak - FastCGI + auto_prepend

[james at jamesreno dot com]

 ID:   48104
 Comment by:   james at jamesreno dot com
 Reported By:  james at jamesreno dot com
 Status:   Feedback
 Bug Type: CGI related
 Operating System: Debian 5.0.1 (lenny); 2.6.26-2-a
 PHP Version:  5.2.9
 New Comment:

The php5.3-200904291830 snapshot worked - yes.   I am not for sure what
causes this in 5.2.9 but 5.3 fixes the problem.  I generally dont like
running beta/rc software in production however looks like this is my
only choice currently.

Any ideas what could cause this issue?


Previous Comments:


[2009-04-30 08:30:41] j...@php.net

Please try using this CVS snapshot:

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

  http://windows.php.net/snapshots/





[2009-04-29 21:53:54] james at jamesreno dot com

Problem still persists. I have not yet found solution to resolve this
problem.

More Information:

This leak only happens in fastCGI mode (-b).
It seems that the leak only happens in a subset of files on the server,
not every file, but i can not find anything in those files other than
the fact that they are larger than the rest (ie: more code). They do not
use any weird extensions or special crazy syntax.

I tried to compile with --disable-all --enable-fastcgi, and the problem
persists.

I was NOT able to re-produce with the "CGI" binary, stracing shows that
php does indeed close the file. Only with -b and running in fastCGI mode
does the PHP leak the FD's.


PHP-fcgi is started like so:

su -m -c "nohup env PHP_FCGI_CHILDREN=5 PHP_FCGI_MAX_REQUESTS=1000
bin/php-fcgi-spawn -b 127.0.0.1:8081 -d 'error_log=$PHP_ERRLOG' >>
$FCGI_LOG 2>&1 &" apache


Is there anything else you can think of trying? The suggestion i
provided in my previous comment, just causes glibc to segfault php with
"glibc detected !prev".

In what file is the original file FD closed when executing via FCGI. I
notice that the other included files are being closed properly, but just
not the main executed .php.

----

[2009-04-29 17:00:05] james at jamesreno dot com

[*** NOT TESTED - DO NOT USE ***]

After spending countless hours trying to determine where php is leaking
the file descriptors as mentioned in the post. It looks like
zend_destroy_file_handle in Zend/zend_language_scanner.c is missing a
call to zend_file_handle_dtor on file_handler.

If you add zend_file_handle_dtor(file_handle); it would seem the issue
would be fixed.

Is this proper - or is there some reason that zend_destroy_file_handle
does not call the destructor zend_file_handle_dtor

----

[2009-04-29 08:18:06] james at jamesreno dot com

strace of the pid is also now included -- i forgot to include it in the
previous pastebin url.

http://pastebin.com/mc72a99b

----

[2009-04-29 07:59:49] james at jamesreno dot com

Description:

PHP leaks file descriptors by not closing the requested file at the end
of request. 

See: http://pastebin.com/m3edccacf

*** REGARDLESS of suhosin being enabled/compiled or disable and NOT
patched, the same problem appears. I have removed suhosin from php and
yet the issue still appears. Please dont just "blame suhosin" and ignore
this fact.

No third-party modules are enabled - apc has been disabled &
uninstalled as well.

This seems like an off-by-one somewhere in relation to the
auto_prepend.

removing the auto_prepend statement from the php.ini fixes the problem.

Reproduce code:
---
Request http://127.0.0.1/somescript.php

auto_prepend_file = "/tmp/test.php";

#/tmp/test.php


#/tmp/test2.php


#/var/www/html/somescript.php
echo " world";

Expected result:

Output of "hello World";

and PHP should close all of its files it opened.

Actual result:
--
Output is proper.

PHP opens:
1) /tmp/test.php
2) /tmp/test2.php
3) /var/www/html/somescript.php

however, php only closes:
1) /tmp/test.php
2) /tmp/test2.php

it does NOT close 3) /var/www/html/somescript.php






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

#47566 [Bgs]: PCNTL Waitpid exit status incorrect

[james at jamesreno dot com]

 ID:   47566
 User updated by:  james at jamesreno dot com
 Reported By:  james at jamesreno dot com
 Status:   Bogus
 Bug Type: PCNTL related
 Operating System: linux-2.6
 PHP Version:  5.2.9
 New Comment:

Not bogus see below:

Its obviously not returning properly:
   1.  while (($pid=pcntl_waitpid(-1,$status,WNOHANG))>0) {
   2.   echo "RAW: {$status}\n";
   3.   var_dump(pcntl_wifexited($status));
   4.var_dump(pcntl_wexitstatus($status));
   5.   var_dump(pcntl_wifsignaled($status));
   6.var_dump(pcntl_wtermsig($status));
   7.   var_dump(pcntl_wifstopped($status));
   8.var_dump(pcntl_wstopsig($status));
   9.   echo "END RAW: {$status}\n";
  10.  }
  11.   
  12.  RAW: 65280
  13.  pcntl_wifexited   == bool(true)  => pcntl_wexitstatus ==
int(-1)
  14.  pcntl_wifsignaled == bool(false) => pcntl_wtermsig==
int(0)
  15.  pcntl_wifstopped  == bool(false) => pcntl_wstopsig==
int(255)
  16.  END RAW: 65280
  17.
  18.  
  19.  RAW: 65280
  20.  bool(true)
  21.  int(-1)
  22.  bool(false)
  23.  int(0)
  24.  bool(false)
  25.  int(255)
  26.  END RAW: 65280

Guess ill be hax0ring the code to make it work properly.

seems the same on PHP 5.3.0-RC2


Previous Comments:
----

[2009-03-05 20:54:53] james at jamesreno dot com

exit(254);

$pid = pcntl_waitpid(-1,$status);

if (pcntl_wifexited($status)) {
 $status = pcntl_wexitstatus($status);
 echo $status;
}

Then why is $status, -2 rather than '254'?

This method does not seem work *properly* either...



[2009-03-04 23:11:46] fel...@php.net

You need to use the pcntl_wexitstatus().

http://docs.php.net/manual/en/function.pcntl-wexitstatus.php
http://www.mkssoftware.com/docs/man3/waitpid.3.asp

----

[2009-03-04 21:59:01] james at jamesreno dot com

Description:

The $status exitcode returned by pcntl_waitpid() is incorrectly casted
resulting in an invalid number being returned.

I believe the int is converted to a long in ext/pcntl/pcntl.c,
resulting in an invalid integer being returned to the parent.

zval *z_status = NULL;
int status;
convert_to_long_ex(&z_status);
status = Z_LVAL_P(z_status);
child_id = waitpid((pid_t) pid, &status, options);
Z_LVAL_P(z_status) = status;

z_status is a long, but status is an int...


Reproduce code:
---


Expected result:

[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 128
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$


Actual result:
--
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 32768
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$





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

#47566 [Bgs]: PCNTL Waitpid exit status incorrect

[james at jamesreno dot com]

 ID:   47566
 User updated by:  james at jamesreno dot com
 Reported By:  james at jamesreno dot com
 Status:   Bogus
 Bug Type: PCNTL related
 Operating System: linux-2.6
 PHP Version:  5.2.9
 New Comment:

/* {{{ proto int pcntl_wexitstatus(int status)
   Returns the status code of a child's exit */
PHP_FUNCTION(pcntl_wexitstatus)

The function definition says it returns an INT, as it SHOULD -- exit
codes can not be negative! and are in the range of 0-255 (8 bits) on
posix systems. (iirc).


-- HOWEVER --

Php actually returns:
status_word = (int) Z_LVAL_PP(status);
/* WEXITSTATUS only returns 8 bits so we *MUST* cast this to
signed char
   if you want to have valid negative exit codes */

RETURN_LONG((signed char) WEXITSTATUS(status_word));

It should NOT, it should not cast it to a (signed char)


So if you actually want the right result in your code :(
In php-5.2.9/ext/pcntl/pcntl.c line 379

Change:
RETURN_LONG((signed char) WEXITSTATUS(status_word));
to:
RETURN_LONG(WEXITSTATUS(status_word));


Previous Comments:


[2009-05-26 04:47:50] james at jamesreno dot com

Not bogus see below:

Its obviously not returning properly:
   1.  while (($pid=pcntl_waitpid(-1,$status,WNOHANG))>0) {
   2.   echo "RAW: {$status}\n";
   3.   var_dump(pcntl_wifexited($status));
   4.var_dump(pcntl_wexitstatus($status));
   5.   var_dump(pcntl_wifsignaled($status));
   6.var_dump(pcntl_wtermsig($status));
   7.   var_dump(pcntl_wifstopped($status));
   8.var_dump(pcntl_wstopsig($status));
   9.   echo "END RAW: {$status}\n";
  10.  }
  11.   
  12.  RAW: 65280
  13.  pcntl_wifexited   == bool(true)  => pcntl_wexitstatus ==
int(-1)
  14.  pcntl_wifsignaled == bool(false) => pcntl_wtermsig==
int(0)
  15.  pcntl_wifstopped  == bool(false) => pcntl_wstopsig==
int(255)
  16.  END RAW: 65280
  17.
  18.  
  19.  RAW: 65280
  20.  bool(true)
  21.  int(-1)
  22.  bool(false)
  23.  int(0)
  24.  bool(false)
  25.  int(255)
  26.  END RAW: 65280

Guess ill be hax0ring the code to make it work properly.

seems the same on PHP 5.3.0-RC2

----

[2009-03-05 20:54:53] james at jamesreno dot com

exit(254);

$pid = pcntl_waitpid(-1,$status);

if (pcntl_wifexited($status)) {
 $status = pcntl_wexitstatus($status);
 echo $status;
}

Then why is $status, -2 rather than '254'?

This method does not seem work *properly* either...



[2009-03-04 23:11:46] fel...@php.net

You need to use the pcntl_wexitstatus().

http://docs.php.net/manual/en/function.pcntl-wexitstatus.php
http://www.mkssoftware.com/docs/man3/waitpid.3.asp

----

[2009-03-04 21:59:01] james at jamesreno dot com

Description:

The $status exitcode returned by pcntl_waitpid() is incorrectly casted
resulting in an invalid number being returned.

I believe the int is converted to a long in ext/pcntl/pcntl.c,
resulting in an invalid integer being returned to the parent.

zval *z_status = NULL;
int status;
convert_to_long_ex(&z_status);
status = Z_LVAL_P(z_status);
child_id = waitpid((pid_t) pid, &status, options);
Z_LVAL_P(z_status) = status;

z_status is a long, but status is an int...


Reproduce code:
---


Expected result:

[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 128
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$


Actual result:
--
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 32768
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$





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

#46141 [NEW]: -lpam missing from imap configure check

[james at bytehosting dot com]

From: james at bytehosting dot com
Operating system: Mandriva Linux 2008.1
PHP version:  5.2.6
PHP Bug Type: Compile Failure
Bug description:  -lpam missing from imap configure check

Description:

PHP ./configure fails when adding --with-imap due to pam not being linked


This is the exact same problem as Bug#:26923 -- however, it seems to again
be recurring therefor, re-opening as new bug against 5.2.6!

**IMAP support is being compiled as a shared-module** Therefor -lpam needs
to be called.

Reproduce code:
---
./configure --with-imap=shared,/usr

Expected result:

Configure should succeed and not exit

Actual result:
--
checking for CRYPTO_free in -lcrypto... (cached) yes
checking for SSL_CTX_set_ssl_version in -lssl... (cached) yes
checking whether build with IMAP works... no
configure: error: build test failed. Please check the config.log for
details.


configure:49236: checking whether build with IMAP works
configure:49274: gcc -o conftest -I/usr/include  -L/usr/lib64  conftest.c 
-lssl -lcrypto -lc-client -lcrypt  -lssl -lcrypto -lcurl -lz
-lresolv -lm -ldl -lnsl  -lxml2 -lz -lm -lcurl -lxml2 -lz -lm 1>&5
/usr/lib64/libc-client.a(osdep.o): In function `ssl_onceonlyinit':
/home/mandrake/rpm/BUILD/imap-2006k/c-client/osdep.c:335: warning: the use
of `tmpnam' is dangerous, better use `mkstemp'
/usr/lib64/libc-client.a(osdep.o): In function `checkpw_cleanup':
osdep.c:(.text+0xd9d9): undefined reference to `pam_setcred'
osdep.c:(.text+0xd9e7): undefined reference to `pam_end'
/usr/lib64/libc-client.a(osdep.o): In function `checkpw':
osdep.c:(.text+0xda62): undefined reference to `pam_start'
osdep.c:(.text+0xda7c): undefined reference to `pam_set_item'
osdep.c:(.text+0xda8e): undefined reference to `pam_authenticate'
osdep.c:(.text+0xdaa0): undefined reference to `pam_acct_mgmt'
osdep.c:(.text+0xdab2): undefined reference to `pam_setcred'
collect2: ld returned 1 exit status
configure: failed program was:
#line 49247 "configure"
#include "confdefs.h"
void mm_log(void){}
void mm_dlog(void){}
void mm_flags(void){}
void mm_fatal(void){}
void mm_critical(void){}
void mm_nocritical(void){}
void mm_notify(void){}
void mm_login(void){}
void mm_diskerror(void){}
void mm_status(void){}
void mm_lsub(void){}
void mm_list(void){}
void mm_exists(void){}
void mm_searched(void){}
void mm_expunged(void){}

char mail_newbody();
int main() {
  mail_newbody();
  return 0;
}


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

#47566 [NEW]: PCNTL Waitpid exit status incorrect

[james at jamesreno dot com]

From: james at jamesreno dot com
Operating system: linux-2.6
PHP version:  5.2.9
PHP Bug Type: PCNTL related
Bug description:  PCNTL Waitpid exit status incorrect

Description:

The $status exitcode returned by pcntl_waitpid() is incorrectly casted
resulting in an invalid number being returned.

I believe the int is converted to a long in ext/pcntl/pcntl.c, resulting
in an invalid integer being returned to the parent.

zval *z_status = NULL;
int status;
convert_to_long_ex(&z_status);
status = Z_LVAL_P(z_status);
child_id = waitpid((pid_t) pid, &status, options);
Z_LVAL_P(z_status) = status;

z_status is a long, but status is an int...


Reproduce code:
---


Expected result:

[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 128
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$


Actual result:
--
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 32768
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$

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

#47566 [Bgs]: PCNTL Waitpid exit status incorrect

[james at jamesreno dot com]

 ID:   47566
 User updated by:  james at jamesreno dot com
 Reported By:  james at jamesreno dot com
 Status:   Bogus
 Bug Type: PCNTL related
 Operating System: linux-2.6
 PHP Version:  5.2.9
 New Comment:

exit(254);

$pid = pcntl_waitpid(-1,$status);

if (pcntl_wifexited($status)) {
 $status = pcntl_wexitstatus($status);
 echo $status;
}

Then why is $status, -2 rather than '254'?

This method does not seem work *properly* either...


Previous Comments:


[2009-03-04 23:11:46] fel...@php.net

You need to use the pcntl_wexitstatus().

http://docs.php.net/manual/en/function.pcntl-wexitstatus.php
http://www.mkssoftware.com/docs/man3/waitpid.3.asp



[2009-03-04 21:59:01] james at jamesreno dot com

Description:

The $status exitcode returned by pcntl_waitpid() is incorrectly casted
resulting in an invalid number being returned.

I believe the int is converted to a long in ext/pcntl/pcntl.c,
resulting in an invalid integer being returned to the parent.

zval *z_status = NULL;
int status;
convert_to_long_ex(&z_status);
status = Z_LVAL_P(z_status);
child_id = waitpid((pid_t) pid, &status, options);
Z_LVAL_P(z_status) = status;

z_status is a long, but status is an int...


Reproduce code:
---


Expected result:

[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 128
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$


Actual result:
--
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 32768
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$





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

Bug #8985 [Com]: shm_put_var wont put the given var into memory

[james at ihush dot com]

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

 ID:   8985
 Comment by:   james at ihush dot com
 Reported by:  fuf at mobil dot cz
 Summary:  shm_put_var wont put the given var into memory
 Status:   No Feedback
 Type: Bug
 Package:  Semaphore related
 Operating System: linux-2.2.18
 PHP Version:  4.0.4pl1

 New Comment:

I had also experienced such problem in my multi-process program, i start
several processes which shared a shared memory segment created by shm_*
method and when i get/set them frequently, i found some value is wrong
or missing, my PHP version is 5.2.11, would you please to help me to
check this problem? thank you very much  :)


Previous Comments:

[2002-02-15 00:00:02] php-bugs at lists dot php dot net

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".


[2002-01-14 12:25:59] gik at zap dot cl

Hi!



Forgot to explain my example :)



In the Log file, "...added successfully to SHM..." means that
shm_put_var() returned true.  But the next time I call shm_get_var(), I
get the following error: "variable key ... doesn't exist in bbb.php4 on
line ..."



Giancarlo.


[2002-01-14 12:19:45] gik at zap dot cl

I've been experiencing the same problem on a dual cpu server, even with
PHP 4.1.1.  Sometimes occurs that shm_put_var() doesn't correctly write
data to SHM but returns true, and as I manage an array of online users
in SHM, I have noticed that all users sometimes are dropped off.



I also check semaphores before writing to SHM.



16:44:41 User aaa added successfully to SHM. (8104 bytes written)

16:45:54 User bbb added successfully to SHM. (8209 bytes written)

16:47:20 User bbb deleted successfully from SHM. (8104 bytes written)

16:47:31 User ccc added successfully to SHM. (8206 bytes written)

16:49:29 User ddd added successfully to SHM. (109 bytes written)



I offer my help to debug this problem,



Giancarlo Girardi


[2002-01-14 02:24:57] lob...@php.net

Have you tried this with 4.1.1?


[2001-01-29 12:27:07] fuf at mobil dot cz

hello,



  this is the same bug as described in #7046. a call to shm_put_var()
returns true all the time, but checking whether the variable has been
_really_ stored reveals that it hasn't.

  this doesn't happen on my 1 cpu box (i can't reproduce it however much
i try), but on a loaded server with 4 cpus it happens pretty often. of
course i call sem_acquire() before writing the variable into the shared
memory, so it should be safe.

  i can supply the whole source in which this happens (445 lines) but
basically it's just list this:



$semid = sem_get($sem_key, 1);

sem_acquire($semid);

$var = shm_get_var($shmid, $var_key); // $var is an array

// some change to $var, $var is still an array

shm_put_var($shmid, $var_key, $var);

if(!is_array(shm_get_var($shmid, $var_key)))

echo "failed to write \$var :(\n";

sem_release($semid);



  could the problem be caused by the true multitasking on the 4 cpu
server?



thanks for any help with this,

Michal Vitecek





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

Bug #8985 [Com]: shm_put_var wont put the given var into memory

[james at ihush dot com]

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

 ID:   8985
 Comment by:   james at ihush dot com
 Reported by:  fuf at mobil dot cz
 Summary:  shm_put_var wont put the given var into memory
 Status:   No Feedback
 Type: Bug
 Package:  Semaphore related
 Operating System: linux-2.2.18
 PHP Version:  4.0.4pl1

 New Comment:

I can provide my code, please contact me~~


Previous Comments:

[2010-06-24 05:37:12] james at ihush dot com

I had also experienced such problem in my multi-process program, i start
several processes which shared a shared memory segment created by shm_*
method and when i get/set them frequently, i found some value is wrong
or missing, my PHP version is 5.2.11, would you please to help me to
check this problem? thank you very much  :)


[2002-02-15 00:00:02] php-bugs at lists dot php dot net

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".


[2002-01-14 12:25:59] gik at zap dot cl

Hi!



Forgot to explain my example :)



In the Log file, "...added successfully to SHM..." means that
shm_put_var() returned true.  But the next time I call shm_get_var(), I
get the following error: "variable key ... doesn't exist in bbb.php4 on
line ..."



Giancarlo.


[2002-01-14 12:19:45] gik at zap dot cl

I've been experiencing the same problem on a dual cpu server, even with
PHP 4.1.1.  Sometimes occurs that shm_put_var() doesn't correctly write
data to SHM but returns true, and as I manage an array of online users
in SHM, I have noticed that all users sometimes are dropped off.



I also check semaphores before writing to SHM.



16:44:41 User aaa added successfully to SHM. (8104 bytes written)

16:45:54 User bbb added successfully to SHM. (8209 bytes written)

16:47:20 User bbb deleted successfully from SHM. (8104 bytes written)

16:47:31 User ccc added successfully to SHM. (8206 bytes written)

16:49:29 User ddd added successfully to SHM. (109 bytes written)



I offer my help to debug this problem,



Giancarlo Girardi


[2002-01-14 02:24:57] lob...@php.net

Have you tried this with 4.1.1?




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=8985


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

#50430 [NEW]: array_key_position

[james at calminferno dot net]

From: james at calminferno dot net
Operating system: All
PHP version:  5.3.1
PHP Bug Type: Feature/Change Request
Bug description:  array_key_position

Description:

Create a single function called array_key_position that returns the array
position of a key. Basically turning array_search( $key, array_keys(
$my_assoc_array ) ) into a single function that returns the key position or
false if doesn't exist.


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

Bug #52339 [Com]: SPL autoloader breaks class_exists()

[james at nearlysensical dot com]

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

 ID: 52339
 Comment by: james at nearlysensical dot com
 Reported by:dangerous dot ben at gmail dot com
 Summary:SPL autoloader breaks class_exists()
 Status: Bogus
 Type:   Bug
 Package:SPL related
 Operating System:   any (debian)
 PHP Version:5.3.3RC2
 Block user comment: N

 New Comment:

I 100% agree with dangerous dot ben. class_exists should return false if
the class 

can't be autoloaded. Allowing it to do so would make it much easier to
use an 

autoloader in contexts where you're interacting with an existing
codebase that may 

not be so spl_autoload friendly. Bump.


Previous Comments:

[2010-07-15 08:18:01] dangerous dot ben at gmail dot com

I beg to differ.  As you say, class_exists() attempts to autoload if
there second param is true, but if autoloading fails it should simply
return false as usual rather than throw an exception.  Otherwise it is
rather useless.



The fact that this only occurs when there isn't another autoloader in
the stack should make it clear that this is a bug.  For example, the
following code does not throw an exception:



spl_autoload_register();

spl_autoload_register(function(){});

class_exists('foo\bar');


[2010-07-15 05:11:04] ka...@php.net

You are calling class_exists() with just a class name, which leaves the
second parameter ($autoload) set to true, which then invokes SPL and
throws the exception, so no bug here


[2010-07-14 21:54:08] dangerous dot ben at gmail dot com

On further investigation, it appears that the error is meant to happen
only if spl_autoload is called directly, and not via spl_autoload_call. 
Unfortunately when spl_autoload is the only autoloader in the stack it
gets called directly and spl_autoload_call doesn't get a look in.


[2010-07-14 21:31:46] dangerous dot ben at gmail dot com

Description:

Using PHP 5.3 from svn.



When SPL's default autoloader is the only loader in the stack it
triggers an error or throws an exception when it can't find a class. 
This means that you get an exception when calling class_exists() for a
class that doesn't exist.  This behaviour seems pointless anyway since
PHP will trigger its own fatal error if the class still doesn't exist
after attempting to autoload, so the attached patch simply removes it.





Test script:
---
spl_autoload_register();

class_exists('foo\bar');



Expected result:

No error



Actual result:
--
b...@arctor:~/src/php-5.3$ sapi/cli/php ~/code/cram/test.php 

PHP Fatal error:  Uncaught exception 'LogicException' with message
'Class foo\bar could not be loaded' in /home/ben/code/cram/test.php:4

Stack trace:

#0 [internal function]: spl_autoload('foo\bar')

#1 /home/ben/code/cram/test.php(4): class_exists('foo\bar')

#2 {main}

  thrown in /home/ben/code/cram/test.php on line 4








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

Bug #31846 [Com]: simplexml_load_string doesn't get root node

[james at populiweb dot com]

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

 ID: 31846
 Comment by: james at populiweb dot com
 Reported by:andrew at shh dot fi
 Summary:simplexml_load_string doesn't get root node
 Status: Bogus
 Type:   Bug
 Package:SimpleXML related
 Operating System:   win32
 PHP Version:5.0.3
 Block user comment: N

 New Comment:

just in case it helps anyone, getting the name of the root node is
possible:



$xml = simplexml_load_string($xml_str);

$xml->getName();


Previous Comments:

[2005-02-07 21:18:11] a...@php.net

No. SimpleXML is not about being able to do 100% of XML. It's about
doing 80% of XML with 20% of the effort.



Do this instead:



$rootTag = dom_import_simplexml($simple)->tagName;


[2005-02-07 19:58:00] andrew at shh dot fi

Will simpleXML ever be changed to include root nodes?


[2005-02-07 19:56:30] andrew at shh dot fi

So, using simpleXML, one can never know the root tag. Should we guess?
The idea of an XML parser is to return ALL the nodes and not some of
them. Take docbook - you have different root nodes depending on whether
its simple or full. My point is, if you are having an xml parser, then
it needs to read all nodes top-bottom, otherwise there is no point using
it - and as you say correctly - might as well use DOM.


[2005-02-07 16:37:04] chr...@php.net

This is correct. print_r shows you the children nodes of the choosen
node. in your code, $simple *is* the root node. I don't see anything
wrong. There's no such thing as SimpleXMLDocument Object in SimpleXML.



And yes, there is no way of getting the name of the root tag. Use DOM if
you need that.




[2005-02-04 16:28:06] andrew at shh dot fi

Description:

$xml = simplexml_load_string($xml_str) returns all tags correctly except
the root node.



There appears to be NO WAY to get the the name of the root tag





Reproduce code:
---
$xml = 'Hello';



$simple = simplexml_load_string($xml);



print_r($simple);

Expected result:

The object should include the root tag, except it starts from child of
the root







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

#42849 [Com]: Configuration File (php.ini) Path incorrect

[james at thundermonkey dot net]

 ID:   42849
 Comment by:   james at thundermonkey dot net
 Reported By:  inglis-php at yahoo dot com dot au
 Status:   No Feedback
 Bug Type: *General Issues
 Operating System: win xp pro
 PHP Version:  5.2.4
 New Comment:

I've found that the positioning of the PHPIniDir within httpd.conf
makes a difference - place it at the end and it loads the correct
php.ini, but place it towards the top of httpd.conf results in the no
php.ini being loaded at all.

Also be sure to explicitly define your extension_dir directive in
php.ini to load extensions correctly.


Previous Comments:


[2008-04-20 04:46:25] orbital_man at hotmail dot com

Additional test case:

OS: Windows XP Pro
Webserver: IIS 5.1
PHP: 5.2.5

phpinfo() produced:

Configuration File (php.ini) Path   C:\WINDOWS
Loaded Configuration File   (none)

After unsuccessful testing most of the night with environment variables
including multiple reboots just to be sure, I finally broke down and
changed the registry value as recommended in the runtime configuration
section here: http://us3.php.net/configuration

Steps to reproduce:
1. Click Start -> Click Run -> Type Regedit -> Hit Enter
2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\PHP\
3. Right click in right-hand window pane and select New->String Value
4. Set Name to: IniFilePath
5. Set Data to: C:\Program Files\PHP\ (or wherever your installation
is)
6. Click Start -> Click Run -> Type cmd -> Hit Enter -> Type iisreset

phpinfo() now produces:

Configuration File (php.ini) Path   C:\WINDOWS
Loaded Configuration File   C:\Program Files\PHP\php.ini

Additionally, my mysql database is now working also.



[2008-04-13 17:20:35] thakralrohit at gmail dot com

I am having a similar problem. Have been trying to search on the web
for the whole day now but no success. I have this,
OS: Win XP Pro SP 2
IIS: 5.1
PHP: 5.2.5 (MSI Installer with MySQL)

Now, when I load phpinfo() I get output,
Configuration File (php.ini) Path   E:\WINDOWS
Loaded Configuration File   (none) 

No information about the three extensions that I have MySQL, MySQLi and
OpenSSL.

If I put the php.ini file in E:\WINDOWS directory nothing loads at
all.
I have tried re-installation, PHPRC environment variable setting and
Registry Settings but to no use. There is another setting further down
in the phpinfo() output,

extension_dir   C:\php5 

Can someone please help. It seems like similar to this bug with no
update.

Thanks in advance.

Regards
Rohit



[2008-04-05 19:02:54] caseyy at gmail dot com

I am also having this problem. phpinfo says config is being looked for
in my windows directory despite httpconf specifying the right
directory(C:\PHP). Problem is on Vista too. When I copy the ini file to
the windows directory, nothing loads at all, just a blank screen.



[2008-03-27 06:09:29] wiseup24 at hotmail dot com

I am having a simular issue but in my phpinfo test i get this:

Configuration File (php.ini) Path   C:\Windows
Loaded Configuration File   (none)


there is no php.ini in the windows directory and my apache httpd conf
file has this: PHPIniDir "C:\PHP\"

I tried to copy the php.ini to the windows directory but apache fails
to start when it is in there.

I am running Vista with PHP 5.2.5 and Apache 2.2
I have tried using the msi install for php and the zipped version and
still doesnt work. without the correct php.ini being read, i can not
enable the correct extensions.



[2008-03-12 10:36:50] algisimu at gmail dot com

I'm using Apache 2.0.54, Php 5.2.5 and Win XP Pro. My php.ini file is
locaed in the c:\php dir (php installation dir, no more php.ini files
found on the computer), apache httpd.conf file is set up with PHPIniDir
"C:/php/", but phpinfo() reports these results:

Configuration File (php.ini) Path   C:\WINDOWS
Loaded Configuration File   C:\php\php.ini

Have tried to add registry values as described in
http://uk3.php.net/configuration, have tried to add PHPRC environment
variable, but phpinf() still gives same result. One thing worth
mentioning is that then I run php script as CLI with '-c c:\php' option
everything works fine, but then I run same script thru my browser
expected php.ini file is not loaded.



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

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

#28790 [Com]: Add option to disable stat cache

[james at bytehosting dot com]

 ID:   28790
 Comment by:   james at bytehosting dot com
 Reported By:  jnoll at prim dot hu
 Status:   Assigned
 Bug Type: Feature/Change Request
 Operating System: Debian GNU/Linux (unstable)
 PHP Version:  4.3.6
 Assigned To:  pollita
 New Comment:

When writing a daemon process that accesses files very often it seems
litterally stupid to cache stat on these files.

With Basic Code such as the below, the statcache adds unneccessary
overhead and actully SLOWS down the code caching & purging the cache on
EACH and EVERY revolution of code.

There MUST be an option to disable it, other than rm -rf'ing the stuff
from the src/.

Regardless if you believe its "quicker" or not is moot, for each and
every case that you give where it is quicker, I can garuntee to give
you a seperate case proving where it slows the code down.

If your not willing to add a config option, how about a runtime option?
 (after all, who needs ob_implicit_flush()? its just another 'useless'
function..., same idioligy applies here). And there are PLUNTY of cases
where code such as this is required (obviously, not the exact code, its
pseudo code)

while (TRUE) {
  clearstatcache();
  if (file_exists("file.tmp")) {
   process_stuff;
  }
}


Previous Comments:


[2004-06-16 17:30:45] [EMAIL PROTECTED]

I'll cut ya in on a secret: The statcache is only one entry long.



[2004-06-16 17:28:42] phpbugs at spam dot raszi dot hu

It would be better if the file modification functions invalidate not
the whole statcache, only the entry of the modified file.



[2004-06-16 16:29:51] [EMAIL PROTECTED]

Ilia was perhaps a bit short winded in his response...

This was actually discussed within the context of a feature change as
well and was turned down on the basis that it would create unnecessary
slowdowns without significant gain.

You should be aware when you're making multiple stat family calls to
the same file and call clearstatcache() accordingly.  If you're
uncertain, then just call it anyway.


However, that said it may be prudent to introduce an .ini option to
disable the cache altogether now that stat calls work on arbitrary
wrappers.  Let's leave this option open for PHP 5.1 for now.



[2004-06-16 16:10:36] jnoll at prim dot hu

Okay, let me change this to a feature request!

After fclose(), the stat cache for that file should be cleared. Also,
unlink and maybe copy should do this.
If a function is KNOWN to change file stat data, it should clear the
cache.

The problem is that even a file_exists() call caches the data
(including the file size!), and this is easy to overlook, when you have
a bigger system.



[2004-06-15 19:03:34] [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 to be expected. 



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/28790

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

#40373 [NEW]: calling "print()" on an ArrayObject fails silently.

[james at thundermonkey dot net]

From: james at thundermonkey dot net
Operating system: WinXP SP2
PHP version:  5.2.0
PHP Bug Type: SPL related
Bug description:  calling "print()" on an ArrayObject fails silently.

Description:

When attempting to "print()" an ArrayObject (rather than "print_r()") no
ouput is returned, no errors are displayed and the script aborts silently.

Reproduce code:
---


Expected result:

*Some kind of error message saying that the ArrayObject couldn't be
converted to a string followed by:*

Reached this point!

Actual result:
--
(no output at all)

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

#40373 [Bgs]: calling "print()" on an ArrayObject fails silently.

[james at thundermonkey dot net]

 ID:   40373
 User updated by:  james at thundermonkey dot net
 Reported By:  james at thundermonkey dot net
 Status:   Bogus
 Bug Type: SPL related
 Operating System: WinXP SP2
 PHP Version:  5.2.0
 New Comment:

Running the following code:



results in:

Warning: Invalid error type specified in C:\dump\trigger.php on line 2

so E_RECOVERABLE_ERROR is not defined in this version?

PHP 5.2.0, build date: Nov 2 2006 11:50:55


Previous Comments:


[2007-02-06 17:27:20] [EMAIL PROTECTED]

Catchable fatal error: Object of class ArrayObject could not be
converted to string 



[2007-02-06 16:23:12] james at thundermonkey dot net

Description:

When attempting to "print()" an ArrayObject (rather than "print_r()")
no ouput is returned, no errors are displayed and the script aborts
silently.

Reproduce code:
---


Expected result:

*Some kind of error message saying that the ArrayObject couldn't be
converted to a string followed by:*

Reached this point!

Actual result:
--
(no output at all)





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

#40373 [Bgs]: calling "print()" on an ArrayObject fails silently.

[james at thundermonkey dot net]

 ID:   40373
 User updated by:  james at thundermonkey dot net
 Reported By:  james at thundermonkey dot net
 Status:   Bogus
 Bug Type: SPL related
 Operating System: WinXP SP2
 PHP Version:  5.2.0
 New Comment:

Ok, so back to the original code snippet - I'm confused why there are
no error messages being displayed when it's executed. I don't get
anything like "Object of class ArrayObject could not be converted to
string", but it is what I'm expecting. It's just horrible blankness.
Nothing in error log file either.

Also, it's not actually related to ArrayObject alone, but rather all
objects, so the following also fails silently:




Previous Comments:


[2007-02-06 18:27:03] [EMAIL PROTECTED]

That's right, you cannot use it in userspace.

----

[2007-02-06 18:23:38] james at thundermonkey dot net

Running the following code:



results in:

Warning: Invalid error type specified in C:\dump\trigger.php on line 2

so E_RECOVERABLE_ERROR is not defined in this version?

PHP 5.2.0, build date: Nov 2 2006 11:50:55



[2007-02-06 17:27:20] [EMAIL PROTECTED]

Catchable fatal error: Object of class ArrayObject could not be
converted to string 

----

[2007-02-06 16:23:12] james at thundermonkey dot net

Description:

When attempting to "print()" an ArrayObject (rather than "print_r()")
no ouput is returned, no errors are displayed and the script aborts
silently.

Reproduce code:
---


Expected result:

*Some kind of error message saying that the ArrayObject couldn't be
converted to a string followed by:*

Reached this point!

Actual result:
--
(no output at all)





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

#40373 [Bgs]: calling "print()" on an ArrayObject fails silently.

[james at thundermonkey dot net]

 ID:   40373
 User updated by:  james at thundermonkey dot net
 Reported By:  james at thundermonkey dot net
 Status:   Bogus
 Bug Type: SPL related
 Operating System: WinXP SP2
 PHP Version:  5.2.0
 New Comment:

Resolved.

Poking around in a convoluted VirtualHost block, I came across the
following:

...
php_value error_reporting 2047
...

Obviously overriding anything in php.ini! Apologies for the bogus
report.


Previous Comments:


[2007-02-06 19:16:02] james at thundermonkey dot net

Ok, so back to the original code snippet - I'm confused why there are
no error messages being displayed when it's executed. I don't get
anything like "Object of class ArrayObject could not be converted to
string", but it is what I'm expecting. It's just horrible blankness.
Nothing in error log file either.

Also, it's not actually related to ArrayObject alone, but rather all
objects, so the following also fails silently:





[2007-02-06 18:27:03] [EMAIL PROTECTED]

That's right, you cannot use it in userspace.

----

[2007-02-06 18:23:38] james at thundermonkey dot net

Running the following code:



results in:

Warning: Invalid error type specified in C:\dump\trigger.php on line 2

so E_RECOVERABLE_ERROR is not defined in this version?

PHP 5.2.0, build date: Nov 2 2006 11:50:55



[2007-02-06 17:27:20] [EMAIL PROTECTED]

Catchable fatal error: Object of class ArrayObject could not be
converted to string 

----

[2007-02-06 16:23:12] james at thundermonkey dot net

Description:

When attempting to "print()" an ArrayObject (rather than "print_r()")
no ouput is returned, no errors are displayed and the script aborts
silently.

Reproduce code:
---


Expected result:

*Some kind of error message saying that the ArrayObject couldn't be
converted to a string followed by:*

Reached this point!

Actual result:
--
(no output at all)





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

#38525 [Com]: 5.2.0RC2 + squirrelmail == random segfaults , heap corruption

[james at digisys dot net]

 ID:   38525
 Comment by:   james at digisys dot net
 Reported By:  judas dot iscariote at gmail dot com
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: linux
 PHP Version:  5.2.0RC2
 New Comment:

FWIW, I'm seeing these same random seg faults with PHP 5.1.4 and
Squirrelmail 1.4.8 with an external IMAP server.  Switching to the
development branch of Squirrelmail (1.5.2) cleared things up. 
According to the Squirrelmail site the current stable releases (1.4.x)
do not work with PHP5, but the CVS version contains fixes which get it
working.  Not that PHP should fault either way :)


Previous Comments:


[2006-08-26 09:35:25] poeml at suse dot de

Hi,

on my machine it happens with IMAP server _on localhost_.

A how-to-reproduce procedure here is:

- open inbox in browser
- open first mail
- click "next mail"
- proceed with clicking "next mail" (thereby stepping 
through mailbox mail by mail), until segfault happens. 
Sometimes it takes a while, but il WILL happen sooner or 
later.
- now, reloading will trigger the segfault again and again.

- viewing the next mail and going back shows the mail 
without segfault. This also allows to continue to use 
squirrelmail until the next segfault is encountered.



[2006-08-23 23:06:11] [EMAIL PROTECTED]

Well, we still need a reproduce case..




[2006-08-23 22:52:46] judas dot iscariote at gmail dot com

Tony :
Sadly I still get a segfault with a fresh CVS copy :-(

=32459== Process terminating with default action of signal 11
(SIGSEGV)
==32459==  Bad permissions for mapped region at address 0x18
==32459==at 0x7BEC108: zend_mm_add_to_free_list (zend_alloc.c:465)
==32459==by 0x7BEDC23: _zend_mm_alloc_int (zend_alloc.c:1233)
==32459==by 0x7BEEB7D: _zend_mm_realloc_int (zend_alloc.c:1543)
==32459==by 0x7BEEE9D: _erealloc (zend_alloc.c:1633)
==32459==by 0x7B84771: php_var_serialize_string (var.c:538)
==32459==by 0x7B86607: php_var_serialize_intern (var.c:701)
==32459==by 0x7B88679: php_var_serialize_intern (var.c:827)
==32459==by 0x7B88679: php_var_serialize_intern (var.c:827)
==32459==by 0x7B89295: php_var_serialize (var.c:845)
==32459==by 0x7B00700: ps_srlzr_encode_php (session.c:479)
==32459==by 0x7B01268: php_session_encode (session.c:581)
==32459==by 0x7B01DDD: php_session_save_current_state
(session.c:860)
==32459==
==32459== ERROR SUMMARY: 26 errors from 8 contexts (suppressed: 149
from 1)
==32459== malloc/free: in use at exit: 21,210,557 bytes in 5,186
blocks.
==32459== malloc/free: 169,756 allocs, 164,570 frees, 216,925,409 bytes
allocated.
==32459== For counts of detected errors, rerun with: -v
==32459== searching for pointers to 5,186 not-freed blocks.
==32459== checked 19,498,696 bytes.



[2006-08-23 13:04:57] [EMAIL PROTECTED]

This seems to be a duplicate of bug #38265.
Dmitry has committed a patch for it several minutes ago, please try the
next snapshot (or CVS sources).
Thanks. 



[2006-08-22 08:02:57] [EMAIL PROTECTED]

No, using IMAP server on a different machine didn't change anything. It
still works fine without any crashes.



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

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

#37698 [NEW]: select on a synonym through a database link

[james at redeye dot com]

From: james at redeye dot com
Operating system: Linux Advanced Server 3.4
PHP version:  5.1.4
PHP Bug Type: PDO related
Bug description:  select on a synonym through a database link

Description:

I have a synonym in my Oracle 10g database that points to a table on a 9i
database. A database link is used to do this.

If I do a select * on this table a segmentation fault is produced in php.
If I do the select with a where clause or by specifying the fields I want
then PHP works ok

Reproduce code:
---
select * from segment // Causes segmentation fault

select * from segment where name like '%MR%' // works ok

select name from segment // works ok

Expected result:

returns the matches from the sql.

Actual result:
--
PHP segmentation fault.

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

#37698 [Fbk->Opn]: select on a synonym through a database link

[james at redeye dot com]

 ID:   37698
 User updated by:  james at redeye dot com
 Reported By:  james at redeye dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Linux Advanced Server 3.4
 PHP Version:  5.1.4
 New Comment:

#0  0x011e0009 in ttcfopr () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#1  0x011d6341 in ttcdrv () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#2  0x0104636d in nioqwa () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#3  0x00ef9ec0 in upirtrc () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#4  0x00ea294d in kpurcsc () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#5  0x00e62ff9 in kpuexecv8 () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#6  0x00e64abe in kpuexec () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#7  0x00ec3c2c in OCIStmtExecute () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#8  0x080ff70b in oci_stmt_execute (stmt=0x9174a74)
at /usr/local/src/php-5.1.4/ext/pdo_oci/oci_statement.c:142
#9  0x080f8bc9 in zif_PDOStatement_execute (ht=0,
return_value=0x916f6ec, return_value_ptr=0x0, 
this_ptr=0x916f7d4, return_value_used=0) at
/usr/local/src/php-5.1.4/ext/pdo/pdo_stmt.c:451
#10 0x081fc669 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfff8bb0) at zend_vm_execute.h:200
#11 0x081fbf8d in execute (op_array=0x916b394) at zend_vm_execute.h:92
#12 0x00592920 in zend_oe () from
/usr/local/Zend/lib/Optimizer-2.6.1/php-5.1.x/ZendOptimizer.so
#13 0x0916b394 in ?? ()
#14 0x0090d180 in run_fp () from /lib/tls/libc.so.6
#15 0x0df0 in ?? ()
#16 0xbfff8c28 in ?? ()
#17 0x00848e9d in malloc () from /lib/tls/libc.so.6


Previous Comments:


[2006-06-05 08:44:29] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2006-06-05 08:17:12] james at redeye dot com

Description:

I have a synonym in my Oracle 10g database that points to a table on a
9i database. A database link is used to do this.

If I do a select * on this table a segmentation fault is produced in
php. If I do the select with a where clause or by specifying the fields
I want then PHP works ok

Reproduce code:
---
select * from segment // Causes segmentation fault

select * from segment where name like '%MR%' // works ok

select name from segment // works ok

Expected result:

returns the matches from the sql.

Actual result:
--
PHP segmentation fault.





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

#37698 [Fbk->Opn]: select on a synonym through a database link

[james at redeye dot com]

 ID:   37698
 User updated by:  james at redeye dot com
 Reported By:  james at redeye dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Linux Advanced Server 3.4
 PHP Version:  5.1.4
 New Comment:

Can't use the latest Oracle Instant Client as I use the ssh library and
using the Oracle 10g client causes this not to work. It only works with
the 9i client.

Using Toad and the Oracle 9i client the query works fine. Using Toad
and the Oracle 10g client the query works fine also.


Previous Comments:


[2006-06-05 09:49:17] [EMAIL PROTECTED]

Doesn't seem to be related to PHP..
Please try to rebuild PHP with the latest Oracle Instant Client and see
if it helps.
See also bug #36607.



[2006-06-05 09:42:34] james at redeye dot com

#0  0x011e0009 in ttcfopr () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#1  0x011d6341 in ttcdrv () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#2  0x0104636d in nioqwa () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#3  0x00ef9ec0 in upirtrc () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#4  0x00ea294d in kpurcsc () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#5  0x00e62ff9 in kpuexecv8 () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#6  0x00e64abe in kpuexec () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#7  0x00ec3c2c in OCIStmtExecute () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#8  0x080ff70b in oci_stmt_execute (stmt=0x9174a74)
at /usr/local/src/php-5.1.4/ext/pdo_oci/oci_statement.c:142
#9  0x080f8bc9 in zif_PDOStatement_execute (ht=0,
return_value=0x916f6ec, return_value_ptr=0x0, 
this_ptr=0x916f7d4, return_value_used=0) at
/usr/local/src/php-5.1.4/ext/pdo/pdo_stmt.c:451
#10 0x081fc669 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfff8bb0) at zend_vm_execute.h:200
#11 0x081fbf8d in execute (op_array=0x916b394) at zend_vm_execute.h:92
#12 0x00592920 in zend_oe () from
/usr/local/Zend/lib/Optimizer-2.6.1/php-5.1.x/ZendOptimizer.so
#13 0x0916b394 in ?? ()
#14 0x0090d180 in run_fp () from /lib/tls/libc.so.6
#15 0x0df0 in ?? ()
#16 0xbfff8c28 in ?? ()
#17 0x00848e9d in malloc () from /lib/tls/libc.so.6



[2006-06-05 08:44:29] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2006-06-05 08:17:12] james at redeye dot com

Description:

I have a synonym in my Oracle 10g database that points to a table on a
9i database. A database link is used to do this.

If I do a select * on this table a segmentation fault is produced in
php. If I do the select with a where clause or by specifying the fields
I want then PHP works ok

Reproduce code:
---
select * from segment // Causes segmentation fault

select * from segment where name like '%MR%' // works ok

select name from segment // works ok

Expected result:

returns the matches from the sql.

Actual result:
--
PHP segmentation fault.





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

#37698 [Fbk->Opn]: select on a synonym through a database link

[james at redeye dot com]

 ID:   37698
 User updated by:  james at redeye dot com
 Reported By:  james at redeye dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Linux Advanced Server 3.4
 PHP Version:  5.1.4
 New Comment:

No patch from bug 36607 did not fix it.


Previous Comments:


[2006-06-05 11:05:47] [EMAIL PROTECTED]

Did you try the patch from the last comment of bug #36607?



[2006-06-05 10:02:29] james at redeye dot com

Can't use the latest Oracle Instant Client as I use the ssh library and
using the Oracle 10g client causes this not to work. It only works with
the 9i client.

Using Toad and the Oracle 9i client the query works fine. Using Toad
and the Oracle 10g client the query works fine also.



[2006-06-05 09:49:17] [EMAIL PROTECTED]

Doesn't seem to be related to PHP..
Please try to rebuild PHP with the latest Oracle Instant Client and see
if it helps.
See also bug #36607.



[2006-06-05 09:42:34] james at redeye dot com

#0  0x011e0009 in ttcfopr () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#1  0x011d6341 in ttcdrv () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#2  0x0104636d in nioqwa () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#3  0x00ef9ec0 in upirtrc () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#4  0x00ea294d in kpurcsc () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#5  0x00e62ff9 in kpuexecv8 () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#6  0x00e64abe in kpuexec () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#7  0x00ec3c2c in OCIStmtExecute () from
/u01/app/oracle/product/920/lib/libclntsh.so.9.0
#8  0x080ff70b in oci_stmt_execute (stmt=0x9174a74)
at /usr/local/src/php-5.1.4/ext/pdo_oci/oci_statement.c:142
#9  0x080f8bc9 in zif_PDOStatement_execute (ht=0,
return_value=0x916f6ec, return_value_ptr=0x0, 
this_ptr=0x916f7d4, return_value_used=0) at
/usr/local/src/php-5.1.4/ext/pdo/pdo_stmt.c:451
#10 0x081fc669 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfff8bb0) at zend_vm_execute.h:200
#11 0x081fbf8d in execute (op_array=0x916b394) at zend_vm_execute.h:92
#12 0x00592920 in zend_oe () from
/usr/local/Zend/lib/Optimizer-2.6.1/php-5.1.x/ZendOptimizer.so
#13 0x0916b394 in ?? ()
#14 0x0090d180 in run_fp () from /lib/tls/libc.so.6
#15 0x0df0 in ?? ()
#16 0xbfff8c28 in ?? ()
#17 0x00848e9d in malloc () from /lib/tls/libc.so.6



[2006-06-05 08:44:29] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





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

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

#37828 [NEW]: mysql and mysqli consistancy

[james at cyberflowsolutions dot com]

From: james at cyberflowsolutions dot com
Operating system: all
PHP version:  5.1.4
PHP Bug Type: Feature/Change Request
Bug description:  mysql and mysqli consistancy

Description:

Would it be possible at some point to add a be_consistant 
flag that would alter the way functions take paramters?

EG: all mysql functions are in the form mysql_query("query", 
db_connection) but MOST mysqli functions are mysqli_query
(db_connection, "query") likewise, the order of haystacks 
and needles in string functions is a craps shoot. 

I understand this would create backwards compatability 
problems, but if it were maybe a flag in the config not on 
by default... 

consistancy is good for consistancies sake, and it would 
allow people to use variable functions more instead of 
having to write wrapper functions just to swap paramter 
order.

Overall, thanks for creating an amazing product that has 
made my life alot simpler than writing perl :) 

-- James


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

#35737 [Com]: undefined symbol: sqlite3SelectDelete

[james at e0ts dot com]

 ID:   35737
 Comment by:   james at e0ts dot com
 Reported By:  jphml at videotron dot ca
 Status:   No Feedback
 Bug Type: SQLite related
 Operating System: Linux
 PHP Version:  5.1.1
 New Comment:

Same with Debian 3.1


Previous Comments:


[2006-01-04 19:23:21] esesen at o2 dot pl

exactly the same problem under slackware 10.2



[2006-01-01 01:00:07] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, 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".



[2005-12-24 14:35:24] [EMAIL PROTECTED]

Are you able to reproduce it without Apache?
Does it work with PHP CLI?



[2005-12-24 07:41:01] jphml at videotron dot ca

I was not successful using CVS of 21-12-2005. I am using 
CentOS 4.1 latest patch.



[2005-12-22 17:22:22] jsuzuki at spamcop dot net

I had the same problem.  The suggestion by [EMAIL PROTECTED] worked out.

Just as an FYI this was on a horribly out of Red Hat 7 with Apache
1.3.

-jack



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

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

#36780 [NEW]: configure fails libxml check

[james at groovytrain dot com]

From: james at groovytrain dot com
Operating system: Redhat Linux 7.1
PHP version:  5.1.2
PHP Bug Type: Compile Failure
Bug description:  configure fails libxml check

Description:

Having compiled PHP without XML support on my system several times without
problem, I decided to try and include XML support.

When I run the following command:

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql
--without-pear --enable-libxml --with-gd --with-png-dir=/usr/lib
--with-jpeg-dir=/usr/lib --with-zlib-dir=/usr --enable-mbstring=all

It fails with:

checking whether libxml build works... no
configure: error: build test failed.  Please check the config.log for
details.

The "config.log" shows:

configure:19959: checking whether libxml build works
configure:19986: gcc -o conftest -g -O2   -Wl,-rpath,/usr/local/lib
-L/usr/local/lib conftest.c 
  
 -lresolv -lm -ldl -lnsl  -lxml2 -lz -lm 1>&5
configure: failed program was:
#line 19975 "configure"
#include "confdefs.h"


char xmlInitParser();
int main() {
  xmlInitParser();
  return 0;
}

My system has libxml2 version 2.6.23, which was compiled and installed
from source not using an RPM.

I have tried a various "--with-libxml-dir" parameters including
"--with-libxml-dir=/usr/local/lib" (libxml2 v2.6.23 is in "/usr/local/lib"
and v 2.4.10 in "/usr/lib").

Any help you can give will be gratefully received.

Expected result:

I expect ./configure to complete successfully.

Actual result:
--
./configure fails with:

checking whether libxml build works... no
configure: error: build test failed.  Please check the config.log for
details.


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

#36780 [Fbk->Opn]: configure fails libxml check

[james at groovytrain dot com]

 ID:   36780
 User updated by:  james at groovytrain dot com
 Reported By:  james at groovytrain dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Redhat Linux 7.1
 PHP Version:  5.1.2
 New Comment:

I tried configuring with "--with-libxml-dir=/usr/local" (although I was
fairly sure I'd tried this) and it still failed with the same error.

I then created "conftest.c", as you recommended, and compiled it.
"conftest.c" compiled without error into the file "conftest".

The only difference I can see, between the "conftest.c" that the
configuration script makes and the one I created, is the include line.


Previous Comments:


[2006-03-18 18:02:12] [EMAIL PROTECTED]

1) "--with-libxml-dir=/usr/local/lib"
This is definitely wrong. The "/lib" part should be omitted, so it
would look like "--with-libxml-dir=/usr/local".
This also applies to all the other options.

2) If you still can reproduce it, please put this code:
--
char xmlInitParser();
int main() {
  xmlInitParser();
  return 0;
}
--
into conftest.c and try to compile it like this:
gcc -o conftest -g -O2   -Wl,-rpath,/usr/local/lib
-L/usr/local/lib conftest.c -lresolv -lm -ldl -lnsl  -lxml2 -lz -lm

and post here the error message you get.

----

[2006-03-18 12:04:07] james at groovytrain dot com

Description:

Having compiled PHP without XML support on my system several times
without problem, I decided to try and include XML support.

When I run the following command:

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql
--without-pear --enable-libxml --with-gd --with-png-dir=/usr/lib
--with-jpeg-dir=/usr/lib --with-zlib-dir=/usr --enable-mbstring=all

It fails with:

checking whether libxml build works... no
configure: error: build test failed.  Please check the config.log for
details.

The "config.log" shows:

configure:19959: checking whether libxml build works
configure:19986: gcc -o conftest -g -O2   -Wl,-rpath,/usr/local/lib
-L/usr/local/lib conftest.c 
  
 -lresolv -lm -ldl -lnsl  -lxml2 -lz -lm 1>&5
configure: failed program was:
#line 19975 "configure"
#include "confdefs.h"


char xmlInitParser();
int main() {
  xmlInitParser();
  return 0;
}

My system has libxml2 version 2.6.23, which was compiled and installed
from source not using an RPM.

I have tried a various "--with-libxml-dir" parameters including
"--with-libxml-dir=/usr/local/lib" (libxml2 v2.6.23 is in
"/usr/local/lib" and v 2.4.10 in "/usr/lib").

Any help you can give will be gratefully received.

Expected result:

I expect ./configure to complete successfully.

Actual result:
--
./configure fails with:

checking whether libxml build works... no
configure: error: build test failed.  Please check the config.log for
details.






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

#36780 [Fbk->Opn]: configure fails libxml check

[james at groovytrain dot com]

 ID:   36780
 User updated by:  james at groovytrain dot com
 Reported By:  james at groovytrain dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Redhat Linux 7.1
 PHP Version:  5.1.2
 New Comment:

Executing the binary gives me the following error:

./conftest: error while loading shared libraries:
/usr/local/lib/libpthread.so.0: undefined symbol: _dl_cpuclock_offset


Previous Comments:


[2006-03-18 19:20:29] [EMAIL PROTECTED]

Did you try to execute the result binary?



[2006-03-18 19:08:15] james at groovytrain dot com

I tried configuring with "--with-libxml-dir=/usr/local" (although I was
fairly sure I'd tried this) and it still failed with the same error.

I then created "conftest.c", as you recommended, and compiled it.
"conftest.c" compiled without error into the file "conftest".

The only difference I can see, between the "conftest.c" that the
configuration script makes and the one I created, is the include line.



[2006-03-18 18:02:12] [EMAIL PROTECTED]

1) "--with-libxml-dir=/usr/local/lib"
This is definitely wrong. The "/lib" part should be omitted, so it
would look like "--with-libxml-dir=/usr/local".
This also applies to all the other options.

2) If you still can reproduce it, please put this code:
--
char xmlInitParser();
int main() {
  xmlInitParser();
  return 0;
}
--
into conftest.c and try to compile it like this:
gcc -o conftest -g -O2   -Wl,-rpath,/usr/local/lib
-L/usr/local/lib conftest.c -lresolv -lm -ldl -lnsl  -lxml2 -lz -lm

and post here the error message you get.

----

[2006-03-18 12:04:07] james at groovytrain dot com

Description:

Having compiled PHP without XML support on my system several times
without problem, I decided to try and include XML support.

When I run the following command:

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql
--without-pear --enable-libxml --with-gd --with-png-dir=/usr/lib
--with-jpeg-dir=/usr/lib --with-zlib-dir=/usr --enable-mbstring=all

It fails with:

checking whether libxml build works... no
configure: error: build test failed.  Please check the config.log for
details.

The "config.log" shows:

configure:19959: checking whether libxml build works
configure:19986: gcc -o conftest -g -O2   -Wl,-rpath,/usr/local/lib
-L/usr/local/lib conftest.c 
  
 -lresolv -lm -ldl -lnsl  -lxml2 -lz -lm 1>&5
configure: failed program was:
#line 19975 "configure"
#include "confdefs.h"


char xmlInitParser();
int main() {
  xmlInitParser();
  return 0;
}

My system has libxml2 version 2.6.23, which was compiled and installed
from source not using an RPM.

I have tried a various "--with-libxml-dir" parameters including
"--with-libxml-dir=/usr/local/lib" (libxml2 v2.6.23 is in
"/usr/local/lib" and v 2.4.10 in "/usr/lib").

Any help you can give will be gratefully received.

Expected result:

I expect ./configure to complete successfully.

Actual result:
--
./configure fails with:

checking whether libxml build works... no
configure: error: build test failed.  Please check the config.log for
details.






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

#33832 [NEW]: segfault with PDO_MYSQL_ATTR_USE_BUFFERED_QUERY

[james at safesearching dot com]

From: james at safesearching dot com
Operating system: *
PHP version:  5.1.0b3
PHP Bug Type: PDO related
Bug description:  segfault with PDO_MYSQL_ATTR_USE_BUFFERED_QUERY

Description:

Getting a segfault with the PDO_MYSQL_ATTR_USE_BUFFERED_QUERY attribute
set to true.

$db = new PDO;
$stmt = $db->prepare();
$stmt->execute();
$db->prepare();

... the above fills PDO::errorInfo() with an error "Cannot execute queries
while other unbuffered queries are active.  Consider using
PDOStatement::fetchAll().  Alternatively, if your code is only ever going
to run against mysql, you may enable query buffering by setting the
PDO_MYSQL_ATTR_USE_BUFFERED_QUERY attribute."

When calling $db->setAttribute(PDO_MYSQL_ATTR_USE_BUFFERED_QUERY, true) I
get a segfault.

Calling $stmt->closeCursor() after the first execute with the
USE_BUFFERED_QUERY attribute still 'causes a segfault. Without the
USE_BUFFERED_QUERY attribute, the above error goes away, there's not
segfault, and everything works as expected.

Reproduce code:
---
$db = new PDO(
'mysql:dbname=test;host=localhost',
'user',
'secret'
);

$db->setAttribute(PDO_MYSQL_ATTR_USE_BUFFERED_QUERY, true);

$stmt = $db->prepare('SHOW TABLES');
$stmt->execute();
$stmt = $db->prepare('SHOW TABLES');

print_r($db->errorInfo());

Expected result:

No segfault

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 30628)]
0x080c6085 in pdo_mysql_stmt_execute (stmt=0x84c5b14)
at /home/james/php/ext/pdo_mysql/mysql_statement.c:102
102 switch (S->fields[i].type)
{
(gdb) bt
#0  0x080c6085 in pdo_mysql_stmt_execute (stmt=0x84c5b14)
at /home/james/php/ext/pdo_mysql/mysql_statement.c:102
#1  0x080c0979 in zif_PDOStatement_execute (ht=0, return_value=0x84c5a3c,
return_value_ptr=0x0, this_ptr=0x84c5ab4, return_value_used=0)
at /home/james/php/ext/pdo/pdo_stmt.c:395
#2  0x081bdb97 in execute_internal (execute_data_ptr=0xbfffced0,
return_value_used=0) at /home/james/php/Zend/zend_execute.c:1324
#3  0x40409795 in xdebug_execute_internal
(current_execute_data=0xbfffced0,
return_value_used=0) at /home/james/xdebug/xdebug.c:1223
#4  0x081be08b in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffced0)
at /home/james/php/Zend/zend_vm_execute.h:186
#5  0x081bdca1 in execute (op_array=0x84c5584)
at /home/james/php/Zend/zend_vm_execute.h:87
#6  0x404095c8 in xdebug_execute (op_array=0x84c5584)
at /home/james/xdebug/xdebug.c:1166
#7  0x081a09b4 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /home/james/php/Zend/zend.c:1087
#8  0x08170916 in php_execute_script (primary_file=0xb2d0)
at /home/james/php/main/main.c:1672
#9  0x08235154 in main (argc=2, argv=0xb384)
at /home/james/php/sapi/cli/php_cli.c:1039
#10 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

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

#33833 [NEW]: fetch doesn't "finish" unbuffered query when all rows have been fetched

[james at safesearching dot com]

From: james at safesearching dot com
Operating system: *
PHP version:  5.1.0b3
PHP Bug Type: PDO related
Bug description:  fetch doesn't "finish" unbuffered query when all rows have 
been fetched

Description:

When a query is expected to return one row, and therefor
PDOStatement::fetch() is only called once, the query isn't "closed" or
"finished" or whatever you like.

The following calls fetch() twice, and only on the second call does the
statment get released so that another statement can be prepared.

$stmt = $db->prepare('SELECT CURDATE()');

while ($row = $stmt->fetch()) {}

The following calls fetch once, and the statement is not released even
though all the rows have been fetched.

$stmt = $db->prepare('SELECT CURDATE()');
$row  = $stmt->fetch();

Calling $stmt->closeCursor() all over the place seems a little kludgy...
and I'm assuming $stmt->fetchAll(PDO_FETCH_BOUND) doesn't work.

Reproduce code:
---
$db = new PDO(
'mysql:dbname=test;host=localhost',
'teecor',
'k3y2t33c0r'
);

$stmt = $db->prepare('SELECT CURDATE()');
$stmt->execute();
$row = $stmt->fetch();

print_r($row);

$stmt = $db->prepare('SELECT CURDATE()');

print_r($db->errorInfo());

Expected result:

Array
(
[0] => Array
(
[CURDATE()] => 2005-07-22
[0] => 2005-07-22
)

)
Array
(
[0] => 0
)


Actual result:
--
Array
(
[CURDATE()] => 2005-07-22
[0] => 2005-07-22
)
Array
(
[0] => HY000
[1] => 2014
[2] => Cannot execute queries while other unbuffered queries are
active.  Consider using PDOStatement::fetchAll().  Alternatively, if your
code is only ever going to run against mysql, you may enable query
buffering by setting the PDO_MYSQL_ATTR_USE_BUFFERED_QUERY attribute.
)


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

#33832 [Fbk->Csd]: segfault with PDO_MYSQL_ATTR_USE_BUFFERED_QUERY

[james at safesearching dot com]

 ID:   33832
 User updated by:  james at safesearching dot com
 Reported By:  james at safesearching dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.1.0b3
 New Comment:

Works in CVS.


Previous Comments:


[2005-07-23 04:22:28] [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

I think that Ilia already fixed this in CVS; please try a snapshot.



[2005-07-23 03:25:17] james at safesearching dot com

Description:

Getting a segfault with the PDO_MYSQL_ATTR_USE_BUFFERED_QUERY attribute
set to true.

$db = new PDO;
$stmt = $db->prepare();
$stmt->execute();
$db->prepare();

... the above fills PDO::errorInfo() with an error "Cannot execute
queries while other unbuffered queries are active.  Consider using
PDOStatement::fetchAll().  Alternatively, if your code is only ever
going to run against mysql, you may enable query buffering by setting
the PDO_MYSQL_ATTR_USE_BUFFERED_QUERY attribute."

When calling $db->setAttribute(PDO_MYSQL_ATTR_USE_BUFFERED_QUERY, true)
I get a segfault.

Calling $stmt->closeCursor() after the first execute with the
USE_BUFFERED_QUERY attribute still 'causes a segfault. Without the
USE_BUFFERED_QUERY attribute, the above error goes away, there's not
segfault, and everything works as expected.

Reproduce code:
---
$db = new PDO(
'mysql:dbname=test;host=localhost',
'user',
'secret'
);

$db->setAttribute(PDO_MYSQL_ATTR_USE_BUFFERED_QUERY, true);

$stmt = $db->prepare('SHOW TABLES');
$stmt->execute();
$stmt = $db->prepare('SHOW TABLES');

print_r($db->errorInfo());

Expected result:

No segfault

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 30628)]
0x080c6085 in pdo_mysql_stmt_execute (stmt=0x84c5b14)
at /home/james/php/ext/pdo_mysql/mysql_statement.c:102
102 switch
(S->fields[i].type) {
(gdb) bt
#0  0x080c6085 in pdo_mysql_stmt_execute (stmt=0x84c5b14)
at /home/james/php/ext/pdo_mysql/mysql_statement.c:102
#1  0x080c0979 in zif_PDOStatement_execute (ht=0,
return_value=0x84c5a3c,
return_value_ptr=0x0, this_ptr=0x84c5ab4, return_value_used=0)
at /home/james/php/ext/pdo/pdo_stmt.c:395
#2  0x081bdb97 in execute_internal (execute_data_ptr=0xbfffced0,
return_value_used=0) at /home/james/php/Zend/zend_execute.c:1324
#3  0x40409795 in xdebug_execute_internal
(current_execute_data=0xbfffced0,
return_value_used=0) at /home/james/xdebug/xdebug.c:1223
#4  0x081be08b in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffced0)
at /home/james/php/Zend/zend_vm_execute.h:186
#5  0x081bdca1 in execute (op_array=0x84c5584)
at /home/james/php/Zend/zend_vm_execute.h:87
#6  0x404095c8 in xdebug_execute (op_array=0x84c5584)
at /home/james/xdebug/xdebug.c:1166
#7  0x081a09b4 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/james/php/Zend/zend.c:1087
#8  0x08170916 in php_execute_script (primary_file=0xb2d0)
at /home/james/php/main/main.c:1672
#9  0x08235154 in main (argc=2, argv=0xb384)
at /home/james/php/sapi/cli/php_cli.c:1039
#10 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6





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

#32101 [Com]: Exception in unknown on line 0 when throwing exception inside exception handler

[james at academicsuperstore dot com]

 ID:   32101
 Comment by:   james at academicsuperstore dot com
 Reported By:  ceefour at gauldong dot net
 Status:   No Feedback
 Bug Type: Scripting Engine problem
 Operating System: *
 PHP Version:  5CVS-2005-02-15
 New Comment:

I am experiencing the same problem using 5.0.4.


Previous Comments:


[2005-05-21 01:00:04] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, 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".



[2005-05-13 13:33:49] [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-02-25 11:20:24] ceefour at gauldong dot net

This modified code may be better illustrate the problem:





[2005-02-25 11:01:19] [EMAIL PROTECTED]





[2005-02-25 07:12:16] ceefour at gauldong dot net

Description:

When an exception is thrown inside an exception handler, a "exception
thrown without stack frame in unknown on line 0" message is displayed.

While the meaning of this message is "clear" enough... it doesn't help
at all.

If you trigger_error() inside an error handler, the default error
handler is triggered, but still showing meaningful/helpful error
message. Exceptions inside exception handler should behave similarly.

Reproduce code:
---
// do this inside an exception handler function
throw new Exception('test'); 

Expected result:

...file something.php on line 483...

Actual result:
--
...unknown on line 0





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

#33598 [Com]: Throwing exception from __destruct causes fatal error

[james at academicsuperstore dot com]

 ID:   33598
 Comment by:   james at academicsuperstore dot com
 Reported By:  carlo dot razzeto at mtginfo dot com
 Status:   Verified
 Bug Type: Class/Object related
 Operating System: *
 PHP Version:  5CVS-2005-07-07
 New Comment:

I am experiencing this same problem in 5.0.4.  I will not have time to
test the snapshot for another week or so due to workload at the office.


Previous Comments:


[2005-07-07 15:27:12] carlo dot razzeto at mtginfo dot com

The same error is occuring when attempting to throw an exception from
the deconstructor of a class while the script is shutting down. As my
linux box is currnetly not available I tested on my windows
workstation. I will verify this later today with my linux box.

Z:\PHP\php5-win32-latest>php -version
PHP 5.1.0-dev (cli) (built: Jul  7 2005 12:24:46)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies

Z:\PHP\php5-win32-latest>php test.php
Construct
Hello World
Destruct

Fatal error: Exception thrown without a stack frame in Unknown on line
0



[2005-07-07 09:43:16] [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-07-07 01:46:59] carlo dot razzeto at mtginfo dot com

Description:

When performing an operation which throws an exception in the
__destruct method of a class, the following Error is generated

Fatal error: Exception thrown without a stack frame in Unknown on line
0

I have only observed this happening when an object goes out of scope
because the script has ended. Rather than generating a scripting engine
error, PHP should allow for the script to deal with the error, for
instance when an exception handler has been specified by the script.

Reproduce code:
---
class test {
function __construct() {
echo "Construct\n";
}

function greet() {
echo "Hello World\n";
}

function __destruct() {
echo "Destruct\n";
throw new Exception( 'test' );
}
}

$test = new test();
$test->greet();

Expected result:

Construct
Hello World
Destruct

Fatal error: Uncaught exception 'Exception' with message 'test' in
/home/crazzeto/test.php:13
Stack trace:
#0 /home/crazzeto/test.php(13): test::__destruct()
#1 /home/crazzeto/test.php(20): test::__destruct()
#2 /home/crazzeto/test.php(20): unknown()
#3 {main}
  thrown in /home/crazzeto/test.php on line 13


Actual result:
--
[EMAIL PROTECTED] crazzeto]$ php test.php
Construct
Hello World
Destruct

Fatal error: Exception thrown without a stack frame in Unknown on line
0






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

#34001 [NEW]: truncating value when optional display width value is used

[james at safesearching dot com]

From: james at safesearching dot com
Operating system: *
PHP version:  5.1.0b3
PHP Bug Type: PDO related
Bug description:  truncating value when optional display width value is used

Description:

PDO seems to be trucating the value from MySQL when using the optional
display width syntax (ie, mediumint(4)).

>From http://dev.mysql.com/doc/mysql/en/numeric-types.html


...

The display width does not constrain the range of values that can be
stored in the column, nor the number of digits that are displayed for
values having a width exceeding that specified for the column. 


I'm not sure if that is the goal of PDO here is to acutally constrain the
display width, since I occasionally get junk characters after the
specified length.

ie:
+-+
| id mediumint(4) |
+-+
| 123456  |
+-+

value from PDO is '1234', but sometimes is '1234Àd' or other junk
characters.

Reproduce code:
---
$c = new PDO(
"mysql:dbname=test;host=localhost", '***', '***'
);

// mysql mediumint
// bytes: 3
// minimum: -8388608 / 0
// maximum: 8388607  / 16777215

$c->exec('CREATE TABLE IF NOT EXISTS foo (id mediumint(4), primary key
(id));');
$c->exec("INSERT INTO foo VALUES (12345);");
$c->exec("INSERT INTO foo VALUES (1234567);");

$stmt = $c->prepare("SELECT * FROM foo");

$stmt->execute();

print_r($stmt->fetchAll());

Expected result:

Array
(
[0] => Array
(
[id] => 12345
[0] => 12345
)

[1] => Array
(
[id] => 1234567
[0] => 1234567
)

)


Actual result:
--
Array
(
[0] => Array
(
[id] => 1234
[0] => 1234
)

[1] => Array
(
[id] => 1234
[0] => 1234
)

)

--- or sometimes 

Array
(
[0] => Array
(
[id] => 1234À
[0] => 1234À
)

[1] => Array
(
[id] => 1234ÀdL
[0] => 1234ÀdL
)

)

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

#34001 [Fbk->Opn]: truncating value when optional display width value is used

[james at safesearching dot com]

 ID:   34001
 User updated by:  james at safesearching dot com
 Reported By:  james at safesearching dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.1.0b3
 New Comment:

Tested php5-200508100030, and the junk character issue seems to be
resolved, but values from the database are still being truncated.


Previous Comments:


[2005-08-05 11:20:46] [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-08-05 02:36:43] james at safesearching dot com

Description:

PDO seems to be trucating the value from MySQL when using the optional
display width syntax (ie, mediumint(4)).

>From http://dev.mysql.com/doc/mysql/en/numeric-types.html


...

The display width does not constrain the range of values that can be
stored in the column, nor the number of digits that are displayed for
values having a width exceeding that specified for the column. 


I'm not sure if that is the goal of PDO here is to acutally constrain
the display width, since I occasionally get junk characters after the
specified length.

ie:
+-+
| id mediumint(4) |
+-+
| 123456  |
+-+

value from PDO is '1234', but sometimes is '1234Àd' or other junk
characters.

Reproduce code:
---
$c = new PDO(
"mysql:dbname=test;host=localhost", '***', '***'
);

// mysql mediumint
// bytes: 3
// minimum: -8388608 / 0
// maximum: 8388607  / 16777215

$c->exec('CREATE TABLE IF NOT EXISTS foo (id mediumint(4), primary key
(id));');
$c->exec("INSERT INTO foo VALUES (12345);");
$c->exec("INSERT INTO foo VALUES (1234567);");

$stmt = $c->prepare("SELECT * FROM foo");

$stmt->execute();

print_r($stmt->fetchAll());

Expected result:

Array
(
[0] => Array
(
[id] => 12345
[0] => 12345
)

[1] => Array
(
[id] => 1234567
[0] => 1234567
)

)


Actual result:
--
Array
(
[0] => Array
(
[id] => 1234
[0] => 1234
)

[1] => Array
(
[id] => 1234
[0] => 1234
)

)

--- or sometimes 

Array
(
[0] => Array
(
[id] => 1234À
[0] => 1234À
)

[1] => Array
(
[id] => 1234ÀdL
[0] => 1234ÀdL
)

)





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

#34001 [Bgs->Opn]: truncating value when optional display width value is used

[james at safesearching dot com]

 ID:   34001
 User updated by:  james at safesearching dot com
 Reported By:  james at safesearching dot com
-Status:   Bogus
+Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.1.0b3
 Assigned To:  wez
 New Comment:

MySQL isn't doing any truncating:


Reproduce code:
---
exec('CREATE TABLE IF NOT EXISTS foo (id mediumint(4), primary key
(id));');
$c->exec("INSERT INTO foo VALUES (6234567);");

$stmt = $c->prepare("SELECT * FROM foo");

$stmt->execute();

print_r($stmt->fetchAll());

$c = mysql_connect('localhost', '***', '***');

mysql_select_db('test');

$r = mysql_query("SELECT * FROM foo");

while ($a = mysql_fetch_array($r))
print_r($a);

?>

Actual result:
--
Array
(
[0] => Array
(
[id] => 6234
[0] => 6234
)

)
Array
(
[0] => 6234567
[id] => 6234567
)

Comments:
-
If MySQL was truncating the data, then the results should be the same
for both APIs.


Previous Comments:


[2005-08-30 01:09:09] [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.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

The pdo_mysql driver does not truncate any data, if it does occur it is
done by myself itself.



[2005-08-10 10:52:10] [EMAIL PROTECTED]

Is the truncating supposed to happen?



[2005-08-10 04:01:33] james at safesearching dot com

Tested php5-200508100030, and the junk character issue seems to be
resolved, but values from the database are still being truncated.



[2005-08-05 11:20:46] [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-08-05 02:36:43] james at safesearching dot com

Description:

PDO seems to be trucating the value from MySQL when using the optional
display width syntax (ie, mediumint(4)).

>From http://dev.mysql.com/doc/mysql/en/numeric-types.html


...

The display width does not constrain the range of values that can be
stored in the column, nor the number of digits that are displayed for
values having a width exceeding that specified for the column. 


I'm not sure if that is the goal of PDO here is to acutally constrain
the display width, since I occasionally get junk characters after the
specified length.

ie:
+-+
| id mediumint(4) |
+-+
| 123456  |
+-+

value from PDO is '1234', but sometimes is '1234Àd' or other junk
characters.

Reproduce code:
---
$c = new PDO(
"mysql:dbname=test;host=localhost", '***', '***'
);

// mysql mediumint
// bytes: 3
// minimum: -8388608 / 0
// maximum: 8388607  / 16777215

$c->exec('CREATE TABLE IF NOT EXISTS foo (id mediumint(4), primary key
(id));');
$c->exec("INSERT INTO foo VALUES (12345);");
$c->exec("INSERT INTO foo VALUES (1234567);");

$stmt = $c->prepare("SELECT * FROM foo");

$stmt->execute();

print_r($stmt->fetchAll());

Expected result:

Array
(
[0] => Array
(
[id] => 12345
[0] => 12345
)

[1] => Array
(
[id] => 1234567
[0] => 1234567
)

)


Actual result:
--
Array
(
[0] => Array
(
[id] => 1234
[0] => 1234
)

[1] => Array
(
[id] => 1234
[0] => 1234
)

)

--- or sometimes 

Array
(
[0] => Array
(
[id] => 1234À
[0] => 1234À
)

[1] => Array
(
[id] => 1234ÀdL
[0] => 1234ÀdL
)

)





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

#34312 [NEW]: segfault in 5.04

[james at academicsuperstore dot com]

From: james at academicsuperstore dot com
Operating system: Debian 3.1 Linux 2.4.29
PHP version:  5.0.4
PHP Bug Type: Reproducible crash
Bug description:  segfault in 5.04

Description:

Segfault

Apache/2.0.53
Build Date  Jun 8 2005 14:44:05

'./configure' '--prefix=/usr/local/php5' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2-dir=/usr/bin/bzip2'
'--with-gd=shared' '--enable-gd-native-ttf' '--without-gdbm' '--with-gmp'
'--with-jpeg-dir=/usr' '--with-png' '--with-layout=GNU' '--enable-exif'
'--enable-ftp' '--enable-magic-quotes' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--with-mysql=/usr'
'--with-pfpro=shared,/usr/local/src/verisign/payflowpro/linux/lib'
'--enable-memory-limit' '--enable-mbstring=shared'
'--enable-mbstr-enc-trans' '--disable-cgi' '--enable-cli' '--with-mm'
'--with-zlib' '--with-apxs2=/usr/sbin/apxs' '--disable-libxml'

Reproduce code:
---
I do not have specific reproduce code as the segfault is part of a large
and complex system.  I am posting the bug only after failing to be able to
isolate the problem further.

Expected result:

no segfault

Actual result:
--
(gdb) bt
#0  0x003b859e in mallopt () from /lib/libc.so.6
#1  0x003b843e in mallopt () from /lib/libc.so.6
#2  0x003b715f in free () from /lib/libc.so.6
#3  0x0064f812 in _efree (ptr=0x85739e4)
at /usr/local/src/php-5.0.4/Zend/zend_alloc.c:287
#4  0x00659f1c in destroy_op_array (op_array=0x856fad0)
at /usr/local/src/php-5.0.4/Zend/zend_opcode.c:225
#5  0x00659c63 in destroy_zend_function (function=0x856fad0)
at /usr/local/src/php-5.0.4/Zend/zend_opcode.c:103
#6  0x00659c79 in zend_function_dtor (function=0x856fad0)
at /usr/local/src/php-5.0.4/Zend/zend_opcode.c:115
#7  0x00666b6c in zend_hash_del_key_or_index (ht=0x810f098,
arKey=0x856f878 "dumpcatsforleftnav", nKeyLength=19, h=0, flag=0)
at /usr/local/src/php-5.0.4/Zend/zend_hash.c:490
#8  0x006670b3 in zend_hash_reverse_apply (ht=0x810f098,
apply_func=0x656e78 )
at /usr/local/src/php-5.0.4/Zend/zend_hash.c:738
#9  0x00657389 in shutdown_executor ()
at /usr/local/src/php-5.0.4/Zend/zend_execute_API.c:264
#10 0x00660eed in zend_deactivate ()
at /usr/local/src/php-5.0.4/Zend/zend.c:817
#11 0x006320f5 in php_request_shutdown (dummy=0x0)
at /usr/local/src/php-5.0.4/main/main.c:1216
#12 0x0069e048 in php_apache_request_dtor (r=0x82df078)
at /usr/local/src/php-5.0.4/sapi/apache2handler/sapi_apache2.c:443
#13 0x0069e5a9 in php_handler (r=0x82df078)
at /usr/local/src/php-5.0.4/sapi/apache2handler/sapi_apache2.c:572
#14 0x0807d429 in ap_run_handler (r=0x82df078) at config.c:152
#15 0x0807d973 in ap_invoke_handler (r=0x82df078) at config.c:364
#16 0x0807ad22 in ap_process_request (r=0x82df078) at http_request.c:249
#17 0x08076c8a in ap_process_http_connection (c=0x82d70e0) at
http_core.c:251
#18 0x08085bb8 in ap_run_process_connection (c=0x82d70e0) at
connection.c:43
#19 0x08085e7c in ap_process_connection (c=0x82d70e0, csd=0x82d7008)
at connection.c:176
#20 0x0807c0b0 in child_main (child_num_arg=2) at prefork.c:610
#21 0x0807c20a in make_child (s=0x80f4058, slot=2) at prefork.c:704
#22 0x0807c261 in startup_children (number_to_start=5) at prefork.c:722
#23 0x0807c563 in ap_mpm_run (_pconf=0x80ba958, plog=0x80eca20,
s=0x80f4058)
at prefork.c:941
#24 0x08081d4e in main (argc=5, argv=0xbdd4) at main.c:618


-- 
Edit bug report at http://bugs.php.net/?id=34312&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=34312&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=34312&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=34312&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34312&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34312&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=34312&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=34312&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=34312&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34312&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=34312&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=34312&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=34312&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34312&

#34312 [Fbk->Opn]: segfault in 5.04

[james at academicsuperstore dot com]

 ID:   34312
 User updated by:  james at academicsuperstore dot com
 Reported By:  james at academicsuperstore dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Debian 3.1 Linux 2.4.29
 PHP Version:  5.0.4
 New Comment:

When I configure, make, make install using the same configure line as
before I am left with a nonfunctioning php.  Hitting php pages just
produces a white screen.  Even the cli php exits with code 1.  There
are no cores or errors in the log.  Was something between 5.0.4 and the
snapshot broken?  Sorry I can't test the fix.


Previous Comments:


[2005-09-01 17:48:58] [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-08-31 01:19:15] james at academicsuperstore dot com

Description:

Segfault

Apache/2.0.53
Build Date  Jun 8 2005 14:44:05

'./configure' '--prefix=/usr/local/php5' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2-dir=/usr/bin/bzip2'
'--with-gd=shared' '--enable-gd-native-ttf' '--without-gdbm'
'--with-gmp' '--with-jpeg-dir=/usr' '--with-png' '--with-layout=GNU'
'--enable-exif' '--enable-ftp' '--enable-magic-quotes'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--with-mysql=/usr'
'--with-pfpro=shared,/usr/local/src/verisign/payflowpro/linux/lib'
'--enable-memory-limit' '--enable-mbstring=shared'
'--enable-mbstr-enc-trans' '--disable-cgi' '--enable-cli' '--with-mm'
'--with-zlib' '--with-apxs2=/usr/sbin/apxs' '--disable-libxml'

Reproduce code:
---
I do not have specific reproduce code as the segfault is part of a
large and complex system.  I am posting the bug only after failing to
be able to isolate the problem further.

Expected result:

no segfault

Actual result:
--
(gdb) bt
#0  0x003b859e in mallopt () from /lib/libc.so.6
#1  0x003b843e in mallopt () from /lib/libc.so.6
#2  0x003b715f in free () from /lib/libc.so.6
#3  0x0064f812 in _efree (ptr=0x85739e4)
at /usr/local/src/php-5.0.4/Zend/zend_alloc.c:287
#4  0x00659f1c in destroy_op_array (op_array=0x856fad0)
at /usr/local/src/php-5.0.4/Zend/zend_opcode.c:225
#5  0x00659c63 in destroy_zend_function (function=0x856fad0)
at /usr/local/src/php-5.0.4/Zend/zend_opcode.c:103
#6  0x00659c79 in zend_function_dtor (function=0x856fad0)
at /usr/local/src/php-5.0.4/Zend/zend_opcode.c:115
#7  0x00666b6c in zend_hash_del_key_or_index (ht=0x810f098,
arKey=0x856f878 "dumpcatsforleftnav", nKeyLength=19, h=0, flag=0)
at /usr/local/src/php-5.0.4/Zend/zend_hash.c:490
#8  0x006670b3 in zend_hash_reverse_apply (ht=0x810f098,
apply_func=0x656e78 )
at /usr/local/src/php-5.0.4/Zend/zend_hash.c:738
#9  0x00657389 in shutdown_executor ()
at /usr/local/src/php-5.0.4/Zend/zend_execute_API.c:264
#10 0x00660eed in zend_deactivate ()
at /usr/local/src/php-5.0.4/Zend/zend.c:817
#11 0x006320f5 in php_request_shutdown (dummy=0x0)
at /usr/local/src/php-5.0.4/main/main.c:1216
#12 0x0069e048 in php_apache_request_dtor (r=0x82df078)
at /usr/local/src/php-5.0.4/sapi/apache2handler/sapi_apache2.c:443
#13 0x0069e5a9 in php_handler (r=0x82df078)
at /usr/local/src/php-5.0.4/sapi/apache2handler/sapi_apache2.c:572
#14 0x0807d429 in ap_run_handler (r=0x82df078) at config.c:152
#15 0x0807d973 in ap_invoke_handler (r=0x82df078) at config.c:364
#16 0x0807ad22 in ap_process_request (r=0x82df078) at
http_request.c:249
#17 0x08076c8a in ap_process_http_connection (c=0x82d70e0) at
http_core.c:251
#18 0x08085bb8 in ap_run_process_connection (c=0x82d70e0) at
connection.c:43
#19 0x08085e7c in ap_process_connection (c=0x82d70e0, csd=0x82d7008)
at connection.c:176
#20 0x0807c0b0 in child_main (child_num_arg=2) at prefork.c:610
#21 0x0807c20a in make_child (s=0x80f4058, slot=2) at prefork.c:704
#22 0x0807c261 in startup_children (number_to_start=5) at
prefork.c:722
#23 0x0807c563 in ap_mpm_run (_pconf=0x80ba958, plog=0x80eca20,
s=0x80f4058)
at prefork.c:941
#24 0x08081d4e in main (argc=5, argv=0xbdd4) at main.c:618






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

#34312 [Fbk->Opn]: segfault in 5.04

[james at academicsuperstore dot com]

 ID:   34312
 User updated by:  james at academicsuperstore dot com
 Reported By:  james at academicsuperstore dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Debian 3.1 Linux 2.4.29
 PHP Version:  5.0.4
 New Comment:

I didn't touch my httpd.conf.  I literally did a ./configure, make,
make install, apachectl restart.  Plus even running just the cli php is
borked, exits with message 1 no matter what options it is given.

Even something like:
php -r "echo 'test';"

just exits with message 1 and no output.


Previous Comments:


[2005-09-01 23:48:50] [EMAIL PROTECTED]

Check your httpd.conf that PHP is really enabled..


----

[2005-09-01 20:57:56] james at academicsuperstore dot com

When I configure, make, make install using the same configure line as
before I am left with a nonfunctioning php.  Hitting php pages just
produces a white screen.  Even the cli php exits with code 1.  There
are no cores or errors in the log.  Was something between 5.0.4 and the
snapshot broken?  Sorry I can't test the fix.



[2005-09-01 17:48:58] [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-08-31 01:19:15] james at academicsuperstore dot com

Description:

Segfault

Apache/2.0.53
Build Date  Jun 8 2005 14:44:05

'./configure' '--prefix=/usr/local/php5' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2-dir=/usr/bin/bzip2'
'--with-gd=shared' '--enable-gd-native-ttf' '--without-gdbm'
'--with-gmp' '--with-jpeg-dir=/usr' '--with-png' '--with-layout=GNU'
'--enable-exif' '--enable-ftp' '--enable-magic-quotes'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--with-mysql=/usr'
'--with-pfpro=shared,/usr/local/src/verisign/payflowpro/linux/lib'
'--enable-memory-limit' '--enable-mbstring=shared'
'--enable-mbstr-enc-trans' '--disable-cgi' '--enable-cli' '--with-mm'
'--with-zlib' '--with-apxs2=/usr/sbin/apxs' '--disable-libxml'

Reproduce code:
---
I do not have specific reproduce code as the segfault is part of a
large and complex system.  I am posting the bug only after failing to
be able to isolate the problem further.

Expected result:

no segfault

Actual result:
--
(gdb) bt
#0  0x003b859e in mallopt () from /lib/libc.so.6
#1  0x003b843e in mallopt () from /lib/libc.so.6
#2  0x003b715f in free () from /lib/libc.so.6
#3  0x0064f812 in _efree (ptr=0x85739e4)
at /usr/local/src/php-5.0.4/Zend/zend_alloc.c:287
#4  0x00659f1c in destroy_op_array (op_array=0x856fad0)
at /usr/local/src/php-5.0.4/Zend/zend_opcode.c:225
#5  0x00659c63 in destroy_zend_function (function=0x856fad0)
at /usr/local/src/php-5.0.4/Zend/zend_opcode.c:103
#6  0x00659c79 in zend_function_dtor (function=0x856fad0)
at /usr/local/src/php-5.0.4/Zend/zend_opcode.c:115
#7  0x00666b6c in zend_hash_del_key_or_index (ht=0x810f098,
arKey=0x856f878 "dumpcatsforleftnav", nKeyLength=19, h=0, flag=0)
at /usr/local/src/php-5.0.4/Zend/zend_hash.c:490
#8  0x006670b3 in zend_hash_reverse_apply (ht=0x810f098,
apply_func=0x656e78 )
at /usr/local/src/php-5.0.4/Zend/zend_hash.c:738
#9  0x00657389 in shutdown_executor ()
at /usr/local/src/php-5.0.4/Zend/zend_execute_API.c:264
#10 0x00660eed in zend_deactivate ()
at /usr/local/src/php-5.0.4/Zend/zend.c:817
#11 0x006320f5 in php_request_shutdown (dummy=0x0)
at /usr/local/src/php-5.0.4/main/main.c:1216
#12 0x0069e048 in php_apache_request_dtor (r=0x82df078)
at /usr/local/src/php-5.0.4/sapi/apache2handler/sapi_apache2.c:443
#13 0x0069e5a9 in php_handler (r=0x82df078)
at /usr/local/src/php-5.0.4/sapi/apache2handler/sapi_apache2.c:572
#14 0x0807d429 in ap_run_handler (r=0x82df078) at config.c:152
#15 0x0807d973 in ap_invoke_handler (r=0x82df078) at config.c:364
#16 0x0807ad22 in ap_process_request (r=0x82df078) at
http_request.c:249
#17 0x08076c8a in ap_process_http_connection (c=0x82d70e0) at
http_core.c:251
#18 0x08085bb8 in ap_run_process_connection (c=0x82d70e0) at
connection.c:43
#19 0x08085e7c in ap_process_connection (c=0x82d70e0, csd=0x82d7008)
at connection.c:176
#20 

#34312 [Fbk->Csd]: segfault in 5.04

[james at academicsuperstore dot com]

 ID:   34312
 User updated by:  james at academicsuperstore dot com
 Reported By:  james at academicsuperstore dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Debian 3.1 Linux 2.4.29
 PHP Version:  5.0.4
 New Comment:

Thanks, everything works as expected and the segfault is fixed.  When
will 5.0.5 be out?


Previous Comments:


[2005-09-02 07:24:39] [EMAIL PROTECTED]

And FYI: PHP touches httpd.conf when you do 'make install'..




[2005-09-02 07:24:10] [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

Try newer snapshot.



[2005-09-02 01:45:36] james at academicsuperstore dot com

I didn't touch my httpd.conf.  I literally did a ./configure, make,
make install, apachectl restart.  Plus even running just the cli php is
borked, exits with message 1 no matter what options it is given.

Even something like:
php -r "echo 'test';"

just exits with message 1 and no output.



[2005-09-01 23:48:50] [EMAIL PROTECTED]

Check your httpd.conf that PHP is really enabled..


----

[2005-09-01 20:57:56] james at academicsuperstore dot com

When I configure, make, make install using the same configure line as
before I am left with a nonfunctioning php.  Hitting php pages just
produces a white screen.  Even the cli php exits with code 1.  There
are no cores or errors in the log.  Was something between 5.0.4 and the
snapshot broken?  Sorry I can't test the fix.



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

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

[PHP-BUG] Bug #54186 [NEW]: Scope Resolution / Closure Class Issues

[james at jamesreno dot com]

From: 
Operating system: Linux-2.6
PHP version:  5.3.5
Package:  Class/Object related
Bug Type: Bug
Bug description:Scope Resolution / Closure Class Issues

Description:

closure objects which are members of another object can not be executed
without 

temp intermediary variables and constants of objects can not be accessed
when 

they are members of another object.



I can not find any documentation to support why these two items throw
syntax 

errors rather than executing as expected. At very least case this is a 

documentation issue and should be noted.

Test script:
---
callback = $callback;

$this->test = new apples();

 }

}





$a = new test(function(){

echo "test\n";

});



/*

 * Broken Closure Class Example

 */



// BROKEN:

$a->callback();



// Works

$tmp = $a->callback;

$tmp();



/*

 * Broken constant scope resolution

 */



// BROKEN:

$a->test::test;



// Works

$tmp = $a->test;

echo $tmp::test;



?>

Expected result:

Would expect:



$a->callback() to execute the anonymous function.



would expect:

echo $a->test::test to echo "This is a test"

Actual result:
--
Both references cause syntax errors.

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

Bug #54186 [Bgs]: Scope Resolution / Closure Class Issues

[james at jamesreno dot com]

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

 ID: 54186
 User updated by:james at jamesreno dot com
 Reported by:james at jamesreno dot com
 Summary:Scope Resolution / Closure Class Issues
 Status: Bogus
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux-2.6
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

"the other is a mere grammatical issue."  Would you care to explain?



To me these features seem half implemented which mean they are bugs --
not 

feature requests. The language already supports said items just not in
"certain 

contexts" (To which should be noted in documentation, at very least). 
At least 

change this to a documentation bug - do not close it as "bogus" the bug
is 

clearly NOT bogus as it indeed is real and does affect the language and
usage 

there-of -- "WONT FIX" is more like it.



Anyone can close bugs as bogus and put some b.s. response. I spent the
time to 

detail out the issue and document it clearly it would be nice if you
could at 

least spend the same effort responding to it.


Previous Comments:

[2011-03-09 11:10:43] cataphr...@php.net

$a->callback(); not working a problem of executing callbacks in fields
not being supported (there's a RFC proposing that), the other is a mere
grammatical issue.



Closing; if anything this would be a feature request, but in that case
the two issues ought to be filled separately, as they're unrelated.

----
[2011-03-07 20:59:11] james at jamesreno dot com

Description:

closure objects which are members of another object can not be executed
without 

temp intermediary variables and constants of objects can not be accessed
when 

they are members of another object.



I can not find any documentation to support why these two items throw
syntax 

errors rather than executing as expected. At very least case this is a 

documentation issue and should be noted.

Test script:
---
callback = $callback;

$this->test = new apples();

 }

}





$a = new test(function(){

echo "test\n";

});



/*

 * Broken Closure Class Example

 */



// BROKEN:

$a->callback();



// Works

$tmp = $a->callback;

$tmp();



/*

 * Broken constant scope resolution

 */



// BROKEN:

$a->test::test;



// Works

$tmp = $a->test;

echo $tmp::test;



?>

Expected result:

Would expect:



$a->callback() to execute the anonymous function.



would expect:

echo $a->test::test to echo "This is a test"

Actual result:
--
Both references cause syntax errors.






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

Bug #59197 [Com]: Impossible PHP Fatal errors produced when APC is enabled

[james at parchment dot com]

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

 ID: 59197
 Comment by: james at parchment dot com
 Reported by:dathan at rockyou dot com
 Summary:Impossible PHP Fatal errors produced when APC is
 enabled
 Status: Open
 Type:   Bug
 Package:APC
 Operating System:   Centos 5.3
 PHP Version:5.3.2
 Block user comment: N
 Private report: N

 New Comment:

I occasionally suffer from this same issue with APC 3.1.3p1 using PHP 5.3.8 on 
RHEL 6.2. Apache version is 2.2.15.

I don't have a simpler test, and unfortunately I cannot always reproduce it. To 
fix, I have to restart Apache. (More drastic approaches, such as deleting the 
entire web directory containing the PHP files and replacing them with a fresh 
copy without a restart, don't fix the issue.)

Apache, PHP, and APC support are all from RPMs, so there is nothing special 
about my setup from that perspective. The disk hosting the files is local to 
the 
VM.


Previous Comments:

[2010-05-28 17:31:23] chris at chrisstreeter dot com

So the RYCrossSiteJSONService has a member variables like 
the following:

protected $m_text_return_data = false;
protected $m_request;
protected $m_version = "";
protected $mUseDirectJsonFormat = true;
protected $mResult = null;

(with a couple more like $m_request that aren't set to 
anything).

Also, there are two lines that Dathan left out that could 
potentially have an impact (though I don't see how). The 
code 
inside run_service() is this:

$this->m_request = RYRequest::get_request();
global $global_context;
$global_context = $this->get_request(); // get_request just 
returns $this->m_request
$container = $this->m_request->get_container(); // <-- This 
is the line that produces the fatal error.

The RYRequest class has several class constants and a few 
protected members, most of which are unset, and one that is 
set 
to a constant in the class.


[2010-05-28 09:03:15] gopalv82 at yahoo dot com

I'm baffled, I cannot think of a good reason this would be a problem for APC.

is there a var $m_request = NULL; in the class definition of the second class?


[2010-05-17 20:08:17] chris at chrisstreeter dot com

Er... I meant that they are large files, where each one is 400 
MB+.


[2010-05-12 19:44:57] chris at chrisstreeter dot com

Here are the backtraces when I collected the coredumps. How 
should I get them to you? They're 400+M files...

Breakpoint 1, zend_error (type=1, format=0x7fe1b9027730 
"Call to a member function %s() on a non-object") at 
/usr/local/src/php532/Zend/zend.c:975
975 in /usr/local/src/php532/Zend/zend.c
(gdb) bt
#0  zend_error (type=1, format=0x7fe1b9027730 "Call to a 
member function %s() on a non-object") at 
/usr/local/src/php532/Zend/zend.c:975
#1  0x7fe1b8b69b5d in 
ZEND_INIT_METHOD_CALL_SPEC_VAR_CONST_HANDLER 
(execute_data=0x7fe1bff2d1a8) at 
/usr/local/src/php532/Zend/zend_vm_execute.h:10368
#2  0x7fe1b8b32b84 in execute (op_array=0x7fe1c0f262b8) 
at /usr/local/src/php532/Zend/zend_vm_execute.h:104
#3  0x7fe1b8b004e4 in zend_execute_scripts (type=8, 
retval=0x0, file_count=3) at 
/usr/local/src/php532/Zend/zend.c:1194
#4  0x7fe1b8a80eea in php_execute_script 
(primary_file=0x7fff878f60d0) at 
/usr/local/src/php532/main/main.c:2260
#5  0x7fe1b8bf1c02 in php_handler (r=0x7fe1c107b468) at 
/usr/local/src/php532/sapi/apache2handler/sapi_apache2.c:655
#6  0x7fe1bf80d7c1 in ap_run_handler () from 
/usr/sbin/httpd
#7  0x7fe1bf80e084 in ap_invoke_handler () from 
/usr/sbin/httpd
#8  0x7fe1bf81fb7a in ap_process_request () from 
/usr/sbin/httpd
#9  0x7fe1bf81c431 in ap_process_http_connection () from 
/usr/sbin/httpd
#10 0x7fe1bf81722c in ap_run_process_connection () from 
/usr/sbin/httpd
#11 0x7fe1bf817679 in ap_process_connection () from 
/usr/sbin/httpd
#12 0x7fe1bf82697f in child_main () from /usr/sbin/httpd
#13 0x7fe1bf826a6b in make_child () from /usr/sbin/httpd
#14 0x7fe1bf827055 in ap_mpm_run () from /usr/sbin/httpd
#15 0x7fe1bf7f37ef in main () from /usr/sbin/httpd
(gdb) gc
Saved corefile core.1

Breakpoint 1, zend_error (type=1, format=0x7fe1b9027730 
"Call to a member function %s() on a non-object") at 
/usr/local/src/php532/Zend/zend.c:975
975 in /usr/local/src/php532/Zend/zend.c
(gdb) bt
#0  zend_error (type=1, format=0x7fe1b9027730 "Call to a 
member function %s() on a non-object") at 
/usr/local/src/php532/Zend/zend.c:975
#1  0x7fe1b8b69b5d in 
ZEND_INIT_METHOD_CALL_SPEC_VAR_CONST_HANDLER 
(execute_data=0x

Bug #59197 [Com]: Impossible PHP Fatal errors produced when APC is enabled

[james at parchment dot com]

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

 ID: 59197
 Comment by: james at parchment dot com
 Reported by:dathan at rockyou dot com
 Summary:Impossible PHP Fatal errors produced when APC is
 enabled
 Status: Open
 Type:   Bug
 Package:APC
 Operating System:   Centos 5.3
 PHP Version:5.3.2
 Block user comment: N
 Private report: N

 New Comment:

I should have mentioned that I get errors in files that aren't even part of the 
workflow. For example, if I have a file that includes header.php, this bug will 
cause me to get errors in header.php. If I exit the other script before any 
file 
that includes header.php gets called, I might *still* get errors in header.php.


Previous Comments:

[2011-11-01 16:49:49] james at parchment dot com

I occasionally suffer from this same issue with APC 3.1.3p1 using PHP 5.3.8 on 
RHEL 6.2. Apache version is 2.2.15.

I don't have a simpler test, and unfortunately I cannot always reproduce it. To 
fix, I have to restart Apache. (More drastic approaches, such as deleting the 
entire web directory containing the PHP files and replacing them with a fresh 
copy without a restart, don't fix the issue.)

Apache, PHP, and APC support are all from RPMs, so there is nothing special 
about my setup from that perspective. The disk hosting the files is local to 
the 
VM.


[2010-05-28 17:31:23] chris at chrisstreeter dot com

So the RYCrossSiteJSONService has a member variables like 
the following:

protected $m_text_return_data = false;
protected $m_request;
protected $m_version = "";
protected $mUseDirectJsonFormat = true;
protected $mResult = null;

(with a couple more like $m_request that aren't set to 
anything).

Also, there are two lines that Dathan left out that could 
potentially have an impact (though I don't see how). The 
code 
inside run_service() is this:

$this->m_request = RYRequest::get_request();
global $global_context;
$global_context = $this->get_request(); // get_request just 
returns $this->m_request
$container = $this->m_request->get_container(); // <-- This 
is the line that produces the fatal error.

The RYRequest class has several class constants and a few 
protected members, most of which are unset, and one that is 
set 
to a constant in the class.


[2010-05-28 09:03:15] gopalv82 at yahoo dot com

I'm baffled, I cannot think of a good reason this would be a problem for APC.

is there a var $m_request = NULL; in the class definition of the second class?


[2010-05-17 20:08:17] chris at chrisstreeter dot com

Er... I meant that they are large files, where each one is 400 
MB+.


[2010-05-12 19:44:57] chris at chrisstreeter dot com

Here are the backtraces when I collected the coredumps. How 
should I get them to you? They're 400+M files...

Breakpoint 1, zend_error (type=1, format=0x7fe1b9027730 
"Call to a member function %s() on a non-object") at 
/usr/local/src/php532/Zend/zend.c:975
975 in /usr/local/src/php532/Zend/zend.c
(gdb) bt
#0  zend_error (type=1, format=0x7fe1b9027730 "Call to a 
member function %s() on a non-object") at 
/usr/local/src/php532/Zend/zend.c:975
#1  0x7fe1b8b69b5d in 
ZEND_INIT_METHOD_CALL_SPEC_VAR_CONST_HANDLER 
(execute_data=0x7fe1bff2d1a8) at 
/usr/local/src/php532/Zend/zend_vm_execute.h:10368
#2  0x7fe1b8b32b84 in execute (op_array=0x7fe1c0f262b8) 
at /usr/local/src/php532/Zend/zend_vm_execute.h:104
#3  0x7fe1b8b004e4 in zend_execute_scripts (type=8, 
retval=0x0, file_count=3) at 
/usr/local/src/php532/Zend/zend.c:1194
#4  0x7fe1b8a80eea in php_execute_script 
(primary_file=0x7fff878f60d0) at 
/usr/local/src/php532/main/main.c:2260
#5  0x7fe1b8bf1c02 in php_handler (r=0x7fe1c107b468) at 
/usr/local/src/php532/sapi/apache2handler/sapi_apache2.c:655
#6  0x7fe1bf80d7c1 in ap_run_handler () from 
/usr/sbin/httpd
#7  0x7fe1bf80e084 in ap_invoke_handler () from 
/usr/sbin/httpd
#8  0x7fe1bf81fb7a in ap_process_request () from 
/usr/sbin/httpd
#9  0x7fe1bf81c431 in ap_process_http_connection () from 
/usr/sbin/httpd
#10 0x7fe1bf81722c in ap_run_process_connection () from 
/usr/sbin/httpd
#11 0x7fe1bf817679 in ap_process_connection () from 
/usr/sbin/httpd
#12 0x7fe1bf82697f in child_main () from /usr/sbin/httpd
#13 0x7fe1bf826a6b in make_child () from /usr/sbin/httpd
#14 0x7fe1bf827055 in ap_mpm_run () from /usr/sbin/httpd
#15 0x7fe1bf7f37ef in main () from /usr/sbin/httpd
(gdb) gc
Saved corefile core.1

[PHP-BUG] Bug #63214 [NEW]: Large PDO Firebird Queries

[james at kenjim dot com]

From: james at kenjim dot com
Operating system: All
PHP version:  5.4Git-2012-10-03 (Git)
Package:  PDO related
Bug Type: Bug
Bug description:Large PDO Firebird Queries

Description:

Large Firebird sql queries are improperly rejected.  Firebird allows for
64k long queries yet current checks reject queries larger than 32k.


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

[PHP-BUG] Req #63215 [NEW]: Add support for Firebird commit retaining transactions.

[james at kenjim dot com]

From: james at kenjim dot com
Operating system: All
PHP version:  5.4Git-2012-10-03 (Git)
Package:  PDO related
Bug Type: Feature/Change Request
Bug description:Add support for Firebird commit retaining transactions.

Description:

Add the ability to do commit retaining transactions using the Firebird PDO
driver.  Commit retaining is faster when committing because it reuses
server transaction resources.  The downside is you are still in the old
transaction context so you won't see any new concurrent commits.  Commit
retaining is ideally used when you have lots of small transactions that do
not rely on other data that may be changed by another thread/user.

I have written a patch to add the ability to do commit retaining
transactions using 
$dbh->setAttribute(PDO::FB_ATTR_COMMIT_RETAINING, true);
Any following commits or rollbacks will use their retaining equivalent
after this attribute is set.  You can return to using normal commit and
rollbacks by setting the attribute to false.
$dbh->setAttribute(PDO::FB_ATTR_COMMIT_RETAINING, false);


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

Bug #61183 [Com]: Firebird PDO memory corruption

[james at kenjim dot com]

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

 ID: 61183
 Comment by: james at kenjim dot com
 Reported by:noxwizard at gmail dot com
 Summary:Firebird PDO memory corruption
 Status: Assigned
 Type:   Bug
 Package:PDO related
 Operating System:   Windows Server 2008 x86
 PHP Version:5.3.10
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

This problem appears to comes from the handling of blobs.  In the function 
firebird_bind_blob in firebird_statement.c we pass param in and are destroying 
it with zval_dtor.  I think we should not be destroying it because it was 
provided by firebird_stmt_param_hook and no other path destroys this variable.  

Commenting out the zval_dtor(param) line fixes the crashing.

I also don't think we need to call SEPARATE_ZVAL(¶m) or 
convert_to_string_ex(¶m) as param appears to always be a string regardless 
of what we bind.


Previous Comments:

[2012-02-25 09:20:30] noxwizard at gmail dot com

Description:

Running Firebird 2.5, and trying to use PDO to run a few queries, I ran into 
memory corruption. I've tested the same code on a few other DBMSs via PDO and 
they 
run fine, so it seems related to the Firebird PDO module. It also doesn't 
happen 
on every table structure. For example, I tried a table consisting of a single 
integer field and the error wasn't triggered. Playing with the script a bit, it 
eventually output: zend_mm_heap corrupted

The structure for the table in the example script can be found here: 
https://github.com/phpbb/phpbb3/blob/release-
3.0.10/phpBB/install/schemas/firebird_schema.sql#L1319

Test script:
---
prepare('INSERT INTO "PHPBB_USERS" 
("USER_ID", "USERNAME", "USERNAME_CLEAN", "USER_PERMISSIONS", "USER_SIG", 
"USER_OCC", "USER_INTERESTS") VALUES (?, ?, ?, ?, ?, ?, ?)');
$statement->execute(array (0 => '2', 1 => 'banned', 2 => 
'banned', 3 => '', 4 => '', 5 => '', 6 => ''));
echo 'Statement run: ' . $i . "\n";
}
}
catch (PDOException $e)
{
echo 'Exception: ' . $e->getMessage();
}

Expected result:

The script should run 5000 times and exit cleanly.

Actual result:
--
The script runs through a few iterations and PHP crashes. Altercations to the 
script can make it run longer or shorter (without trailing ?> crashes in 2 
iterations, with it, crashes after 1998 iterations).

This first backtrace is from a 32bit Windows Server 2008 install running in a 
VirtualBox VM:
Entry point   php!mainCRTStartup 
Create time   2/25/2012 2:40:53 AM 
Time spent in user mode   0 Days 0:0:0.15 
Time spent in kernel mode   0 Days 0:0:0.781 

Function Arg 1 Arg 2 Arg 3   Source 
php5ts!zend_mm_set_custom_handlers+225 0001 0212fa20 0212e7e0   
 
php5ts!_estrndup+35 02130770  02272f78
php5ts!_zval_copy_ctor_func+42 0212e7e0 0001 0212f490
php5ts!pdo_stmt_describe_columns+701 0001 02130810 
php5ts!execute+1130 02160080 02272f01 634b7838
php5ts!execute+15ed 02272f78 0091f440 
php5ts!execute+2e8 0212e548 02272f00 02272f78
php5ts!zend_execute_scripts+fe 0008 02272f78 
php5ts!php_execute_script+24c 0091f6f0 02272f78 00ee742c
php!main+b9b 0002 02272f08 02271be0
php!memcpy+160 7ffd7000 0091f830 777b1603
kernel32!BaseThreadInitThunk+12 7ffd7000 75823a7e 
ntdll!RtlInitializeExceptionChain+63 00ee3002 7ffd7000 
ntdll!RtlInitializeExceptionChain+36 00ee3002 7ffd7000 

PHP5TS!ZEND_MM_SET_CUSTOM_HANDLERS+225In 
php__PID__4908__Date__02_25_2012__Time_02_41_07AM__420__Second_Chance_Exception_
C005.dmp the assembly instruction at 
php5ts!zend_mm_set_custom_handlers+225 in C:\php\php5ts.dll from The PHP Group 
has caused an access violation exception (0xC005) when trying to read from 
memory location 0x6e6e616a on thread 0

Module Information 
Image Name: C:\php\php5ts.dll   Symbol Type:  PDB 
Base address: 0x6349   Time Stamp:  Thu Feb 02 13:36:49 2012  
Checksum: 0x005a3fb6   Comments:   
COM DLL: False   Company Name:  The PHP Group 
ISAPIExtension: False   File Description:  PHP Script Interpreter 
ISAPIFilter: False   File Version:  5.3.10 
Managed DLL: False   Internal Name:  PHP Script Interpreter 
VB DLL: False   Legal Copyright:  Copyright © 1997-2010 The PHP Group 
Loaded Image Name:  php5ts.dll   Legal T

Bug #61183 [Com]: Firebird PDO memory corruption

[james at kenjim dot com]

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

 ID: 61183
 Comment by: james at kenjim dot com
 Reported by:noxwizard at gmail dot com
 Summary:Firebird PDO memory corruption
 Status: Assigned
 Type:   Bug
 Package:PDO related
 Operating System:   Windows Server 2008 x86
 PHP Version:5.3.10
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

After further testing I've found that NULL zval's may be passed into 
firebird_bind_blob so convert_to_string_ex needs to be called or a check for 
NULL param needs to be done before calling Z_STRLEN_P.


Previous Comments:

[2012-10-04 08:30:24] james at kenjim dot com

This problem appears to comes from the handling of blobs.  In the function 
firebird_bind_blob in firebird_statement.c we pass param in and are destroying 
it with zval_dtor.  I think we should not be destroying it because it was 
provided by firebird_stmt_param_hook and no other path destroys this variable.  

Commenting out the zval_dtor(param) line fixes the crashing.

I also don't think we need to call SEPARATE_ZVAL(¶m) or 
convert_to_string_ex(¶m) as param appears to always be a string regardless 
of what we bind.


[2012-02-25 09:20:30] noxwizard at gmail dot com

Description:

Running Firebird 2.5, and trying to use PDO to run a few queries, I ran into 
memory corruption. I've tested the same code on a few other DBMSs via PDO and 
they 
run fine, so it seems related to the Firebird PDO module. It also doesn't 
happen 
on every table structure. For example, I tried a table consisting of a single 
integer field and the error wasn't triggered. Playing with the script a bit, it 
eventually output: zend_mm_heap corrupted

The structure for the table in the example script can be found here: 
https://github.com/phpbb/phpbb3/blob/release-
3.0.10/phpBB/install/schemas/firebird_schema.sql#L1319

Test script:
---
prepare('INSERT INTO "PHPBB_USERS" 
("USER_ID", "USERNAME", "USERNAME_CLEAN", "USER_PERMISSIONS", "USER_SIG", 
"USER_OCC", "USER_INTERESTS") VALUES (?, ?, ?, ?, ?, ?, ?)');
$statement->execute(array (0 => '2', 1 => 'banned', 2 => 
'banned', 3 => '', 4 => '', 5 => '', 6 => ''));
echo 'Statement run: ' . $i . "\n";
}
}
catch (PDOException $e)
{
echo 'Exception: ' . $e->getMessage();
}

Expected result:

The script should run 5000 times and exit cleanly.

Actual result:
--
The script runs through a few iterations and PHP crashes. Altercations to the 
script can make it run longer or shorter (without trailing ?> crashes in 2 
iterations, with it, crashes after 1998 iterations).

This first backtrace is from a 32bit Windows Server 2008 install running in a 
VirtualBox VM:
Entry point   php!mainCRTStartup 
Create time   2/25/2012 2:40:53 AM 
Time spent in user mode   0 Days 0:0:0.15 
Time spent in kernel mode   0 Days 0:0:0.781 

Function Arg 1 Arg 2 Arg 3   Source 
php5ts!zend_mm_set_custom_handlers+225 0001 0212fa20 0212e7e0   
 
php5ts!_estrndup+35 02130770  02272f78
php5ts!_zval_copy_ctor_func+42 0212e7e0 0001 0212f490
php5ts!pdo_stmt_describe_columns+701 0001 02130810 
php5ts!execute+1130 02160080 02272f01 634b7838
php5ts!execute+15ed 02272f78 0091f440 
php5ts!execute+2e8 0212e548 02272f00 02272f78
php5ts!zend_execute_scripts+fe 0008 02272f78 
php5ts!php_execute_script+24c 0091f6f0 02272f78 00ee742c
php!main+b9b 0002 02272f08 02271be0
php!memcpy+160 7ffd7000 0091f830 777b1603
kernel32!BaseThreadInitThunk+12 7ffd7000 75823a7e 
ntdll!RtlInitializeExceptionChain+63 00ee3002 7ffd7000 
ntdll!RtlInitializeExceptionChain+36 00ee3002 7ffd7000 

PHP5TS!ZEND_MM_SET_CUSTOM_HANDLERS+225In 
php__PID__4908__Date__02_25_2012__Time_02_41_07AM__420__Second_Chance_Exception_
C005.dmp the assembly instruction at 
php5ts!zend_mm_set_custom_handlers+225 in C:\php\php5ts.dll from The PHP Group 
has caused an access violation exception (0xC005) when trying to read from 
memory location 0x6e6e616a on thread 0

Module Information 
Image Name: C:\php\php5ts.dll   Symbol Type:  PDB 
Base address: 0x6349   Time Stamp:  Thu Feb 02 13:36:49 2012  
Checksum: 0x005a3fb6   Comments:

[PHP-BUG] Req #63356 [NEW]: Add support for native php data types returned from Firebird PDO select queries

[james at kenjim dot com]

From: james at kenjim dot com
Operating system: All
PHP version:  5.4Git-2012-10-25 (Git)
Package:  PDO related
Bug Type: Feature/Change Request
Bug description:Add support for native php data types returned from Firebird 
PDO select queries

Description:

The data returned from a $rs->fetch() should use native data types when
applicable.  Currently all data is turned into strings.  Using native data
types will not only provide a way for the user to easily check the data
type.  It should also give a performance enhancement since everything does
not need to be turned into a string.  Some other database adapters already
provide this ability.

I have included a patch to add this functionality however I did have to
modify /ext/pdo/pdo_stmt.c due to the way it was handling returning of
zval's.  It was expecting a ***zval when it really should of been a **zval.
 Due to this excessive pointer requirement any other pdo database driver
that returns zval's will need to be fixed.  I included in my patch a
possible fix for the mysqlng pdo driver since I believe this is the only
driver that uses it.  I say possible fix because I have not tested the
mysqlng support part of it.  The patch also includes my patch for Bug
#61183 - Firebird PDO memory corruption.  It should also fix Bug #60052 -
Integer returned as a 64bit integer on X64_86.  It also fixes the patch
that was improperly applied in Bug #47415 - PDO_Firebird segfaults when
passing lowercased column name to bindColumn().


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

[PHP-BUG] Bug #63690 [NEW]: Problems with a manual transaction while auto commit is enabled.

[james at kenjim dot com]

From: james at kenjim dot com
Operating system: All
PHP version:  master-Git-2012-12-05 (Git)
Package:  PDO related
Bug Type: Bug
Bug description:Problems with a manual transaction while auto commit is enabled.

Description:

The documentation at http://php.net/manual/en/pdo.transactions.php gives me
the impression that the default mode a pdo db driver is in is auto-commit. 
If I choose to create a batch of queries in one transaction I can do so by
first issuing a begin transaction.  This however does not appear to be the
case when looking at the c code for all but the odbc pdo driver. 
Auto-commit is never actually disabled so all my queries in my transaction
block get committed when they get executed.  I have only tested this
behavior with Firebird.

I have created a patch that will turn off auto-commit at the driver level
when beginTransaction is called and will restore the user setting when
commit or rollback is called.  This way all pdo drivers that support
transactions and auto-commit should now act properly.  The patch also
includes the ability to support commits/rollbacks that keep the transaction
open.  Also included in this patch is my patch from Request #63215 since I
realized that patch needed pdo to support the ability to keep a transaction
open after calling commit/rollback.

Please note my patch was only tested with the Firebird database driver so
other database drivers should have their beginTransaction with auto-commit
on functionality tested.



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

Req #63215 [Com]: Add support for Firebird commit retaining transactions.

[james at kenjim dot com]

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

 ID: 63215
 Comment by: james at kenjim dot com
 Reported by:james at kenjim dot com
 Summary:Add support for Firebird commit retaining
 transactions.
 Status: Assigned
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   All
 PHP Version:5.4Git-2012-10-03 (Git)
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

I have uploaded a new improved patch with Bug #63690 that includes the 
functionality here.  I suggest using that patch instead of the one I uploaded 
here as that is a more complete solution and fixes some unexpected behavior if 
someone uses commit retaining.


Previous Comments:

[2012-10-04 00:01:51] james at kenjim dot com

Description:

Add the ability to do commit retaining transactions using the Firebird PDO 
driver.  Commit retaining is faster when committing because it reuses server 
transaction resources.  The downside is you are still in the old transaction 
context so you won't see any new concurrent commits.  Commit retaining is 
ideally used when you have lots of small transactions that do not rely on other 
data that may be changed by another thread/user.

I have written a patch to add the ability to do commit retaining transactions 
using 
$dbh->setAttribute(PDO::FB_ATTR_COMMIT_RETAINING, true);
Any following commits or rollbacks will use their retaining equivalent after 
this attribute is set.  You can return to using normal commit and rollbacks by 
setting the attribute to false.
$dbh->setAttribute(PDO::FB_ATTR_COMMIT_RETAINING, false);







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

Req #63356 [Asn]: Add support for native php data types returned from Firebird PDO select queries

[james at kenjim dot com]

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

 ID: 63356
 User updated by:james at kenjim dot com
 Reported by:james at kenjim dot com
 Summary:Add support for native php data types returned from
 Firebird PDO select queries
 Status: Assigned
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   All
 PHP Version:5.4Git-2012-10-25 (Git)
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

The problem with the ***zval is I could not figure out how to return such a 
data type without causing a memory leak.  The extra pointer to a pointer just 
seemed excessive and removing it solved my problem.

As for splitting the patches, a few of them depend on each other so there is no 
good way to split them without creating patches that do not work with each 
other.  The patch for bug #61183 has already been submitted there and is simple 
enough that it could be removed from my submitted patch here by hand.  Bug 
#60552 gets fixed because the majority of the time I'm using native data types 
so I can't exactly remove it from my native data type support patch.
As for Bug #47415 that patch was just improperly applied to the php source tree 
and ended up in the wrong switch statement.  I suppose that could be pulled out 
of this patch but I did also modify the PDO_PARAM_EVT_FETCH_POST case which the 
patch was embedded in.  I don't remember why I removed most of that 
PDO_PARAM_EVT_FETCH_POST switch statement.  I think it was because I couldn't 
figure out why it was ever needed or even run.  It's also possible it may have 
caused a crash but I don't recall it's been too long.


Previous Comments:

[2013-02-08 07:53:03] mar...@php.net

Could you split the patch for each bug the ones that you mentioned at the end

Also i will ask about the patching of /ext/pdo/pdo_stmt.c , i'm not sure what 
is 
the right way so i better ask on the list first

----
[2012-10-25 08:11:17] james at kenjim dot com

Description:

The data returned from a $rs->fetch() should use native data types when 
applicable.  Currently all data is turned into strings.  Using native data 
types will not only provide a way for the user to easily check the data type.  
It should also give a performance enhancement since everything does not need to 
be turned into a string.  Some other database adapters already provide this 
ability.

I have included a patch to add this functionality however I did have to modify 
/ext/pdo/pdo_stmt.c due to the way it was handling returning of zval's.  It was 
expecting a ***zval when it really should of been a **zval.  Due to this 
excessive pointer requirement any other pdo database driver that returns zval's 
will need to be fixed.  I included in my patch a possible fix for the mysqlng 
pdo driver since I believe this is the only driver that uses it.  I say 
possible fix because I have not tested the mysqlng support part of it.  The 
patch also includes my patch for Bug #61183 - Firebird PDO memory corruption.  
It should also fix Bug #60052 - Integer returned as a 64bit integer on X64_86.  
It also fixes the patch that was improperly applied in Bug #47415 - 
PDO_Firebird segfaults when passing lowercased column name to bindColumn().







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

#31966 [NEW]: SSL:// wrapper does not obey NON_BLOCKING mode.

[james-php at bytehosting dot com]

From: james-php at bytehosting dot com
Operating system: linux
PHP version:  4.3.10
PHP Bug Type: *Network Functions
Bug description:  SSL:// wrapper does not obey NON_BLOCKING mode.

Description:

When php is compiled against openssl. If you use a non_blocking stream PHP
does not obet the non_blocking options. If you REMOVE the ssl:// and
connect to a non-secure port, and it works perfectly fine.


OpenSSL 0.9.7e

PHP 4.3.10 (cgi-fcgi) (built: Dec 27 2004 04:01:15)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
Kernel: 2.4.22-36mdkenterprise
Mandrake Linux release 9.2 (FiveStar) for i586

Dual xeon + hyperthreading:
model name  : Intel(R) Xeon(TM) CPU 2.40GHz
stepping: 9
cpu MHz : 2389.117
cache size  : 512 KB


./configure  --enable-fastcgi --with-mysql --enable-aspell --enable-ftp
--enable-xml --enable-trans-sid --enable-curl \
--enable-force-cgi-redirect --with-gd --with-zlib-dir
--with-curl=/usr/include/curl --with-openssl \
--with-openssl-dir=/usr/compile/openssl-0.9.7e


Reproduce code:
---


Expected result:

Socket to be non-blocked, and return immediately.


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

#31966 [Opn]: SSL:// wrapper does not obey NON_BLOCKING mode.

[james-php at bytehosting dot com]

 ID:   31966
 User updated by:  james-php at bytehosting dot com
 Reported By:  james-php at bytehosting dot com
 Status:   Open
 Bug Type: *Network Functions
 Operating System: linux
 PHP Version:  4.3.10
 New Comment:

opps -- stream_set_blocking()

~james


Previous Comments:


[2005-02-14 11:15:36] james-php at bytehosting dot com

Description:

When php is compiled against openssl. If you use a non_blocking stream
PHP does not obet the non_blocking options. If you REMOVE the ssl://
and connect to a non-secure port, and it works perfectly fine.


OpenSSL 0.9.7e

PHP 4.3.10 (cgi-fcgi) (built: Dec 27 2004 04:01:15)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
Kernel: 2.4.22-36mdkenterprise
Mandrake Linux release 9.2 (FiveStar) for i586

Dual xeon + hyperthreading:
model name  : Intel(R) Xeon(TM) CPU 2.40GHz
stepping: 9
cpu MHz : 2389.117
cache size  : 512 KB


./configure  --enable-fastcgi --with-mysql --enable-aspell --enable-ftp
--enable-xml --enable-trans-sid --enable-curl \
--enable-force-cgi-redirect --with-gd --with-zlib-dir
--with-curl=/usr/include/curl --with-openssl \
--with-openssl-dir=/usr/compile/openssl-0.9.7e


Reproduce code:
---


Expected result:

Socket to be non-blocked, and return immediately.






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

#31966 [Opn]: SSL:// wrapper does not obey NON_BLOCKING mode.

[james-php at bytehosting dot com]

 ID:   31966
 User updated by:  james-php at bytehosting dot com
 Reported By:  james-php at bytehosting dot com
 Status:   Open
 Bug Type: *Network Functions
 Operating System: linux
 PHP Version:  4.3.10
 New Comment:

Too late of night, the previous comment was ment to say (I made an
error when submitting the bug). I do have it properly set as
stream_set_blocking($fd,FALSE); and the problem still exists. The code
sample submitted was wrong, the bug applies when you actully use the
proper function names. Thats what I get when re-typing the code out in
the form, instead of pasting it.

~james


Previous Comments:


[2005-02-14 11:20:23] james-php at bytehosting dot com

opps -- stream_set_blocking()

~james



[2005-02-14 11:15:36] james-php at bytehosting dot com

Description:

When php is compiled against openssl. If you use a non_blocking stream
PHP does not obet the non_blocking options. If you REMOVE the ssl://
and connect to a non-secure port, and it works perfectly fine.


OpenSSL 0.9.7e

PHP 4.3.10 (cgi-fcgi) (built: Dec 27 2004 04:01:15)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
Kernel: 2.4.22-36mdkenterprise
Mandrake Linux release 9.2 (FiveStar) for i586

Dual xeon + hyperthreading:
model name  : Intel(R) Xeon(TM) CPU 2.40GHz
stepping: 9
cpu MHz : 2389.117
cache size  : 512 KB


./configure  --enable-fastcgi --with-mysql --enable-aspell --enable-ftp
--enable-xml --enable-trans-sid --enable-curl \
--enable-force-cgi-redirect --with-gd --with-zlib-dir
--with-curl=/usr/include/curl --with-openssl \
--with-openssl-dir=/usr/compile/openssl-0.9.7e


Reproduce code:
---


Expected result:

Socket to be non-blocked, and return immediately.






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