ID: 26598 Updated by: [EMAIL PROTECTED] Reported By: robert at interjinn dot com -Status: Open +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: Mandrake 9.0 PHP Version: 5CVS-2003-12-12 (dev) New Comment:
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. :) Previous Comments: ------------------------------------------------------------------------ [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 <?php and ends 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 <b>Fatal error</b>: Only variables or references can be returned by reference in <b>/home/suds/yackspit/interJinn-0.9.1/Core/libraries/templateJinn/templ ateManager.inc</b> on line <b>17</b><br /> 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): <b>Fatal error</b>: Only variables or references can be returned by reference in <b>/home/suds/yackspit/interJinn-0.9.1/Core/libraries/templateJinn/templateManager.inc</b> on line <b>17</b><br /> 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: <b>Strict Standards</b>: 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
