#35634 [Bgs->Opn]: Erroneous "Class declarations may not be nested" error raised.
ID: 35634 User updated by: robert at interjinn dot com Reported By: robert at interjinn dot com -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.1.1 New Comment: I think this report should be given further consideration. I've read the docs (not that I hadn't before), and I will assume you think this is bogus because of the following int he PHP docs: The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called. However, the E_STRICT raised int he error handler script should not be raised in the first place since it is PHP erroneous context that believes the class declaration is being nested, when in fact the class declaration is not being nested. If the include context was properly scoped, then no E_STRICT would be raised and I wouldn't be having a problem. If this is not why this bug was marked bogus, please shed some light for me, since the bogus comment was pretty uninformative (yes I know you're busy and don't have time for 50 million bogus bugs but there's only so much RTFM I can do and hope I can come across exactly what you think makes this a bogus bug). Cheers, Rob. Previous Comments: [2005-12-11 23:19:59] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php ---- [2005-12-11 19:15:37] robert at interjinn dot com Description: PHP bails out with class declaration nesting error when an error handler dynamically loads an error handling class during a class related E_STRICT warning. Reproduce code: --- test.php handleException( $errorNumber, $errorMessage, $fileName, $lineNumber ); } require_once( 'testClass.php' ); $test = new TestClass(); ?> - testClass.php __construct(); } } ?> - errorClass.php Expected result: I expect to properly be able to handle the following E_STRICT in my custom error class: Strict Standards: Redefining already defined constructor for class TestClass in /home/suds/testClass.php on line 9 Actual result: -- Fatal error: Class declarations may not be nested in /home/suds/errorClass.php on line 4 -- Edit this bug report at http://bugs.php.net/?id=35634&edit=1
#35634 [NEW]: Erroneous "Class declarations may not be nested" error raised.
From: robert at interjinn dot com Operating system: Linux PHP version: 5.1.1 PHP Bug Type: Scripting Engine problem Bug description: Erroneous "Class declarations may not be nested" error raised. Description: PHP bails out with class declaration nesting error when an error handler dynamically loads an error handling class during a class related E_STRICT warning. Reproduce code: --- test.php handleException( $errorNumber, $errorMessage, $fileName, $lineNumber ); } require_once( 'testClass.php' ); $test = new TestClass(); ?> - testClass.php __construct(); } } ?> - errorClass.php Expected result: I expect to properly be able to handle the following E_STRICT in my custom error class: Strict Standards: Redefining already defined constructor for class TestClass in /home/suds/testClass.php on line 9 Actual result: -- Fatal error: Class declarations may not be nested in /home/suds/errorClass.php on line 4 -- Edit bug report at http://bugs.php.net/?id=35634&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35634&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35634&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35634&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35634&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35634&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35634&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35634&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35634&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35634&r=support Expected behavior:http://bugs.php.net/fix.php?id=35634&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35634&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35634&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35634&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35634&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35634&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35634&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35634&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35634&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35634&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35634&r=mysqlcfg
#26598 [NoF->Csd]: Segmentation fault
ID: 26598 User updated by: robert at interjinn dot com Reported By: robert at interjinn dot com -Status: No Feedback +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * -PHP Version: 5CVS-2003-12-15 +PHP Version: 5CVS-2004-01-25 New Comment: Sorry to get to this so long after the last update. Somehow the email got filed under spam. Anyways I just checked out the latest CVS and tested. Everything works perfectly. Well done and thanks. Rob. Previous Comments: [2004-01-01 20:51:50] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-12-27 18:07:14] [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 [2003-12-16 05:05:58] robert at interjinn dot com Hmmm, that's interesting. How does include() work? I always thought of it as an evaluation outside of the working scope. I checked the gdb backtrace for the code sample in bug #26065 and it segfaults on the same code, but at different points in the source, namely: if (CG(active_class_entry)->ce_flags & ZEND_ACC_INTERFACE) Cheers, Rob. [2003-12-16 02:57:21] [EMAIL PROTECTED] btw. bug #26065 looks quite similar to this. [2003-12-16 02:52:48] [EMAIL PROTECTED] http://www.interjinn.com/download/interJinn-0.9.1-php5mods-3.tar.gz 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/26598 -- Edit this bug report at http://bugs.php.net/?id=26598&edit=1
#26598 [Ver]: Segmentation fault
ID: 26598
User updated by: robert at interjinn dot com
Reported By: robert at interjinn dot com
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2003-12-15
New Comment:
Hmmm, that's interesting. How does include() work? I always thought of
it as an evaluation outside of the working scope. I checked the gdb
backtrace for the code sample in bug #26065 and it segfaults on the
same code, but at different points in the source, namely:
if (CG(active_class_entry)->ce_flags & ZEND_ACC_INTERFACE)
Cheers,
Rob.
Previous Comments:
[2003-12-16 02:57:21] [EMAIL PROTECTED]
btw. bug #26065 looks quite similar to this.
[2003-12-16 02:52:48] [EMAIL PROTECTED]
http://www.interjinn.com/download/interJinn-0.9.1-php5mods-3.tar.gz
[2003-12-15 17:33:49] [EMAIL PROTECTED]
Start by removing all the unnecessary lines from the first file, all
unnecessary include()'s etc. Then remove all the includes, ie. put the
stuff in one file. But only those parts of the code that are necessary
for the reduced first file..
Just remove stuff line by line, run the code and if it still crashes,
continue nuking the code until it doesn't crash. :)
[2003-12-15 15:03:09] robert at interjinn dot com
As stated previously I was unable to come up with a short script that
can reproduce the bug. I attached a link to a big script in my last
response. I apologize if this is not suitable but I don't see another
alternative.
----
[2003-12-12 18:10:28] robert at interjinn dot com
I hav recompiled with minimal extensions compiled in, namely:
./configure \
--disable-all \
--with-pcre-regex \
--prefix=/usr/local/php/${PHP_VERSION_DIR}/installation \
--exec-prefix=/usr/local/php/${PHP_VERSION_DIR}/installation
And I still have a no go. I spent the last 3 hours trying to produce a
short script which would illustrate the bug and running the PHP binary
through GDB and Valgrind to no avail. What I do know is that at:
zend_do_declare_property
(/usr/local/php/php5-200312120830/Zend/zend_compile.c:2442)
CG(active_class_entry) evaluates to null and so
CG(active_class_entry)->ce_flags causes a NULL pointer fault. I tried
patching with a test for NULL, but then I got a crash in
zend_hash_find() where the memory for the hash appeared to be corrupted
- Valgrind was not useful in determining where the memory may have
become corrupt.
I was going to set up a link to an InterJinn download, but while I was
testing to make sure it ran, I got the following error (possibly
related to this bug):
Fatal error: Only variables or references can be returned by
reference in
/home/suds/yackspit/interJinn-0.9.1/Core/libraries/templateJinn/templateManager.inc
on line 17
For which the actual line of code is:
var $filename = __FILE__;
which is in a class. If it is also helpful I get a LOT of deprecated
warnings for:
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers.
The reason I think maybe the above is related is because in the
backtrace of the original report, and more recent ones with minimal
extensions, the zend_do_declare_property() function is attmepting to
work with a property called "filename".
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/26598
--
Edit this bug report at http://bugs.php.net/?id=26598&edit=1
#26598 [Fbk->Opn]: Segmentation fault
ID: 26598 User updated by: robert at interjinn dot com Reported By: robert at interjinn dot com -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Mandrake 9.0 PHP Version: 5CVS-2003-12-12 (dev) New Comment: The following does NOT combine everything into one file since when I do that the segmentation fault disappears. However, it does shrink the code into as few files as possible. http://www.interjinn.com/download/interJinn-0.9.1-php5mods-3.tar.gz FYI, I'm not getting payed for this, I don't get payed to do InterJinn, and I have very little disposable time lately since I became a father 3 weeks ago. I'm doing this because I came across a bug and thought I would help out, I was not paricularly in a rush to ensure InterJinn has PHP5 compatibility, since I don't think it's going to have massive adoption for a year or two. I just happened to have a little spare time one night to test. Now I've spent about 10 hours debugging, trimming, and rewriting various chunks of my application all so I could help you guys. Time which probably would have been better spent helping my wife with the baby. A little tolerance and less sarcasm would be great for your karma. Thanks, Rob. Previous Comments: [2003-12-15 23:56:02] [EMAIL PROTECTED] Maybe I wasn't clear enough..but I think I said something about ONE file..? And that generating of some weird configuration file really wasn't necessary either? (one file -> no need for includes -> no need for config file) hardcode the stuff.. ------------ [2003-12-15 20:46:46] robert at interjinn dot com I have done as you asked and stripped away everything that I could while still reproducing the same segmentation fault. You can download the tarball at this following location: http://www.interjinn.com/download/interJinn-0.9.1-php5mods-2.tar.gz [2003-12-15 17:33:49] [EMAIL PROTECTED] Start by removing all the unnecessary lines from the first file, all unnecessary include()'s etc. Then remove all the includes, ie. put the stuff in one file. But only those parts of the code that are necessary for the reduced first file.. Just remove stuff line by line, run the code and if it still crashes, continue nuking the code until it doesn't crash. :) ---------------- [2003-12-15 15:03:09] robert at interjinn dot com As stated previously I was unable to come up with a short script that can reproduce the bug. I attached a link to a big script in my last response. I apologize if this is not suitable but I don't see another alternative. [2003-12-15 09:43:05] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26598 -- Edit this bug report at http://bugs.php.net/?id=26598&edit=1
#26598 [Fbk->Opn]: Segmentation fault
ID: 26598 User updated by: robert at interjinn dot com Reported By: robert at interjinn dot com -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Mandrake 9.0 PHP Version: 5CVS-2003-12-12 (dev) New Comment: I have done as you asked and stripped away everything that I could while still reproducing the same segmentation fault. You can download the tarball at this following location: http://www.interjinn.com/download/interJinn-0.9.1-php5mods-2.tar.gz Previous Comments: [2003-12-15 17:33:49] [EMAIL PROTECTED] Start by removing all the unnecessary lines from the first file, all unnecessary include()'s etc. Then remove all the includes, ie. put the stuff in one file. But only those parts of the code that are necessary for the reduced first file.. Just remove stuff line by line, run the code and if it still crashes, continue nuking the code until it doesn't crash. :) [2003-12-15 15:03:09] robert at interjinn dot com As stated previously I was unable to come up with a short script that can reproduce the bug. I attached a link to a big script in my last response. I apologize if this is not suitable but I don't see another alternative. [2003-12-15 09:43:05] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2003-12-14 21:17:36] robert at interjinn dot com I compiled and ran the latest CVS snapshot with the minimal compile options indicated in a recent post with the same results. Engine still segfaults at the same line of code. On the flip side, I also tried the binary on the script I wanted to make available that illustrates the problem, and it now works (so the bug previously mentioned as Fatal error: Only variables or references can be returned by reference in /home/suds/yackspit/interJinn-0.9.1/Core/libraries/templateJinn/templ ateManager.inc on line 17 is now fixed.) So to test you can download the following link: http://www.interjinn.com/download/interJinn-0.9.1-php5mods.tar.gz then switch into the created directory (interJinn-0.9.1-php5mods) and type: $ /usr/bin/wherever/phpbinary -qC makeInterJinnSite.php The segfault should occur immediately after a bunch of deprecation warnings. HTH, Rob. [2003-12-14 20:23:25] [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 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/26598 -- Edit this bug report at http://bugs.php.net/?id=26598&edit=1
#26598 [Fbk->Opn]: Segmentation fault
ID: 26598
User updated by: robert at interjinn dot com
Reported By: robert at interjinn dot com
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Mandrake 9.0
PHP Version: 5CVS-2003-12-12 (dev)
New Comment:
As stated previously I was unable to come up with a short script that
can reproduce the bug. I attached a link to a big script in my last
response. I apologize if this is not suitable but I don't see another
alternative.
Previous Comments:
[2003-12-15 09:43:05] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2003-12-14 21:17:36] robert at interjinn dot com
I compiled and ran the latest CVS snapshot with the minimal compile
options indicated in a recent post with the same results. Engine still
segfaults at the same line of code. On the flip side, I also tried the
binary on the script I wanted to make available that illustrates the
problem, and it now works (so the bug previously mentioned as Fatal
error: Only variables or references can be returned by
reference in
/home/suds/yackspit/interJinn-0.9.1/Core/libraries/templateJinn/templ
ateManager.inc on line 17 is now fixed.)
So to test you can download the following link:
http://www.interjinn.com/download/interJinn-0.9.1-php5mods.tar.gz
then switch into the created directory (interJinn-0.9.1-php5mods) and
type:
$ /usr/bin/wherever/phpbinary -qC makeInterJinnSite.php
The segfault should occur immediately after a bunch of deprecation
warnings.
HTH,
Rob.
[2003-12-14 20:23:25] [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
[2003-12-12 18:10:28] robert at interjinn dot com
I hav recompiled with minimal extensions compiled in, namely:
./configure \
--disable-all \
--with-pcre-regex \
--prefix=/usr/local/php/${PHP_VERSION_DIR}/installation \
--exec-prefix=/usr/local/php/${PHP_VERSION_DIR}/installation
And I still have a no go. I spent the last 3 hours trying to produce a
short script which would illustrate the bug and running the PHP binary
through GDB and Valgrind to no avail. What I do know is that at:
zend_do_declare_property
(/usr/local/php/php5-200312120830/Zend/zend_compile.c:2442)
CG(active_class_entry) evaluates to null and so
CG(active_class_entry)->ce_flags causes a NULL pointer fault. I tried
patching with a test for NULL, but then I got a crash in
zend_hash_find() where the memory for the hash appeared to be corrupted
- Valgrind was not useful in determining where the memory may have
become corrupt.
I was going to set up a link to an InterJinn download, but while I was
testing to make sure it ran, I got the following error (possibly
related to this bug):
Fatal error: Only variables or references can be returned by
reference in
/home/suds/yackspit/interJinn-0.9.1/Core/libraries/templateJinn/templateManager.inc
on line 17
For which the actual line of code is:
var $filename = __FILE__;
which is in a class. If it is also helpful I get a LOT of deprecated
warnings for:
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers.
The reason I think maybe the above is related is because in the
backtrace of the original report, and more recent ones with minimal
extensions, the zend_do_declare_property() function is attmepting to
work with a property called "filename".
[2003-12-12 06:49:03] [EMAIL PROTECTED]
Don't forget to remove the non-standard exts from your PHP config
either.
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/26598
--
Edit this bug report at http://bugs.php.net/?id=26598&edit=1
#26598 [Fbk->Opn]: Segmentation fault
ID: 26598
User updated by: robert at interjinn dot com
Reported By: robert at interjinn dot com
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Mandrake 9.0
PHP Version: 5CVS-2003-12-12 (dev)
New Comment:
I compiled and ran the latest CVS snapshot with the minimal compile
options indicated in a recent post with the same results. Engine still
segfaults at the same line of code. On the flip side, I also tried the
binary on the script I wanted to make available that illustrates the
problem, and it now works (so the bug previously mentioned as Fatal
error: Only variables or references can be returned by
reference in
/home/suds/yackspit/interJinn-0.9.1/Core/libraries/templateJinn/templ
ateManager.inc on line 17 is now fixed.)
So to test you can download the following link:
http://www.interjinn.com/download/interJinn-0.9.1-php5mods.tar.gz
then switch into the created directory (interJinn-0.9.1-php5mods) and
type:
$ /usr/bin/wherever/phpbinary -qC makeInterJinnSite.php
The segfault should occur immediately after a bunch of deprecation
warnings.
HTH,
Rob.
Previous Comments:
[2003-12-14 20:23:25] [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
[2003-12-12 18:10:28] robert at interjinn dot com
I hav recompiled with minimal extensions compiled in, namely:
./configure \
--disable-all \
--with-pcre-regex \
--prefix=/usr/local/php/${PHP_VERSION_DIR}/installation \
--exec-prefix=/usr/local/php/${PHP_VERSION_DIR}/installation
And I still have a no go. I spent the last 3 hours trying to produce a
short script which would illustrate the bug and running the PHP binary
through GDB and Valgrind to no avail. What I do know is that at:
zend_do_declare_property
(/usr/local/php/php5-200312120830/Zend/zend_compile.c:2442)
CG(active_class_entry) evaluates to null and so
CG(active_class_entry)->ce_flags causes a NULL pointer fault. I tried
patching with a test for NULL, but then I got a crash in
zend_hash_find() where the memory for the hash appeared to be corrupted
- Valgrind was not useful in determining where the memory may have
become corrupt.
I was going to set up a link to an InterJinn download, but while I was
testing to make sure it ran, I got the following error (possibly
related to this bug):
Fatal error: Only variables or references can be returned by
reference in
/home/suds/yackspit/interJinn-0.9.1/Core/libraries/templateJinn/templateManager.inc
on line 17
For which the actual line of code is:
var $filename = __FILE__;
which is in a class. If it is also helpful I get a LOT of deprecated
warnings for:
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers.
The reason I think maybe the above is related is because in the
backtrace of the original report, and more recent ones with minimal
extensions, the zend_do_declare_property() function is attmepting to
work with a property called "filename".
[2003-12-12 06:49:03] [EMAIL PROTECTED]
Don't forget to remove the non-standard exts from your PHP config
either.
[2003-12-12 06:28:00] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2003-12-12 05:17:46] robert at interjinn dot com
Description:
No idea why script crashes. I'm including my compile information and
the backtrace.
export PHP_VERSION_DIR=php5-200312120830
make clean
rm config.cache
./configure \
--disable-all \
--with-mysql \
--enable-carnagemath \
--enable-carnagexml \
--enable-carnageutilities \
--enable-interjinn \
--enable-ctype \
--with-zlib \
--enable-ftp \
--enable-sockets \
--with-ncurses \
--enable-pcntl \
--with-pcre-regex \
--enable-exif \
--with-jpeg-dir=/usr/lib \
--with-png-dir=/usr/lib \
--with-tiff-dir=/usr/lib \
--with-gif-dir=/usr/lib \
--with-gd \
--prefix=/usr/local/php/${PHP_VERSION_DIR}/installation \
--exec-prefix=/usr/local/php/${PHP_VERSION_DIR}/installation
make
make install
#26598 [Fbk->Opn]: Segmentation fault
ID: 26598
User updated by: robert at interjinn dot com
Reported By: robert at interjinn dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Mandrake 9.0
PHP Version: 5CVS-2003-12-12 (dev)
New Comment:
I hav recompiled with minimal extensions compiled in, namely:
./configure \
--disable-all \
--with-pcre-regex \
--prefix=/usr/local/php/${PHP_VERSION_DIR}/installation \
--exec-prefix=/usr/local/php/${PHP_VERSION_DIR}/installation
And I still have a no go. I spent the last 3 hours trying to produce a
short script which would illustrate the bug and running the PHP binary
through GDB and Valgrind to no avail. What I do know is that at:
zend_do_declare_property
(/usr/local/php/php5-200312120830/Zend/zend_compile.c:2442)
CG(active_class_entry) evaluates to null and so
CG(active_class_entry)->ce_flags causes a NULL pointer fault. I tried
patching with a test for NULL, but then I got a crash in
zend_hash_find() where the memory for the hash appeared to be corrupted
- Valgrind was not useful in determining where the memory may have
become corrupt.
I was going to set up a link to an InterJinn download, but while I was
testing to make sure it ran, I got the following error (possibly
related to this bug):
Fatal error: Only variables or references can be returned by
reference in
/home/suds/yackspit/interJinn-0.9.1/Core/libraries/templateJinn/templateManager.inc
on line 17
For which the actual line of code is:
var $filename = __FILE__;
which is in a class. If it is also helpful I get a LOT of deprecated
warnings for:
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers.
The reason I think maybe the above is related is because in the
backtrace of the original report, and more recent ones with minimal
extensions, the zend_do_declare_property() function is attmepting to
work with a property called "filename".
Previous Comments:
[2003-12-12 06:49:03] [EMAIL PROTECTED]
Don't forget to remove the non-standard exts from your PHP config
either.
[2003-12-12 06:28:00] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2003-12-12 05:17:46] robert at interjinn dot com
Description:
No idea why script crashes. I'm including my compile information and
the backtrace.
export PHP_VERSION_DIR=php5-200312120830
make clean
rm config.cache
./configure \
--disable-all \
--with-mysql \
--enable-carnagemath \
--enable-carnagexml \
--enable-carnageutilities \
--enable-interjinn \
--enable-ctype \
--with-zlib \
--enable-ftp \
--enable-sockets \
--with-ncurses \
--enable-pcntl \
--with-pcre-regex \
--enable-exif \
--with-jpeg-dir=/usr/lib \
--with-png-dir=/usr/lib \
--with-tiff-dir=/usr/lib \
--with-gif-dir=/usr/lib \
--with-gd \
--prefix=/usr/local/php/${PHP_VERSION_DIR}/installation \
--exec-prefix=/usr/local/php/${PHP_VERSION_DIR}/installation
make
make install
Program received signal SIGSEGV, Segmentation fault.
zend_do_declare_property (var_name=0xbffed0e0, value=0xbffed110,
access_type=256)
at /usr/local/php/php5-200312120830/Zend/zend_compile.c:2442
2442if (CG(active_class_entry)->ce_flags &
ZEND_ACC_INTERFACE) {
(gdb) bt
#0 zend_do_declare_property (var_name=0xbffed0e0, value=0xbffed110,
access_type=256)
at /usr/local/php/php5-200312120830/Zend/zend_compile.c:2442
#1 0x08121b3a in zendparse () at Zend/zend_language_parser.c:2545
#2 0x0812371e in compile_file (file_handle=0xbffee4e0, type=2) at
Zend/zend_language_scanner.c:3139
#3 0x08155ad1 in zend_include_or_eval_handler
(execute_data=0xbfff0ad0, op_array=0x0)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:3355
#4 0x08151442 in execute (op_array=0x4032039c) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#5 0x0815407a in zend_do_fcall_common_helper (execute_data=0xbfff5180,
op_array=0x40315e44)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:2580
#6 0x081542c9 in zend_do_fcall_by_name_handler (execute_data=0x0,
op_array=0x40315e44)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:2666
#7 0x08151442 in execute (op_array=0x40315e44) at
/usr/local/php/php5-2003121
#26598 [NEW]: Segmentation fault
From: robert at interjinn dot com
Operating system: Mandrake 9.0
PHP version: 5CVS-2003-12-12 (dev)
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault
Description:
No idea why script crashes. I'm including my compile information and the
backtrace.
export PHP_VERSION_DIR=php5-200312120830
make clean
rm config.cache
./configure \
--disable-all \
--with-mysql \
--enable-carnagemath \
--enable-carnagexml \
--enable-carnageutilities \
--enable-interjinn \
--enable-ctype \
--with-zlib \
--enable-ftp \
--enable-sockets \
--with-ncurses \
--enable-pcntl \
--with-pcre-regex \
--enable-exif \
--with-jpeg-dir=/usr/lib \
--with-png-dir=/usr/lib \
--with-tiff-dir=/usr/lib \
--with-gif-dir=/usr/lib \
--with-gd \
--prefix=/usr/local/php/${PHP_VERSION_DIR}/installation \
--exec-prefix=/usr/local/php/${PHP_VERSION_DIR}/installation
make
make install
Program received signal SIGSEGV, Segmentation fault.
zend_do_declare_property (var_name=0xbffed0e0, value=0xbffed110,
access_type=256)
at /usr/local/php/php5-200312120830/Zend/zend_compile.c:2442
2442if (CG(active_class_entry)->ce_flags & ZEND_ACC_INTERFACE)
{
(gdb) bt
#0 zend_do_declare_property (var_name=0xbffed0e0, value=0xbffed110,
access_type=256)
at /usr/local/php/php5-200312120830/Zend/zend_compile.c:2442
#1 0x08121b3a in zendparse () at Zend/zend_language_parser.c:2545
#2 0x0812371e in compile_file (file_handle=0xbffee4e0, type=2) at
Zend/zend_language_scanner.c:3139
#3 0x08155ad1 in zend_include_or_eval_handler (execute_data=0xbfff0ad0,
op_array=0x0)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:3355
#4 0x08151442 in execute (op_array=0x4032039c) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#5 0x0815407a in zend_do_fcall_common_helper (execute_data=0xbfff5180,
op_array=0x40315e44)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:2580
#6 0x081542c9 in zend_do_fcall_by_name_handler (execute_data=0x0,
op_array=0x40315e44)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:2666
#7 0x08151442 in execute (op_array=0x40315e44) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#8 0x0815407a in zend_do_fcall_common_helper (execute_data=0xbfff9e30,
op_array=0x40282c04)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:2580
#9 0x081542c9 in zend_do_fcall_by_name_handler (execute_data=0x0,
op_array=0x40282c04)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:2666
#10 0x08151442 in execute (op_array=0x40282c04) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#11 0x08155b55 in zend_include_or_eval_handler (execute_data=0xbfffbbc0,
op_array=0x0)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:3403
#12 0x08151442 in execute (op_array=0x402796b4) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#13 0x08155b55 in zend_include_or_eval_handler (execute_data=0xbfffc000,
op_array=0x0)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:3403
#14 0x08151442 in execute (op_array=0x40278a5c) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#15 0x08139c32 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/local/php/php5-200312120830/Zend/zend.c:1016
#16 0x0810d368 in php_execute_script (primary_file=0xbfffe370)
at /usr/local/php/php5-200312120830/main/main.c:1638
#17 0x0815ac57 in main (argc=3, argv=0xbfffe404) at
/usr/local/php/php5-200312120830/sapi/cgi/cgi_main.c:1564
#18 0x40154082 in __libc_start_main () from /lib/i686/libc.so.6
--
Edit bug report at http://bugs.php.net/?id=26598&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26598&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26598&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26598&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26598&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26598&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26598&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26598&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26598&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26598&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26598&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26598&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26598&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26598&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26598&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26598&r=isa
#25575 [Com]: stream_set_blocking with STDIN doesnt block
ID: 25575 Comment by: robert at interjinn dot com Reported By: bill at baghead dot co dot uk Status: Open Bug Type: Sockets related Operating System: Redhat 9 PHP Version: 4CVS-2003-09-17 (stable) New Comment: I've been directed here from bug #25616 with the indication that this is the same bug. I read this bug before I posted bug #25616 and the issues seems different. This one describes an issue with blocking mode, my bug describes an issue whith the script exitting successfully while in an infinite loop, which is contrary to the expected functionality of a while( 1 ) loop. I'm not sure why I was pointed here. Albeit my bug seemed to come into existence with the use of stream_set_blocking( $stdin, FALSE ) Previous Comments: [2003-09-18 04:15:44] bill at baghead dot co dot uk The case is with the original code stated, the code loops, and does not block on the fread - ie, it keeps returning instantly (even with nothing), which seems to me to be non blocking eventhough I'd told it to block.. If I remove the stream_set_blocking(STDIN,TRUE); altogether, fread appears to block - but instead of returning after receiving a block of data, it blocks until the buffer is filled up (in this case being 128 bytes) - *then* it returns.. [2003-09-17 18:37:38] [EMAIL PROTECTED] What you have just described is blocking IO, and that is precisely what I'd expect to happen when reading from STDIN. Now, when reading from a socket, you would expect the call to return at the end of a packet, but php doesn't yet have any idea that stdin is a socket, and that sounds like the cause of your problems. Can you confirm that this is the case, as your more recent comments don't seem to match up to your original report? [2003-09-17 18:35:41] [EMAIL PROTECTED] Comment sent from user by mail; please don't mail people directly; keep all info related to the bug in the database unless requested to do otherwise. -- What exactly was the workaround? I did try removing the statement, and it kept reading the STDIN with the fread until the amount, in this case being 128 bytes is filled, rather than taking it to the end of the packet... [2003-09-17 13:14:14] [EMAIL PROTECTED] Will you please try the workaround I suggested? I'm not saying it isn't a bug, I'm just suggesting something that might help get your script working in the time it takes for this bug to get fixed. [2003-09-17 12:49:37] bill at baghead dot co dot uk Surely it wouldnt matter if xinetd opened the socket blocking or non-blocking, as the script opens STDIN which needs to be blocking as php is talking to stdin, *not* the socket directly.. 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/25575 -- Edit this bug report at http://bugs.php.net/?id=25575&edit=1
#25616 [Fbk->Opn]: stream-set_blocking() causes unexpected non erroneous exit from script.
ID: 25616 User updated by: robert at interjinn dot com Reported By: robert at interjinn dot com -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Linux version 2.4.19-16mdk PHP Version: 4.3.3 New Comment: I just ran it with the -n flag and no change. Still exits seemingly randomly :( Previous Comments: [2003-09-21 02:44:21] [EMAIL PROTECTED] Works fine for me..I let your script run for few minutes and it works just as expected. Try running it without any php.ini loaded, like this: # php -n test.php (-n will make PHP not load any php.ini) [2003-09-21 01:08:41] robert at interjinn dot com I have downloaded and compiled the PHP package located at http://snaps.php.net/php4-STABLE-latest.tar.gz When I ran the script I got the same result as before. It still exits successfully when it should be in an infinite loop. [2003-09-20 17:46:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-09-20 17:23:27] robert at interjinn dot com Description: When I use stream_set_blocking() to make the standard input file handle non-blocking the script exits seemingly random. For example the $count output can have a last printed value anywhere from 200 to 3000. Reproduce code: --- http://bugs.php.net/?id=25616&edit=1
#25616 [Fbk->Opn]: stream-set_blocking() causes unexpected non erroneous exit from script.
ID: 25616 User updated by: robert at interjinn dot com Reported By: robert at interjinn dot com -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Linux version 2.4.19-16mdk PHP Version: 4.3.3 New Comment: I have downloaded and compiled the PHP package located at http://snaps.php.net/php4-STABLE-latest.tar.gz When I ran the script I got the same result as before. It still exits successfully when it should be in an infinite loop. Previous Comments: [2003-09-20 17:46:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-09-20 17:23:27] robert at interjinn dot com Description: When I use stream_set_blocking() to make the standard input file handle non-blocking the script exits seemingly random. For example the $count output can have a last printed value anywhere from 200 to 3000. Reproduce code: --- http://bugs.php.net/?id=25616&edit=1
#25616 [NEW]: stream-set_blocking() causes unexpected non erroneous exit from script.
From: robert at interjinn dot com Operating system: Linux version 2.4.19-16mdk PHP version: 4.3.3 PHP Bug Type: Filesystem function related Bug description: stream-set_blocking() causes unexpected non erroneous exit from script. Description: When I use stream_set_blocking() to make the standard input file handle non-blocking the script exits seemingly random. For example the $count output can have a last printed value anywhere from 200 to 3000. Reproduce code: --- http://bugs.php.net/?id=25616&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25616&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25616&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25616&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25616&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25616&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25616&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25616&r=support Expected behavior: http://bugs.php.net/fix.php?id=25616&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25616&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25616&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25616&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25616&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25616&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25616&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25616&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25616&r=float
