Loading...
 
Architecture / Installation

Architecture / Installation


Tiki6.1/2: Blank Pages / Allowed memory size of xxxx bytes exhausted (tried to allocate yyyy bytes) in /web/lib/tikidate-php5.php on line 182

posts: 14

hi,

i have a problem with tikiwiki.

all our tiki3.x instalations are working fine. but the tiki6.1 (or 2 - doesnt matter) have serious problems.

if i run them with localhost everything is fine. if i try to access it from an external pc i got either a blank page or the following error message:

Allowed memory size of xxxx bytes exhausted (tried to allocate yyyy bytes) in /web/lib/tikidate-php5.php on line 182 (i think it is always tikidate but am not sure)

so the tikiwiki is now useless in its current version. luckily we haven't upgraded the biggest tiki yet and only have had the problem with one small one, and a new one i just wanted to set up.

i also realised it on several official *.tiki pages (info, dev and themes) too - so it is not only my problem. thats also the reason why i post it in here and not in the bug tracker on dev - 'cause everytime i try to log in i get the memory size exhausted message.

i also think it is not a memory issue as it works fine if i call the page from localhost via vnc. besides that i already had increased the memory limit up to 700something mb without getting rid of the error.

any help is apreaciated

posts: 22 Germany

Hi Desertwolf,

this issue should be fixed by now in Tiki 6.2. The problem was caused by a timezone cookie and was reportet when using Firefox 3.6/4.0 and IE 7 in windows environments only.

Solution: update your Tiki 6.2 to current built, w8 for Tiki 7 or use a different browser like google chrome until next update - or use linux :-)

Dev.to is still not upgraded, so it cant be accesed with FF/IE-browsers using windows. I assume, this will be fixed soon.

Btw: keep the php mem limit lower, if you dont need it, like 32 mb.

HTH
Gregor

DesertWolf wrote:

hi,

i have a problem with tikiwiki.

all our tiki3.x instalations are working fine. but the tiki6.1 (or 2 - doesnt matter) have serious problems.

if i run them with localhost everything is fine. if i try to access it from an external pc i got either a blank page or the following error message:

Allowed memory size of xxxx bytes exhausted (tried to allocate yyyy bytes) in /web/lib/tikidate-php5.php on line 182 (i think it is always tikidate but am not sure)

so the tikiwiki is now useless in its current version. luckily we haven't upgraded the biggest tiki yet and only have had the problem with one small one, and a new one i just wanted to set up.

i also realised it on several official *.tiki pages (info, dev and themes) too - so it is not only my problem. thats also the reason why i post it in here and not in the bug tracker on dev - 'cause everytime i try to log in i get the memory size exhausted message.

i also think it is not a memory issue as it works fine if i call the page from localhost via vnc. besides that i already had increased the memory limit up to 700something mb without getting rid of the error.

any help is apreaciated

posts: 14
Gregor (gta74) wrote:

Hi Desertwolf,

this issue should be fixed by now in Tiki 6.2. The problem was caused by a timezone cookie and was reportet when using Firefox 3.6/4.0 and IE 7 in windows environments only.

Solution: update your Tiki 6.2 to current built, w8 for Tiki 7 or use a different browser like google chrome until next update - or use linux :-)

Dev.to is still not upgraded, so it cant be accesed with FF/IE-browsers using windows. I assume, this will be fixed soon.

Btw: keep the php mem limit lower, if you dont need it, like 32 mb.

HTH
Gregor


YOu are right - it only happens in FF/IE on windows - i tried opera/safari/chrome and tiki works fine in it.

and it happens also with tiki 6.2 - so now i will try the fix mr. laporte suggested

what is strange to me is, that i have no problems when i am trying to access the tiki from the same network or from localhost - but only when i try to access it from another network (luckily i can test both here as we have two seperate networks here)

and another thing: i reduced the memory usage after i tested such hughe amounts of memery back to a normal value


posts: 14
Marc Laporte wrote:

If that doesn't work, can you try this patch and report if it helps?

http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/trunk/lib/tikidate-php5.php?r1=33400&r2=33399&pathrev=33400

Thanks!


hi,

first i tried downloading the complete file from
http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/trunk/lib/tikidate-php5.php?revision=33400&pathrev=33400

from that i got an error that the function convertTZbyID was missing - so i copied the function from the original 6.2 to the file i just downloaded but there is still the memory exhausted error

and manually copying the lines into the original 6.2 tikidate-php5.ph file at the specific section hasn't helped either.

after clearing the cache of ff/ie i could see the homepage but no other WIKIpage - it seems like a page not found page works as well as entering admin menu and some other non-WIKIpages


posts: 1

Same Problem here - this is absolutely severe as Tiki is not working anymore on current browsers! The fix helps nothing! i added:

''// Checks that the string is either a timezone identifier or an abbreviation. display_timezone can be manually set to an identifier in preferences but will be an uppercase abbreviation if auto-detected by JavaScript.
static function TimezoneIsValidId($id) {
static $abbrevs = null, $ids = null;

if (! $abbrevs) {
$abbrevs = DateTimeZone::listAbbreviations();
$ids = DateTimeZone::listIdentifiers();
}

return array_key_exists( strtolower($id), $abbrevs ) ||

in_array($id, $ids);
}''

instead of the orginal function but i get the same error.

how could this slip into a release?


posts: 14
any progress on this problem?
posts: 1584 Canada

Not sure how this happens, but here is what I discovered:


For some unknown reason, an event was with a start date in 1901. Thus, the module "calendar_new" has a ton of calculations, which makes it time out. The module should be smarter, I agree.

Workaround is to remove calendar_new module:
http://doc.tiki.org/Troubleshooting#Module_breaks_site

This could also affect other calendar modules so remove them as well. Please note that you can easily re-instate via the admin panel after, as it is not deleted but just unassigned.

Now, any theories on the 1901? User error? bug?

Best regards,

M ;-)


posts: 14

well it isn't a bad module here it seems or a calendar event. on some of the (test-)systems the calendar feature is disabled and you got the error.

but that March-user-set-timezone-from-germany problem seems to be it.

if i clear my cookies now i have no problems, if i set my date back to march, clear cookies and try to surf on the tiki i have the problem, if i change date back to today, change settings to standard timezone, clear cookies, set date back to march, i have no problems surfing on the tiki.

and thinking of the situation it seems to me that i can surf on all tiki sites again since the beginning of april.

posts: 22 Germany

Hi DesertWolf,

afaik the timezone problem should be solved by now. I encountered this issue on dev.t.o and i18n.t.o. Both sites are now accessible to me (using Win/FF 3.6 und 4.0), IE 7, Chrome). Dev runs now on TW 6.2 and i18n on TW 8.0 (trunk).

Does a fresh and clean install of TW 6.2 work? What's the content of your local_tz cookie? You can try to set another timezone in your tiki.

DesertWolf wrote:

well it isn't a bad module here it seems or a calendar event. on some of the (test-)systems the calendar feature is disabled and you got the error.

but that March-user-set-timezone-from-germany problem seems to be it.

if i clear my cookies now i have no problems, if i set my date back to march, clear cookies and try to surf on the tiki i have the problem, if i change date back to today, change settings to standard timezone, clear cookies, set date back to march, i have no problems surfing on the tiki.

and thinking of the situation it seems to me that i can surf on all tiki sites again since the beginning of april.