I’ve installed 3.18 RC1 GPL on a VM of Ubuntu JeOS 7.10
I used standard packages first try and it seemed to mostly work.
After experiencing this problem I went back and compiled my own apache2 and php 5.2.5.
I can login to the 3.18 system but on the details screen none of the black labels display any text, (under the Details heading on the Details screen on a Standard Page asset there is normally “Page Name” and “Page Short Name” displayed next to the two fields. On my 3.18 system there’s nothing there).
Doing a view source shows this:
Working 3.14 system -
Page Name
<td class="sq-backend-data"></pre><br />
Broken 3.18 system -
<td class="sq-backend-data"></pre><br />
I have turned SQ_CONF_DEBUG up to 7 and looked for errors on the front end and in system.log and error.log with no success, any suggestions for where else to look?
Edit: After playing around some more I've also found that I can't set urls on sites or save the contents of a standard page...
[quote]Same issues that I have and also reported as a bug, but seems as they can't replicate it.
I run Fedora8, apache/2.2.6 and php 5.2.4.[/quote]
Yeah, we cant replicate any of these problems. We're going to have to go looking deeper.
One obvious difference if the PHP version; we use 5.1 for RHEL support. PEAR package versions might also be a problem. I don't have access to our dev server from here, so could someone post the result of "pear list" for the dev server please.
I adjusted my pear packages to reflect your dev server (I couldn't upgrade mail to 1.1.15 as it doesn't seem to exist on the pear site but I doubt the mail package has anything to do with this):
I have downgraded to php 5.1.6, dropped the db and matrix filesystem and reinstalled and everything appears to be working. I had to hack at php-5.1.6/ext/curl/interface.c to convince it to compile on my box though probably should have gone the alternate route of finding the right version curl library…
There is a slim chance that some other change I made has caused it to start working rather than the version shift, but I may leave that to another day for testing.
If anyone wants any left out details on my system as it seems to be working, just ask.
We haven't done a full install on 5.2 yet, so we can't confirm if our setup works on that version. I hope you find out what was the cause of your problems.
I've done everything I can think of to get this install working and I'm still getting blank screens for details pages on any assets that don't implement the paintBackend function directly. This looks exactly like a memory issue, absolutely blank screen with no error output but I have the memory limits in main.inc at 256MB and php.ini set to 512M.
Is there anything else known to cause the blank screens?
Alternatively is there an actual known working set of versions and configs for all the software (including the linux install) sitting under matrix 3.18. Would you guys be able to post that info on the forum or on the requirements page somewhere?
v3.18 is being developed to run on a stock installation of Red Hat Enterprise Linux 5 (or CentOS 5). However, I've been so busy onsite at clients over the past month, I haven't had any time to install my own copy to see how it goes. :)
Ok after learning how to work a RPM distro I'm still stuck.
I've done a full reinstall using CentOS 5.0 CDs and I've only installed packages available with yum (and I didn't configure yum to look in any special places) so as far as I'm concerned I've performed a "standard" install. During the actual install process I unticked all the "install extra package" type options so it should be as close to empty as possible.
I'm still getting a blank screen on the sitemap asset, all other assets appear fine.
phpinfo() says it's got 512MB of memory and matrix is set to use 256MB, are there any other ideas for where to look?
it accesses "core/lib/DAL/QueryStore/core_isAssetDependentlyLinkedd41d8cd98f00b204e9800998ecf8427e.qob" so I decided to go looking for where that it is used and try and track down what line number it's segfaulting on.
After putting die("test") on far too many lines in far too many files I eventually found that inside ./core/lib/DAL/Query.inc:_findAndReplacePlaceHolder() was where it seems to hang itself.
if I place "die('test'); at *1 I see the test message, if I place it at *2 or *3 I don't.
While trying to figure out why echo statements weren't outputting if I put them in at *1 without a die I tried "while(@ob_end_clean());" and magically almost everything seemed to work on the sitemap asset, this combined with the fact that adding the paintBackend function to any asset that is dying seems to make it work make me think I have some weird memory problem.
To try and rule out the normal one I now have php.ini, matrix and the vm all set to allow 2048MB (as much as windows should allow the vm to have I think). That doesn't fix the issue.
Does anyone know of any memory tweaks I may be able to do that might effect the memory space used by both the output buffer and I'm guessing php's stack (I'm just assuming that's where the issue is with array_walk_recursive).
I can confirm that I too haven't been able to confirm this seg-fault issue on a 5.1.6 system (for completeness, this was a Debian system; it was probably built with apt-get modules given the lack of configure line, but I don't know for sure).
We haven't been able to test a MySource Matrix system on a 5.2 version beyond installation, but we will be able to test it soon and see if we can come up with the same problem.
I doubt that it is a memory issue - you should have received errors in your error.log if that was the case, since PHP generally does dump them in there. Perhaps the blank screen is due to PHP seg-faulting before it has been able to clear the buffer (as display of the backend is buffered).
You said you tried compiling your own PHP 5.2.5. Just out of curiosity, could you try compiling the latest PHP 5.2-CVS version (one I downloaded appeared to be relatively stable, given I have had to use it for some testing) and having a look to see if that changes anything at all? There was one seg-fault bug related to array_walk_recursive() that they say should have been fixed in PHP 5.2.5, but I guess it's worth a shot in any case.
To try and rule out the vm as being an issue we "borrowed" a propper box and put centos 5.0 on it and it has the same issue, the details screen is blank.
I should probably add that just after creating the asset the details screen displays just fine. If I try to acquire locks OR right click on the asset in the asset map and select details it then displays the blank screen. Also just confirming it's only on some assets, the Site and Site Map come up blank but a Standard Page does not.
probably should have gone the alternate route of finding the right version curl library…