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

When using the suggested snapshot, the installer manages to complete successfully.  However, first login generates the following error when register_long_arrays is set ON

( Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 47 bytes) in /home/www/dev/htdocs/sugarsuite-3.5.1a/data/SugarBean.php on line 1087

When register_long_arrays is set off, php generates a segfault, which is apparently a documented problem with Sugar and php5.  This segfault condition also exists in php 5.0.4, however, turning register_log_arrays=On solves this problem in 5.0.4.

I have tested this latest snap shot.  Like the previous 5.1RC4 snap shot, the installer phase completes successfully, however, first login results in an out of memory error as follows:

( Fatal error: Allowed memory size of 67108864 bytes exhausted at /usr/local/apache_src/php5-200510260230/Zend/zend_hash.c:242 (tried to allocate 58 bytes) in /home/www/dev/htdocs/sugarsuite-3.5.1a/data/SugarBean.php on line 1087)

This occurs with register_long_arrays=on.  Unlike the previous snapshot, which segfaulted when register_long_arrays=off, this one generates the same out of memory error regardless of the register_long_arrays setting.

As this drop is not segfaulting I'm not sure how to provide a backtrace of this problem.  Please advise.

TTYL
  CDC

I realize that a general out of memory condition is not a bug.  However, this appears to be some kind of race condition that is consumming memory.  This problem in new since version 5.0.4.  The same code runs fine under 5.0.4 but generates this race condition in 5.0.5 and newer.  

As you can see from the error message below, I already have the memlimit set at 64M.  I started at 16.  It makes no difference where I have it set, the race condition consumes all available memory and fails with an out of memory error. 

I will attempt to isolate the code in sugar which is resulting in the race condition, however, the fact remains that this code runs fine under 5.0.4 and does not run under new versions.

Can you create some sort of a simple test case?
For example if you pass all get/post/cookie data from the failing request to <?php phpinfo(); ?> script do you get the same error?

From the application logs, it is apparent that many hundreds, even thousands of lines of code are executing successfully after the post before this out of memory condition occurs.  I have not yet been able to trace the exact code location as I cannot step the code in my Zend Studios environment using php 5.1.  It appears the the code may be dying on either and array_merge or in a mysql call.  I will roll back to php 5.0.5, which I can step in the Zend debugger, and attempt to isolate the exact section of code which is generating these errors.  If I can locate it, I can perhaps write a small test script to reproduce the error under the CVS snapshot release.

This will likely take me a day or two to complete.

Thanks for your continued attention to this problem.

TTYL
  CDC

I can't say the exact point of failure (though its due to how the objects are linked to each other), but I recently had to get a highly modified version of this running under 5.1 and it was falling into infinite loops. Had to disable the ze1.compatibility_mode, remove the majority of explicit reference usage (xxx = & object) and use some explcit clone calls in spots. Runs stable after those changes, so not sure if this is just a PHP compatbility issue.

When getting the error is ze1 compact mode enabled or disabled and does changing the setting alter the behaviour in any way?

I assume you meant ze1_compatiblity_mode and compact was just a typo?  Yes compatibility_mode is set.  It is explicitly set numerous places within the Sugar Code.  I can try changing it, but I'm assuming it was set within the code for a reason.

I'll try changing it and see what happens.

The zend.ze_compatiblity_mode is set to 1 in the index.php file and several other files using the following test for php version number

if (substr(phpversion(), 0, 1) == "5") {
        ini_set("zend.ze1_compatibility_mode", "1");
}

Disabling this option (ie zend.ze_compatiblity_mode=0) under php 5.0.5 and under the last cvs snapshot that was recommended seems to solve this race condition.  I have not tested the code fully to see that this hasn't introduced other problems.  However, it does remove the out of memory and segfault problems.

Were there changes made in php 5.0.5 and later that make this option obsolete.  Or, will disabling this condition lead to other compatility issues?

TTYL
  CDC

This is really critical issue. Obviously that stupid "compatibility" mode misbehaves still?

Can anybody provide a test case?
May be this bug already fixed in HEAD and PHP_5_1.

I have tried to locate the exact code triggering the bug but have so far been unsuccessfull.  So, I have been unable to come up with a simple test case.  The bug is easily reproducible by trying to load and run the Sugar code available here 
http://www.sugarforge.org/frs/download.php/466/SugarSuite-3.5.1a.zip

I can tell you that the bug still existed in the following CVS snapshot.

php5-200510251830

If you believe that it might have been fixed in a newer snapshot, I would be happy to test it.  Just point me at it.

TTYL
  CDC

As I expected, the bag was already fixed in CVS HEAD and PHP_5_1 togehter with bug #34712.

Now I backported the fix to PHP_5_0 too.

Awesome!  I just checked out and built the latest php-5.0 cvs tree and the backport of the fix does indeed fix the ze1_compatibility_mode problems with sugar!  

Thanks!  I'll pass the word along to the Sugar folks.