Calendar module update 16.0.28

Yesterday we updated our Calendar module to version 16.0.28. This resulted in us not being able to view our calendars, it “gets stuck” on loading and eventually gives an AJAX error. We also immediately started getting emails approx. every 2 minutes with the below message.

PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 536870920 bytes) in /var/www/html/admin/modules/calendar/IcalParser/IcalRangedParser.php on line 114

I tried changing the PHP memory limit to 256 which did not resolve the issue. I was able resolve the issue by downgrading the calendar module to version 16.0.22. I tried some of the modules later than 16.0.22 and they all resulted in this error.

We are running PBXact

Anyone have any idea’s how to resolve this without downgrading to an old module?

I have a similar problem. Three machines updated the calendar module to 16.0.28. Since then, a process “fwconsole job --run --quiet” runs at 100% cpu load and eats more and more memory until the system stucks.

The machines have different setups, but the calendar module is linked in many routes, so it is not possible to remove them. All machines run also with auto update.

As a quick fix, i wrote a cronjob, which kills the “fwconsole job” task every 5 minutes. I also had to change all routes, so that they do not link to a calendar condition, otherwise no inbound calls are possible, because the call stucks at checking the calendar conditions.

Well typically here I would look at the difference between the versions but according to github calendar hasn’t been touched in 7 months since version 16.0.27. Yet more evidence they have NOT moved to github just closed the public out of seeing the code and development.

We have downgraded the stable version to 16.0.21 as of now and raised internal Jira so we can investigate what is the issue in the latest version.

Well it is good to see there is still a tracking system. The old one but hey, it is something.

yeah it seems like they are still using the atlassian stack just don’t want it to be public. The funny thing is FreePBX had assuming someone maintained the relationship an open source license so public access by way of crowd cost nothing. So this saves them nothing unless of course they lost that license

Hey! I’m the developer of the patches in 16.0.23 and the fix related in 16.0.27. I don’t see any problem in .27 so I think you should rollback to that because there were some large improvements in the speed of matching (the issue is lost but anyway it was like 100x faster).

And if you need any clarification about the code I’m here :wink:

Edit: I also know the code well now, if you want to share with me the buggy version I could have a look into

As they mentioned they rolled back

Can you tell us why none of this code is public so others can review it? If it was on github there may already be a patch rather than waiting for advice to do what is already being done. If had gone through a proper PR process and code review on github then people like myself who wrote the code could have given feedback if something was a miss.

Ok it seems like the source of .28 version was released on GitHub. They added very few lines of code to one of the functions I added with my previous commits! So I think I’m the perfect guy to debug why it goes stuck now :wink:

I will have a look into later and see what’s the problem.

@prophead @richie
Could you please tell me what exactly is your setup? in particular:

  • How many calendars you have and the type (OAuth, CalDav…)
  • How the match for the route is setup (are you using Time Conditions with calendar mode? Calendar groups? something else?)

This is definitely a consequence of my PRs and I’m sorry for that, I’m trying to debug the problem but it doesn’t show up for me

I’m curious, why are you using the goto function in PHP? This kind of goes back to @jfinstrom point of not being able to review. Nothing else in the FreePBX code uses goto to handle things and there should be consistency in this code for handle functions/routines that everything uses.

As an example, all the database interactions are done with PDO in FreePBX. Writing a fix/module/feature that requires all MySQLi calls goes outside the standard of database interaction. The MySQLi should be converted to PDO for consistency.

For the love of all things holy… I don’t know how anyone approved such a thing

  • No real review
  • Lack of code standard
  • Had a review, no one notices or didn’t care.

Three options right there, pick one or any of them.

1 Like

Well I can tell you there were pages of coding standards and best practices but they simply have nobody enforcing them

I don’t remember why I used the goto right now, anyway the code did go through the review process and everything, it was publicly available on Jira and GitLab (both of which are down now so you can’t see it).

Anyway the problem is related to recurring events and it seems like in some cases calendar will get stuck calculating it. It’s true that 16.0.27 was here for 7 months now, so in theory should be a specific issue with some kind of event. I’m trying to dive into but I need more information.
As for myself I’m using this version for I think a year now with no problem at all.

And if you wanna know why those patches were implemented it was because matching time of old recurring events (I had many starting 2 years prior the system date) was taking something like 15 seconds, so every incoming call was delayed by 15 seconds!

I’ll wait for some update by the author (and others) of the post. And will also delete the goto :wink:


So this site is a bit of an anomaly… It’s a pbx that is shared between two offices that have different hours and the Dentist has religious holidays that they are closed outside of the normal nationally recognized bank holidays.

Typically I set my systems up with 3 local calendars and use time conditions. Open Hours, Holiday and Weather/Special Events.

The open hours is self explanatory, the Holiday and Weather calendars will send the call to an announcement stating the reason the office is closed during normal hours and then dump the call to whatever the after hours location is. The additional two calendars for this PBX are for the special religious holidays the Dentist’s office observes.

So… to answer you questions…

8 local calendars, all used with time conditions in calendar mode.

Good morning,

  • How many calendars you have and the type (OAuth, CalDav…)

We have 18 calendars. 4 of them are local calendars, 14 of them are Remote iCal Calendars

  • How the match for the route is setup (are you using Time Conditions with calendar mode? Calendar groups? something else?)

Call flow is as follows:

1- 3 Local holiday calendars are tested
2- Local Work day calendar is tested
3- If 2 has a match - Play business hours IVR
If 2 does not match - Play After Hours IVR

Since we have 24x7 emergency service, after hours IVR gives an option to request emergency service.
If the caller selects the after hours service option, the 14 iCal calendars will be tested. When
a match is found the call is routed to the on call person.

Hope this helps

@prophead @ashcortech
Thank you very much to both for the information. Yep everything is useful! Would you mind to share with me one event (.ics format) for the Open hours (those are recurring events right?) so that I can import it and hopefully catch the error?

Thank you again

Just a quick update: I talked to @ashcortech and I think I found the issue. Later I will dive into and update you all

1 Like

And that issue is?