#21399 [NEW]: strtotime() request

[colin]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4CVS-2003-01-03 (dev)
PHP Bug Type: Feature/Change Request
Bug description:  strtotime() request

Derick,

Make strtotime() recognize "MMDDhhmmss [ZZZ]" strings.

Pretty please.

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

Bug #17143: make install fails with --disable-cli

[colin]

From: [EMAIL PROTECTED]
Operating system: Linux / Debian
PHP version:  4.0CVS-2002-05-10
PHP Bug Type: Compile Failure
Bug description:  make install fails with --disable-cli

Using --disable-cli in the configure line causes "make install" to fail
with:

/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Taking that out of the configure line solves it (but, of course, makes the
CLI).

- Colin

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

Bug #17143 Updated: make install fails with --disable-cli

[colin]

 ID:   17143
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Linux / Debian
 PHP Version:  4.0CVS-2002-05-10
 New Comment:

FWIW, the full configure line is:

./configure \
--with-mysql=/usr/local \
--with-apxs=/usr/local/apache/bin/apxs \
--enable-track-vars \
--disable-magic-quotes \
--disable-debug \
--with-gettext \
--with-xml \
--with-xmlrpc \
--with-dom \
--with-curl \
--with-zlib \
--with-mcrypt \
--enable-ftp \
--with-imap \
[ --disable-cli ]


Previous Comments:


[2002-05-10 14:14:55] [EMAIL PROTECTED]

Using --disable-cli in the configure line causes "make install" to fail
with:

/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Taking that out of the configure line solves it (but, of course, makes
the CLI).

- Colin





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

#19480 [NEW]: register_shutdown_function causes Apache to hang

[colin]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.6
PHP version:  4CVS-2002-09-18
PHP Bug Type: Scripting Engine problem
Bug description:  register_shutdown_function causes Apache to hang

Take this script:




If run as is, it works as expected: happily counting away until it times
out, or you abort the script.

If you uncomment the register_shutdown_function line and abort the script
part-way through, Apache doesn't seem to close the connection.  And, in
fact, all other Apache processes get "hung" up waiting for it.  Running
apachectl server-status shows this.

Let me know if you need more info.

(This was actually tested on 4.3.0-dev, built Aug 27 2002.  I'm getting
the current CVS version now, but I understand from other people that this
will still not function.)

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

#4248 [Com]: Unable to run ./configure --with-cdb using cdb v0.75

[colin]

 ID:   4248
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Installation problem
 Operating System: Solaris 2.6
 PHP Version:  3.0.16
 New Comment:

This still doesn't seem to be corrected in PHP 4.3.0-dev, which makes
the --with-cdb option pretty much useless.

Could one of the developers maybe look rewriting the PHP code to
interface with the CDB 0.75 library?

- Colin


Previous Comments:


[2000-04-26 12:14:13] [EMAIL PROTECTED]

./configure checks for cdb_bread when passed --with-cdb. However, the
CDB API has changed somewhere between 0.55 (the version that works) and
version 0.75 (the version that gave me a couple of hours of headaches
;) ). Enough so that the the check performed by ./configure to see if
libcdb.a works now fails. Yay. (note that cdb-0.55 *does* work, with
relevant files in the same locations)

My full ./configure line:

./configure \
  --enable-versioning \
  --with-apache=../apache_1.3.12 \
  --with-aspell=/usr/local/include/aspell \
  --with-ftp \
  --with-gd \
  --with-jpeg-dir \
  --with-mysql \
  --with-xml \
  --with-zlib \
  --with-pdflib \
  --with-config-file-path=/usr/local/etc \
  --enable-safe-mode \
  --enable-track-vars \
  --enable-force-cgi-redirect \
  --enable-memory-limit \
  --enable-sysvsem \
  --enable-sysvshm \
  --with-gdbm \
  --with-db2 \
  --with-cdb




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

#19480 [Com]: register_shutdown_function causes Apache to hang

[colin]

 ID:   19480
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.4.6
 PHP Version:  4CVS-2002-09-18
 New Comment:

Yeah, the current CVS seems to have fixed it.

Dunno if this is important but ... when I stop the script in my
browser, it's counted up to 568247, yet the email I get says it's
counted to 584359.  I don't have output buffering enabled.


Previous Comments:


[2002-09-22 14:53:24] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Unable to replicate on latest CVS w/ Apache 1.3.26.



[2002-09-18 14:48:41] [EMAIL PROTECTED]

Take this script:




If run as is, it works as expected: happily counting away until it
times out, or you abort the script.

If you uncomment the register_shutdown_function line and abort the
script part-way through, Apache doesn't seem to close the connection. 
And, in fact, all other Apache processes get "hung" up waiting for it. 
Running apachectl server-status shows this.

Let me know if you need more info.

(This was actually tested on 4.3.0-dev, built Aug 27 2002.  I'm getting
the current CVS version now, but I understand from other people that
this will still not function.)

- Colin




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

Bug #14688 Updated: session_register() doesn't register

[colin]

 ID:   14688
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: Session related
 Operating System: linux 2.2
 PHP Version:  4.1.0
 New Comment:

I notice this too under 4.1.2.  unset($var) doesn't unregister $var
from the session

FWIW, this is with Linux 2.4.6-pre6, and I'm using the default files
for session storage.

- Colin


Previous Comments:


[2002-02-02 06:38:08] [EMAIL PROTECTED]

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



[2002-01-11 18:31:26] [EMAIL PROTECTED]

Clarification. 
Which save handler are you using files or user?



[2001-12-25 14:20:57] [EMAIL PROTECTED]

This bug is in 4.1.1 aswell



[2001-12-25 07:44:24] [EMAIL PROTECTED]

Both servers got register_globals = On.
On the 4.1.0 server i run with a php.ini that originates from the 4.0.5
release.

--niklas



[2001-12-25 06:00:24] [EMAIL PROTECTED]

What is your register_globals setting?

Derick



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

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

Bug #16078: var_export() doesn't handle classes

[colin]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4
PHP version:  4.0CVS-2002-03-14
PHP Bug Type: Feature/Change Request
Bug description:  var_export() doesn't handle classes

Can we make var_export() handle classes, too?

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

Bug #16078 Updated: var_export() doesn't handle classes

[colin]

 ID:   16078
 Updated by:   [EMAIL PROTECTED]
-Summary:  var_export() doesn't handle classes
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Feature/Change Request
+Bug Type: Variables related
 Operating System: Linux 2.4
 PHP Version:  4.0CVS-2002-03-14
 New Comment:

re-categorized


Previous Comments:


[2002-03-14 12:57:48] [EMAIL PROTECTED]

Can we make var_export() handle classes, too?

- Colin




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

#21973 [Com]: 'configure' script can't find libpng.(a|so), openldap...

[colin . madere]

 ID:   21973
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *Configuration Issues
 Operating System: Solaris 8
 PHP Version:  4.3.0
 New Comment:

I've run into a similar problem with --with-java switch.

Assuming $PHP_JAVA is set to "/usr/java" with the --with-java=/usr/java
switch...

The "libjava.so" library is looked for in $PHP_JAVA/lib/ but the file
is not there (j2se 1.4.1_01).

This may however be a different/new bug, since the file being looked
for by configure isn't even in that part of the java tree.  It resides
in:

$PHP_JAVA/jre/lib/sparc/
and
$PHP_JAVA/jre/lib/sparcv9/

The rest of the files looked for by configure are found by using:
--with-java=/usr/java

For it to find this library file, even if there weren't separate
architectures, it would have to be:
--with-java=/usr/java/jre

which would make it so the other java files looked for are not found.

Off to sym-link...


Previous Comments:


[2003-02-04 11:52:45] [EMAIL PROTECTED]

Yes, you have to install libpng if you don't have it. The download URL
is in the manual, .



[2003-02-04 06:23:30] [EMAIL PROTECTED]

Hello there,

I'm having a similar problem as this one. I'm using a Sun Cobalt Qube 3
server on which I try to install PHP 4.3
I have searched for libpng on the harddisk but can't find it anywhere.
So how can I install GD when I don't have libpng on the server ??

Do I have to install libpng first, if yes then where can I get it?? I
guess this is the only problem I'm having right now, first I had a
problem because the qube requires php 4.0.6. for it's admin
functionality, but I managed to create a workaround for that problem.
When I finally have installed php 4.3 I can write a how-to so other
Qube users can update their php too. Sun doesn't support updating PHP
on a Qube just because they don't want to.



[2003-02-02 18:50:10] [EMAIL PROTECTED]

Back to dba:

I tried several combinations and having problems with
shared dba earlier than 3.3. I did some fixes and 
disallowed buildng shared dba with those versions for now.
However i got a short reply from sleepycat that they do
not have any idea how to explain what is happening.

Back to general linking:
I made a configure function which allows me to
handle all libraries required by gd and dba extension.
Since those are the most complicated cases i suppose we
could easily expand that function to handle all external
libraries. If that is done we may even add automatic
detection support for your directory structure.
I will post that function here and as a diff on php-dev
during the week 



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

> Anyway, in what version of PHP did LDAP configure
> work without any patches? 

The CVS tag is php_4_3_0pre2. I've done a fresh checkout
with that tag and can verify that the 'configure' script
generated by my copies of autoconf, etc, works. I tried
the following successful combinations:

 - autoconf 2.52, automake 1.5, libtool 1.4
 - autoconf 2.57, automake 1.7.2, libtool 1.4.3
 - flex 2.5.4 and bison 1.75 were used in all cases.

Compiler was gcc 3.2.1 for Sun UltraSPARC v9 using
Sun's CCS assembler Sun's CCS linker (typical scenario).

Notes:
 - first, I applied my int/long correctness patches
   (fortunately, these do not influence the configure step).
 - ldap configures and compiles with no warnings or
   errors. BUT I have to induce -lldap myself (other modules,
   such as database modules, seem to pick up their libraries
   okay, though). So really, ldap configuration wasn't
   entirely working in pre2 but the fault had a different
   manifestation than in the release, and had obvious
   output/cause/workaround.
 - the gd module configures with errors but I commented out
   the 'exit' commands and configure completes.
 - the ldap and gd modules then appear work fine with Apache.
 - I had to comment out _LT_AC_TRY_DLOPEN_SELF when using
   the second lot of auto tools.

But when I do a buildconf, configure, make with php_4_3_0, I
get the problem "Cannot find ldap libraries in $LDAP_LIBDIR."

Notes:
 - first, I applied my int/long correctness patches
   (fortunately, these do not influence the configure step).
 - I can work around the gd & ldap problems by manually
   deleting the 'exit' commands in the configure
   script or inserting the sparcv9 path element into the
   configure script, in which case the ldap module then
   picks up -lldap by itself.
 - the _LT_AC_TRY_DLOPEN_SELF problem has disappeared
   in 4.3.0 release.
 - the ldap and gd modules

#22236 [Com]: Libsablot compile error

[colin at easydns dot com]

 ID:   22236
 Comment by:   colin at easydns dot com
 Reported By:  shunter at venticon dot com
 Status:   Bogus
 Bug Type: XSLT related
 Operating System: Mandrake 9.0
 PHP Version:  4.3.0
 New Comment:

I'm getting the same error on my Debian system, with Sablotron 0.97,
and I can't find the bug of which this is supposed to be a duplicate.

Debian packages installed are:

libxslt1   1.0.24-2
libxslt1-dev   1.0.24-2
libsablot0-dev 0.97-5
libsablot0c102 0.97-5
sablotron  0.97-5
libexpat1  1.95.6-3
libexpat1-dev  1.95.6-3
libtool1.4.2-7

- Colin


Previous Comments:


[2003-02-16 13:03:00] shunter at venticon dot com

I hate to say it, but i have done a search and advanced search for the
bug and i have not found one that is open.

Could you please specify the bug that you are referring too.

Thanks,

Ray



[2003-02-16 11:38:13] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.


Try search before you submit any reports..




[2003-02-15 18:43:33] shunter at venticon dot com

OS:  Mandrake 9.0
Expat:   expat 1.95.2 & 1.95.6
Sablot:  Sablot 0.97
Libtool: 1.4.2
PHP: php 4.3.0

Sablot config:
./configure 
--prefix=/usr/local/sablot --with-expat-prefix=/usr/local/expat

PHP config:
./configure \
--prefix=/usr/local/php \
--bindir=/usr/local/bin \
--with-apxs=/usr/local/apache/bin/apxs \
--with-config-file-path=/etc \
--with-zlib \
--with-dom \
--with-dom-xslt \
--with-gd \
--with-gettext \
--with-java=/usr/local/java \
--with-mysql \
--with-pgsql \
--with-regex=system \
--with-xslt-sablot=/usr/local/sablot \
--with-xml \
--enable-magic-quotes \
--enable-bcmath \
--enable-calendar \
--enable-dio \
--enable-exif \
--enable-shmop \
--enable-sockets \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx \
--enable-xslt


PHP Error:
/usr/local/sablot/lib/libsablot.so: undefined reference to `operator
new[](unsigned)'
/usr/local/sablot/lib/libsablot.so: undefined reference to `vtable for
__cxxabiv1::__si_class_type_info'
/usr/local/sablot/lib/libsablot.so: undefined reference to `operator
delete(void*)'
/usr/local/sablot/lib/libsablot.so: undefined reference to
`__gxx_personality_v0'
/usr/local/sablot/lib/libsablot.so: undefined reference to
`__cxa_pure_virtual'
/usr/local/sablot/lib/libsablot.so: undefined reference to `vtable for
__cxxabiv1::__class_type_info'
/usr/local/sablot/lib/libsablot.so: undefined reference to `operator
delete[](void*)'
/usr/local/sablot/lib/libsablot.so: undefined reference to `vtable for
__cxxabiv1::__vmi_class_type_info'
/usr/local/sablot/lib/libsablot.so: undefined reference to `operator
new(unsigned)'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

This error is generated durning the "make" process.
What can i do to fix this problem?

Thanks,

Ray




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

#25480 [NEW]: All exec, passthru, system, shell execution commands fail intermittently.

[colin at grandecom dot com]

From: colin at grandecom dot com
Operating system: Solaris 2.8
PHP version:  4.3.3
PHP Bug Type: Program Execution
Bug description:  All exec, passthru, system, shell execution commands fail 
intermittently.

Description:

At certain times (no discernible load, nor any unusually
high memory or swap usage, etc.) all shell exec commands
fail.  Typically it will last a short period of time, and
then all commands work fine.  Restarting apache does not
appear to cure or improve the situation.  Below are my
particulars.

My configure line:
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-oracle=/opt/oracle --with-snmp=/usr/local --with-curl=/opt
--with-gd --with-zlib-dir=/usr/local/lib

Other information:
Sun E250, 2x296mhz, 1024MB RAM, gcc 2.95.2

Changes to php.ini from php.ini-dist:
register_globals = On

Here are some error examples from various execs:
Warning: shell_exec(): Unable to execute 'nslookup -timeout=3  10.130.0.1
2>/dev/null' in /usr/local/apache/htdocs/my.php on line 39
Warning: system(): Unable to fork [/opt/qip/usr/bin/qping -v -r 3 -t 250
10.130.2.163] in /usr/local/apache/htdocs/my.php on line 79
Warning: passthru(): Unable to fork [/opt/qip/usr/bin/qping -v -r 3 -t 250
10.130.2.163] in /usr/local/apache/htdocs/my.php on line 78

Reproduce code:
---
echo ""; system("ping -s $ip 56 10"); echo "";

Expected result:

Warning: system(): Unable to fork [ping -s 10.130.2.163 56 10] in
/usr/local/apache/htdocs/ping.php on line 55

Actual result:
--
Command simply doesn't execute, program continues without
a problem or error.

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

#25480 [Opn]: All exec, passthru, system, shell execution commands fail intermittently.

[colin at grandecom dot com]

 ID:   25480
 User updated by:  colin at grandecom dot com
 Reported By:  colin at grandecom dot com
 Status:   Open
 Bug Type: Program Execution
 Operating System: Solaris 2.8
 PHP Version:  4.3.3
 New Comment:

Sorry, the 'expected result' is naturally just the output
of a ping process, ie:
PING blah: 56 data bytes
64 bytes from 192.168.5.1: icmp_seq=0. time=1. ms
64 bytes from 192.168.5.1: icmp_seq=1. time=0. ms

blah PING Statistics
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 0/0/1

And the actual result is the error I pasted under
expected output.  Excuse my braindead first post.


Previous Comments:


[2003-09-10 18:10:47] colin at grandecom dot com

Description:

At certain times (no discernible load, nor any unusually
high memory or swap usage, etc.) all shell exec commands
fail.  Typically it will last a short period of time, and
then all commands work fine.  Restarting apache does not
appear to cure or improve the situation.  Below are my
particulars.

My configure line:
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-oracle=/opt/oracle --with-snmp=/usr/local --with-curl=/opt
--with-gd --with-zlib-dir=/usr/local/lib

Other information:
Sun E250, 2x296mhz, 1024MB RAM, gcc 2.95.2

Changes to php.ini from php.ini-dist:
register_globals = On

Here are some error examples from various execs:
Warning: shell_exec(): Unable to execute 'nslookup -timeout=3 
10.130.0.1 2>/dev/null' in /usr/local/apache/htdocs/my.php on line 39
Warning: system(): Unable to fork [/opt/qip/usr/bin/qping -v -r 3 -t
250 10.130.2.163] in /usr/local/apache/htdocs/my.php on line 79
Warning: passthru(): Unable to fork [/opt/qip/usr/bin/qping -v -r 3 -t
250 10.130.2.163] in /usr/local/apache/htdocs/my.php on line 78

Reproduce code:
---
echo ""; system("ping -s $ip 56 10"); echo "";

Expected result:

Warning: system(): Unable to fork [ping -s 10.130.2.163 56 10] in
/usr/local/apache/htdocs/ping.php on line 55

Actual result:
--
Command simply doesn't execute, program continues without
a problem or error.





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

#25480 [Fbk->Opn]: All exec, passthru, system, shell execution commands fail intermittently.

[colin at grandecom dot com]

 ID:   25480
 User updated by:  colin at grandecom dot com
 Reported By:  colin at grandecom dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Program Execution
 Operating System: Solaris 2.8
 PHP Version:  4.3.3
 New Comment:

safe_mode = Off

It is only happening to me with 4.3.3 - on this particular
machine I upgraded from 4.3.1 yesterday to fix an snmp bug,
and the problem start happening today (I'd run 4.3.1 
without any exec issues for several weeks prior.)  In
retrospect, this definitely should have been mentioned in
my initial bug report.  Sorry about that.


Previous Comments:


[2003-09-10 20:07:27] [EMAIL PROTECTED]

Also, did this happen with previous PHP versions? If not, which was the
previous version you had? 




[2003-09-10 20:06:43] [EMAIL PROTECTED]

Is "safe_mode" enabled?




[2003-09-10 18:14:54] colin at grandecom dot com

Sorry, the 'expected result' is naturally just the output
of a ping process, ie:
PING blah: 56 data bytes
64 bytes from 192.168.5.1: icmp_seq=0. time=1. ms
64 bytes from 192.168.5.1: icmp_seq=1. time=0. ms

blah PING Statistics
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 0/0/1

And the actual result is the error I pasted under
expected output.  Excuse my braindead first post.

----

[2003-09-10 18:10:47] colin at grandecom dot com

Description:

At certain times (no discernible load, nor any unusually
high memory or swap usage, etc.) all shell exec commands
fail.  Typically it will last a short period of time, and
then all commands work fine.  Restarting apache does not
appear to cure or improve the situation.  Below are my
particulars.

My configure line:
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-oracle=/opt/oracle --with-snmp=/usr/local --with-curl=/opt
--with-gd --with-zlib-dir=/usr/local/lib

Other information:
Sun E250, 2x296mhz, 1024MB RAM, gcc 2.95.2

Changes to php.ini from php.ini-dist:
register_globals = On

Here are some error examples from various execs:
Warning: shell_exec(): Unable to execute 'nslookup -timeout=3 
10.130.0.1 2>/dev/null' in /usr/local/apache/htdocs/my.php on line 39
Warning: system(): Unable to fork [/opt/qip/usr/bin/qping -v -r 3 -t
250 10.130.2.163] in /usr/local/apache/htdocs/my.php on line 79
Warning: passthru(): Unable to fork [/opt/qip/usr/bin/qping -v -r 3 -t
250 10.130.2.163] in /usr/local/apache/htdocs/my.php on line 78

Reproduce code:
---
echo ""; system("ping -s $ip 56 10"); echo "";

Expected result:

Warning: system(): Unable to fork [ping -s 10.130.2.163 56 10] in
/usr/local/apache/htdocs/ping.php on line 55

Actual result:
--
Command simply doesn't execute, program continues without
a problem or error.





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

#25480 [Fbk->Opn]: All exec, passthru, system, shell execution commands fail intermittently.

[colin at grandecom dot com]

 ID:   25480
 User updated by:  colin at grandecom dot com
 Reported By:  colin at grandecom dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Program Execution
 Operating System: Solaris 2.8
 PHP Version:  4.3.3
 New Comment:

Uh... My ./configure line appears in my very first post as is required
by the bug submission form.


Previous Comments:


[2003-10-04 00:11:04] [EMAIL PROTECTED]

Please check phpinfo() output for the configure line
and paste it here.




[2003-09-10 21:05:50] colin at grandecom dot com

safe_mode = Off

It is only happening to me with 4.3.3 - on this particular
machine I upgraded from 4.3.1 yesterday to fix an snmp bug,
and the problem start happening today (I'd run 4.3.1 
without any exec issues for several weeks prior.)  In
retrospect, this definitely should have been mentioned in
my initial bug report.  Sorry about that.



[2003-09-10 20:07:27] [EMAIL PROTECTED]

Also, did this happen with previous PHP versions? If not, which was the
previous version you had? 




[2003-09-10 20:06:43] [EMAIL PROTECTED]

Is "safe_mode" enabled?




[2003-09-10 18:14:54] colin at grandecom dot com

Sorry, the 'expected result' is naturally just the output
of a ping process, ie:
PING blah: 56 data bytes
64 bytes from 192.168.5.1: icmp_seq=0. time=1. ms
64 bytes from 192.168.5.1: icmp_seq=1. time=0. ms

blah PING Statistics
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 0/0/1

And the actual result is the error I pasted under
expected output.  Excuse my braindead first post.



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

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

#25480 [Opn]: All exec, passthru, system, shell execution commands fail intermittently.

[colin at grandecom dot com]

 ID:   25480
 User updated by:  colin at grandecom dot com
 Reported By:  colin at grandecom dot com
 Status:   Open
 Bug Type: Program Execution
 Operating System: Solaris 2.8
 PHP Version:  4.3.3
 New Comment:

I only had mine (ulimit -n) set to 256, and I tried upping it to 1024
with no discernible result.  My system is an internal one, and has no
customer vhosts - just a couple of name vhosts, referencing about 4
logs total.  I'm not sure why _dropping_ your number of file
descriptors would fix the problem - if anything, that would make it
worse it would seem.   I have to say that I doubt your problem is gone
for good.


Previous Comments:


[2003-10-16 10:28:46] bk at galaxy dot net

Sure enough, when I reduce the file descriptors down (it was over 400),
the intermittent problems went away.  I
eliminated the ErrorLog for the virtual hosts to knock
the file descriptors down to 200 and it seems to work
consistently (so far).



[2003-10-16 09:25:13] bk at galaxy dot net

I'm seeing the same thing.  I get shell_exec() to fail
ever since upgrading to 4.3.3 as well as popen() within
the sendmail module of pear.

I'm wondering if this has something to do with the
solaris limit of 256 file descriptors in FILE streams
and running out of them.  But it is strange that this
didn't start until I upgraded to 4.3.3.



[2003-09-10 21:05:50] colin at grandecom dot com

safe_mode = Off

It is only happening to me with 4.3.3 - on this particular
machine I upgraded from 4.3.1 yesterday to fix an snmp bug,
and the problem start happening today (I'd run 4.3.1 
without any exec issues for several weeks prior.)  In
retrospect, this definitely should have been mentioned in
my initial bug report.  Sorry about that.



[2003-09-10 20:07:27] [EMAIL PROTECTED]

Also, did this happen with previous PHP versions? If not, which was the
previous version you had? 




[2003-09-10 20:06:43] [EMAIL PROTECTED]

Is "safe_mode" enabled?




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

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

#25480 [Bgs]: All exec, passthru, system, shell execution commands fail intermittently.

[colin at grandecom dot com]

 ID:   25480
 User updated by:  colin at grandecom dot com
 Reported By:  colin at grandecom dot com
 Status:   Bogus
 Bug Type: Program Execution
 Operating System: Solaris 2.8
 PHP Version:  4.3.3
 New Comment:

Yes, I guess I thought you meant you reduced the number of system file
descriptors.

For what its worth though, my system is set w/rlimit 1024 and with
4.3.3, it would continually fail the exec commands after mere hours of
operation.  I did not check how many FDs were in use with Apache at the
time, but for the purposes of comparison, my server (which has been
running 4.3.1 flawlessly non-stop since 09/08, or about a month and a
half) is currently using 21 descriptors.

So my guess is that 4.3.3 has some kind of problem releasing  ones that
have already been used?


Previous Comments:


[2003-10-18 23:11:42] [EMAIL PROTECTED]

Given the above comment, this is not PHP bug.





[2003-10-18 11:14:33] bk at galaxy dot net

I guess you misunderstood.  I reduced the number of file
descriptors in use to make sure fd value is < 256.

In the FILE* structure, which is what fopen(), popen(), etc
uses, they only have a "char" to hold the file descriptor.
fopen() and popen() will fail if the file descriptor it gets
assigned is >= 256.  This problem goes away in 64 bit mode,
but not many people are using that yet.

Sure enough, all my problems with shell_exec() have gone
away since eliminating all the ErrorLog lines from my web
server.  If you run "pfiles" on your httpd process, you'll
see the ulimit as well as how many file descriptors you have
open.  If this value goes above 255, you'll start seeing
intermittent exec failures.  Its intermittent since some
fd's less than 256 may get closed and reused to allow an
exec to work, however once they're all full in the lower
numbers, you'll fail again.

----

[2003-10-16 13:17:53] colin at grandecom dot com

I only had mine (ulimit -n) set to 256, and I tried upping it to 1024
with no discernible result.  My system is an internal one, and has no
customer vhosts - just a couple of name vhosts, referencing about 4
logs total.  I'm not sure why _dropping_ your number of file
descriptors would fix the problem - if anything, that would make it
worse it would seem.   I have to say that I doubt your problem is gone
for good.



[2003-10-16 10:28:46] bk at galaxy dot net

Sure enough, when I reduce the file descriptors down (it was over 400),
the intermittent problems went away.  I
eliminated the ErrorLog for the virtual hosts to knock
the file descriptors down to 200 and it seems to work
consistently (so far).



[2003-10-16 09:25:13] bk at galaxy dot net

I'm seeing the same thing.  I get shell_exec() to fail
ever since upgrading to 4.3.3 as well as popen() within
the sendmail module of pear.

I'm wondering if this has something to do with the
solaris limit of 256 file descriptors in FILE streams
and running out of them.  But it is strange that this
didn't start until I upgraded to 4.3.3.



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

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

#30524 [NEW]: Can't compile mysqli

[colin at viebrock dot ca]

From: colin at viebrock dot ca
Operating system: Mac OS X 10.3.5
PHP version:  5.0.2
PHP Bug Type: Compile Failure
Bug description:  Can't compile mysqli

Description:

I'm trying to compile 5.0.2 from source on OS X, and it 
fails when trying to find the mysqli libraries.  MySQL 
3.23.58 and 4.0.21 were installed using the binaries 
from mysql.com.  4.0.21 is "active", although neither 
servers are running.

Reproduce code:
---
My test configure line is:

./configure \
  --prefix=/usr/local/php5
  --with-config-file-path=/usr/local/php5/lib
  --with-apxs
  --enable-cli
  --with-mysql=/usr/local/mysql-3.23.58-apple-darwin6.4-powerpc
  --with-mysqli=/usr/local/mysql/bin/mysql_config

(FYI: /usr/local/mysql is a symlink to
/usr/local/mysql-standard-4.0.21-apple-darwin7.5.0-powerpc, the default
installation path of the MySQL binaries.)


Expected result:

I expect it to compile. :)

Actual result:
--
The configure process ends with:

  checking for MySQL support... yes
  checking for specified location of the MySQL UNIX 
socket... no
  checking for MySQL UNIX socket location... no
  checking for mysql_close in -lmysqlclient... yes
  checking for MySQLi support... yes
  checking whether to enable embedded MySQLi support... 
no
  checking for mysql_set_server_option in 
-lmysqlclient... no
  configure: error: wrong mysql library version or lib 
not found. Check config.log for more information.

config.log ends with:

configure:53964: checking for MySQL UNIX socket location
configure:54120: checking for mysql_close in 
-lmysqlclient
configure:54139: gcc -o conftest -g -O2  -no-cpp-precomp 
-L/usr/local/mysql-3.23.58-apple-darwin6.4-powerpc/lib 
-L/usr/local/mysql-3.23.58-apple-darwin6.4-powerpc/lib  
conftest.c -lmysqlclient  -lm  -lxml2 -lz -liconv -lm 
-lxml2 -lz -liconv -lm 1>&5
configure:54936: checking for MySQLi support
configure:54982: checking whether to enable embedded 
MySQLi support
configure:55115: checking for mysql_set_server_option in 
-lmysqlclient
configure:55134: gcc -o conftest -g -O2  -no-cpp-precomp 
-L/usr/local/mysql/lib -L/usr/local/mysql/lib  -L/usr/
local/mysql-3.23.58-apple-darwin6.4-powerpc/lib -L/usr/
local/mysql-3.23.58-apple-darwin6.4-powerpc/lib 
-lmysqlclient -lz -lm conftest.c -lmysqlclient  
-lmysqlclient -lm  -lxml2 -lz -liconv -lm -lxml2 -lz 
-liconv -lm 1>&5
ld: Undefined symbols:
_mysql_set_server_option
configure: failed program was:
#line 55123 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an 
error.  */
/* We use char because int might match the return type 
of a gcc2
builtin and then its argument prototype would still 
apply.  */
char mysql_set_server_option();

int main() {
mysql_set_server_option()
; return 0; }

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

#30524 [Bgs->Csd]: Can't compile mysqli

[colin at viebrock dot ca]

 ID:   30524
 User updated by:  colin at viebrock dot ca
 Reported By:  colin at viebrock dot ca
-Status:   Bogus
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.3.5
 PHP Version:  5.0.2
 New Comment:

I'm an idiot ... thanks, Georg.  :)


Previous Comments:


[2004-10-22 09:32:47] [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

Colin, 
 
mysqli requires MySQL 4.1.x or above! 



[2004-10-22 00:47:06] colin at viebrock dot ca

Description:

I'm trying to compile 5.0.2 from source on OS X, and it 
fails when trying to find the mysqli libraries.  MySQL 
3.23.58 and 4.0.21 were installed using the binaries 
from mysql.com.  4.0.21 is "active", although neither 
servers are running.

Reproduce code:
---
My test configure line is:

./configure \
  --prefix=/usr/local/php5
  --with-config-file-path=/usr/local/php5/lib
  --with-apxs
  --enable-cli
  --with-mysql=/usr/local/mysql-3.23.58-apple-darwin6.4-powerpc
  --with-mysqli=/usr/local/mysql/bin/mysql_config

(FYI: /usr/local/mysql is a symlink to
/usr/local/mysql-standard-4.0.21-apple-darwin7.5.0-powerpc, the default
installation path of the MySQL binaries.)


Expected result:

I expect it to compile. :)

Actual result:
--
The configure process ends with:

  checking for MySQL support... yes
  checking for specified location of the MySQL UNIX 
socket... no
  checking for MySQL UNIX socket location... no
  checking for mysql_close in -lmysqlclient... yes
  checking for MySQLi support... yes
  checking whether to enable embedded MySQLi support... 
no
  checking for mysql_set_server_option in 
-lmysqlclient... no
  configure: error: wrong mysql library version or lib 
not found. Check config.log for more information.

config.log ends with:

configure:53964: checking for MySQL UNIX socket location
configure:54120: checking for mysql_close in 
-lmysqlclient
configure:54139: gcc -o conftest -g -O2  -no-cpp-precomp 
-L/usr/local/mysql-3.23.58-apple-darwin6.4-powerpc/lib 
-L/usr/local/mysql-3.23.58-apple-darwin6.4-powerpc/lib  
conftest.c -lmysqlclient  -lm  -lxml2 -lz -liconv -lm 
-lxml2 -lz -liconv -lm 1>&5
configure:54936: checking for MySQLi support
configure:54982: checking whether to enable embedded 
MySQLi support
configure:55115: checking for mysql_set_server_option in 
-lmysqlclient
configure:55134: gcc -o conftest -g -O2  -no-cpp-precomp 
-L/usr/local/mysql/lib -L/usr/local/mysql/lib  -L/usr/
local/mysql-3.23.58-apple-darwin6.4-powerpc/lib -L/usr/
local/mysql-3.23.58-apple-darwin6.4-powerpc/lib 
-lmysqlclient -lz -lm conftest.c -lmysqlclient  
-lmysqlclient -lm  -lxml2 -lz -liconv -lm -lxml2 -lz 
-liconv -lm 1>&5
ld: Undefined symbols:
_mysql_set_server_option
configure: failed program was:
#line 55123 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an 
error.  */
/* We use char because int might match the return type 
of a gcc2
builtin and then its argument prototype would still 
apply.  */
char mysql_set_server_option();

int main() {
mysql_set_server_option()
; return 0; }





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

#30534 [NEW]: fails compiling XSL

[colin at easydns dot com]

From: colin at easydns dot com
Operating system: Darwin / Mac OS X 10.3.5
PHP version:  5.0.2
PHP Bug Type: Compile Failure
Bug description:  fails compiling XSL

Description:

Building PHP 5.0.2 fails on xsl.  libxslt (1.1.4-3) is 
installed using the binary from Fink.

Reproduce code:
---
./configure \
--prefix=/usr/local/php5 \
--with-config-file-path=/usr/local/php5/lib \
--with-apxs \
--enable-cli \
--with-iconv \
--with-openssl=/usr \
--with-zlib=/usr \
--with-mysql=/usr/local/mysql \
--with-mysqli=/usr/local/mysql/bin/mysql_config \
--with-xsl=/sw \
--with-pdflib=/sw \
--with-gd \
--with-jpeg-dir=/sw \
--with-tiff-dir=/sw \
--with-png-dir=/sw \
--with-ming-dir=/sw \
--with-zlib-dir=/usr \
--with-freetype-dir=/sw/lib/freetype2 \
--with-t1lib=/sw \
--with-imap=/sw/share/c-client \
--with-imap-ssl=/sw \
--with-gettext=/sw \
--with-ldap \
--with-mime-magic=/usr/share/file/magic \
--with-iodbc=/usr \
--with-xmlrpc \
--with-expat-dir=/sw \
--with-iconv-dir=/usr \
--with-curl=/sw \
--enable-exif \
--enable-wddx \
--enable-soap \
--enable-sqlite-utf8 \
--enable-ftp \
--enable-sockets \
--enable-dbx \
--enable-dbase \
--enable-mbstring \
--enable-calendar \
--with-bz2=/usr \
--with-mcrypt=/sw \
--with-mhash=/sw

Expected result:

Compile should work. :)

Actual result:
--
gcc  -Iext/xsl/ -I/Users/cviebrock/Documents/Source/php
-5.0.2/ext/xsl/ -DPHP_ATOM_INC -I/Users/cviebrock/
Documents/Source/php-5.0.2/include -I/Users/cviebrock/
Documents/Source/php-5.0.2/main -I/Users/cviebrock/
Documents/Source/php-5.0.2 -I/Users/cviebrock/Documents/
Source/php-5.0.2/Zend -I/usr/include/libxml2 -I/sw/
include -I/sw/lib/freetype2/include -I/sw/lib/freetype2/
include/freetype2 -I/sw/share/c-client/include -I/Users/
cviebrock/Documents/Source/php-5.0.2/ext/mbstring/
oniguruma -I/Users/cviebrock/Documents/Source/php-5.0.2/
ext/mbstring/libmbfl -I/Users/cviebrock/Documents/
Source/php-5.0.2/ext/mbstring/libmbfl/mbfl -I/usr/local/
mysql/include -I/sw/include/libxml2  -no-cpp-precomp -I/
Users/cviebrock/Documents/Source/php-5.0.2/TSRM  -g -O2  
-c /Users/cviebrock/Documents/Source/php-5.0.2/ext/xsl/
php_xsl.c -o ext/xsl/php_xsl.o  && echo > ext/xsl/
php_xsl.lo
In file included from /sw/include/libxslt/
xsltInternals.h:20,
 from /Users/cviebrock/Documents/Source/
php-5.0.2/ext/xsl/php_xsl.h:38,
 from /Users/cviebrock/Documents/Source/
php-5.0.2/ext/xsl/php_xsl.c:28:
/sw/include/libxml2/libxml/dict.h:30: error: syntax 
error before "xmlDictPtr"
/sw/include/libxml2/libxml/dict.h:31: warning: data 
definition has no type or storage class
/sw/include/libxml2/libxml/dict.h:32: error: syntax 
error before "xmlDictPtr"
/sw/include/libxml2/libxml/dict.h:33: warning: data 
definition has no type or storage class
/sw/include/libxml2/libxml/dict.h:34: error: syntax 
error before "int"
/sw/include/libxml2/libxml/dict.h:35: warning: data 
definition has no type or storage class
/sw/include/libxml2/libxml/dict.h:36: error: syntax 
error before "void"
/sw/include/libxml2/libxml/dict.h:37: warning: data 
definition has no type or storage class
/sw/include/libxml2/libxml/dict.h:42: error: syntax 
error before "const"
/sw/include/libxml2/libxml/dict.h:43: error: parse error 
before "xmlDictLookup"
/sw/include/libxml2/libxml/dict.h:45: warning: data 
definition has no type or storage class
/sw/include/libxml2/libxml/dict.h:46: error: syntax 
error before "const"
/sw/include/libxml2/libxml/dict.h:47: error: parse error 
before "xmlDictQLookup"
/sw/include/libxml2/libxml/dict.h:49: warning: data 
definition has no type or storage class
/sw/include/libxml2/libxml/dict.h:50: error: syntax 
error before "int"
/sw/include/libxml2/libxml/dict.h:52: warning: data 
definition has no type or storage class
/sw/include/libxml2/libxml/dict.h:53: error: syntax 
error before "int"
/sw/include/libxml2/libxml/dict.h:54: warning: data 
definition has no type or storage class
make: *** [ext/xsl/php_xsl.lo] Error 1

-- 
Edit bug report at http://bugs.php.net/?id=30534&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=30534&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30534&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30534&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30534&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30534&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=30534&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=30534&r=needscript
Try newer version:   

#29550 [NEW]: error handler not used by create_function parser

[colin at mms3 dot com]

From: colin at mms3 dot com
Operating system: Linux (2.4)
PHP version:  4.3.8
PHP Bug Type: Output Control
Bug description:  error handler not used by create_function parser

Description:

I am writing an application which allows the 'user' to specify some PHP
code. This is then invoked at run-time by the create_function() function.

I want to provide a facility for pre-checking this code by using a custom
error-handler, however the errors seem to be getting handled by the
built-in error handler.

Reproduce code:
---
function lister_check_errors($errno, $errstr, $errfile, $errline)
{
global $lister_embed_errors;
$lister_embed_errors.="$errno: $errstr\n  in line
$errline";
}
function lister_check_syntax($code,$params)
{
global $lister_embed_errors;
$lister_embed_errors='';
$errhandler=set_error_handler('lister_check_errors');
$fn=create_function($params,$code);
restore_error_handler();
return($lister_embed_errors);
}

$stored=lister_check_syntax(" bad stuff", '$something');
print strlen($stored);

Expected result:

I expected to just get an integer back, but it behaves as if I hadn't
called set_error_handler()

Actual result:
--
The following was output to the browser:

Parse error: parse error, unexpected T_STRING in
/home/colin/public_html/form/check_err.php(15) : runtime-created function
on line 1

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

[PHP-BUG] Bug #61878 [NEW]: FILTER_VALIDATE_URL doesn't support tel: schema

[colin at viebrock dot ca]

From: 
Operating system: Debian
PHP version:  5.3.11
Package:  Filter related
Bug Type: Bug
Bug description:FILTER_VALIDATE_URL doesn't support tel: schema

Description:

filter_var($uri, FILTER_VALIDATE_URL) will return false if $uri is a "tel:"

scheme.

I'm not sure if this is covered by RFC 2396, so if it isn't then this
should 
become a feature request instead of a bug.

Test script:
---
$uri = 'tel:4166520322';

echo filter_var($uri, FILTER_VALIDATE_URL) ? "ok" : "no";


Expected result:

ok

Actual result:
--
no

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

Req #53713 [Com]: Add sqlite3 session handler

[colin at viebrock dot ca]

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

 ID: 53713
 Comment by: colin at viebrock dot ca
 Reported by:jinmoku at hotmail dot com
 Summary:Add sqlite3 session handler
 Status: Open
 Type:   Feature/Change Request
 Package:SQLite related
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

This isn't in 5.4.4 as of yet, is it?


Previous Comments:

[2011-08-01 05:15:27] crrodriguez at opensuse dot org

I have reviewed this patch, ACKed, fixed build in Unix (broken #if) and 
config0.m4

also added IF NOT EXISTS to the table creation routine.

Looks good =)


[2011-04-30 04:05:54] jinmoku at hotmail dot com

Added patch


[2011-01-11 15:43:38] jinmoku at hotmail dot com

Description:

ext/sqlite will disappear soon, it's seem good to add support for sqlite3 
session handler (merge ext/sqlite/sess_sqlite.c)
;)

Test script:
---
session_module_name('sqlite3');

Actual result:
--
Warning: session_module_name(): Cannot find named PHP session module (sqlite3)






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

[PHP-BUG] Bug #62451 [NEW]: no sqlite3 replacement session handlers

[colin at viebrock dot ca]

From: colin at viebrock dot ca
Operating system: Debian
PHP version:  5.4.4
Package:  Session related
Bug Type: Bug
Bug description:no sqlite3 replacement session handlers

Description:

Since sqlite was dropped from 5.4, we've lost the sqlite session handlers. 
I was 
hoping there'd be a sqlite3 replacement, but that doesn't seem to be the
case.

There was a bug report about this previously
(https://bugs.php.net/bug.php?
id=53713) with a patch ... but it never seems to have been applied to a
release 
build.

Can I ask that this be added to the 5.4.x branch?  I'm sure it was an
oversight, 
but removing sqlite session handler support seems to be a pretty important

backwards compatability issue that wasn't explicitly mentioned.


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

Req #36072 [Com]: stream_set_connection_timeout()

[colin at mollenhour dot com]

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

 ID: 36072
 Comment by: colin at mollenhour dot com
 Reported by:ceo at l-i-e dot com
 Summary:stream_set_connection_timeout()
 Status: Open
 Type:   Feature/Change Request
 Package:Streams related
 Operating System:   *
 PHP Version:*
 Block user comment: N
 Private report: N

 New Comment:

I think an excellent solution would be to add a "timeout" option to the Socket 
stream options. The HTTP stream already supports timeout, but not regular 
sockets.  
For example, I want to connect to a Redis server using tcp for caching 
(infinite 
timeout needed for blocking calls) and may want to connect to a different 
server 
for some other purpose with a short timeout. Example:

$context = stream_context_create(array('socket' => array('timeout' => 5)));


Previous Comments:

[2010-09-27 16:13:26] cataphr...@php.net

You can already do this for http/https:

 array("timeout"=>2),
));
var_dump(fopen("http://136.234.1.4/";, "r", false, $context));

For FTP, there isn't unfortunately a way, by you can set a default timeout:

ini_set("default_socket_timeout", 2);


[2006-01-19 00:31:14] ceo at l-i-e dot com

E. If you read the actual Feature Request, I think it's pretty clear that 
RTFM stream_set_timeout won't cut it...

stream_set_timeout is useful only AFTER a stream is open.

fopen() gives no control (tho fsockopen() does) over connection timeout.

But fsockopen is missing all the great stuff in fopen() that takes care of.

I really don't think I'm being an idiot here...  Honest.


[2006-01-18 21:24:49] he...@php.net

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.

RTFM: stream_set_timeout(), context of fopen(), streams section in manual


[2006-01-18 21:16:55] ceo at l-i-e dot com

Description:

I love the simplicity of fopen() that takes most URLs / files / whatever and 
does what I want.

Do whatever it takes to start sending me the data.

I NEED the ability to set the time-out for the opening, as well as the time-out 
after the stream has opened.

I'm stuck with duplicating whatever code is down in fopen() in my own PHP code 
to detect and initiate protocol specific minutia because fopen() has no 
user-configurable timeout, but fsockopen doesn't do all that.
$parts = parse_url($url);
extract($parts);
switch($scheme){
case 'http': fputs("GET $path HTTP/1.0\n"); fputs("Host: $host\n"); break;
case 'ftp': fputs("GET $path\n"); break;
.
.
.
}

I REALLY don't want to re-invent the wheel here, when I know that code is down 
in the guts of fopen()

A function stream_set_connection_timeout() to let me tell PHP how long fopen() 
should wait would make life way more better for many users, I believe.


Expected result:

The PHP Dev Team is going to add this function because YOU ROCK!
:-)








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

#48112 [NEW]: Printing a "++"

[colin at shuaige dot org]

From: colin at shuaige dot org
Operating system: Windows Server 2003 (and others)
PHP version:  5.2.9
PHP Bug Type: Feature/Change Request
Bug description:  Printing a "++"

Description:

Printing a short-hand addition statement ("++") produces the value of the
integer before the statement was run instead of the integer "+ 1".

Reproduce code:
---
$test = 0;

echo $test++;
// produces "0"

echo $test;
// produces "1"

Expected result:

$test = 0;

echo $test++;
// produces "1"

echo $test;
// produces "1"

Actual result:
--
$test = 0;

echo $test++;
// produces "0"

echo $test;
// produces "1"

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

#48991 [NEW]: JPG -> JPEG change breaks things

[colin at viebrock dot ca]

From: colin at viebrock dot ca
Operating system: Linux
PHP version:  5.3.0
PHP Bug Type: GD related
Bug description:  JPG -> JPEG change breaks things

Description:

We recently upgraded to 5.3.0.  The change made here:

http://svn.php.net/viewvc?view=revision&revision=277688

has had the unintended effect of breaking some applications that rely on 
gd_info() to test for JPEG support (specifically in my case the 
Textpattern blogging engine).  Neither the manual nor the migration 
notes made reference to this.

Not a big deal, but was this really required?  I suppose the person 
posting bug #47757 thought so!

Reproduce code:
---
var_dump(gd_info())

Expected result:

... ["JPG Support"]=> bool(true) ...

Actual result:
--
... ["JPEG Support"]=> bool(true) ...

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

#49558 [Com]: Sunrise Problems around 91 degree zenith

[colin at viebrock dot ca]

 ID:   49558
 Comment by:   colin at viebrock dot ca
 Reported By:  eclipsechasers2 at yahoo dot com
 Status:   Open
 Bug Type: Date/time related
 Operating System: *
 PHP Version:  5.2.10
 New Comment:

I'd say that all the times from 91 degrees onward are off.  Graphing
the 
data shows it "jumps" at that point, but is smooth before and after.

Could it be some error related to line 3930 in ext/date/php_date.c

rs = timelib_astro_rise_set_altitude(t, longitude, latitude, altitude,

altitude > -1 ? 1 : 0, &h_rise, &h_set, &rise, &set, &transit);

Altitude is 90-zenith, so when you get to 91, the code would set that 
param from 0 to 1 ... which I think means it calculates the twilight 
time instead of sunrise/set.  I would say this param should always be
1, 
if you are calculating sunrise/set (see note on line 187 of 
ext/date/lib/astro.c).


Previous Comments:


[2009-09-15 05:51:13] eclipsechasers2 at yahoo dot com

Description:

Script showing times for series of zeniths from 90.0 to 92.0 by 0.1
should show time uniformly decreasing (earlier) as zenith gets larger.
This is true for most values. However, 91.1 shows a later time than
91.0, as does 91.2; this would happen only if earth changed its
direction of rotation.

Reproduce code:
---
$gregyear $gregmonthname $dd  - " . jddayofweek($jd,1) . " -
";
  echo "Latitude $latitude Longitude $longitude Time Zone $timezone
Location $location\n";
  $ts = $gregyear . "-" . $gregmonth . "-" . $dd . " 06:00:00";
  $strts = strtotime($ts);
  $gmto = -8;
  for ($deg = 90; $deg <= 92; $deg += .1) {
$sunris0 = date_sunrise($strts,SUNFUNCS_RET_TIMESTAMP, $latitude,
$longitude, $deg, $gmto);
printf("%02.1f %s\n",$deg,date("g:i:sa",$sunris0));
}
?> 

Expected result:

Unsure of exact result (can't do these calculations in my head), but
the times on each line should be earlier than the line above.

Actual result:
--
2009 March - Friday - Latitude 37.787 Longitude -122.447 Time Zone
America/Los_Angeles Location San Francisco
90.0 7:28:40am
90.1 7:28:05am
90.2 7:27:30am
90.3 7:26:56am
90.4 7:26:21am
90.5 7:25:46am
90.6 7:25:11am
90.7 7:24:37am
90.8 7:24:02am
90.9 7:23:28am
91.0 7:22:53am
91.1 7:23:52am ** Either these 2 values, or the 2 above, are wrong.
91.2 7:23:18am
91.3 7:22:43am
91.4 7:22:08am
91.5 7:21:34am
91.6 7:20:59am
91.7 7:20:25am
91.8 7:19:51am
91.9 7:19:16am
92.0 7:18:42am





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

#49558 [Com]: Sunrise Problems around 91 degree zenith

[colin at viebrock dot ca]

 ID:   49558
 Comment by:   colin at viebrock dot ca
 Reported By:  eclipsechasers2 at yahoo dot com
 Status:   Open
 Bug Type: Date/time related
 Operating System: *
 PHP Version:  5.2.10
 New Comment:

TYPO IN LAST COMMENT - SHOULD READ:

Altitude is 90-zenith, so when you are below 91, the code sets that 
param to 0 ... which I think means it calculates the twilight 
time instead of sunrise/set.  I would say this param should always be 1

if you are calculating sunrise/set (see note on line 187 of 
ext/date/lib/astro.c).


Previous Comments:


[2009-09-15 17:18:18] colin at viebrock dot ca

I'd say that all the times from 91 degrees onward are off.  Graphing
the 
data shows it "jumps" at that point, but is smooth before and after.

Could it be some error related to line 3930 in ext/date/php_date.c

rs = timelib_astro_rise_set_altitude(t, longitude, latitude, altitude,

altitude > -1 ? 1 : 0, &h_rise, &h_set, &rise, &set, &transit);

Altitude is 90-zenith, so when you get to 91, the code would set that 
param from 0 to 1 ... which I think means it calculates the twilight 
time instead of sunrise/set.  I would say this param should always be
1, 
if you are calculating sunrise/set (see note on line 187 of 
ext/date/lib/astro.c).



[2009-09-15 05:51:13] eclipsechasers2 at yahoo dot com

Description:

Script showing times for series of zeniths from 90.0 to 92.0 by 0.1
should show time uniformly decreasing (earlier) as zenith gets larger.
This is true for most values. However, 91.1 shows a later time than
91.0, as does 91.2; this would happen only if earth changed its
direction of rotation.

Reproduce code:
---
$gregyear $gregmonthname $dd  - " . jddayofweek($jd,1) . " -
";
  echo "Latitude $latitude Longitude $longitude Time Zone $timezone
Location $location\n";
  $ts = $gregyear . "-" . $gregmonth . "-" . $dd . " 06:00:00";
  $strts = strtotime($ts);
  $gmto = -8;
  for ($deg = 90; $deg <= 92; $deg += .1) {
$sunris0 = date_sunrise($strts,SUNFUNCS_RET_TIMESTAMP, $latitude,
$longitude, $deg, $gmto);
printf("%02.1f %s\n",$deg,date("g:i:sa",$sunris0));
}
?> 

Expected result:

Unsure of exact result (can't do these calculations in my head), but
the times on each line should be earlier than the line above.

Actual result:
--
2009 March - Friday - Latitude 37.787 Longitude -122.447 Time Zone
America/Los_Angeles Location San Francisco
90.0 7:28:40am
90.1 7:28:05am
90.2 7:27:30am
90.3 7:26:56am
90.4 7:26:21am
90.5 7:25:46am
90.6 7:25:11am
90.7 7:24:37am
90.8 7:24:02am
90.9 7:23:28am
91.0 7:22:53am
91.1 7:23:52am ** Either these 2 values, or the 2 above, are wrong.
91.2 7:23:18am
91.3 7:22:43am
91.4 7:22:08am
91.5 7:21:34am
91.6 7:20:59am
91.7 7:20:25am
91.8 7:19:51am
91.9 7:19:16am
92.0 7:18:42am





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

#49558 [Com]: Sunrise Problems around 91 degree zenith

[colin at viebrock dot ca]

 ID:   49558
 Comment by:   colin at viebrock dot ca
 Reported By:  eclipsechasers2 at yahoo dot com
 Status:   Open
 Bug Type: Date/time related
 Operating System: *
 PHP Version:  5.2.10
 New Comment:

The comments from the sun.c file are also in PHP's ext/date/lib/astro.c

(around line 187).

>From my reading of things, this upper-limb value should be pegged at 1

in php_date.c

Which, of course, means that most systems have been generating 
sunrise/set times that are off by about 26 seconds.  Think of all the 
angry emails you're gonna get from The Weather Network!


Previous Comments:


[2009-09-15 18:11:10] kr dot shaishav at gmail dot com

This is from the original sun.c file
Written as DAYLEN.C, 1989-08-16
Modified to SUNRISET.C, 1992-12-01
(c) Paul Schlyter, 1989, 1992
Released to the public domain by Paul Schlyter, December 1992
Portions Modified to SUNDOWN.NLM by Cliff Haas 98-05-22

the comment states
/* upper_limb: non-zero -> upper limb, zero -> center   */
/*   Set to non-zero (e.g. 1) when computing rise/set   */
/*   times, and to zero when computing start/end of */
/*   twilight.  */

Therefore, if we are calculating sunrise-sunset time the value of
upper_limb will be set to permanently non zero.
If twilight time is needed then it has to be 0.


(PS - just for clearing what this upper limb is. Sunrise happens when
the sun's centre is visible. But for the twilight to occur, the sun's
top should come over the horizon. that means,centre angle - sradius:)



[2009-09-15 17:43:04] ras...@php.net

Hardcoding that upper_limit to correction flag to either 0 or 1 does
remove the quirk in the series.  So, is it correct that for the sunrise
function we should just peg it at 1?



[2009-09-15 17:39:59] kr dot shaishav at gmail dot com

i think the bug is being caused by this 
altitude > -1 ? 1:0 ,line 3930 in php_date.c. 
becoz of this upper_limb correction is being applied here
if (upper_limb) {altit -= sradius;} line 253, astro.c 

the series gets advanced because of the altit-=sradius;. 
and hence the anamoly. i dont knw if its a bug. don't know about the
upper limb correction and why is it being selectively beyond -1 applied.
but the bug can be removed if we remove the uppr_limb if code. or add it
without an if. and if the correction is correctly applied, then i guess
thats the way it is.not a bug.

----

[2009-09-15 17:21:46] colin at viebrock dot ca

TYPO IN LAST COMMENT - SHOULD READ:

Altitude is 90-zenith, so when you are below 91, the code sets that 
param to 0 ... which I think means it calculates the twilight 
time instead of sunrise/set.  I would say this param should always be 1

if you are calculating sunrise/set (see note on line 187 of 
ext/date/lib/astro.c).

----

[2009-09-15 17:18:18] colin at viebrock dot ca

I'd say that all the times from 91 degrees onward are off.  Graphing
the 
data shows it "jumps" at that point, but is smooth before and after.

Could it be some error related to line 3930 in ext/date/php_date.c

rs = timelib_astro_rise_set_altitude(t, longitude, latitude, altitude,

altitude > -1 ? 1 : 0, &h_rise, &h_set, &rise, &set, &transit);

Altitude is 90-zenith, so when you get to 91, the code would set that 
param from 0 to 1 ... which I think means it calculates the twilight 
time instead of sunrise/set.  I would say this param should always be
1, 
if you are calculating sunrise/set (see note on line 187 of 
ext/date/lib/astro.c).



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

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

[PHP-BUG] Bug #51765 [NEW]: class constant has different setter behavior than global constant

[colin at sheaff dot net]

From: 
Operating system: Any
PHP version:  Irrelevant
Package:  Class/Object related
Bug Type: Bug
Bug description:class constant has different setter behavior than global 
constant

Description:

Global constants can be set using string concatenation and other global
constants. This is useful.



Class constants cannot be set using string concatenation or any functions,
although they can be set to a global constant, or another class constant.
The difference in setter behavior is confusing and limits utility of class
constants.

Test script:
---
define( 'FOO', 'foo' );

define( 'BAR', FOO . 'bar' );

echo BAR . PHP_EOL;



class Foobar {

  const foo = 'foo';

  const bar = self::foo . 'bar';

}

echo Foobar::bar;

Expected result:

foobar

foobar

Actual result:
--
Parse error: syntax error, unexpected '.', expecting ',' or ';' on line 8

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

Bug #51765 [Bgs]: class constant has different setter behavior than global constant

[colin at sheaff dot net]

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

 ID:   51765
 User updated by:  colin at sheaff dot net
 Reported by:  colin at sheaff dot net
 Summary:  class constant has different setter behavior than
   global constant
 Status:   Bogus
 Type: Bug
 Package:  Class/Object related
 Operating System: Any
 PHP Version:  Irrelevant

 New Comment:

And yet the following works:

define( 'FOO', 'foo' );

define( 'BAR', FOO . 'bar' );



class ThisWorks {

  const bar = BAR;

}



echo ThisWorks::bar;



If class constants are really compile time dependent, why is it ok to
set one to 

a global const value which is only evaluated at run time?


Previous Comments:

[2010-05-07 16:55:20] johan...@php.net

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 a limitation in the implementation. For the class constant we
need a constant value at compile time and can't evaluate expressions.
define() is a regular function, evaluated at run time and can therefore
contain any value of any form.



changing this would mean to add an execution phase in the compiler ...

----
[2010-05-07 15:17:53] colin at sheaff dot net

Description:

Global constants can be set using string concatenation and other global
constants. This is useful.



Class constants cannot be set using string concatenation or any
functions, although they can be set to a global constant, or another
class constant. The difference in setter behavior is confusing and
limits utility of class constants.

Test script:
---
define( 'FOO', 'foo' );

define( 'BAR', FOO . 'bar' );

echo BAR . PHP_EOL;



class Foobar {

  const foo = 'foo';

  const bar = self::foo . 'bar';

}

echo Foobar::bar;

Expected result:

foobar

foobar

Actual result:
--
Parse error: syntax error, unexpected '.', expecting ',' or ';' on line
8






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

Bug #51765 [Bgs]: class constant has different setter behavior than global constant

[colin at sheaff dot net]

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

 ID:   51765
 User updated by:  colin at sheaff dot net
 Reported by:  colin at sheaff dot net
 Summary:  class constant has different setter behavior than
   global constant
 Status:   Bogus
 Type: Bug
 Package:  Class/Object related
 Operating System: Any
 PHP Version:  Irrelevant

 New Comment:

In a more complicated example that shows how these dependencies are not
clear-cut, 

the following also works:



define( 'BAR', ThisWorks::foo . 'bar' );



class ThisWorks {

  const foo = 'foo';

  const bar = BAR;

}



echo ThisWorks::bar;



this will output 'foobar' without an error.


Previous Comments:
----
[2010-05-07 17:52:04] colin at sheaff dot net

And yet the following works:

define( 'FOO', 'foo' );

define( 'BAR', FOO . 'bar' );



class ThisWorks {

  const bar = BAR;

}



echo ThisWorks::bar;



If class constants are really compile time dependent, why is it ok to
set one to 

a global const value which is only evaluated at run time?


[2010-05-07 16:55:20] johan...@php.net

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 a limitation in the implementation. For the class constant we
need a constant value at compile time and can't evaluate expressions.
define() is a regular function, evaluated at run time and can therefore
contain any value of any form.



changing this would mean to add an execution phase in the compiler ...

----
[2010-05-07 15:17:53] colin at sheaff dot net

Description:

Global constants can be set using string concatenation and other global
constants. This is useful.



Class constants cannot be set using string concatenation or any
functions, although they can be set to a global constant, or another
class constant. The difference in setter behavior is confusing and
limits utility of class constants.

Test script:
---
define( 'FOO', 'foo' );

define( 'BAR', FOO . 'bar' );

echo BAR . PHP_EOL;



class Foobar {

  const foo = 'foo';

  const bar = self::foo . 'bar';

}

echo Foobar::bar;

Expected result:

foobar

foobar

Actual result:
--
Parse error: syntax error, unexpected '.', expecting ',' or ';' on line
8






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

Bug #51765 [Bgs]: class constant has different setter behavior than global constant

[colin at sheaff dot net]

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

 ID: 51765
 User updated by:colin at sheaff dot net
 Reported by:colin at sheaff dot net
 Summary:class constant has different setter behavior than
 global constant
 Status: Bogus
 Type:   Bug
 Package:Class/Object related
 Operating System:   Any
 PHP Version:Irrelevant
 Block user comment: N

 New Comment:

In your response, you wrote - 

For the class constant we need a constant value at compile time and
can't 

evaluate expressions. define() is a regular function, evaluated at run
time and 

can therefore contain any value of any form.



However, why then does the code example from 2010-05-07 15:57 UTC work?
This has 

a "compile time" class constant populated properly by a define() that is
only 

evaluated at run time with a string concatenation. By your definition,
this code 

should fail. Yet it doesn't, so I don't see how your explanation
actually makes 

sense.


Previous Comments:
----
[2010-05-07 17:57:38] colin at sheaff dot net

In a more complicated example that shows how these dependencies are not
clear-cut, 

the following also works:



define( 'BAR', ThisWorks::foo . 'bar' );



class ThisWorks {

  const foo = 'foo';

  const bar = BAR;

}



echo ThisWorks::bar;



this will output 'foobar' without an error.

----
[2010-05-07 17:52:04] colin at sheaff dot net

And yet the following works:

define( 'FOO', 'foo' );

define( 'BAR', FOO . 'bar' );



class ThisWorks {

  const bar = BAR;

}



echo ThisWorks::bar;



If class constants are really compile time dependent, why is it ok to
set one to 

a global const value which is only evaluated at run time?


[2010-05-07 16:55:20] johan...@php.net

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 a limitation in the implementation. For the class constant we
need a constant value at compile time and can't evaluate expressions.
define() is a regular function, evaluated at run time and can therefore
contain any value of any form.



changing this would mean to add an execution phase in the compiler ...


[2010-05-07 15:17:53] colin at sheaff dot net

Description:

Global constants can be set using string concatenation and other global
constants. This is useful.



Class constants cannot be set using string concatenation or any
functions, although they can be set to a global constant, or another
class constant. The difference in setter behavior is confusing and
limits utility of class constants.

Test script:
---
define( 'FOO', 'foo' );

define( 'BAR', FOO . 'bar' );

echo BAR . PHP_EOL;



class Foobar {

  const foo = 'foo';

  const bar = self::foo . 'bar';

}

echo Foobar::bar;

Expected result:

foobar

foobar

Actual result:
--
Parse error: syntax error, unexpected '.', expecting ',' or ';' on line
8






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

#34894 [NEW]: make install-pear-installer segfaults

[colin at viebrock dot ca]

From: colin at viebrock dot ca
Operating system: Linux 
PHP version:  5.1.0RC1
PHP Bug Type: CGI related
Bug description:  make install-pear-installer segfaults

Description:

make install fails, and it's the install-pear-installer 
section that causes it, but it seems to be due to a 
segfault in the CLI.

Configure line is:

# ./configure  --enable-cli --disable-cgi --prefix=/
home/cmv --enable-track-vars --disable-magic-quotes --
disable-debug --with-mysql=/usr/local --with-gettext --
with-xml --with-xmlrpc --with-dom-xslt --enable-xslt --
with-expat-dir=/usr --with-xslt-sablot --with-dom --
with-curl --with-zlib --with-mcrypt --enable-ftp

Reproduce code:
---
just running ./sapi/cli/php causes the segfault.

Actual result:
--
[EMAIL PROTECTED]:~/sources/php-5.1.0RC1$ gdb sapi/cli/php
GNU gdb 5.3-debian
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it 
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "i386-linux"...
(gdb) run -n -dsafe_mode=0 pear/install-pear.php pear/
package-*.xml
Starting program: /usr/local/home/cmv/sources/php
-5.1.0RC1/sapi/cli/php -n -dsafe_mode=0 pear/install-
pear.php pear/package-*.xml

Program received signal SIGSEGV, Segmentation fault.
0x081f2dad in _zend_hash_add_or_update (ht=0x8344ba0, 
arKey=0x829378c "sqlite", nKeyLength=6, 
pData=0xb9c0, 
nDataSize=4, pDest=0x0, flag=2) at /home/cmv/
sources/php-5.1.0RC1/Zend/zend_hash.c:213
213 p = ht->arBuckets[nIndex];
(gdb) bt
#0  0x081f2dad in _zend_hash_add_or_update 
(ht=0x8344ba0, arKey=0x829378c "sqlite", nKeyLength=6, 
pData=0xb9c0, 
nDataSize=4, pDest=0x0, flag=2) at /home/cmv/
sources/php-5.1.0RC1/Zend/zend_hash.c:213
#1  0x080ce25a in php_pdo_register_driver 
(driver=0x8332198) at /home/cmv/sources/php-5.1.0RC1/
ext/pdo/pdo.c:149
#2  0x080d6283 in zm_startup_pdo_sqlite (type=1, 
module_number=10)
at /home/cmv/sources/php-5.1.0RC1/ext/pdo_sqlite/
pdo_sqlite.c:80
#3  0x081f0517 in zend_startup_module_ex 
(module=0x83826f0) at /home/cmv/sources/php-5.1.0RC1/
Zend/zend_API.c:1280
#4  0x081f3d00 in zend_hash_apply (ht=0x834b480, 
apply_func=0x81f0414 )
at /home/cmv/sources/php-5.1.0RC1/Zend/zend_hash.c:
664
#5  0x081f061f in zend_startup_modules () at /home/cmv/
sources/php-5.1.0RC1/Zend/zend_API.c:1327
#6  0x081bcb5a in php_module_startup (sf=0x8343ac0, 
additional_modules=0x0, num_additional_modules=0)
at /home/cmv/sources/php-5.1.0RC1/main/main.c:1501
#7  0x0827db7e in main (argc=7, argv=0xbca4) at /
home/cmv/sources/php-5.1.0RC1/sapi/cli/php_cli.c:656

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

#34894 [Fbk->Opn]: make install-pear-installer segfaults

[colin at viebrock dot ca]

 ID:   34894
 User updated by:  colin at viebrock dot ca
 Reported By:  colin at viebrock dot ca
-Status:   Feedback
+Status:   Open
 Bug Type: CGI related
 Operating System: Linux
 PHP Version:  5.1.0RC1
 New Comment:

The new snap seems to fix that issue, however I now get 
the following messages on "make install"

[EMAIL PROTECTED]:~/sources/php5-200510171430$ make install
Installing PHP CLI binary:/home/cmv/bin/
Installing PHP CLI man page:  /home/cmv/man/man1/
Installing build environment: /home/cmv/lib/php/
build/
Installing header files:  /home/cmv/include/php/
Installing helper programs:   /home/cmv/bin/
  program: phpize
  program: php-config
Installing man pages: /home/cmv/man/man1/
  page: phpize.1
  page: php-config.1
Installing PEAR environment:  /home/cmv/lib/php/
--11:21:34--  http://pear.php.net/install-pear-
nozlib.phar
   => `/home/cmv/sources/php5-200510171430/pear/
install-pear-nozlib.phar'
Resolving pear.php.net... done.
Connecting to pear.php.net[216.92.131.66]:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 3,321,897 [text/plain]

100%[===
=>] 3,321,897179.37K/s
ETA 00:00

11:21:52 (179.37 KB/s) - `/home/cmv/sources/php5
-200510171430/pear/install-pear-nozlib.phar' saved 
[3321897/3321897]


Fatal error: Error: phar "/usr/local/home/cmv/sources/
php5-200510171430/pear/install-pear-nozlib.phar" 
Checksum error on entry "" in /usr/local/home/cmv/
sources/php5-200510171430/pear/install-pear-nozlib.phar 
on line 376
make[1]: *** [install-pear-installer] Error 255
make: *** [install-pear] Error 2


Previous Comments:


[2005-10-17 17:27:18] [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-10-17 17:25:36] colin at viebrock dot ca

Description:

make install fails, and it's the install-pear-installer 
section that causes it, but it seems to be due to a 
segfault in the CLI.

Configure line is:

# ./configure  --enable-cli --disable-cgi --prefix=/
home/cmv --enable-track-vars --disable-magic-quotes --
disable-debug --with-mysql=/usr/local --with-gettext --
with-xml --with-xmlrpc --with-dom-xslt --enable-xslt --
with-expat-dir=/usr --with-xslt-sablot --with-dom --
with-curl --with-zlib --with-mcrypt --enable-ftp

Reproduce code:
---
just running ./sapi/cli/php causes the segfault.

Actual result:
--
[EMAIL PROTECTED]:~/sources/php-5.1.0RC1$ gdb sapi/cli/php
GNU gdb 5.3-debian
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it 
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "i386-linux"...
(gdb) run -n -dsafe_mode=0 pear/install-pear.php pear/
package-*.xml
Starting program: /usr/local/home/cmv/sources/php
-5.1.0RC1/sapi/cli/php -n -dsafe_mode=0 pear/install-
pear.php pear/package-*.xml

Program received signal SIGSEGV, Segmentation fault.
0x081f2dad in _zend_hash_add_or_update (ht=0x8344ba0, 
arKey=0x829378c "sqlite", nKeyLength=6, 
pData=0xb9c0, 
nDataSize=4, pDest=0x0, flag=2) at /home/cmv/
sources/php-5.1.0RC1/Zend/zend_hash.c:213
213 p = ht->arBuckets[nIndex];
(gdb) bt
#0  0x081f2dad in _zend_hash_add_or_update 
(ht=0x8344ba0, arKey=0x829378c "sqlite", nKeyLength=6, 
pData=0xb9c0, 
nDataSize=4, pDest=0x0, flag=2) at /home/cmv/
sources/php-5.1.0RC1/Zend/zend_hash.c:213
#1  0x080ce25a in php_pdo_register_driver 
(driver=0x8332198) at /home/cmv/sources/php-5.1.0RC1/
ext/pdo/pdo.c:149
#2  0x080d6283 in zm_startup_pdo_sqlite (type=1, 
module_number=10)
at /home/cmv/sources/php-5.1.0RC1/ext/pdo_sqlite/
pdo_sqlite.c:80
#3  0x081f0517 in zend_startup_module_ex 
(module=0x83826f0) at /home/cmv/sources/php-5.1.0RC1/
Zend/zend_API.c:1280
#4  0x081f3d00 in zend_hash_apply (ht=0x834b480, 
apply_func=0x81f0414 )
at /home/cmv/sources/php-5.1.0RC1/Zend/zend_hash.c:
664
#5  0x081f061f in zend_startup_modules () at /home/cmv/
sources/php-5.1.0RC1/Zend/zend_API.c:1327
#6  0x081bcb5a in php_module_startup (sf=0x8343ac0, 
additional_modules=0x0, num_additional_modules=0)
at /home/cmv/sources/php-5.1.0RC1/main/main.c:1501
#7  0x0827db7e in main (argc=7, argv=0xbca4) at /
home/cmv/sources/php-5.1.0RC1/sapi/cli/php_cli.c:656





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

#34563 [NEW]: use of indexer on function return value

[colin at breame dot net]

From: colin at breame dot net
Operating system: 
PHP version:  5.0.5
PHP Bug Type: Compile Failure
Bug description:  use of indexer on function return value

Description:

When using an indexer on a return value of a function, the
compiler returns an error:

parse error, unexpected '['

I would expect it to compile as it would be a valid
expression. 

Reproduce code:
---
Does not compile:
1);
}
?>

Does compile:
1);
}
?>

Expected result:

 

Actual result:
--
PHP Parse error:  parse error, unexpected '[' in test.php 
on line 2 
 

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

#33571 [NEW]: PHPIniDir directive appears to be ignored

[colin at encode dot net dot au]

From: colin at encode dot net dot au
Operating system: Windows XP Professional SP2
PHP version:  5.1.0b2
PHP Bug Type: Apache2 related
Bug description:  PHPIniDir directive appears to be ignored

Description:

Hello,

I understand this is a beta version of PHP but felt I should report that
it appears the PHPIniDir Apache configuration directive is ignored by this
release of PHP.  I installed PHP according to the install.txt instructions
and configured the httpd.conf of Apache 2.0.54 using the directives
below:

#
# Load PHP5 module:
#
LoadModule php5_module "C:/PHP/php5apache2.dll"

#
# To use PHP scripts:
#
AddType application/x-httpd-php .php

#
# Define php.ini path:
#
PHPIniDir "C:/PHP"

To begin with I renamed the "php.ini-recommended" file to "php.ini" within
the "C:/PHP" folder.  PHP would not load correctly however, and upon
accessing a phpinfo test page within the browser I would receive the PHP
code itself within the browser window, i.e:



...would appear in the page source.  I also tried adding the PHP path to
the "path" and "PHPRC" environment variables with no success.  Upon
removing the php.ini from "C:/PHP", PHP appeared to load but would report
"C:\WINDOWS" in the "Configuration File (php.ini) Path" field of the
phpinfo() output.  Note, there is no php.ini file in "C:\WINDOWS".


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

#33571 [Bgs->Opn]: PHPIniDir directive appears to be ignored

[colin at encode dot net dot au]

 ID:   33571
 User updated by:  colin at encode dot net dot au
 Reported By:  colin at encode dot net dot au
-Status:   Bogus
+Status:   Open
 Bug Type: Apache2 related
 Operating System: Windows XP Professional SP2
 PHP Version:  5.1.0b2
 New Comment:

Hello Derick,

Since I just followed the same installation process with PHP 5.0.4, and
it *worked* as expected, I would say that this does imply a bug in PHP
5.1.0b2, wouldn't you agree?

Regards,

Colin.


Previous Comments:


[2005-07-05 09:14:57] [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.

.



[2005-07-05 03:09:21] colin at encode dot net dot au

Description:

Hello,

I understand this is a beta version of PHP but felt I should report
that it appears the PHPIniDir Apache configuration directive is ignored
by this release of PHP.  I installed PHP according to the install.txt
instructions and configured the httpd.conf of Apache 2.0.54 using the
directives below:

#
# Load PHP5 module:
#
LoadModule php5_module "C:/PHP/php5apache2.dll"

#
# To use PHP scripts:
#
AddType application/x-httpd-php .php

#
# Define php.ini path:
#
PHPIniDir "C:/PHP"

To begin with I renamed the "php.ini-recommended" file to "php.ini"
within the "C:/PHP" folder.  PHP would not load correctly however, and
upon accessing a phpinfo test page within the browser I would receive
the PHP code itself within the browser window, i.e:



...would appear in the page source.  I also tried adding the PHP path
to the "path" and "PHPRC" environment variables with no success.  Upon
removing the php.ini from "C:/PHP", PHP appeared to load but would
report "C:\WINDOWS" in the "Configuration File (php.ini) Path" field of
the phpinfo() output.  Note, there is no php.ini file in "C:\WINDOWS".






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

#25767 [NEW]: Apache will not start with PHP Modules

[colin dot harford at ualberta dot ca]

From: colin dot harford at ualberta dot ca
Operating system: OpenBSD -current
PHP version:  4.3.4RC1
PHP Bug Type: *General Issues
Bug description:  Apache will not start with PHP Modules

Description:

Machine Information:

# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd3.4/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease, propolice)

i386 running OpenBSD with Apache 2.0.47.

I have the same problem with PHP-4.3.3 and PHP-4.3.4-RC1

PHP is compiled with:  ./configure --enable-sockets
--with-mysql=/opt/db/mysql/ --with-apxs2=/opt/apache2/bin/apxs


What happens, is that when I have the lines:
LoadModule php4_modulemodules/libphp4.so
AddType application/x-httpd-php .php
 
in my httpd.conf.  If the lines are uncommented, apache will start.

I changed apache debug level to debug, however, there is no errors on
screen or in the error_log.  

I have tried both php.ini-dist and php.ini-recommended.   Neither of which
have any effect on it.

What I was expecting quite simply is for apache and php to load.  I have
rebuilt apache and php to new locations as well, ran make distcleans
before doing the installs.  



Thanks,


CH


FYI only with snapshost:

I tried to compile the snapshot, but run into errors with that.  FYI only,
it is:

(external!/opt/php4-200310061730)
# make
/bin/sh /opt/php4-200310061730/libtool --silent --preserve-dup-deps
--mode=link gcc -export-dynamic -g -O2  -avoid-version -module
-L/opt/db/mysql//lib/mysql  -R /opt/db/mysql//lib/mysql ext/ctype/ctype.lo
ext/mysql/php_mysql.lo ext/overload/overload.lo
ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo
ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo
ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo
ext/session/mod_mm.lo ext/session/mod_user.lo ext/sockets/sockets.lo
ext/standard/array.lo ext/standard/base64.lo
ext/standard/basic_functions.lo ext/standard/browscap.lo
ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo
ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo
ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo
ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo
ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo
ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo
ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo
ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo
ext/standard/pageinfo.lo ext/standard/parsedate.lo
ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo
ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo
ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo
ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo
ext/standard/versioning.lo ext/standard/assert.lo
ext/standard/strnatcmp.lo ext/standard/levenshtein.lo
ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo
ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo
ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo
ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo
ext/standard/aggregation.lo ext/standard/sha1.lo
ext/tokenizer/tokenizer.lo ext/xml/xml.lo ext/xml/expat/xmlparse.lo
ext/xml/expat/xmlrole.lo ext/xml/expat/xmltok.lo regex/regcomp.lo
regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo
TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo
main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo
main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo main/php_ini.lo
main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo
main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo
main/php_ticks.lo main/streams.lo main/network.lo
main/php_open_temporary_file.lo main/php_logos.lo main/output.lo
main/memory_streams.lo main/user_streams.lo Zend/zend_language_parser.lo
Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo
Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo
Zend/zend_constants.lo Zend/zend_dynamic_array.lo Zend/zend_execute_API.lo
Zend/zend_highlight.lo Zend/zend_llist.lo Zend/zend_opcode.lo
Zend/zend_operators.lo Zend/zend_ptr_stack.lo Zend/zend_stack.lo
Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo
Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo
Zend/zend_indent.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo
Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo
Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo
main/internal_functions_cli.lo -lmysqlclient -lm  -o sapi/cli/php
ext/standard/filestat.lo: In function `php_stat':
/opt/php4-200310061730/ext/standard/filestat.c:575: undefined reference to
`php_check_open_basedir_ex'
collect2: ld returned 1 exit status
*** Error code 1

Stop in /opt/php4-200310061730 (line 169 o

#25767 [Opn]: Apache will not start with PHP Modules

[colin dot harford at ualberta dot ca]

 ID:   25767
 User updated by:  colin dot harford at ualberta dot ca
 Reported By:  colin dot harford at ualberta dot ca
 Status:   Open
 Bug Type: *General Issues
 Operating System: OpenBSD -current
 PHP Version:  4.3.4RC1
 New Comment:

Errr. The line:

in my httpd.conf.  If the lines are uncommented, apache will start.


should be:

in my httpd.conf.  If the lines are uncommented, apache will NOT
start.

Sorry for any confusion.


CH


Previous Comments:


[2003-10-06 15:00:37] colin dot harford at ualberta dot ca

Description:

Machine Information:

# gcc -v
Reading specs from
/usr/lib/gcc-lib/i386-unknown-openbsd3.4/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease, propolice)

i386 running OpenBSD with Apache 2.0.47.

I have the same problem with PHP-4.3.3 and PHP-4.3.4-RC1

PHP is compiled with:  ./configure --enable-sockets
--with-mysql=/opt/db/mysql/ --with-apxs2=/opt/apache2/bin/apxs


What happens, is that when I have the lines:
LoadModule php4_modulemodules/libphp4.so
AddType application/x-httpd-php .php
 
in my httpd.conf.  If the lines are uncommented, apache will start.

I changed apache debug level to debug, however, there is no errors on
screen or in the error_log.  

I have tried both php.ini-dist and php.ini-recommended.   Neither of
which have any effect on it.

What I was expecting quite simply is for apache and php to load.  I
have rebuilt apache and php to new locations as well, ran make
distcleans before doing the installs.  



Thanks,


CH


FYI only with snapshost:

I tried to compile the snapshot, but run into errors with that.  FYI
only, it is:

(external!/opt/php4-200310061730)
# make
/bin/sh /opt/php4-200310061730/libtool --silent --preserve-dup-deps
--mode=link gcc -export-dynamic -g -O2  -avoid-version -module
-L/opt/db/mysql//lib/mysql  -R /opt/db/mysql//lib/mysql
ext/ctype/ctype.lo ext/mysql/php_mysql.lo ext/overload/overload.lo
ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo
ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo
ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo
ext/session/mod_mm.lo ext/session/mod_user.lo ext/sockets/sockets.lo
ext/standard/array.lo ext/standard/base64.lo
ext/standard/basic_functions.lo ext/standard/browscap.lo
ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo
ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo
ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo
ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo
ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo
ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo
ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo
ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo
ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo
ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo
ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo
ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo
ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo
ext/standard/versioning.lo ext/standard/assert.lo
ext/standard/strnatcmp.lo ext/standard/levenshtein.lo
ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo
ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo
ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo
ext/standard/css.lo ext/standard/var_unserializer.lo
ext/standard/ftok.lo ext/standard/aggregation.lo ext/standard/sha1.lo
ext/tokenizer/tokenizer.lo ext/xml/xml.lo ext/xml/expat/xmlparse.lo
ext/xml/expat/xmlrole.lo ext/xml/expat/xmltok.lo regex/regcomp.lo
regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo
TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo
main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo
main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo
main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo
main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo
main/php_variables.lo main/php_ticks.lo main/streams.lo main/network.lo
main/php_open_temporary_file.lo main/php_logos.lo main/output.lo
main/memory_streams.lo main/user_streams.lo
Zend/zend_language_parser.lo Zend/zend_language_scanner.lo
Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo
Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo
Zend/zend_execute_API.lo Zend/zend_highlight.lo Zend/zend_llist.lo
Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_stack.lo
Zend/zend_stack.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo
Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo
Zend/zend_indent.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo
Zend/zend_ini.lo Zend

#25767 [Fbk->Opn]: Apache will not start with PHP Modules

[colin dot harford at ualberta dot ca]

 ID:   25767
 User updated by:  colin dot harford at ualberta dot ca
 Reported By:  colin dot harford at ualberta dot ca
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: OpenBSD -current
 PHP Version:  4.3.4RC1
 New Comment:

Installed the new snapshot... Installs fine...

Apache still won't start

(gw!/opt/apache2/bin) [root-ttyp3]
# gdb httpd 
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it 
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "i386-unknown-openbsd3.4"...
(gdb) r -DONE_PROCESS
Starting program: /opt/apache2/bin/httpd -DONE_PROCESS

Program exited with code 04.


CH


Previous Comments:


[2003-10-06 18:25:12] [EMAIL PROTECTED]

Use this snapshot, and EXACTLY this one: 
http://snaps.php.net/php4-STABLE-latest.tar.gz

And make sure those 2 lines are the 2 LAST lines in your httpd.conf.

If this still fails, start apache in gdb:

# gdb httpd
(gdb) r -DONE_PROCESS

Then you might see more what's going on.


----

[2003-10-06 15:00:37] colin dot harford at ualberta dot ca

Description:

Machine Information:

# gcc -v
Reading specs from
/usr/lib/gcc-lib/i386-unknown-openbsd3.4/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease, propolice)

i386 running OpenBSD with Apache 2.0.47.

I have the same problem with PHP-4.3.3 and PHP-4.3.4-RC1

PHP is compiled with:  ./configure --enable-sockets
--with-mysql=/opt/db/mysql/ --with-apxs2=/opt/apache2/bin/apxs


What happens, is that when I have the lines:
LoadModule php4_modulemodules/libphp4.so
AddType application/x-httpd-php .php
 
in my httpd.conf.  If the lines are uncommented, apache will start.

I changed apache debug level to debug, however, there is no errors on
screen or in the error_log.  

I have tried both php.ini-dist and php.ini-recommended.   Neither of
which have any effect on it.

What I was expecting quite simply is for apache and php to load.  I
have rebuilt apache and php to new locations as well, ran make
distcleans before doing the installs.  



Thanks,


CH


FYI only with snapshost:

I tried to compile the snapshot, but run into errors with that.  FYI
only, it is:

(external!/opt/php4-200310061730)
# make
/bin/sh /opt/php4-200310061730/libtool --silent --preserve-dup-deps
--mode=link gcc -export-dynamic -g -O2  -avoid-version -module
-L/opt/db/mysql//lib/mysql  -R /opt/db/mysql//lib/mysql
ext/ctype/ctype.lo ext/mysql/php_mysql.lo ext/overload/overload.lo
ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo
ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo
ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo
ext/session/mod_mm.lo ext/session/mod_user.lo ext/sockets/sockets.lo
ext/standard/array.lo ext/standard/base64.lo
ext/standard/basic_functions.lo ext/standard/browscap.lo
ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo
ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo
ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo
ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo
ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo
ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo
ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo
ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo
ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo
ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo
ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo
ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo
ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo
ext/standard/versioning.lo ext/standard/assert.lo
ext/standard/strnatcmp.lo ext/standard/levenshtein.lo
ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo
ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo
ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo
ext/standard/css.lo ext/standard/var_unserializer.lo
ext/standard/ftok.lo ext/standard/aggregation.lo ext/standard/sha1.lo
ext/tokenizer/tokenizer.lo ext/xml/xml.lo ext/xml/expat/xmlparse.lo
ext/xml/expat/xmlrole.lo ext/xml/expat/xmltok.lo regex/regcomp.lo
regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo
TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo
main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo
main/fopen_wrappers.lo main/alloca.lo main/php_scan

#25767 [Fbk->Opn]: Apache will not start with PHP Modules

[colin dot harford at ualberta dot ca]

 ID:   25767
 User updated by:  colin dot harford at ualberta dot ca
 Reported By:  colin dot harford at ualberta dot ca
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: OpenBSD -current
 PHP Version:  4.3.4RC1
 New Comment:

There is nothing in /var/log: I set syslog to log 
everything to /var/log/all as well as everywhere else, 
and nothing was placed there.


I can't run strace, as it doesn't exist for OpenBSD.  
However, I did run a ktrace, which is similar ktrace ./
httpd -X -DONE_PROCESS.  The kdump of it is quite long, 
so I placed it on: http://www.ualberta.ca/~charford/
log.txt

Thanks,


CH


Previous Comments:


[2003-10-06 21:18:36] [EMAIL PROTECTED]

you should also try strace on httpd:

# strace httpd -X -DONE_PROCESS 

You can then see where it bails out.




[2003-10-06 21:16:40] [EMAIL PROTECTED]

Are you sure the error is not outputted elsewhere, like syslog?





[2003-10-06 19:05:13] colin dot harford at ualberta dot ca

Installed the new snapshot... Installs fine...

Apache still won't start

(gw!/opt/apache2/bin) [root-ttyp3]
# gdb httpd 
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it 
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "i386-unknown-openbsd3.4"...
(gdb) r -DONE_PROCESS
Starting program: /opt/apache2/bin/httpd -DONE_PROCESS

Program exited with code 04.


CH



[2003-10-06 18:25:12] [EMAIL PROTECTED]

Use this snapshot, and EXACTLY this one: 
http://snaps.php.net/php4-STABLE-latest.tar.gz

And make sure those 2 lines are the 2 LAST lines in your httpd.conf.

If this still fails, start apache in gdb:

# gdb httpd
(gdb) r -DONE_PROCESS

Then you might see more what's going on.


----

[2003-10-06 15:00:37] colin dot harford at ualberta dot ca

Description:

Machine Information:

# gcc -v
Reading specs from
/usr/lib/gcc-lib/i386-unknown-openbsd3.4/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease, propolice)

i386 running OpenBSD with Apache 2.0.47.

I have the same problem with PHP-4.3.3 and PHP-4.3.4-RC1

PHP is compiled with:  ./configure --enable-sockets
--with-mysql=/opt/db/mysql/ --with-apxs2=/opt/apache2/bin/apxs


What happens, is that when I have the lines:
LoadModule php4_modulemodules/libphp4.so
AddType application/x-httpd-php .php
 
in my httpd.conf.  If the lines are uncommented, apache will start.

I changed apache debug level to debug, however, there is no errors on
screen or in the error_log.  

I have tried both php.ini-dist and php.ini-recommended.   Neither of
which have any effect on it.

What I was expecting quite simply is for apache and php to load.  I
have rebuilt apache and php to new locations as well, ran make
distcleans before doing the installs.  



Thanks,


CH


FYI only with snapshost:

I tried to compile the snapshot, but run into errors with that.  FYI
only, it is:

(external!/opt/php4-200310061730)
# make
/bin/sh /opt/php4-200310061730/libtool --silent --preserve-dup-deps
--mode=link gcc -export-dynamic -g -O2  -avoid-version -module
-L/opt/db/mysql//lib/mysql  -R /opt/db/mysql//lib/mysql
ext/ctype/ctype.lo ext/mysql/php_mysql.lo ext/overload/overload.lo
ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo
ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo
ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo
ext/session/mod_mm.lo ext/session/mod_user.lo ext/sockets/sockets.lo
ext/standard/array.lo ext/standard/base64.lo
ext/standard/basic_functions.lo ext/standard/browscap.lo
ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo
ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo
ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo
ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo
ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo
ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo
ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo
ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo
ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo
ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo
ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.

#25767 [Fbk->Opn]: Apache will not start with PHP Modules

[colin dot harford at ualberta dot ca]

 ID:   25767
 User updated by:  colin dot harford at ualberta dot ca
 Reported By:  colin dot harford at ualberta dot ca
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: OpenBSD -current
 PHP Version:  4.3.4RC1
 New Comment:

(gw!/opt/apache2/modules) [root-ttyp2]
# ldd libphp4.so
libphp4.so:
libphp4.so: Exec format error
libphp4.so: exit status 1


h.


CH


Previous Comments:


[2003-10-07 04:04:16] [EMAIL PROTECTED]

Not sure but I think it's just missing path in LD_LIBRARY_PATH..check
what this outputs:

# ldd libphp4.so




[2003-10-06 21:50:27] colin dot harford at ualberta dot ca

There is nothing in /var/log: I set syslog to log 
everything to /var/log/all as well as everywhere else, 
and nothing was placed there.


I can't run strace, as it doesn't exist for OpenBSD.  
However, I did run a ktrace, which is similar ktrace ./
httpd -X -DONE_PROCESS.  The kdump of it is quite long, 
so I placed it on: http://www.ualberta.ca/~charford/
log.txt

Thanks,


CH



[2003-10-06 21:18:36] [EMAIL PROTECTED]

you should also try strace on httpd:

# strace httpd -X -DONE_PROCESS 

You can then see where it bails out.




[2003-10-06 21:16:40] [EMAIL PROTECTED]

Are you sure the error is not outputted elsewhere, like syslog?





[2003-10-06 19:05:13] colin dot harford at ualberta dot ca

Installed the new snapshot... Installs fine...

Apache still won't start

(gw!/opt/apache2/bin) [root-ttyp3]
# gdb httpd 
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it 
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "i386-unknown-openbsd3.4"...
(gdb) r -DONE_PROCESS
Starting program: /opt/apache2/bin/httpd -DONE_PROCESS

Program exited with code 04.


CH



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

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

#25767 [Opn]: Apache will not start with PHP Modules

[colin dot harford at ualberta dot ca]

 ID:   25767
 User updated by:  colin dot harford at ualberta dot ca
 Reported By:  colin dot harford at ualberta dot ca
 Status:   Open
 Bug Type: Apache2 related
 Operating System: OpenBSD -current
 PHP Version:  4.3.4RC1
 New Comment:

# objdump -p libphp4.so

libphp4.so: file format elf32-i386

Program Header:
LOAD off0x vaddr 0x paddr 0x align
2**12
 filesz 0x000fc450 memsz 0x000fc450 flags r-x
LOAD off0x000fd000 vaddr 0x2000 paddr 0x2000 align
2**12
 filesz 0x000274e0 memsz 0x000274e0 flags r--
LOAD off0x001244e0 vaddr 0x200284e0 paddr 0x200284e0 align
2**12
 filesz 0xd248 memsz 0xd248 flags rw-
LOAD off0x00131728 vaddr 0x20036728 paddr 0x20036728 align
2**12
 filesz 0x1408 memsz 0x1408 flags rw-
LOAD off0x00132b30 vaddr 0x20038b30 paddr 0x20038b30 align
2**12
 filesz 0x0088 memsz 0x5024 flags rw-
 DYNAMIC off0x00132b30 vaddr 0x20038b30 paddr 0x20038b30 align
2**2
 filesz 0x0088 memsz 0x0088 flags rw-

Dynamic Section:
  NEEDED  libmysqlclient.so.12.0
  NEEDED  libm.so.1.0
  INIT0x24770
  FINI0x247a0
  HASH0x134
  STRTAB  0xc998
  SYMTAB  0x42f8
  STRSZ   0x93e8
  SYMENT  0x10
  PLTGOT  0x20036728
  PLTRELSZ0x2210
  PLTREL  0x11
  JMPREL  0x1e098
  REL 0x15d80
  RELSZ   0x8318
  RELENT  0x8



I have put up the config.log from that STABLE-snapshot at 

http://www.ualberta.ca/~charford/config.log


Previous Comments:


[2003-10-07 11:00:56] colin dot harford at ualberta dot ca

(gw!/opt/apache2/modules) [root-ttyp2]
# ldd libphp4.so
libphp4.so:
libphp4.so: Exec format error
libphp4.so: exit status 1


h.


CH



[2003-10-07 04:04:16] [EMAIL PROTECTED]

Not sure but I think it's just missing path in LD_LIBRARY_PATH..check
what this outputs:

# ldd libphp4.so




[2003-10-06 21:50:27] colin dot harford at ualberta dot ca

There is nothing in /var/log: I set syslog to log 
everything to /var/log/all as well as everywhere else, 
and nothing was placed there.


I can't run strace, as it doesn't exist for OpenBSD.  
However, I did run a ktrace, which is similar ktrace ./
httpd -X -DONE_PROCESS.  The kdump of it is quite long, 
so I placed it on: http://www.ualberta.ca/~charford/
log.txt

Thanks,


CH



[2003-10-06 21:18:36] [EMAIL PROTECTED]

you should also try strace on httpd:

# strace httpd -X -DONE_PROCESS 

You can then see where it bails out.




[2003-10-06 21:16:40] [EMAIL PROTECTED]

Are you sure the error is not outputted elsewhere, like syslog?





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

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

#25767 [Fbk->Csd]: Apache will not start with PHP Modules

[colin dot harford at ualberta dot ca]

 ID:   25767
 User updated by:  colin dot harford at ualberta dot ca
 Reported By:  colin dot harford at ualberta dot ca
-Status:   Feedback
+Status:   Closed
 Bug Type: Apache2 related
 Operating System: OpenBSD -current
 PHP Version:  4.3.4RC1
 New Comment:

In my rc.conf:

shlib_dirs=/opt/db/mysql/lib/mysql/ 
# extra directories for ldconfig, separated
# by space


# ldconfig -r | grep mysql
search directories: /usr/lib:/usr/X11R6/lib:/
usr/local/lib:/opt/db/mysql/lib/mysql:/opt/apache2/lib:/
opt/php-4.3.3/libs:/opt/php-4.3.4RC1/libs:/opt/php4-
STABLE-200310062130/libs

Which I thought was odd, as I know that mysql was 
working so I did an 

ldconfig -R ldconfig -R /opt/db/mysql /opt/db/mysql/lib/
mysql/

Then when I did a:

# ldconfig -r | grep mysql
search directories: /usr/lib:/usr/X11R6/lib:/
usr/local/lib:/opt/apache2/lib:/opt/php-4.3.3/libs:/opt/
php-4.3.4RC1/libs:/opt/php4-STABLE-200310062130/libs:/
opt/db/mysql/lib:/opt/db/mysql/lib/mysql
130:-lmysqlclient.12.0 => /opt/db/mysql/lib/
mysql/libmysqlclient.so.12.0c

Then, I tried to start apache, and ran into some errors 
about not enough space, which I traced to some 
semaphores still in use by apache.  Killing them off I 
was able to start apache and php works.


Thanks for your help.


CH


FYI:

ldd still comes up like:

# ldd libphp4.so 
libphp4.so:
libphp4.so: Exec format error
libphp4.so: exit status 1


Previous Comments:


[2003-10-07 19:01:44] [EMAIL PROTECTED]

Is the path to that mysql lib in your LD_LIBRARY_PATH or not?





[2003-10-07 16:23:13] colin dot harford at ualberta dot ca

# objdump -p libphp4.so

libphp4.so: file format elf32-i386

Program Header:
LOAD off0x vaddr 0x paddr 0x align
2**12
 filesz 0x000fc450 memsz 0x000fc450 flags r-x
LOAD off0x000fd000 vaddr 0x2000 paddr 0x2000 align
2**12
 filesz 0x000274e0 memsz 0x000274e0 flags r--
LOAD off0x001244e0 vaddr 0x200284e0 paddr 0x200284e0 align
2**12
 filesz 0xd248 memsz 0xd248 flags rw-
LOAD off0x00131728 vaddr 0x20036728 paddr 0x20036728 align
2**12
 filesz 0x1408 memsz 0x1408 flags rw-
LOAD off0x00132b30 vaddr 0x20038b30 paddr 0x20038b30 align
2**12
 filesz 0x0088 memsz 0x5024 flags rw-
 DYNAMIC off0x00132b30 vaddr 0x20038b30 paddr 0x20038b30 align
2**2
 filesz 0x0088 memsz 0x0088 flags rw-

Dynamic Section:
  NEEDED  libmysqlclient.so.12.0
  NEEDED  libm.so.1.0
  INIT0x24770
  FINI0x247a0
  HASH0x134
  STRTAB  0xc998
  SYMTAB  0x42f8
  STRSZ   0x93e8
  SYMENT  0x10
  PLTGOT  0x20036728
  PLTRELSZ0x2210
  PLTREL  0x11
  JMPREL  0x1e098
  REL 0x15d80
  RELSZ   0x8318
  RELENT  0x8



I have put up the config.log from that STABLE-snapshot at 

http://www.ualberta.ca/~charford/config.log



[2003-10-07 11:00:56] colin dot harford at ualberta dot ca

(gw!/opt/apache2/modules) [root-ttyp2]
# ldd libphp4.so
libphp4.so:
libphp4.so: Exec format error
libphp4.so: exit status 1


h.


CH



[2003-10-07 04:04:16] [EMAIL PROTECTED]

Not sure but I think it's just missing path in LD_LIBRARY_PATH..check
what this outputs:

# ldd libphp4.so




[2003-10-06 21:50:27] colin dot harford at ualberta dot ca

There is nothing in /var/log: I set syslog to log 
everything to /var/log/all as well as everywhere else, 
and nothing was placed there.


I can't run strace, as it doesn't exist for OpenBSD.  
However, I did run a ktrace, which is similar ktrace ./
httpd -X -DONE_PROCESS.  The kdump of it is quite long, 
so I placed it on: http://www.ualberta.ca/~charford/
log.txt

Thanks,


CH



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

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

#30350 [NEW]: Returning reference to array element produces strange result

[colin at encode dot net dot au]

From: colin at encode dot net dot au
Operating system: Windows XP Pro SP2
PHP version:  5.0.2
PHP Bug Type: Arrays related
Bug description:  Returning reference to array element produces strange result

Description:

I'm not entirely sure if this is a bug or not, but it seems very odd
nonetheless.  I have an array of attributes as a protected class property,
and some simple functions to manipulate this array:

attributes = array();
   }

   public function setAttribute($name=null,$value=null)
   {
  $this->attributes[$name] = $value;
   }

   public function getAttribute($name=null)
   {
  return $this->attributes[$name];
   }
}

$test = new Test();

$test->setAttribute('foo','bar');
$test->setAttribute('omg','bbq');

echo $test->getAttribute('foo');
echo $test->getAttribute('eep');

print_r($test);

?>

Upon executing this code we should define two elements in the attributes
array, show the output of one, then generate a notice error because the
index 'eep' does not exist, and then receive a dump of the $test object,
which should look like this:

Test Object
(
[attributes:protected] => Array
(
[foo] => bar
[omg] => bbq
)

)

This is all fine and to be expected.  Now typically with code like this in
PHP4, I would have used an ampersand in front of the getAttribute function
definition to allow a reference to an attribute array element to be
returned.  To my understanding only objects are *always* passed around by
reference in PHP5, everything else is still copied (though I may be
wrong), so that would seem to imply to me that we still need the ampersand
to allow a reference to be returned.  So let's see what happens when we put
an ampersand in front of the getAttribute function definition above, like
so:

public function &getAttribute($name=null)
{
   return $this->attributes[$name];
}

Ok, upon execution now, I receive *no* notice error that the index 'eep'
does not exist - instead, a new null element is added to the array mapped
to the key 'eep'.  The print_r($test) now shows:

Test Object
(
[attributes:protected] => Array
(
[foo] => bar
[omg] => bbq
[eep] => 
)

)

What gives?  Am I doing something really stupid?  I don't understand this.


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

#30350 [Opn->Bgs]: Returning reference to array element produces strange result

[colin at encode dot net dot au]

 ID:   30350
 User updated by:  colin at encode dot net dot au
 Reported By:  colin at encode dot net dot au
-Status:   Open
+Status:   Bogus
 Bug Type: Arrays related
 Operating System: Windows XP Pro SP2
 PHP Version:  5.0.2
 New Comment:

Ok, it appears that the element is created because we are attempting to
return a reference to something that does not exist.  Updating status. 
:)


Previous Comments:


[2004-10-07 05:26:07] colin at encode dot net dot au

Description:

I'm not entirely sure if this is a bug or not, but it seems very odd
nonetheless.  I have an array of attributes as a protected class
property, and some simple functions to manipulate this array:

attributes = array();
   }

   public function setAttribute($name=null,$value=null)
   {
  $this->attributes[$name] = $value;
   }

   public function getAttribute($name=null)
   {
  return $this->attributes[$name];
   }
}

$test = new Test();

$test->setAttribute('foo','bar');
$test->setAttribute('omg','bbq');

echo $test->getAttribute('foo');
echo $test->getAttribute('eep');

print_r($test);

?>

Upon executing this code we should define two elements in the
attributes array, show the output of one, then generate a notice error
because the index 'eep' does not exist, and then receive a dump of the
$test object, which should look like this:

Test Object
(
[attributes:protected] => Array
(
[foo] => bar
[omg] => bbq
)

)

This is all fine and to be expected.  Now typically with code like this
in PHP4, I would have used an ampersand in front of the getAttribute
function definition to allow a reference to an attribute array element
to be returned.  To my understanding only objects are *always* passed
around by reference in PHP5, everything else is still copied (though I
may be wrong), so that would seem to imply to me that we still need the
ampersand to allow a reference to be returned.  So let's see what
happens when we put an ampersand in front of the getAttribute function
definition above, like so:

public function &getAttribute($name=null)
{
   return $this->attributes[$name];
}

Ok, upon execution now, I receive *no* notice error that the index
'eep' does not exist - instead, a new null element is added to the
array mapped to the key 'eep'.  The print_r($test) now shows:

Test Object
(
[attributes:protected] => Array
(
[foo] => bar
[omg] => bbq
[eep] => 
)

)

What gives?  Am I doing something really stupid?  I don't understand
this.






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

#30712 [NEW]: Error Message

[Colin at wnds dot co dot uk]

From: Colin at wnds dot co dot uk
Operating system: Windows server 200
PHP version:  4.3.9
PHP Bug Type: *Web Server problem
Bug description:  Error Message

Description:

Hi

I am getting the following error on my site and no one know what it means,
can you help?

PHP has encountered an Access Violation at 77F470FE

It happens when customers follow links to next page, but only happens 1 in
10 times.

Regards

Colin



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

#50027 [NEW]: $this becomes a non-object

[phpbugs at colin dot guthr dot ie]

From: phpbugs at colin dot guthr dot ie
Operating system: Mandriva Linux (Cooker x86_64)
PHP version:  5.3.1RC2
PHP Bug Type: Reproducible crash
Bug description:  $this becomes a non-object

Description:

This is a really hard bug to reproduce (e.g. build a simple test case) but
I can reliably do so here with my application. I'll attempt to describe the
problem in depth, although I warn in advance that it's a bit of a confusing
one.

During a particular request, PHP seems to corrupt itself quite badly which
cases $this to become corrupted within an object.

When this happens, is_object($this) still returns true, but any attempt to
access a member variable (e.g. $this->mFuncs) will result in the "Notice:
Trying to get property of non-object" warning. Similar warning exist when
trying to call methods etc.

Once this corruption happens, it will remain until the Apache process is
restarted (mpm-prefork) although some requests will succeed (I presume it
depends what mpm-preforked httpd handler is used?). When this happens, a
much simpler test case (which I'll link to) fails also (i.e. it seems that
the initial trigger of this causes it to continue, but the simpler test
case itself does not seem enough to trigger it initially).

The trigger case I have is a rather complex Zend Framework application
that I sadly cannot share.

I have confirmed this problem is present on 5.3.0 and 5.3.1RC2, so I
suspect it's a 5.3.x problem over all. I cannot reproduce the problem on
5.2.11.

All builds use -O0 for optimisations (as higher values have proven to
cause problems, particularly on x86_64).

Reproduce code:
---
A tarball containing three PHP files: one a UniversalAutoloader structure
we use in our projects (it predates spl stuff and actually gives us a
different fallback mechanism anyway), and a simple test class that is meant
to be autoloaded. Then the test.php file which actually exhibits the bug.

As noted previously however, this test case only *exhibits* this bug if
the problem is triggered already by some other code. You can see from the
backtrace.txt the effect of it failing. I provide this in the hope that it
allows something obvious to jump out at you, but I suspect the problem is
really some form of stack frame corruption or similar (possibly due to
x86_64 as I've not tested to see if it affects 5.3.1 although I will be
able to do so in the coming weeks).

The URL for this bundle is: http://colin.guthr.ie/php-bug.tar

Expected result:

It should just echo "Foo\n". But as you can see the Notice is triggered
and the is_array() check fails (as can be seen, it is impossible for the
variable to be anything other than an array).

Actual result:
--
*After* triggering the problem, $this becomes a non-object (although in
other tests (is_object($this) still returns true).

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

#50027 [Fbk->Opn]: $this becomes a non-object

[phpbugs at colin dot guthr dot ie]

 ID:   50027
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Mandriva Linux (Cooker x86_64)
 PHP Version:  5.3.1RC2
 New Comment:

I knew you were going to say that Jani :p

As I said on the original mail, even my simple test is not sufficient
to trigger this.

Sadly I'm not sure if I can create such a test script, but I will
certainly try. It may take me a few days to come up with something and
it's most likely that it will not be a simple application (my current
trigger case is part of the Zend Framework and I have no real desire to
dissect that!)

Give me a week or two.


Previous Comments:


[2009-11-03 10:57:43] j...@php.net

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

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

Please avoid embedding huge scripts into the report.





[2009-10-28 09:05:14] phpbugs at colin dot guthr dot ie

Description:

This is a really hard bug to reproduce (e.g. build a simple test case)
but I can reliably do so here with my application. I'll attempt to
describe the problem in depth, although I warn in advance that it's a
bit of a confusing one.

During a particular request, PHP seems to corrupt itself quite badly
which cases $this to become corrupted within an object.

When this happens, is_object($this) still returns true, but any attempt
to access a member variable (e.g. $this->mFuncs) will result in the
"Notice: Trying to get property of non-object" warning. Similar warning
exist when trying to call methods etc.

Once this corruption happens, it will remain until the Apache process
is restarted (mpm-prefork) although some requests will succeed (I
presume it depends what mpm-preforked httpd handler is used?). When this
happens, a much simpler test case (which I'll link to) fails also (i.e.
it seems that the initial trigger of this causes it to continue, but the
simpler test case itself does not seem enough to trigger it initially).

The trigger case I have is a rather complex Zend Framework application
that I sadly cannot share.

I have confirmed this problem is present on 5.3.0 and 5.3.1RC2, so I
suspect it's a 5.3.x problem over all. I cannot reproduce the problem on
5.2.11.

All builds use -O0 for optimisations (as higher values have proven to
cause problems, particularly on x86_64).

Reproduce code:
---
A tarball containing three PHP files: one a UniversalAutoloader
structure we use in our projects (it predates spl stuff and actually
gives us a different fallback mechanism anyway), and a simple test class
that is meant to be autoloaded. Then the test.php file which actually
exhibits the bug.

As noted previously however, this test case only *exhibits* this bug if
the problem is triggered already by some other code. You can see from
the backtrace.txt the effect of it failing. I provide this in the hope
that it allows something obvious to jump out at you, but I suspect the
problem is really some form of stack frame corruption or similar
(possibly due to x86_64 as I've not tested to see if it affects 5.3.1
although I will be able to do so in the coming weeks).

The URL for this bundle is: http://colin.guthr.ie/php-bug.tar

Expected result:

It should just echo "Foo\n". But as you can see the Notice is triggered
and the is_array() check fails (as can be seen, it is impossible for the
variable to be anything other than an array).

Actual result:
--
*After* triggering the problem, $this becomes a non-object (although in
other tests (is_object($this) still returns true).





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

#50027 [Com]: $this becomes a non-object

[phpbugs at colin dot guthr dot ie]

 ID:   50027
 Comment by:   phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Mandriva Linux (Cooker x86_64)
 PHP Version:  5.3.1RC2
 New Comment:

(Hopefully this will not reset the Feedback status).

I've tried this on a similar i586 machine and cannot reproduce the
problem, this leads me to believe the problem is indeed x86_64 related.
I will try and obtain access to another x86_64 machine to reproduce the
problem there too.

If the bug status changes, please put it back to Feedback.


Previous Comments:


[2009-11-04 10:40:12] j...@php.net

Leave the report in "Feedback" (requested) status until you have that
script around. (do not reply before that ;)



[2009-11-04 08:43:49] phpbugs at colin dot guthr dot ie

I knew you were going to say that Jani :p

As I said on the original mail, even my simple test is not sufficient
to trigger this.

Sadly I'm not sure if I can create such a test script, but I will
certainly try. It may take me a few days to come up with something and
it's most likely that it will not be a simple application (my current
trigger case is part of the Zend Framework and I have no real desire to
dissect that!)

Give me a week or two.



[2009-11-03 10:57:43] j...@php.net

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

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

Please avoid embedding huge scripts into the report.





[2009-10-28 09:05:14] phpbugs at colin dot guthr dot ie

Description:

This is a really hard bug to reproduce (e.g. build a simple test case)
but I can reliably do so here with my application. I'll attempt to
describe the problem in depth, although I warn in advance that it's a
bit of a confusing one.

During a particular request, PHP seems to corrupt itself quite badly
which cases $this to become corrupted within an object.

When this happens, is_object($this) still returns true, but any attempt
to access a member variable (e.g. $this->mFuncs) will result in the
"Notice: Trying to get property of non-object" warning. Similar warning
exist when trying to call methods etc.

Once this corruption happens, it will remain until the Apache process
is restarted (mpm-prefork) although some requests will succeed (I
presume it depends what mpm-preforked httpd handler is used?). When this
happens, a much simpler test case (which I'll link to) fails also (i.e.
it seems that the initial trigger of this causes it to continue, but the
simpler test case itself does not seem enough to trigger it initially).

The trigger case I have is a rather complex Zend Framework application
that I sadly cannot share.

I have confirmed this problem is present on 5.3.0 and 5.3.1RC2, so I
suspect it's a 5.3.x problem over all. I cannot reproduce the problem on
5.2.11.

All builds use -O0 for optimisations (as higher values have proven to
cause problems, particularly on x86_64).

Reproduce code:
---
A tarball containing three PHP files: one a UniversalAutoloader
structure we use in our projects (it predates spl stuff and actually
gives us a different fallback mechanism anyway), and a simple test class
that is meant to be autoloaded. Then the test.php file which actually
exhibits the bug.

As noted previously however, this test case only *exhibits* this bug if
the problem is triggered already by some other code. You can see from
the backtrace.txt the effect of it failing. I provide this in the hope
that it allows something obvious to jump out at you, but I suspect the
problem is really some form of stack frame corruption or similar
(possibly due to x86_64 as I've not tested to see if it affects 5.3.1
although I will be able to do so in the coming weeks).

The URL for this bundle is: http://colin.guthr.ie/php-bug.tar

Expected result:

It should just echo "Foo\n". But as you can see the Notice is triggered
and the is_array() check fails (as can be seen, it is impossible for the
variable to be anything other than an array).

Actual result:
--
*After* triggering the problem, $this becomes a non-object (although in
other tests (is_object($this) still returns true).





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

#45996 [NEW]: libxml2 2.7.1 causes breakage with character data in xml_parse()

[phpbugs at colin dot guthr dot ie]

From: phpbugs at colin dot guthr dot ie
Operating system: Mandriva Linux
PHP version:  5.2.6
PHP Bug Type: *XML functions
Bug description:  libxml2 2.7.1 causes breakage with character data in 
xml_parse()

Description:

With libxml2 2.7.1, When using the expat type xml parsing routines in PHP,
the characater data seems to silently drop any encoded text e.g. > <
and friends.

Please see Mandriva bug for details:
https://qa.mandriva.com/show_bug.cgi?id=43486

And also please note the thread on the libxml mailing list:
http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610

And most notably the reply to the above thread:

Can you report this as a PHP bug? It looks like some really old hack 
code in the PHP extension in order to mimic some specific expat 
functionality. The behavior change you see though resulting from a code
changes in libxml2 is really due to the hackish code in the extension doing
things it wasnt meant to be doing.


Reproduce code:
---
Please see this code:
https://qa.mandriva.com/attachment.cgi?id=10757

Expected result:

<
foo
>
wibble
<
/foo
>


Actual result:
--
foo
wibble
/foo


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

#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()

[phpbugs at colin dot guthr dot ie]

 ID:   45996
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Assigned
 Bug Type: XML related
 Operating System: Mandriva Linux
 PHP Version:  5.2.6
 Assigned To:  rrichards
 New Comment:

Comments by Daniel Veillard on the libxml ML:

  The only thing I can think of is that libxml2 doesn't anymore ask
though a SAX callback when looking for entities references if they
are in the predefined set. This comes in essence by an old decision
from the XML working group stating that user definition for those 5
entities could not override the default predefined ones. So I guess
that change is logical. Now what is done on top of SAX to result
in that bug, I don't really know  :-\


Previous Comments:


[2008-09-06 15:43:29] [EMAIL PROTECTED]

Assigned to the maintainer (Rob, don't forget to change status too when
you assign something to yourself :)



[2008-09-04 17:29:21] phpbugs at colin dot guthr dot ie

Description:

With libxml2 2.7.1, When using the expat type xml parsing routines in
PHP, the characater data seems to silently drop any encoded text e.g.
> < and friends.

Please see Mandriva bug for details:
https://qa.mandriva.com/show_bug.cgi?id=43486

And also please note the thread on the libxml mailing list:
http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610

And most notably the reply to the above thread:

Can you report this as a PHP bug? It looks like some really old hack 
code in the PHP extension in order to mimic some specific expat 
functionality. The behavior change you see though resulting from a code
changes in libxml2 is really due to the hackish code in the extension
doing things it wasnt meant to be doing.


Reproduce code:
---
Please see this code:
https://qa.mandriva.com/attachment.cgi?id=10757

Expected result:

<
foo
>
wibble
<
/foo
>


Actual result:
--
foo
wibble
/foo






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

#45996 [Com]: libxml2 2.7.1 causes breakage with character data in xml_parse()

[phpbugs at colin dot guthr dot ie]

 ID:   45996
 Comment by:   phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Assigned
 Bug Type: XML related
 Operating System: Mandriva Linux
 PHP Version:  5.2.6
 Assigned To:  rrichards
 New Comment:

Yes, I suspect that the comments left by ptn at post dot cz are
incorrect when they say it is fixed in libxml. rrichards has given a
very complete explanation of the problem and it is more fundamental than
a simple bug.

Compiling PHP with libexpat is the correct workaround for now.


Previous Comments:


[2008-10-08 09:18:54] uraes at hot dot ee

just tried libxml2-2.7.2 and 5.2.6-pl7-gentoo and it is still broken:

Example PHP code:


  

  <a
href="http://www.google.com";>Google</a>

  

";

$parser = xml_parser_create('UTF-8');
xml_parser_set_option($parser, XML_OPTION_SKIP_WHITE, 1);
xml_parse_into_struct($parser, $data, $vals, $index);
xml_parser_free($parser);

echo "";

echo "Original XML:".htmlentities($data);

echo "Parsed struct:";
print_r($vals);
?>

.. parsed result is "a href=http://www.google.com>Google/a>"



[2008-10-07 11:19:33] ptn at post dot cz

this bug seems to be fixed in libxm2-2.7.2

http://svn.gnome.org/viewvc/libxml2?view=revision&revision=3798

----

[2008-09-09 23:06:00] phpbugs at colin dot guthr dot ie

Comments by Daniel Veillard on the libxml ML:

  The only thing I can think of is that libxml2 doesn't anymore ask
though a SAX callback when looking for entities references if they
are in the predefined set. This comes in essence by an old decision
from the XML working group stating that user definition for those 5
entities could not override the default predefined ones. So I guess
that change is logical. Now what is done on top of SAX to result
in that bug, I don't really know  :-\



[2008-09-06 15:43:29] [EMAIL PROTECTED]

Assigned to the maintainer (Rob, don't forget to change status too when
you assign something to yourself :)

----

[2008-09-04 17:29:21] phpbugs at colin dot guthr dot ie

Description:

With libxml2 2.7.1, When using the expat type xml parsing routines in
PHP, the characater data seems to silently drop any encoded text e.g.
> < and friends.

Please see Mandriva bug for details:
https://qa.mandriva.com/show_bug.cgi?id=43486

And also please note the thread on the libxml mailing list:
http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610

And most notably the reply to the above thread:

Can you report this as a PHP bug? It looks like some really old hack 
code in the PHP extension in order to mimic some specific expat 
functionality. The behavior change you see though resulting from a code
changes in libxml2 is really due to the hackish code in the extension
doing things it wasnt meant to be doing.


Reproduce code:
---
Please see this code:
https://qa.mandriva.com/attachment.cgi?id=10757

Expected result:

<
foo
>
wibble
<
/foo
>


Actual result:
--
foo
wibble
/foo






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

#45996 [Com]: libxml2 2.7.1 causes breakage with character data in xml_parse()

[phpbugs at colin dot guthr dot ie]

 ID:   45996
 Comment by:   phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Assigned
 Bug Type: XML related
 Operating System: Mandriva Linux
 PHP Version:  5.2.6
 Assigned To:  rrichards
 New Comment:

Mike, it's fairly easy to recompile PHP with the libexpat library for
the legacy XML parsing functions while keeping libxml2 for the more
modern ones.

We did that in the Mandriva package for our 2009.0 release after I
reported the bug.

See the SPEC file here:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/updates/2009.0/php/current/SPECS/php.spec?revision=291141&view=markup

The particular change that worked around it is here:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/updates/2009.0/php/current/SPECS/php.spec?r1=278891&r2=281822

I'm sure you can work out how to get the needed patch that is mentioned
by navigating the webcvs :) You should be able to use this to recompile
the CentOS PHP package accordingly.

Hope this helps.

Col


Previous Comments:


[2008-10-15 00:04:01] mike at kogan dot org

I also have run into this - we had some legacy php code on the
xml_parser that was fine on some centos 4 servers with php4 and 5
running apache 1.3. We've been debugging this failure for a day now on
our new centos 5 server running php5 and libxml2 2.7.2, and we confirm
the same problem. The characterHandler is not called for the known
entities so scripts depending on this (rss feed converters etc) emit
flawed html. I agree there's much better ways to parse XML but this is
legacy stuff thats somewhat pervasive and we didn;t choose what these
folks used for their apps.

I'd love to rebuild their server with an older libxml2 but am not sure
how to go backwards without causing some other problem. Customer has
cpanel/whm and all that hooey and I'd rather not create a mess on their
new server.

Hope ya'll fix this soon as it is an issue on the cpanel folks that
have 2.7.2 in their stable branch for centos 5 that is being spread by
their updater.

If someone can give me a pointer that a straightup build and install of
the old release code wont make things worse I'll take a crack at moving
their server back.

----

[2008-10-08 09:50:16] phpbugs at colin dot guthr dot ie

Yes, I suspect that the comments left by ptn at post dot cz are
incorrect when they say it is fixed in libxml. rrichards has given a
very complete explanation of the problem and it is more fundamental than
a simple bug.

Compiling PHP with libexpat is the correct workaround for now.



[2008-10-08 09:18:54] uraes at hot dot ee

just tried libxml2-2.7.2 and 5.2.6-pl7-gentoo and it is still broken:

Example PHP code:


  

  <a
href="http://www.google.com";>Google</a>

  

";

$parser = xml_parser_create('UTF-8');
xml_parser_set_option($parser, XML_OPTION_SKIP_WHITE, 1);
xml_parse_into_struct($parser, $data, $vals, $index);
xml_parser_free($parser);

echo "";

echo "Original XML:".htmlentities($data);

echo "Parsed struct:";
print_r($vals);
?>

.. parsed result is "a href=http://www.google.com>Google/a>"



[2008-10-07 11:19:33] ptn at post dot cz

this bug seems to be fixed in libxm2-2.7.2

http://svn.gnome.org/viewvc/libxml2?view=revision&revision=3798



[2008-09-09 23:06:00] phpbugs at colin dot guthr dot ie

Comments by Daniel Veillard on the libxml ML:

  The only thing I can think of is that libxml2 doesn't anymore ask
though a SAX callback when looking for entities references if they
are in the predefined set. This comes in essence by an old decision
from the XML working group stating that user definition for those 5
entities could not override the default predefined ones. So I guess
that change is logical. Now what is done on top of SAX to result
in that bug, I don't really know  :-\



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

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

#46568 [NEW]: Segfault on 64bit when chaining function calls that generate exceptions

[phpbugs at colin dot guthr dot ie]

From: phpbugs at colin dot guthr dot ie
Operating system: Linux
PHP version:  5.2.7RC3
PHP Bug Type: Reproducible crash
Bug description:  Segfault on 64bit when chaining function calls that generate 
exceptions

Description:

I seem to have uncovered a bug that has been affecting me for a while
(e.g. it affects 5.2.6 as well) but that, until now, I have been able to
work around.

I have confirmed this bug on both 5.2.6 and 5.2.7RC3 on x86_64. I have
confirmed this bug does *not* occur on i586 with these same versions.

The reproduce code has two examples. It should be obvious which is which
;)

I compiled up a fresh 5.2.7RC3 to produce the below backtrace.

Please remember that this bug affects x86_64 only.

I discovered this when using code in the Zend Framework in which this
scenario crops up in the natural flow of code.

Reproduce code:
---
bar($this->wibble());
  }
  public function nobug()
  {
$wibble = $this->wibble();
$this->bar($wibble);
  }
}
$foo = new foo;
$foo->bug();
//$foo->nobug();


Expected result:

PHP Fatal error:  Uncaught exception 'Exception' with message 'Wibble' in
/home/colin/bug.php:10
Stack trace:
#0 /home/colin/bug.php(14): foo->wibble()
#1 /home/colin/bug.php(23): foo->bug()
#2 {main}
  thrown in /home/colin/bug.php on line 10


Actual result:
--
[EMAIL PROTECTED] pfx]$ gdb bin/php
GNU gdb 6.8-2mdv2009.0 (Mandriva Linux release 2009.0)
Copyright (C) 2008 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
  
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  
and "show warranty" for details.  
  
This GDB was configured as "x86_64-mandriva-linux-gnu"...     
  
(gdb) set args bug.php
(gdb) run 
Starting program: /home/colin/php/pfx/bin/php bug.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f75d9a056f0 (LWP 18074)]  

Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x7fffe1a4fbd0) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:289
289 if (RETURN_VALUE_USED(ctor_opline)) { 
  
Missing debug package(s), you should install: glibc-debug libxml2-debug
zlib-debug   
(gdb) thread apply all bt full
  

Thread 1 (Thread 0x7f75d9a056f0 (LWP 18074)):
#0  zend_do_fcall_common_helper_SPEC (execute_data=0x7fffe1a4fbd0) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:289
opline = (zend_op *) 0x7f75d9a2a770   
  
original_return_value = (zval **) 0x7fffe1a4fcd0  
  
current_scope = (zend_class_entry *) 0x0  
  
current_this = (zval *) 0x0   
  
return_value_used = 0 
  
should_change_scope = 1 '\001'
  
#1  0x0064b8a4 in execute (op_array=0x7f75d9a2a108) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:92
execute_data = {opline = 0x7f75d9a2a770, function_state =
{function_symbol_table = 0x7f75d9a2d470,   
function = 0x7f75d9a2a108, reserved = {0x0, 0x7f75d9a2a200, 0x0,
0x7f75d9a2a210}}, fbc = 0x7f75d9a2cb90, 
  op_array = 0x7f75d9a2a108, object = 0x7f75d9a29928, Ts = 0x7fffe1a4fa80,
CVs = 0x7fffe1a4fa60, original_in_execution = 0 '\0', 
  symbol_table = 0x9db608, prev_execute_data = 0x0, old_error_reporting =
0x0}   
#2  0x006290d1 in zend_execute_scripts (type=8, retval=0x51,
file_count=3)   
at /home/colin/php/php-5.2.7RC3/Zend/zend.c:1134  
  
files = {{gp_offset = 40, fp_offset = 0, overflow_arg_area =
0x7fffe1a4fdd0, reg_save_area = 0x7fffe1a4fce0}}
i = 1 
  
file_handle = (zend_file_handle *) 0x7fffe1a52240 
   

#46568 [Opn]: Segfault on 64bit when chaining function calls that generate exceptions

[phpbugs at colin dot guthr dot ie]

 ID:   46568
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  5.2.7RC3
 New Comment:

Well I've confirmed this problem on three Mandriva systems with
Mandriva packages but for this bug report I built a fresh vanilla
version from the 5.2.7rc3 tarball on my own machine to ensure it was
nothing to do with any additional patches in the Mandriva package
causing the problem.

I do not have access to any non-Mandriva 64 bit build hosts here to do
more tests... 

FWIW, the GCC version is 4.3.2.

I can tarball up the installed version if you want to give my build a
run and see if it crashes on your machine. If it does crash then I'd
expect the problem to be related to GCC.


Previous Comments:


[2008-11-13 22:23:05] [EMAIL PROTECTED]

I can't reproduce it on FreeBSD amd64.




[2008-11-13 16:18:13] phpbugs at colin dot guthr dot ie

Description:

I seem to have uncovered a bug that has been affecting me for a while
(e.g. it affects 5.2.6 as well) but that, until now, I have been able to
work around.

I have confirmed this bug on both 5.2.6 and 5.2.7RC3 on x86_64. I have
confirmed this bug does *not* occur on i586 with these same versions.

The reproduce code has two examples. It should be obvious which is
which ;)

I compiled up a fresh 5.2.7RC3 to produce the below backtrace.

Please remember that this bug affects x86_64 only.

I discovered this when using code in the Zend Framework in which this
scenario crops up in the natural flow of code.

Reproduce code:
---
bar($this->wibble());
  }
  public function nobug()
  {
$wibble = $this->wibble();
$this->bar($wibble);
  }
}
$foo = new foo;
$foo->bug();
//$foo->nobug();


Expected result:

PHP Fatal error:  Uncaught exception 'Exception' with message 'Wibble'
in /home/colin/bug.php:10
Stack trace:
#0 /home/colin/bug.php(14): foo->wibble()
#1 /home/colin/bug.php(23): foo->bug()
#2 {main}
  thrown in /home/colin/bug.php on line 10


Actual result:
--
[EMAIL PROTECTED] pfx]$ gdb bin/php
GNU gdb 6.8-2mdv2009.0 (Mandriva Linux release 2009.0)
Copyright (C) 2008 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. 
 
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"   
and "show warranty" for details.   
 
This GDB was configured as "x86_64-mandriva-linux-gnu"...  
 
(gdb) set args bug.php
(gdb) run 
Starting program: /home/colin/php/pfx/bin/php bug.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f75d9a056f0 (LWP 18074)]  

Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x7fffe1a4fbd0) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:289
289 if (RETURN_VALUE_USED(ctor_opline)) {  
 
Missing debug package(s), you should install: glibc-debug libxml2-debug
zlib-debug   
(gdb) thread apply all bt full 
 

Thread 1 (Thread 0x7f75d9a056f0 (LWP 18074)):
#0  zend_do_fcall_common_helper_SPEC (execute_data=0x7fffe1a4fbd0) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:289
opline = (zend_op *) 0x7f75d9a2a770
 
original_return_value = (zval **) 0x7fffe1a4fcd0   
 
current_scope = (zend_class_entry *) 0x0   
 
current_this = (zval *) 0x0
 
return_value_used = 0  
 
should_change_scope = 1 '\001' 
     
#1  0x0064b8a4 in execute (op_array=0x7f75d9a2a108) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:92
execute_data = {opline = 0x7f75d9a2a770, function_state =
{function_symbol_table = 0x7f75d9a2d470,   
function = 0x7f75d9a2a108, reserved = {0x0, 0x7f75d9a2a200, 0x0,
0x7f75d9a2a210}}, fbc = 0x7f75d9a2cb90,   

#46568 [Com]: Segfault on 64bit when chaining function calls that generate exceptions

[phpbugs at colin dot guthr dot ie]

 ID:   46568
 Comment by:   phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: * (64bit)
 PHP Version:  5.2.7RC3
 New Comment:

My configure line is just the default. All I did was pass a custom
prefix.

I'll try and find some other 64 bit systems to play on. I should be
able to fire a few different systems into a vm to see if I can reproduce
it with other distros.


Previous Comments:


[2008-11-17 10:18:57] [EMAIL PROTECTED]

I can not reproduce this within x86_64 Centos 5 using latest PHP_5_2
checkout. Would be nice to know your configure line for PHP too..?



[2008-11-16 08:03:46] bruno at ioda dot net

I've try this on 3 differents openSUSE 10.3 all with the lastest
opensuse build services php version 5.2.6.

And the result was the expected exception
Fatal error: Uncaught exception 'Exception' with message 'Wibble' in
/tmp/bugs.php:10
Stack trace:
#0 /tmp/bugs.php(14): foo->wibble()
#1 /tmp/bugs.php(23): foo->bug()
#2 {main}
  thrown in /tmp/bugs.php on line 10

PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov  5 2008
13:42:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH

For 10.3 gcc is :
Target: x86_64-suse-linux
Configuré avec: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Modèle de thread: posix
version gcc 4.2.1 (SUSE Linux)

I've not yet try on the lastest 11.0 x64 which have the gcc
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux)

----

[2008-11-13 22:41:05] phpbugs at colin dot guthr dot ie

Well I've confirmed this problem on three Mandriva systems with
Mandriva packages but for this bug report I built a fresh vanilla
version from the 5.2.7rc3 tarball on my own machine to ensure it was
nothing to do with any additional patches in the Mandriva package
causing the problem.

I do not have access to any non-Mandriva 64 bit build hosts here to do
more tests... 

FWIW, the GCC version is 4.3.2.

I can tarball up the installed version if you want to give my build a
run and see if it crashes on your machine. If it does crash then I'd
expect the problem to be related to GCC.



[2008-11-13 22:23:05] [EMAIL PROTECTED]

I can't reproduce it on FreeBSD amd64.


----

[2008-11-13 16:18:13] phpbugs at colin dot guthr dot ie

Description:

I seem to have uncovered a bug that has been affecting me for a while
(e.g. it affects 5.2.6 as well) but that, until now, I have been able to
work around.

I have confirmed this bug on both 5.2.6 and 5.2.7RC3 on x86_64. I have
confirmed this bug does *not* occur on i586 with these same versions.

The reproduce code has two examples. It should be obvious which is
which ;)

I compiled up a fresh 5.2.7RC3 to produce the below backtrace.

Please remember that this bug affects x86_64 only.

I discovered this when using code in the Zend Framework in which this
scenario crops up in the natural flow of code.

Reproduce code:
---
bar($this->wibble());
  }
  public function nobug()
  {
$wibble = $this->wibble();
$this->bar($wibble);
  }
}
$foo = new foo;
$foo->bug();
//$foo->nobug();


Expected result:

PHP Fatal error:  Uncaught exception 'Exception' with message 'Wibble'
in /home/colin/bug.php:10
Stack trace:
#0 /home/colin/bug.php(14): foo->wibble()
#1 /home/colin/bug.php(23): foo->bug()
#2 {main}
  thrown in /home/colin/bug.php on line 10


Actual result:
--
[EMAIL PROTECTED] pfx]$ gdb bin/php
GNU gdb 6.8-2mdv2009.0 (Mandriva Linux release 2009.0)
Copyright (C) 2008 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. 
 
There 

#46568 [Fbk->Opn]: Segfault on 64bit when chaining function calls that generate exceptions

[phpbugs at colin dot guthr dot ie]

 ID:   46568
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: * (64bit)
 PHP Version:  5.2.7RC3
 New Comment:

Thanks for all the feedback/help. I will have to investigate further. I
do not think my system hardware is at fault due to having confirmed on
two other machines, although both Mandriva based. This is why I
suspected the compiler.

I will try and work out more info.


Previous Comments:


[2008-11-18 17:23:16] crrodriguez at opensuse dot org

Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or
without suhosin.

I suspect either your system or your compiler is doing something wrong.



[2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie

My configure line is just the default. All I did was pass a custom
prefix.

I'll try and find some other 64 bit systems to play on. I should be
able to fire a few different systems into a vm to see if I can reproduce
it with other distros.



[2008-11-17 10:18:57] [EMAIL PROTECTED]

I can not reproduce this within x86_64 Centos 5 using latest PHP_5_2
checkout. Would be nice to know your configure line for PHP too..?



[2008-11-16 08:03:46] bruno at ioda dot net

I've try this on 3 differents openSUSE 10.3 all with the lastest
opensuse build services php version 5.2.6.

And the result was the expected exception
Fatal error: Uncaught exception 'Exception' with message 'Wibble' in
/tmp/bugs.php:10
Stack trace:
#0 /tmp/bugs.php(14): foo->wibble()
#1 /tmp/bugs.php(23): foo->bug()
#2 {main}
  thrown in /tmp/bugs.php on line 10

PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov  5 2008
13:42:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH

For 10.3 gcc is :
Target: x86_64-suse-linux
Configuré avec: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Modèle de thread: posix
version gcc 4.2.1 (SUSE Linux)

I've not yet try on the lastest 11.0 x64 which have the gcc
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux)

----

[2008-11-13 22:41:05] phpbugs at colin dot guthr dot ie

Well I've confirmed this problem on three Mandriva systems with
Mandriva packages but for this bug report I built a fresh vanilla
version from the 5.2.7rc3 tarball on my own machine to ensure it was
nothing to do with any additional patches in the Mandriva package
causing the problem.

I do not have access to any non-Mandriva 64 bit build hosts here to do
more tests... 

FWIW, the GCC version is 4.3.2.

I can tarball up the installed version if you want to give my build a
run and see if it crashes on your machine. If it does crash then I'd
expect the problem to be related to GCC.



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

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

#46568 [Opn]: Segfault on 64bit when chaining function calls that generate exceptions

[phpbugs at colin dot guthr dot ie]

 ID:   46568
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: * (64bit)
 PHP Version:  5.2.7RC3
 New Comment:

Just tried --enable-debug and when built this way, it does indeed work
as expected. Does this suggest anything else I can try to narrow down
the problem.

I also tried make test and did get several failures.

I uploaded the test results to
http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt
although none of these look particularly relevant. I will do another
build sans --enable-debug and see if any different standard tests fail.


Previous Comments:


[2008-11-18 18:11:21] crrodriguez at opensuse dot org

Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it
crash anyway ?



[2008-11-18 17:36:56] phpbugs at colin dot guthr dot ie

Thanks for all the feedback/help. I will have to investigate further. I
do not think my system hardware is at fault due to having confirmed on
two other machines, although both Mandriva based. This is why I
suspected the compiler.

I will try and work out more info.



[2008-11-18 17:23:16] crrodriguez at opensuse dot org

Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or
without suhosin.

I suspect either your system or your compiler is doing something wrong.



[2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie

My configure line is just the default. All I did was pass a custom
prefix.

I'll try and find some other 64 bit systems to play on. I should be
able to fire a few different systems into a vm to see if I can reproduce
it with other distros.



[2008-11-17 10:18:57] [EMAIL PROTECTED]

I can not reproduce this within x86_64 Centos 5 using latest PHP_5_2
checkout. Would be nice to know your configure line for PHP too..?



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

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

#46568 [Opn]: Segfault on 64bit when chaining function calls that generate exceptions

[phpbugs at colin dot guthr dot ie]

 ID:   46568
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: * (64bit)
 PHP Version:  5.2.7RC3
 New Comment:

OK, I repeated the make test sans-debug and it seems that a couple more
tests fail under this scenario.

http://kenobi.mandriva.com/~colin/php_test_results_20081118_2054.txt

The most interesting extra failure is:
Bug #30707 (Segmentation fault on exception in method)
[Zend/tests/bug30707.phpt]

This could perhaps provide some clues?

For convenience, here is a diff of non-debug vs. debug:
http://kenobi.mandriva.com/~colin/php-make-test.diff.txt


Previous Comments:


[2008-11-18 20:46:09] phpbugs at colin dot guthr dot ie

Just tried --enable-debug and when built this way, it does indeed work
as expected. Does this suggest anything else I can try to narrow down
the problem.

I also tried make test and did get several failures.

I uploaded the test results to
http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt
although none of these look particularly relevant. I will do another
build sans --enable-debug and see if any different standard tests fail.



[2008-11-18 18:11:21] crrodriguez at opensuse dot org

Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it
crash anyway ?



[2008-11-18 17:36:56] phpbugs at colin dot guthr dot ie

Thanks for all the feedback/help. I will have to investigate further. I
do not think my system hardware is at fault due to having confirmed on
two other machines, although both Mandriva based. This is why I
suspected the compiler.

I will try and work out more info.



[2008-11-18 17:23:16] crrodriguez at opensuse dot org

Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or
without suhosin.

I suspect either your system or your compiler is doing something wrong.



[2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie

My configure line is just the default. All I did was pass a custom
prefix.

I'll try and find some other 64 bit systems to play on. I should be
able to fire a few different systems into a vm to see if I can reproduce
it with other distros.



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

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

#46568 [Opn->Csd]: Segfault on 64bit when chaining function calls that generate exceptions

[phpbugs at colin dot guthr dot ie]

 ID:   46568
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
-Status:   Open
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: * (64bit)
 PHP Version:  5.2.7RC3
 New Comment:

Thank you for your help Mr Rodriguez!

The first CFLAGs option was sufficient to not trigger the segv.

This is clearly not a problem of PHP and the problem obviously lies
with the GCC in Mandriva.

I'll raise the bug within our own systems for that.

Thanks to everyone for their patience and effort in helping diagnose
this issue.


Previous Comments:


[2008-11-19 05:22:00] crrodriguez at opensuse dot org

Yes, it suggest that your compiler optimized badly.. try 

export CFLAGS="-O2 -fno-strict-aliasing"  and rebuild. if still
crashes... try -O1..



[2008-11-18 21:20:43] phpbugs at colin dot guthr dot ie

OK, I repeated the make test sans-debug and it seems that a couple more
tests fail under this scenario.

http://kenobi.mandriva.com/~colin/php_test_results_20081118_2054.txt

The most interesting extra failure is:
Bug #30707 (Segmentation fault on exception in method)
[Zend/tests/bug30707.phpt]

This could perhaps provide some clues?

For convenience, here is a diff of non-debug vs. debug:
http://kenobi.mandriva.com/~colin/php-make-test.diff.txt



[2008-11-18 20:46:09] phpbugs at colin dot guthr dot ie

Just tried --enable-debug and when built this way, it does indeed work
as expected. Does this suggest anything else I can try to narrow down
the problem.

I also tried make test and did get several failures.

I uploaded the test results to
http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt
although none of these look particularly relevant. I will do another
build sans --enable-debug and see if any different standard tests fail.



[2008-11-18 18:11:21] crrodriguez at opensuse dot org

Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it
crash anyway ?



[2008-11-18 17:36:56] phpbugs at colin dot guthr dot ie

Thanks for all the feedback/help. I will have to investigate further. I
do not think my system hardware is at fault due to having confirmed on
two other machines, although both Mandriva based. This is why I
suspected the compiler.

I will try and work out more info.



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

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

#46568 [Csd]: Segfault on 64bit when chaining function calls that generate exceptions

[phpbugs at colin dot guthr dot ie]

 ID:   46568
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: * (64bit)
 PHP Version:  5.2.7RC3
 New Comment:

Actually for clarity in my further dealing with this problem, can you
tell me if the OpenSuse builds used -fno-strict-aliasing or not? If it
is compiled with -O2 -fstrict-aliasing and does not exhibit the bug it
would be easier for me to point the finger at our gcc build.

Thanks.


Previous Comments:


[2008-11-19 09:36:50] phpbugs at colin dot guthr dot ie

Thank you for your help Mr Rodriguez!

The first CFLAGs option was sufficient to not trigger the segv.

This is clearly not a problem of PHP and the problem obviously lies
with the GCC in Mandriva.

I'll raise the bug within our own systems for that.

Thanks to everyone for their patience and effort in helping diagnose
this issue.



[2008-11-19 05:22:00] crrodriguez at opensuse dot org

Yes, it suggest that your compiler optimized badly.. try 

export CFLAGS="-O2 -fno-strict-aliasing"  and rebuild. if still
crashes... try -O1..



[2008-11-18 21:20:43] phpbugs at colin dot guthr dot ie

OK, I repeated the make test sans-debug and it seems that a couple more
tests fail under this scenario.

http://kenobi.mandriva.com/~colin/php_test_results_20081118_2054.txt

The most interesting extra failure is:
Bug #30707 (Segmentation fault on exception in method)
[Zend/tests/bug30707.phpt]

This could perhaps provide some clues?

For convenience, here is a diff of non-debug vs. debug:
http://kenobi.mandriva.com/~colin/php-make-test.diff.txt



[2008-11-18 20:46:09] phpbugs at colin dot guthr dot ie

Just tried --enable-debug and when built this way, it does indeed work
as expected. Does this suggest anything else I can try to narrow down
the problem.

I also tried make test and did get several failures.

I uploaded the test results to
http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt
although none of these look particularly relevant. I will do another
build sans --enable-debug and see if any different standard tests fail.



[2008-11-18 18:11:21] crrodriguez at opensuse dot org

Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it
crash anyway ?



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

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

#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()

[phpbugs at colin dot guthr dot ie]

 ID:   45996
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Assigned
 Bug Type: XML related
 Operating System: Mandriva Linux
 PHP Version:  5.2.6
 Assigned To:  rrichards
 New Comment:

To build with expat just read my earlier posts on this bug where I've
shown how we did this in our recent Mandriva 2009 release.


Previous Comments:


[2008-11-21 15:31:40] ajay12006 at gmail dot com

I already have libxml 2.7.2

Can anyone help me how to "build PHP with libxml2 <= 2.6.32 or 
build ext/xml with expat."? Any link on how to so it?

Thanks.



[2008-11-20 22:37:34] rcasagraude at interfaces dot fr

Confirm : build xml against libexpat workaround this bug



[2008-11-05 16:30:35] [EMAIL PROTECTED]

just use the example in the manual. Your change simply gets predefined

entities working but breaks all other cases. I'm currently looking at 
getting the change in libxml2 that caused this reverted. The problem 
stems from the magic needed to emulate expat behavior as its not native

in libxml so non-standard use of the libxml sax hooks was needed.



[2008-11-05 16:13:17] [EMAIL PROTECTED]

Rob, do you have a test case for the regression caused by my test
patch, so I can look at that further?  



[2008-11-04 21:00:18] [EMAIL PROTECTED]

This is still being worked on.
Currently the only options are to build PHP with libxml2 <= 2.6.32 or 
build ext/xml with expat.



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

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

#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()

[phpbugs at colin dot guthr dot ie]

 ID:   45996
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Assigned
 Bug Type: XML related
 Operating System: Mandriva Linux
 PHP Version:  5.2.6
 Assigned To:  rrichards
 New Comment:

While I do not doubt that this is an annoying bug, there are very
simple and clear workarounds. I'm really not seeing why everyone is so
upset about this. I reported the bug and we fixed the Mandriva package
almost immediately with the work around and I'm not aware of any fallout
from that change.


Previous Comments:


[2008-12-28 03:55:04] alex at magnet dot ru

4 month!!! This is not serious?!



[2008-12-25 02:41:10] gordon at kanazawa-gu dot ac dot jp

This issue also affects Moodle backup+restore and HotPot module
http://tracker.moodle.org/browse/MDL-17136



[2008-12-17 15:18:50] valli at icsurselva dot ch

Where can I find the libxml2 patch?
Does someone have a link to the libxml2 bug reporting tool
which describes this issue?



[2008-12-17 00:56:14] rricha...@php.net

Does no one pay attention to the comments? The fix for this needs to 
happen on the libxml2 layer. The next version of libxml2 should resolve

this and this bug is being kept open only in case some modification to

the extension also needs to occur with the fix.



[2008-12-17 00:49:19] scott...@php.net

Recompile with libexpat or downgrade libxml. One of those will sort you
out.

A change to libxml will be in the next release, though the patch isn't
in their repository yet.



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

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

#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()

[phpbugs at colin dot guthr dot ie]

 ID:   45996
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Assigned
 Bug Type: XML related
 Operating System: Mandriva Linux
 PHP Version:  5.2.6
 Assigned To:  rrichards
 New Comment:

If you are on a shared host with a fixed PHP version then really the
host should be responsible for deploying a well packaged version of PHP.
If they are not doing that it is the host that is at fault and you
should raise the issue with them.


Previous Comments:


[2008-12-31 00:56:58] mark at mcclusky dot com

I understand that there are workarounds to this bug, but for those of
us on shared hosts that we can't recompile, this is a colossally
frustrating state of affairs.

Does anyone in PHP land have any timeline for a fix?



[2008-12-29 17:02:44] jeffrey dot roberts at ibsgroup dot org

For those as challenged as me at determining how to either downgrade
libxml2 or recompile with libexpat while using cPANEL (easyapache), here
is a link to the details.  I confirm that after recompiling it is a
workaround for the problem.

http://blog.code-head.com/fixing-libxml-php-bug-and-issues-with-html-entities-libexpat

First you will need to find out where libexpat is located on your
server, it¡¯s probably here:
/usr/lib

To find out for sure, open this folder (/usr/lib) and look for the
file:
libexpat.so

If you can¡¯t find it, log in as root via SSH and enter:
whereis libexpat.so

This should list the folder in which libexpat is located.

After all this you will need to compile PHP to use libexpat instead of
libxml, so go to:
/var/cpanel/easy/apache/rawopts/

And create a file and name it ¡°all_php5¡å (no quotes), if there is a
file with this name edit it and add these lines to the end of it:
¨Cwith-expat=builtin
¨Cwith-libexpat-dir=/usr/lib

(lines start with two dashes ¡°-¡± that are not showing up here for
some reason)
Remember that depending on where libexpat is located on your server you
might need to edit the second line.

Now compile Apache and everything should work fine!



[2008-12-28 13:37:13] phpbugs at colin dot guthr dot ie

While I do not doubt that this is an annoying bug, there are very
simple and clear workarounds. I'm really not seeing why everyone is so
upset about this. I reported the bug and we fixed the Mandriva package
almost immediately with the work around and I'm not aware of any fallout
from that change.



[2008-12-28 03:55:04] alex at magnet dot ru

4 month!!! This is not serious?!



[2008-12-25 02:41:10] gordon at kanazawa-gu dot ac dot jp

This issue also affects Moodle backup+restore and HotPot module
http://tracker.moodle.org/browse/MDL-17136



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

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

#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()

[phpbugs at colin dot guthr dot ie]

 ID:   45996
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported By:  phpbugs at colin dot guthr dot ie
 Status:   Assigned
 Bug Type: XML related
 Operating System: Mandriva Linux
 PHP Version:  5.2.6
 Assigned To:  rrichards
 New Comment:

If the Fedora packages do not work then this is a RedHat packaging
problem and you should complain to them/open a bug etc. etc.

Like I say, in Mandriva we made sure we provided packages that worked
because they were compiled with expat.


Previous Comments:


[2009-01-01 19:31:49] alex at peoples dot ru

Thanks for advice, but I'm not guru in the Linux, as I haven't cpanel
on my server. I tried use 'yum remove' libxml2 and add new, but off
course this is stupid and doesn't work. I liked Linux, as the easiest
and powerful system, but now, I'm stock. I haven't any idea how I can
remove libxml2 and build new system with old one. One idea - change
system on Fedora 9, because FC 10 have the same bug with fucking
libxml2. Sorry, I was at Data Center 8 hours and I had problem with
servers with new system. I don't like updates now... they have bugs
every where, and I'm tiered resolve this bugs. Sorry, Have a Happy New
Year. I'll never ever will update my systems less when half year.



[2008-12-31 15:22:17] scott...@php.net

Guys please READ the report, this is a bug in libxml NOT a bug in PHP.



[2008-12-31 14:35:13] hougiwro at guerrillamail dot org

Why not just fix the bug so that existing installs can pick up a
standard update without having to rebuild the program.

Not everyone using PHP is necessarily comfortable with recompiling it
in order to implement a workaround for a bug.

----

[2008-12-31 13:37:17] phpbugs at colin dot guthr dot ie

If you are on a shared host with a fixed PHP version then really the
host should be responsible for deploying a well packaged version of PHP.
If they are not doing that it is the host that is at fault and you
should raise the issue with them.



[2008-12-31 00:56:58] mark at mcclusky dot com

I understand that there are workarounds to this bug, but for those of
us on shared hosts that we can't recompile, this is a colossally
frustrating state of affairs.

Does anyone in PHP land have any timeline for a 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/45996

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

Bug #50027 [Com]: $this becomes a non-object

[phpbugs at colin dot guthr dot ie]

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

 ID:   50027
 Comment by:   phpbugs at colin dot guthr dot ie
 Reported by:  phpbugs at colin dot guthr dot ie
 Summary:  $this becomes a non-object
 Status:   No Feedback
 Type: Bug
 Package:  Reproducible crash
 Operating System: Mandriva Linux (Cooker x86_64)
 PHP Version:  5.3.1RC2

 New Comment:

I'm curious as to why this bug is set to "No Feedback"... Lukas has
provided more information about the topic to nail it down to a Garbage
Collection issue.



I will try and upgrade sometime soon on my development machine to see if
I can retrigger the problem, but in the meantime, has there been any
progress? Are there now some potentially duplicate bugs and even a fix?
Does the issue still cause you problems Lukas?



Thanks :)


Previous Comments:

[2010-01-04 12:22:00] lukas at twobits dot cz

We now have about three weeks of successful operation with
zend.enable_gc = Off



I assume it is safe to say that this bug indeed is GC related.


[2009-12-16 08:53:15] lukas at twobits dot cz

I switched the gc off, will provide feedback in about a week.


[2009-12-16 08:11:52] ras...@php.net

Does this happen with gc turned off?



Try adding:



zend.enable_gc = Off



to your php.ini file.


[2009-12-16 08:09:06] lukas at twobits dot cz

We're affected with the same bug - 5.3.1, Fedora Core 8, 32bit, Apache
2.2.6.



This happens suddenly after few days of normal operation - then some of
the Apache requests end up with $this not defined inside an object
instance. Normal operation is resumed after Apache is restarted.



We never encountered this problem on 5.3.0 (used for over a month),
though I am not saying its not there as lots of our code changed
meanwhile as well.


[2009-11-12 01:00:02] 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".




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


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

Bug #50027 [Opn]: $this becomes a non-object

[phpbugs at colin dot guthr dot ie]

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

 ID:   50027
 User updated by:  phpbugs at colin dot guthr dot ie
 Reported by:  phpbugs at colin dot guthr dot ie
 Summary:  $this becomes a non-object
 Status:   Open
 Type: Bug
 Package:  Reproducible crash
 Operating System: Mandriva Linux (Cooker x86_64)
 PHP Version:  5.3.1RC2

 New Comment:

Just for reference, I just tested and this bug is still a problem with
5.3.2.


Previous Comments:

[2010-04-28 10:05:16] ahar...@php.net

The way this bug tracker works is that the bug doesn't get automatically
re-opened from the Feedback status when someone posts a comment; it's
only if the original reporter or a PHP developer actually resets it to
Open.



Reopening, anyway, since feedback was provided.


[2010-04-28 09:47:53] lukas at twobits dot cz

I am unfortunately unable to provide more feedback except that we have
never encountered this problem again with GC off. We have now been using
5.3.2. If we decide to test it with the garbage collector one once
again, I'll provide some more feedback.


[2010-04-27 13:08:07] phpbugs at colin dot guthr dot ie

I'm curious as to why this bug is set to "No Feedback"... Lukas has
provided more information about the topic to nail it down to a Garbage
Collection issue.



I will try and upgrade sometime soon on my development machine to see if
I can retrigger the problem, but in the meantime, has there been any
progress? Are there now some potentially duplicate bugs and even a fix?
Does the issue still cause you problems Lukas?



Thanks :)


[2010-01-04 12:22:00] lukas at twobits dot cz

We now have about three weeks of successful operation with
zend.enable_gc = Off



I assume it is safe to say that this bug indeed is GC related.


[2009-12-16 08:53:15] lukas at twobits dot cz

I switched the gc off, will provide feedback in about a week.




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


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

Bug #50027 [Com]: $this becomes a non-object

[phpbugs at colin dot guthr dot ie]

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

 ID: 50027
 Comment by: phpbugs at colin dot guthr dot ie
 Reported by:phpbugs at colin dot guthr dot ie
 Summary:$this becomes a non-object
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Mandriva Linux (Cooker x86_64)
 PHP Version:5.3.1RC2
 Block user comment: N
 Private report: N

 New Comment:

So far so good! I updated to PHP 5.3.3 again and reproduced the error
(and got four nice core dumps), then applied the patch and tried to
reproduce again and so far, I'm coreless.



Thanks for highlighting the patch. Just with this bug had lead to more
investigations earlier as I've had to jump through hoops to avoid
updating to PHP 5.3.x because of this problem. Still hopefully looking
good now :)


Previous Comments:

[2010-11-16 09:38:23] bsteinbrink at saltation dot de

We encountered this bug yesterday (we could reproduce it quite easily
with our code, but unfortunately we cannot disclose it), debugged it,
found out that it was due to the GC corrupting the std_object_handlers
prototype and once we knew that, we checked with the svn repo and saw
that that was fixed in r303016.



The corruption that happens is that the read_property field of
std_object_handlers gets set to NULL, because the GC treated the handler
as a zval.



The report from lukas about the failure to set a property seems like an
independent bug, as a different field got corrupted (and he had the gc
turned off anyway).


[2010-11-10 15:44:51] lukas at twobits dot cz

Bad news. Just got the same bug again, with PHP 5.3.3 and GC switched
OFF. Again, only one Apache process fails. The process begun failing
immediately after Apache restart. A simple reproduce class:



Reproduce code:

---

class Test

{



private $data = NULL;



public function __construct($data)

{

echo "";

var_dump($this);

echo "";

$this->data = $data;

}



public function getData()

{

echo "";

var_dump($this);

echo "";

return $this->data;

}

}



echo "PID: " . getmypid();



$foo = new Test('Hello');



echo $foo->getData();





Correct output:

---

PID: 22839

object(Test)#1 (1) {

  ["data":"Test":private]=>

  NULL

}

object(Test)#1 (1) {

  ["data":"Test":private]=>

  string(5) "Hello"

}

Hello



Malfunctioning Apache process output:

-

PID: 22818

object(Test)#1 (1) {

  ["data":"Test":private]=>

  NULL

}

Warning: Attempt to assign property of non-object in
/var/www/html/testthis.php on line 16 

object(Test)#1 (1) {

  ["data":"Test":private]=>

  NULL

}


[2010-05-15 19:06:58] phpbugs at colin dot guthr dot ie

Just for reference, I just tested and this bug is still a problem with
5.3.2.


[2010-04-28 10:05:16] ahar...@php.net

The way this bug tracker works is that the bug doesn't get automatically
re-opened from the Feedback status when someone posts a comment; it's
only if the original reporter or a PHP developer actually resets it to
Open.



Reopening, anyway, since feedback was provided.


[2010-04-28 09:47:53] lukas at twobits dot cz

I am unfortunately unable to provide more feedback except that we have
never encountered this problem again with GC off. We have now been using
5.3.2. If we decide to test it with the garbage collector one once
again, I'll provide some more feedback.




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


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

#42000 [NEW]: Installer creates httpd.conf entries in the wrong order

[colin dot ogilvie at gmail dot com]

From: colin dot ogilvie at gmail dot com
Operating system: Windows XP SP2
PHP version:  5.2.3
PHP Bug Type: Apache related
Bug description:  Installer creates httpd.conf entries in the wrong order

Description:

When installing PHP5.2.3 with Apache 1.3.37, it automatically creates the
required entries for me in httpd.conf.

Unfortunately, it creates them such that Apache won't start.

Expected result:

Lines will be created as follows;

#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
LoadModule php5_module "C:\\Program Files\\PHP\\php5apache.dll"
PHPIniDir "C:\\Program Files\\PHP\\"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL


Actual result:
--
Lines are created as follows:

#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
PHPIniDir "C:\\Program Files\\PHP\\"
LoadModule php5_module "C:\\Program Files\\PHP\\php5apache.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL


Apache then fails to load due to the fact it doesn't understand PHPIniDir.

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

#36656 [NEW]: http_build_query generates invalid URIs due to use of square brackets

[php at colin dot guthr dot ie]

From: php at colin dot guthr dot ie
Operating system: Linux 2.6.12
PHP version:  5.1.2
PHP Bug Type: *URL Functions
Bug description:  http_build_query generates invalid URIs due to use of square 
brackets

Description:

According to RFC3986, which I beleive to be the latest in a long line of
RFCs on URI syntaxt, it is illegal to use square brackets in the search
string.

There is a comment on the PHP manual page for rawurlencode that states
that these are now permitted but extensive RFC reading and googling fails
to back this up for me.

>From what I can gather they should be encoded as %5B and %5D.

Here is the pseudo fix: str_replace(array('[',']'), array('%5B','%5D'),
http_build_query(array('hello' => array('interesting','eh'

The fix is quite simple and some small changes need to be made to http.c -
I've not got a patch unfortunatly, but it should only take a short while to
fix and would probably take just as long as a patch review ;)

Reproduce code:
---
echo http_build_query(array('hello' => array('interesting','eh')))."\n";

Expected result:

hello%5B0%5D=interesting&hello%5B1%5D=eh

Actual result:
--
hello[0]=interesting&hello[1]=eh

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

#34243 [NEW]: ReflectionClass::getDocComment() returns no result

[colin at encode dot net dot au]

From: colin at encode dot net dot au
Operating system: Win XP SP2
PHP version:  5.1.0RC1
PHP Bug Type: Scripting Engine problem
Bug description:  ReflectionClass::getDocComment() returns no result

Description:

The getDocComment() method from the Reflection API (in this case, the
ReflectionClass class) returns no result where an if block exists before
the documentation comment.

Reproduce code:
---
if (!class_exists('AnotherObject'))
{
   require("anotherobject.php");
}

/**
 * Comment to test getDocComment()
 */

class TestObject
{

}

$rclass = new ReflectionClass('TestObject');

echo "Comment: '".$rclass->getDocComment()."'";

Expected result:

Comment: '/** * Comment to test getDocComment() */'

Actual result:
--
Comment: ''

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

Bug #50027 [Csd]: $this becomes a non-object

[phpbugs at colin dot guthr dot ie]

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

 ID: 50027
 User updated by:phpbugs at colin dot guthr dot ie
 Reported by:phpbugs at colin dot guthr dot ie
 Summary:$this becomes a non-object
 Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Mandriva Linux (Cooker x86_64)
 PHP Version:5.3.1RC2
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

The revision was mentioned a few comments back: r303016

http://svn.php.net/viewvc?view=revision&revision=303016
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/Zend/zend_gc.c?r1=297307&r2=303016&pathrev=303016


According to the log:
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_4/Zend/zend_gc.c?view=log

This was included in PHP 5.3.4.


Previous Comments:

[2011-09-07 23:38:55] brian dot feaver at sellingsource dot com

Looking through the SVN log and the change log for releases since this was 
fixed, 
I can't find when this was released, nor the commit to SVN that fixed it.

What commit fixed it and what release was this fixed in?


[2011-01-16 22:10:12] s...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




[2010-11-16 11:10:35] phpbugs at colin dot guthr dot ie

So far so good! I updated to PHP 5.3.3 again and reproduced the error (and got 
four nice core dumps), then applied the patch and tried to reproduce again and 
so far, I'm coreless.

Thanks for highlighting the patch. Just with this bug had lead to more 
investigations earlier as I've had to jump through hoops to avoid updating to 
PHP 5.3.x because of this problem. Still hopefully looking good now :)


[2010-11-16 09:38:23] bsteinbrink at saltation dot de

We encountered this bug yesterday (we could reproduce it quite easily with our 
code, but unfortunately we cannot disclose it), debugged it, found out that it 
was due to the GC corrupting the std_object_handlers prototype and once we knew 
that, we checked with the svn repo and saw that that was fixed in r303016.

The corruption that happens is that the read_property field of 
std_object_handlers gets set to NULL, because the GC treated the handler as a 
zval.

The report from lukas about the failure to set a property seems like an 
independent bug, as a different field got corrupted (and he had the gc turned 
off anyway).


[2010-11-10 15:44:51] lukas at twobits dot cz

Bad news. Just got the same bug again, with PHP 5.3.3 and GC switched OFF. 
Again, only one Apache process fails. The process begun failing immediately 
after Apache restart. A simple reproduce class:

Reproduce code:
---
class Test
{

private $data = NULL;

public function __construct($data)
{
echo "";
var_dump($this);
echo "";
$this->data = $data;
}

public function getData()
{
echo "";
var_dump($this);
echo "";
return $this->data;
}
}

echo "PID: " . getmypid();

$foo = new Test('Hello');

echo $foo->getData();


Correct output:
---
PID: 22839
object(Test)#1 (1) {
  ["data":"Test":private]=>
  NULL
}
object(Test)#1 (1) {
  ["data":"Test":private]=>
  string(5) "Hello"
}
Hello

Malfunctioning Apache process output:
-
PID: 22818
object(Test)#1 (1) {
  ["data":"Test":private]=>
  NULL
}
Warning: Attempt to assign property of non-object in /var/www/html/testthis.php 
on line 16 
object(Test)#1 (1) {
  ["data":"Test":private]=>
  NULL
}




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

https://bugs.php.net/bug.php?id=50027


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

Bug #13880 [Com]: date(I) does not correctly identify daylight saving time

[colin dot mutter at gmail dot com]

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

 ID: 13880
 Comment by: colin dot mutter at gmail dot com
 Reported by:bmplummer1 at home dot com
 Summary:date(I) does not correctly identify daylight saving
 time
 Status: Bogus
 Type:   Bug
 Package:Date/time related
 Operating System:   Windows NT/XP
 PHP Version:4.0.6
 Block user comment: N
 Private report: N

 New Comment:

Bradford, yes it's been 10 years, but I thought I should not leave this 
question 
unanswered.

If you ran your test on the 31st (as you mentioned), but just subtracted "1" 
from 
the month, you would have a date like "2001-06-31";  There is no such date, 
thus 
PHP rounds to a real date:

echo date("Y-m-d", strtotime("2001-06-31"));
// => 2001-07-01


Previous Comments:

[2001-11-01 01:34:05] bmplummer1 at home dot com

cnewbill said this:

Two obvious problems with your test script.
I should be in quotes, and = should be ==.  Make those changes and try again.
This works okay on Linux.
-Chris

--

First of all...
You are right.  I left the quotes out of my bug report.  I was, however, using 
them in the actual script.  If you tested my script you may have also noticed 
that the following commands return a zero on a Win32 system when they should 
return a one:

echo date("I", mktime(0,0,0,5,1,2001));
echo date("I", mktime(0,0,0,6,1,2001));
echo date("I", mktime(0,0,0,7,1,2001));
echo date("I", mktime(0,0,0,8,1,2001));
echo date("I", mktime(0,0,0,9,1,2001));
echo date("I", mktime(0,0,0,10,1,2001));

  Also returning a zero instead of a one are:

echo date("I", mktime(0,0,0,date("m")-1,date("d"),  date("Y")));
echo date("I", mktime(0,0,0,date("m")-2,date("d"),  date("Y")));
echo date("I", mktime(0,0,0,date("m")-3,date("d"),  date("Y")));
echo date("I", mktime(0,0,0,date("m")-4,date("d"),  date("Y")));
echo date("I", mktime(0,0,0,date("m")-5,date("d"),  date("Y")));
echo date("I", mktime(0,0,0,date("m")-6,date("d"),  date("Y")));
echo date("I", mktime(0,0,0,date("m")-7,date("d"),  date("Y")));

So it doesn't seem to matter how I format the original if/then statement 
because it will always evaluate incorrectly because date() is doing something 
screwy on Win32.  Also, I found something else while working on this.  When 
using the M format, date() has a problem figuring out what month name it is 
supposed to return.  Here is some example script:

echo date("M, I", mktime(0,0,0,date("m")-1,date("d"),  date("Y")));
echo "";
echo date("M, I", mktime(0,0,0,date("m")-2,date("d"),  date("Y")));
echo "";
echo date("M, I", mktime(0,0,0,date("m")-3,date("d"),  date("Y")));
echo "";
echo date("M, I", mktime(0,0,0,date("m")-4,date("d"),  date("Y")));
echo "";
echo date("M, I", mktime(0,0,0,date("m")-5,date("d"),  date("Y")));
echo "";
echo date("M, I", mktime(0,0,0,date("m")-6,date("d"),  date("Y")));
echo "";
echo date("M, I", mktime(0,0,0,date("m")-7,date("d"),  date("Y")));

  That script returns this on my Win32 system:

Oct, 0
Aug, 0
Jul, 0
Jul, 0
May, 0
May, 0
Mar, 0

  At least it did for my yesterday (31 Oct 2001).  Notice how Jul and May 
are doubled?  What happened to Apr and Jun?

Could you check in to these issues and let me know what you find out.  By the 
way, thank you for responding so quickly.
Bradford Plummer


[2001-10-30 19:36:33] cnewb...@php.net

Works on Windows XP as well with 4.0.6.

-Chris


[2001-10-30 19:36:28] cnewb...@php.net

Works on Windows XP as well with 4.0.6.

-Chris


[2001-10-30 19:33:48] cnewb...@php.net

Two obvious problems with your test script.

I should be in quotes, and = should be ==.  Make those changes and try again.

This works okay on Linux.

-Chris


[2001-10-30 19:25:30] bmplummer1 at home dot com

There appears to be a bug in

#35848 [Com]: Failing when including --with-mysql

[colin dot anderson at red-man dot com]

 ID:   35848
 Comment by:   colin dot anderson at red-man dot com
 Reported By:  shawn dot richards at ink dot ltd dot uk
 Status:   No Feedback
 Bug Type: MySQL related
 Operating System: Mac OS X Tiger.
 PHP Version:  5CVS-2005-12-30 (snap)
 Assigned To:  andrey
 New Comment:

You're getting this problem because the MySQL >>binaries<< do not come
with certain libraries that are created when you build from source on
INTEL systems.

To resolve this problem, you need to download the appropriate
libraries.

Visit >> http://dev.mysql.com/downloads/os-linux.html

And grab the appropriate library for your server.  All of the latest
MySQL releases are compiled with the ICC9 libraries; so grab those for
your appropriate architecture.

This should solve your problems; as stated repeatedly above,
--WITH-MYSQL-DIR[=DIR] WILL NOT WORK.  :P


Previous Comments:


[2007-01-09 20:14:56] dweller at devonweller dot com

I experienced this same problem on Mac OS X 10.4 with the 64 bit
package of MySQL 5.0.27.

I installed the 32-bit version of MySQL 5.0.27.  After that, the php
compilation worked successfully.



[2006-11-21 16:43:33] nicolasboulet at maisonlaprise dot com

Thanks alot!
The with-mysql-dir= command also fixed my problem on Suse Linux 10.1.
Many thanks!
Nicolas



[2006-11-17 14:25:21] furyx001 at umn dot edu

Has there been any update on the status of this?  I was able to
reproduce this as well on OS 10.4.8 Server using the 64 bit edition of
MySQL (which I installed from a package).



[2006-10-29 23:30:25] davxoc at hotmail dot com

Hi everybody!!!, I had the same problem, but looking for and answer I
found two things that can help me to solve it...

The first one is located on http://lists.mysql.com/internals/34023

On this link explain which is the problem of integration of mysql, and
give an answer ...

http://dev.mysql.com/downloads/os-linux.html

I had to download the libraries, after tried a lot, and reading the
man's help from php config file (configure --help), found the
solution.

Finally those are the lines to compile my LAMP AND LAPP
"framework's"

./configure --prefix=/usr/local/php5 
--with-apxs2=/usr/local/web/bin/apxs --enable-sockets 
--with-config-file-path=/usr/local/php5
--with-mysql-dir=/usr/local/mysql --with-pgsql=/usr/local/pgsql
--with-zlib-dir=/usr/local/zlib-1.2.3 
--with-libdir=/usr/local/intel-icc8-libs-8.1-i386


and tha's all!!!
I hope that can help!!...



[2006-09-28 10:57:13] rafudu at gmail dot com

I was having the same trouble..so I've checked the md5sum of my Mysql
tarball and it was corrupted. So, I've downloaded and installed again
and it worked.
:D



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

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