SOGo | BTS

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004289SOGoBackend Calendarpublic2017-09-15 09:062019-03-20 13:54
Reporterrongten 
Assigned Toludovic 
PrioritynormalSeverityblockReproducibilityalways
StatusresolvedResolutionfixed 
Platform[Server] LinuxOSRHEL/CentOSOS Version7
Product Version3.2.10 
Target VersionFixed in Version4.0.8 
Summary0004289: Freebusy lookup fails with proxy error for certain users but not for others
DescriptionA freebusy lockup initiated from outlook or from wget fails 100% of the time for a couple of users.
The error is ERROR 502: Proxy Error, and it is after the last SQL query on the calendar of the user, I assume for the building of the freebusy answer. A sogo worker goes 100% of cpu and then it is killed.
Steps To Reproducewget https://URL/SOGo/dav/public/USER1@DOMAIN/freebusy.ifb [^]

gets
HTTP request sent, awaiting response... 502 Proxy Error
2017-09-15 14:02:41 ERROR 502: Proxy Error.

another user (i.e. USER2) gets the file immediately (i.e.)

HTTP request sent, awaiting response... 200 OK
Length: 1181 (1.2K) [text/calendar]
Saving to: ‘freebusy.ifb.3’

Additional Informationactivating the debug, the log for the two users (USER1 and USER2), one that works, one that does not work are identical until to a certain SQL query:

2017-09-15 13:48:39.145 sogod[467:467] PG0x0x7f49aaeeb290 SQL: SELECT b.c_content,a.c_partmails,a.c_partstates,a.c_isopaque,a.c_status,a.c_cycleinfo,a.c_orgmail,b.c_name,a.c_uid,a.c_startdate,a.c_enddate,a.c_isallday FROM sogoUSER100168fa0a38_quick a, sogoUSER100168fa0a38 b WHERE ((c_component = 'vevent') AND (c_classification != 1) AND ((c_startdate IS NULL) OR (c_startdate <= 1513206000)) AND ((c_cycleenddate IS NULL) OR (c_cycleenddate >= 1504828800)) AND (c_iscycle = 1)) AND a.c_name = b.c_name AND (c_deleted != 1 OR c_deleted IS NULL)

after for USER1 there is no more activity of the process with pid 467 until it start saying that
Sep 15 13:49:38 sogod [456]: [WARN] <0x0x7f49aabb5910[WOWatchDogChild]> pid 467 has been hanging in the same request for 1 minutes
until the safety bet kills it.
For the USER2 instead there is immediately a closure

Sep 15 14:01:19 sogod [1095]: |SOGo| request took 0.733621 seconds to execute.


If I use psql, I can execute both final queries and I get the output immediately for USER1, so my guess is that maybe there is something in the output that cannot be formatted interpreted.

Is there any way to know how to fix this issue?

I could try to add one appointment at a time, but it is a calendar imported from outlook with caldav syncronizer with around 150 entries, so...

Tagspossible memory leak
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0012293)
rongten (reporter)
2017-09-15 09:31

Comparing another user with a similar problem, it seems that the issue is linked to repeated events.

The last user had 1 single event repeated every Monday. Removing the event repetition allowed to download the freebusy.ifb file without any issue.
If I sent the end of repetition, it works too, but more distant in the future I put the end of the repetition, longer it takes to generate the freebusy (i.e. 14 secs for end in 2030, 1 sec for end in 2019).

I think I should change the title of the ticket now...
(0012294)
rongten (reporter)
2017-09-15 11:01

And it seems that when a sogod process is taking 100% cpu trying to handle the repetition, its memory consumption grows, from 0.2% memory like to the other sogod workers to 15%, 20%, 30%, growing ever more until is killed.

So if we have multiple sogo workers that start hoarding memory, we start swapping and the server slows to a crawl...
(0012306)
rongten (reporter)
2017-09-18 11:59

On a side note, changing SOGoFreeBusyDefaultInterval seems having no effect. My starting value is (7,30), but decreasing progressively does not have any effect.
even at (1,1) the sogod worker process takes 100% cpu and start hoarding memory.
(0012340)
rongten (reporter)
2017-09-29 04:00

Another useful info: it seems that repeating events are not included at all in the freebusy.ifb file returned, even when their repetition is limited in time (i.e. weekly event that stops after 4 repetitions) and the sogod does not crash. More info below.

I take a newly generated account, with an empty calendar, and I download the freebusy.ifb via wget (after giving to Public permission to view Date & Time for public and confidential events).

 No problems, it downloads a file with no events:

BEGIN:VCALENDAR
PRODID:-//Inverse inc./SOGo 3.2.10//EN
VERSION:2.0
BEGIN:VFREEBUSY
ATTENDEE:mailto:ciccio@domain
DTSTAMP:20170928T144057Z
DTSTART:117612381011T000000Z
DTEND:20171027T220000Z
END:VFREEBUSY
END:VCALENDAR

If I put a single event tomorrow, with weekly repetition and no end, one sogo worker starts taking 100% cpu and hoarding memory. I have now a script that checks every 5 seconds if a sogod process takes more than 1GB of ram and kills it, so I get rather rapidly:

HTTP request sent, awaiting response... 502 Proxy Error
2017-09-28 16:43:31 ERROR 502: Proxy Error.

If I limit the repetition to 4 times only, it downloads exactly the same ifb file then before, the only difference being the DTSTAMP field. So the freebusy file seems not built correctly.

If I put a simple, not repeating event tomorrow (just before the event being repeated 4 times), I get a freebusy ifb that only mention the non repeating event:

BEGIN:VCALENDAR
PRODID:-//Inverse inc./SOGo 3.2.10//EN
VERSION:2.0
BEGIN:VFREEBUSY
ATTENDEE:mailto:ciccio@domain
DTSTAMP:20170928T145040Z
DTSTART:117612381011T000000Z
DTEND:20171027T220000Z
FREEBUSY;FBTYPE=BUSY:20170929T124500Z/20170929T134500Z
END:VFREEBUSY
END:VCALENDAR

Maybe this could shed some light on the issue?
(0012526)
rongten (reporter)
2018-01-19 09:11

Just installed a clean machine, installed iReadMail 0.9.7 with sogo-3.2.10.20180116-1.el7.centos.x86_64.

With only one user (the default postmaster of iReadMail), with 1 single weekly repeating event I have the same problem.


I only add to the default settings:

  /* For Freebusy info */
  SOGoEnablePublicAccess=YES;
  SOGoFreeBusyDefaultInterval = (7,30);

in sogo.conf,
and when I do from another machine


wget --no-check-certificate https://${MACHINE}/SOGo/dav/public/postmaster@${DOMAIN}/freebusy.ifb [^]

I get a series of
HTTP request sent, awaiting response... 504 Gateway Time-out
Retrying.

In the meantime I see a sogod taking 100% and slowing increasing the memory use.
When there is the timeout, another sogod process starts taking 100% and slowly increasing the memory use.

I am really surprised that no-one else has this problem.

I could provide the vm (lxc centos7 image) if necessary.

Is there any way to pay for a bounty or buy a reasonable support package from Inverse to fix this? I surely cannot afford the platinum support package that it is it seems the only one that promise bug fixes.
(0012527)
rongten (reporter)
2018-01-19 10:07

Possible explaination.

Consider an event like this (it repeats only 30 times):

###########
BEGIN:VCALENDAR
PRODID:-//Inverse inc./SOGo 3.2.10//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:2FF-5A61F880-1-7D603A80
SUMMARY:Testing repetition
CLASS:PUBLIC
TRANSP:OPAQUE
DTSTART;TZID=America/New_York:20180119T150000
DTEND;TZID=America/New_York:20180119T160000
CREATED:20180119T135442Z
DTSTAMP:20180119T135442Z
LAST-MODIFIED:20180119T150145Z
RRULE:FREQ=WEEKLY;COUNT=30
SEQUENCE:1
END:VEVENT
END:VCALENDAR
################

Now I have the (7,30) like SOGoFreeBusyDefaultInterval, and when I go the wget of the freebusy I get:


BEGIN:VCALENDAR
PRODID:-//Inverse inc./SOGo 3.2.10//EN
VERSION:2.0
BEGIN:VFREEBUSY
ATTENDEE:mailto:USER@DOMAIN
DTSTAMP:20180119T150456Z
DTSTART:117612390201T050000Z
DTEND:20180218T050000Z
FREEBUSY;FBTYPE=BUSY:20180223T200000Z/20180223T210000Z
FREEBUSY;FBTYPE=BUSY:20180302T200000Z/20180302T210000Z
FREEBUSY;FBTYPE=BUSY:20180309T200000Z/20180309T210000Z
FREEBUSY;FBTYPE=BUSY:20180316T190000Z/20180316T200000Z
FREEBUSY;FBTYPE=BUSY:20180323T190000Z/20180323T200000Z
FREEBUSY;FBTYPE=BUSY:20180330T190000Z/20180330T200000Z
FREEBUSY;FBTYPE=BUSY:20180406T190000Z/20180406T200000Z
FREEBUSY;FBTYPE=BUSY:20180413T190000Z/20180413T200000Z
FREEBUSY;FBTYPE=BUSY:20180420T190000Z/20180420T200000Z
FREEBUSY;FBTYPE=BUSY:20180427T190000Z/20180427T200000Z
FREEBUSY;FBTYPE=BUSY:20180504T190000Z/20180504T200000Z
FREEBUSY;FBTYPE=BUSY:20180511T190000Z/20180511T200000Z
FREEBUSY;FBTYPE=BUSY:20180518T190000Z/20180518T200000Z
FREEBUSY;FBTYPE=BUSY:20180525T190000Z/20180525T200000Z
FREEBUSY;FBTYPE=BUSY:20180601T190000Z/20180601T200000Z
FREEBUSY;FBTYPE=BUSY:20180608T190000Z/20180608T200000Z
FREEBUSY;FBTYPE=BUSY:20180615T190000Z/20180615T200000Z
FREEBUSY;FBTYPE=BUSY:20180622T190000Z/20180622T200000Z
FREEBUSY;FBTYPE=BUSY:20180629T190000Z/20180629T200000Z
FREEBUSY;FBTYPE=BUSY:20180706T190000Z/20180706T200000Z
FREEBUSY;FBTYPE=BUSY:20180713T190000Z/20180713T200000Z
FREEBUSY;FBTYPE=BUSY:20180720T190000Z/20180720T200000Z
FREEBUSY;FBTYPE=BUSY:20180727T190000Z/20180727T200000Z
FREEBUSY;FBTYPE=BUSY:20180803T190000Z/20180803T200000Z
FREEBUSY;FBTYPE=BUSY:20180810T190000Z/20180810T200000Z
END:VFREEBUSY
END:VCALENDAR

it looks like the freebusy is not looking within the -7 and +30 days of the DefaultInterval, but after 30 days...

It is possible a negation has been lost somewhere?
(0012615)
Nterowski (reporter)
2018-02-21 01:23

If in ics You add UNTIL (for example: RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU;UNTIL=20201231), should work properly and .ibf file will be generate.
But This is still debugging, not a solution.

Some problems with Repetitive events ?
(0012616)
Nterowski (reporter)
2018-02-21 01:57

And some logs:
sogod[26313:26313] EXCEPTION: <NSException: 0x56322e876990> NAME:NSInternalInconsistencyException REASON:NSIncrementExtraRefCount() asked to increment too far INFO:(null)
sogod [26313]: |SOGo| request took 48.906093 seconds to execute
sogod [26313]: xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx "GET /SOGo/dav/public/XXXXXX/freebusy.ifb HTTP/1.1" 501 0/0 48.910 - - 2524M

GET request has grown up to ~2500M
(0012617)
rongten (reporter)
2018-02-21 08:31

Hello Nterowski,

 The biggest issue I am afraid is that sogo seems to look outside the
 SOGoFreeBusyDefaultInterval...

 So if you have an event that always repeat, the process goes on collecting info until it exhaust the memory...
User avatar (0012623)
ludovic (administrator)
2018-03-05 11:02

@Nterowski

Regarding the exception you get, please generate a stack trace.

https://sogo.nu/support/faq/how-do-i-debug-sogo.html [^]
(0012646)
sy-subrc (reporter)
2018-03-09 11:48
edited on: 2018-03-09 12:00

Hi,
I'am facing the same error.
I created a fresh SOGO-User account to run the test
Created a none repeating calender event
When I now request the freebusy URL the result is correct

https://sogo.xyz.de/SOGo/dav/public/test01/freebusy.ifb [^]

BEGIN:VCALENDAR
PRODID:-//Inverse inc./SOGo 4.0.0//EN
VERSION:2.0
BEGIN:VFREEBUSY
ATTENDEE:mailto:test01@xyz.de
DTSTAMP:20180309T163053Z
DTSTART:117612390321T230000Z
DTEND:20180315T230000Z
FREEBUSY;FBTYPE=BUSY:20180310T110000Z/20180310T114500Z
END:VFREEBUSY
END:VCALENDAR

When I now create a second calender event repeating each day and fetch the same URL sogod is consuming 100% CPU and is using more and more and more memory

The following messages are written into the SOGo-Log
Mar 09 17:37:44 sogod [3730]: [WARN] <0x0x55b025fb0260[WOWatchDogChild]> pid 3731 has been hanging in the same request for 1 minutes
Mar 09 17:38:44 sogod [3730]: [WARN] <0x0x55b025fb0260[WOWatchDogChild]> pid 3731 has been hanging in the same request for 2 minutes
Mar 09 17:39:44 sogod [3730]: [WARN] <0x0x55b025fb0260[WOWatchDogChild]> pid 3731 has been hanging in the same request for 3 minutes
Mar 09 17:40:44 sogod [3730]: [WARN] <0x0x55b025fb0260[WOWatchDogChild]> pid 3731 has been hanging in the same request for 4 minutes
Mar 09 17:41:44 sogod [3730]: [WARN] <0x0x55b025fb0260[WOWatchDogChild]> pid 3731 has been hanging in the same request for 5 minutes

I tested with SOGo 3.2.10 and SOGo 4.0.0 still the same behaviour

Best regards
Harald

(0012821)
sy-subrc (reporter)
2018-04-09 10:05
edited on: 2018-08-09 11:27

Hello Nterowski,
is there any progress regarding this issue?
Is there possibly an approximate date on which a correction can be expected?

Best regards
Harald

(0012993)
sy-subrc (reporter)
2018-08-09 11:27

Meanwhile we are running Version 4.0.1 (@shiva2.inverse 201808090043), but still the same error.
(0012994)
rongten (reporter)
2018-08-10 07:16

I have a subscription but did not have the time to install a server with the official rpms instead of the nightly, I suppose the problem is there as well..
(0013124)
rongten (reporter)
2018-10-23 02:32

On stable 4.0.3-1.el7.centos on a new server, still an issue.

If you change the number of repeats for a recurrent event, the freebusy file will report all the occurrences (i.e. 30, 200, 3000...) without respecting SOGoFreeBusyDefaultInterval.

Even commenting it out from the config file (and therefore assuming a sane default) does not change affect it.

As it stands this means that SOGo cannot inter-operate with outlook users and we will be probably forced to look elsewhere.

As interim we would be satisfied with something like what proposed here (https://community.nethserver.org/t/sogo-outlook-free-busy-information/6809/6 [^]) where a script parses the output of sogo-tool.

Pity that the source code is not available.
(0013161)
sy-subrc (reporter)
2018-11-07 06:16

@rongten
Thank you for testing!
I hope the SOGo-team will fix this issue soon because it's a show-stopper to us.
(0013238)
sy-subrc (reporter)
2019-01-08 10:13

@ludovic
I have seen that in version 4.0.5 some ActiveSync fixes are included. Is there a chance that this problem here is also fixed?
User avatar (0013411)
ludovic (administrator)
2019-02-21 15:00

I've tested everything with v4.0.6 and I don't have any issue - SOGoFreeBusyDefaultInterval is respected.

If you have a hanging child, please attach to it using gdb and produce a stack trace. Before doing so, install SOPE, SOGo and GNUstep debugging packages and restart SOGo.
(0013425)
rongten (reporter)
2019-03-05 06:20

Hello Ludovic,

 I just tested on an ubuntu 18.04 (to see if the problem is linked to centos), sogo 4.0.7-1, fresh install (up to the version my subscription allows), I have exactly the same issue.

 With 1 recurring weekly event, sogo daemon 100% cpu time, wget the freebusy file hangs, and I need to kill the sogo process by hand.

 If I define a recurring weekly event that repeats 100 times starting today 5th of March, I get a ifb where the first event is a
FREEBUSY;FBTYPE=BUSY:20190409T100000Z/20190409T110000Z
and the last one is
FREEBUSY;FBTYPE=BUSY:20210126T110000Z/20210126T120000Z

Where 2021/01/26 is exactly the last occurrence of the repeating event.

Please note that the freebusy reports correctly a dummy event the 2019/03/07 but not one the 2019/03/28 as for the SOGoFreeBusyDefaultInterval, so the problem is only with recurring events.
(0013426)
rongten (reporter)
2019-03-05 08:34

Changing the interval of the event does not affect the behavior: daily, weekly, monthly and yearly events all give the same error.

Enabling SQL debug we can see that the sql queries correctly identify the non repetitive events and the repetitive events inside the FreeBusy interval (from SOPE/GDLContentStore/GCSFolder.m I think), but after it seems that it cannot process correctly the repeating event (the RRULE:FREQ=WEEKLY;COUNT=100 settings for example).

I do not know where it expands the recurring event, in sogo/SoObjects/Appointments/SOGoFreeBusyObject.m maybe? Is not very clear to me..
(0013432)
sy-subrc (reporter)
2019-03-08 08:26

Hello Ludovic,
I also tested this in our environment (Version 4.0.7 (@shiva2.inverse 201903070216).
If at least one recurring event exist in the account cpu usage on the server climbs up to 100% when the freebusy request for the account is made.
Still the same behavior as described last year https://sogo.nu/bugs/view.php?id=4289#c12646 [^]
User avatar (0013437)
ludovic (administrator)
2019-03-12 08:42

@sy-subrc - please show me the full iCalendar data for that event.
(0013438)
sy-subrc (reporter)
2019-03-12 10:04

@ludovic
I created a PDF with detailed information.
You can download the document here:
https://filehorst.de/d/ctqhItkp [^]
User avatar (0013455)
ludovic (administrator)
2019-03-15 15:30

It works for me.

Show your complete list of installed SOPE, SOGo and GNUstep packages.
(0013460)
rongten (reporter)
2019-03-18 04:21

Personally I have
dpkg -l | grep -i -e sope -e sogo -e gnustep
ii gnustep-base-common 1.25.1-2ubuntu3 all GNUstep Base library - common files
ii gnustep-base-runtime 1.25.1-2ubuntu3 amd64 GNUstep Base library - daemons and tools
ii gnustep-common 2.7.0-3 amd64 Common files for the core GNUstep environment
ii gnustep-make 2.7.0-3 all GNUstep build system
ii libgnustep-base1.25 1.25.1-2ubuntu3 amd64 GNUstep Base library
ii libsope-appserver4.9 4.9.r1664.20190221 amd64 SOPE application server libraries
ii libsope-core4.9 4.9.r1664.20190221 amd64 Core libraries of the SOPE application server
ii libsope-gdl1-4.9 4.9.r1664.20190221 amd64 GNUstep database libraries for SOPE
ii libsope-ldap4.9 4.9.r1664.20190221 amd64 SOPE libraries for LDAP access
ii libsope-mime4.9 4.9.r1664.20190221 amd64 SOPE libraries for MIME processing
ii libsope-xml4.9 4.9.r1664.20190221 amd64 SOPE libraries for XML processing
ii sogo 4.0.7-1 amd64 a modern and scalable groupware
ii sogo-dbg 4.0.7-1 amd64 a modern and scalable groupware - debugging symbols
ii sope4.9-gdl1-mysql 4.9.r1664.20190221 amd64 MySQL connector for SOPE's fork of the GNUstep database environment
ii sope4.9-gdl1-postgresql 4.9.r1664.20190221 amd64 PostgreSQL connector for SOPE's fork of the GNUstep database environment
ii sope4.9-libxmlsaxdriver 4.9.r1664.20190221 amd64 XML Parser for SOPE's SAX engine


Just installed sogo-dbg, will try to see if I am able to use it.
(0013461)
rongten (reporter)
2019-03-18 04:50

Running in gdb, and giving Cntrl-c when the wget is hanging gives the following bt:

2019-03-18 09:45:33.917 sogod[6165:6165] PG0x0x555555996700 SQL: SELECT c_path4 FROM sogo_folder_info WHERE c_path2 = 'LOGIN' AND c_folder_type = 'Appointment'
2019-03-18 09:45:33.918 sogod[6165:6165] PG0x0x555555996700 SQL: SELECT c_folder_id, c_path, c_location, c_quick_location, c_acl_location, c_folder_type FROM sogo_folder_info WHERE c_path1 = 'Users' AND c_path2 = 'LOGIN' AND c_path3 = 'Calendar' AND c_path4 = 'personal'
2019-03-18 09:45:33.919 sogod[6165:6165] PG0x0x555555996700 SQL: SELECT c_uid, c_object, c_role FROM sogoLOGIN0015516d229_acl WHERE (c_object = '/LOGIN/Calendar/personal') AND ((c_uid = 'anonymous') OR (c_uid LIKE '@%'))
2019-03-18 09:45:33.920 sogod[6165:6165] PG0x0x555555996700 SQL: SELECT b.c_content,a.c_partmails,a.c_partstates,a.c_isopaque,a.c_status,a.c_cycleinfo,a.c_orgmail,b.c_name,a.c_uid,a.c_startdate,a.c_enddate,a.c_isallday FROM sogoLOGIN0015516d229_quick a, sogoLOGIN0015516d229 b WHERE ((c_component = 'vevent') AND (c_classification = 0) AND ((c_startdate IS NULL) OR (c_startdate <= 1553468400)) AND ((c_enddate IS NULL) OR (c_enddate >= 1552262400)) AND (c_iscycle = 0)) AND a.c_name = b.c_name AND (c_deleted != 1 OR c_deleted IS NULL)
2019-03-18 09:45:33.921 sogod[6165:6165] PG0x0x555555996700 SQL: SELECT b.c_content,a.c_partmails,a.c_partstates,a.c_isopaque,a.c_status,a.c_cycleinfo,a.c_orgmail,b.c_name,a.c_uid,a.c_startdate,a.c_enddate,a.c_isallday FROM sogoLOGIN0015516d229_quick a, sogoLOGIN0015516d229 b WHERE ((c_component = 'vevent') AND (c_classification = 0) AND ((c_startdate IS NULL) OR (c_startdate <= 1553468400)) AND ((c_cycleenddate IS NULL) OR (c_cycleenddate >= 1552262400)) AND (c_iscycle = 1)) AND a.c_name = b.c_name AND (c_deleted != 1 OR c_deleted IS NULL)



^C
Program received signal SIGINT, Interrupt.
0x00007ffff52df1a5 in ?? () from /usr/lib/libgnustep-base.so.1.25
(gdb) bt
#0 0x00007ffff52df1a5 in ?? () from /usr/lib/libgnustep-base.so.1.25
0000001 0x00007ffff6034038 in -[NSCalendarDate(misc) dateByAddingYears:months:days:] (self=0x555555f179b0, _cmd=0x7ffff7264780 <_OBJC_SELECTOR_TABLE+192>,
    _years=0, _months=0, _days=2927351) at NSCalendarDate+misc.m:440
0000002 0x00007ffff703c9c0 in -[iCalWeeklyRecurrenceCalculator recurrenceRangesWithinCalendarDateRange:] (self=0x555555f23d00,
    _cmd=0x7ffff725f9e0 <_OBJC_SELECTOR_TABLE+192>, _r=0x555555f21b40) at iCalWeeklyRecurrenceCalculator.m:143
0000003 0x00007ffff7036364 in +[iCalRecurrenceCalculator _fillRanges:fromRules:withinRange:startingWithDate:] (
    self=0x7ffff725f8a0 <_OBJC_Class_iCalRecurrenceCalculator>, _cmd=0x7ffff725fb20 <_OBJC_SELECTOR_TABLE+512>, ranges=0x555555f22ff0,
    rrules=0x555555f22070, limits=0x555555f21b40, first=0x555555f1f2d0) at iCalRecurrenceCalculator.m:133
0000004 0x00007ffff7036b95 in +[iCalRecurrenceCalculator recurrenceRangesWithinCalendarDateRange:firstInstanceCalendarDateRange:recurrenceRules:exceptionRules:recurrenceDates:exceptionDates:] (self=0x7ffff725f8a0 <_OBJC_Class_iCalRecurrenceCalculator>, _cmd=0x7fffe9363980 <_OBJC_SELECTOR_TABLE+2272>,
    _r=0x555555f21b40, _fir=0x555555f1f2d0, _rRules=0x555555f22070, _exRules=0x555555f221e0, _rDates=0x555555f21d60, _exDates=0x555555f21b70)
    at iCalRecurrenceCalculator.m:268
0000005 0x00007fffe91204af in -[SOGoAppointmentFolder flattenCycleRecord:forRange:intoArray:withCalendar:] (self=0x555555b75200,
    _cmd=0x7fffe9363a00 <_OBJC_SELECTOR_TABLE+2400>, theRecord=0x555555ed96e0, theRange=0x555555ed8b00, theRecords=0x555555ed8ac0, calendar=0x555555f00fd0)
    at SOGoAppointmentFolder.m:1355
0000006 0x00007fffe9120956 in -[SOGoAppointmentFolder _flattenCycleRecords:fetchRange:] (self=0x555555b75200, _cmd=0x7fffe9363ad0 <_OBJC_SELECTOR_TABLE+2608>,
    _records=0x555555ed9450, _r=0x555555ed8b00) at SOGoAppointmentFolder.m:1421
0000007 0x00007fffe91218f6 in -[SOGoAppointmentFolder fetchFields:from:to:title:component:additionalFilters:includeProtectedInformation:] (self=0x555555b75200,
    _cmd=0x7fffe9364300 <_OBJC_SELECTOR_TABLE+4704>, _fields=0x555555e93a10, _startDate=0x555555e87900, _endDate=0x555555e87a40, title=0x0,
    _component=0x7fffe9360240 <_OBJC_INSTANCE_43>, filters=0x0, _includeProtectedInformation=1 '\001') at SOGoAppointmentFolder.m:1643
0000008 0x00007fffe912704b in -[SOGoAppointmentFolder fetchFreeBusyInfosFrom:to:] (self=0x555555b75200, _cmd=0x7fffe936b480 <_OBJC_SELECTOR_TABLE+992>,
    _startDate=0x555555e87900, _endDate=0x555555e87a40) at SOGoAppointmentFolder.m:2900
0000009 0x00007fffe9132284 in -[SOGoFreeBusyObject fetchFreeBusyInfosFrom:to:] (self=0x555555e6dca0, _cmd=0x7fffe936b420 <_OBJC_SELECTOR_TABLE+896>,
    startDate=0x555555e87900, endDate=0x555555e87a40) at SOGoFreeBusyObject.m:334
0000010 0x00007fffe91320bb in -[SOGoFreeBusyObject fetchFreeBusyInfosFrom:to:forContact:] (self=0x555555e6dca0, _cmd=0x7fffe936b390 <_OBJC_SELECTOR_TABLE+752>,
    startDate=0x555555e87900, endDate=0x555555e87a40, uid=0x0) at SOGoFreeBusyObject.m:300
0000011 0x00007fffe9131d4b in -[SOGoFreeBusyObject contentAsStringWithMethod:andUID:andOrganizer:andContact:from:to:] (self=0x555555e6dca0,
    _cmd=0x7fffe936b3b0 <_OBJC_SELECTOR_TABLE+784>, method=0x0, UID=0x0, organizer=0x0, contactID=0x0, _startDate=0x555555e87900, _endDate=0x555555e87a40)
    at SOGoFreeBusyObject.m:234
0000012 0x00007fffe9131df9 in -[SOGoFreeBusyObject contentAsStringFrom:to:] (self=0x555555e6dca0, _cmd=0x7fffe936b380 <_OBJC_SELECTOR_TABLE+736>,
    _startDate=0x555555e87900, _endDate=0x555555e87a40) at SOGoFreeBusyObject.m:251
0000013 0x00007fffe9131cea in -[SOGoFreeBusyObject contentAsString] (self=0x555555e6dca0, _cmd=0x7fffe936b580 <_OBJC_SELECTOR_TABLE+1248>)
    at SOGoFreeBusyObject.m:222
0000014 0x00007fffe9132a45 in -[SOGoFreeBusyObject GETAction:] (self=0x555555e6dca0, _cmd=0x55555589f7c0, _ctx=0x555555e12e40) at SOGoFreeBusyObject.m:421
0000015 0x00007ffff6ca29c2 in -[SoSelectorInvocation primaryCallSelector:withArguments:] (self=0x555555e7e4f0, _cmd=0x7ffff6fde9c0 <_OBJC_SELECTOR_TABLE+992>,
    _sel=0x55555589f7c0, _args=0x555555e7e540) at SoSelectorInvocation.m:226
0000016 0x00007ffff6ca30e7 in -[SoSelectorInvocation callOnObject:inContext:] (self=0x555555e7e4f0, _cmd=0x7ffff6fde920 <_OBJC_SELECTOR_TABLE+832>,
    _client=0x555555e6dca0, _ctx=0x555555e12e40) at SoSelectorInvocation.m:323
0000017 0x00007ffff6ca2d01 in -[SoSelectorInvocation callOnObject:inContext:] (self=0x555555c50690, _cmd=0x7ffff6ff28c0 <_OBJC_SELECTOR_TABLE+480>,
    _client=0x555555e6dca0, _ctx=0x555555e12e40) at SoSelectorInvocation.m:280
0000018 0x00007ffff6cb3156 in -[SoObjectWebDAVDispatcher doGET:] (self=0x555555e405c0, _cmd=0x5555558e3560, _ctx=0x555555e12e40)
    at SoObjectWebDAVDispatcher.m:192
0000019 0x00007ffff6cb95b3 in -[SoObjectWebDAVDispatcher performMethod:inContext:] (self=0x555555e405c0, _cmd=0x7ffff6ff3110 <_OBJC_SELECTOR_TABLE+2608>,
    _method=0x7ffff6f6a720 <_OBJC_INSTANCE_4>, _ctx=0x555555e12e40) at SoObjectWebDAVDispatcher.m:1740
0000020 0x00007ffff6cb98a6 in -[SoObjectWebDAVDispatcher dispatchInContext:] (self=0x555555e405c0, _cmd=0x7ffff6fd5920 <_OBJC_SELECTOR_TABLE+1536>,
    _ctx=0x555555e12e40) at SoObjectWebDAVDispatcher.m:1775
0000021 0x00007ffff6c93e60 in -[SoObjectRequestHandler handleRequest:inContext:session:application:] (self=0x555555c53a80,
    _cmd=0x7ffff6f56b10 <_OBJC_SELECTOR_TABLE+848>, _rq=0x555555bdd4f0, _ctx=0x555555e12e40, _sn=0x0, app=0x555555bbf630) at SoObjectRequestHandler.m:584
0000022 0x00007ffff6c17fb0 in -[WORequestHandler handleRequest:] (self=0x555555c53a80, _cmd=0x7ffff6f1f1d0 <_OBJC_SELECTOR_TABLE+1616>, _request=0x555555bdd4f0)
    at WORequestHandler.m:237
0000023 0x00007ffff6bd8214 in -[WOCoreApplication dispatchRequest:usingHandler:] (self=0x555555bbf630, _cmd=0x7ffff6f1f220 <_OBJC_SELECTOR_TABLE+1696>,
---Type <return> to continue, or q <return> to quit---
    _request=0x555555bdd4f0, handler=0x555555c53a80) at WOCoreApplication.m:712
0000024 0x00007ffff6bd852d in -[WOCoreApplication dispatchRequest:] (self=0x555555bbf630, _cmd=0x555555764520 <_OBJC_SELECTOR_TABLE+1664>,
    _request=0x555555bdd4f0) at WOCoreApplication.m:752
0000025 0x000055555555cdc5 in -[SOGo dispatchRequest:] (self=0x555555bbf630, _cmd=0x7ffff6fbcf80 <_OBJC_SELECTOR_TABLE+1760>, _request=0x555555bdd4f0)
    at SOGo.m:584
0000026 0x00007ffff6c823b7 in -[WOHttpTransaction _run] (self=0x555555dffc20, _cmd=0x7ffff6fbcfb0 <_OBJC_SELECTOR_TABLE+1808>) at WOHttpTransaction.m:566
0000027 0x00007ffff6c8272d in -[WOHttpTransaction run] (self=0x555555dffc20, _cmd=0x7ffff6fbacf0 <_OBJC_SELECTOR_TABLE+1168>) at WOHttpTransaction.m:619
0000028 0x00007ffff6c7e3b6 in -[WOHttpAdaptor runConnection:] (self=0x555555deb950, _cmd=0x7ffff6fbad90 <_OBJC_SELECTOR_TABLE+1328>, _socket=0x555555dfc060)
    at WOHttpAdaptor.m:373
0000029 0x00007ffff6c7e5d6 in -[WOHttpAdaptor _handleAcceptedConnection:] (self=0x555555deb950, _cmd=0x7ffff6fbada0 <_OBJC_SELECTOR_TABLE+1344>,
    _connection=0x555555dfc060) at WOHttpAdaptor.m:407
0000030 0x00007ffff6c7e9dc in -[WOHttpAdaptor _handleConnection:] (self=0x555555deb950, _cmd=0x7ffff6fbae40 <_OBJC_SELECTOR_TABLE+1504>,
    connection=0x555555dfc060) at WOHttpAdaptor.m:466
0000031 0x00007ffff6c7ee7b in -[WOHttpAdaptor acceptConnection:] (self=0x555555deb950, _cmd=0x7ffff6fbacb0 <_OBJC_SELECTOR_TABLE+1104>,
    _notification=0x555555dfb3e0) at WOHttpAdaptor.m:527
0000032 0x00007ffff538004e in ?? () from /usr/lib/libgnustep-base.so.1.25
0000033 0x00007ffff603aa49 in -[NSObject(FileObjectWatcher) receivedEvent:type:extra:forMode:] (self=0x555555deb3b0, _cmd=0x7ffff58fb1d0, _fdData=0x6,
    _type=ET_RDESC, _extra=0x6, _mode=0x7ffff58832c0) at NSRunLoop+FileObjects.m:58
0000034 0x00007ffff5496641 in ?? () from /usr/lib/libgnustep-base.so.1.25
0000035 0x00007ffff53c8913 in ?? () from /usr/lib/libgnustep-base.so.1.25
0000036 0x00007ffff53c85e4 in ?? () from /usr/lib/libgnustep-base.so.1.25
0000037 0x00007ffff6bd7a44 in -[WOCoreApplication run] (self=0x555555bbf630, _cmd=0x555555764280 <_OBJC_SELECTOR_TABLE+992>) at WOCoreApplication.m:584
0000038 0x000055555555bf0c in -[SOGo run] (self=0x555555bbf630, _cmd=0x7ffff6f41db0 <_OBJC_SELECTOR_TABLE+208>) at SOGo.m:337
0000039 0x00007ffff6c023ea in WOApplicationMain (_appClassName=0x5555557620c0 <_OBJC_INSTANCE_0>, argc=13, argv=0x7fffffffebe8) at WOApplicationMain.m:42
0000040 0x00007ffff6c23971 in WOWatchDogApplicationMain (appName=0x5555557620c0 <_OBJC_INSTANCE_0>, argc=13, argv=0x7fffffffebe8)
    at WOWatchDogApplicationMain.m:1049
0000041 0x000055555555aaa3 in main (argc=13, argv=0x7fffffffebe8, env=0x7fffffffec58) at sogod.m:51
(0013462)
rongten (reporter)
2019-03-18 05:14

The runaway behavior is observed as well during a debug session.

If i do a break as b iCalWeeklyRecurrenceCalculator.m:143 and then i just step into all the functions, I see that there is a loop where
[NSCalendarDate(misc) dateByAddingYears:months:days:] (self=0x555555f179b0, _cmd=0x7ffff7264780 <_OBJC_SELECTOR_TABLE+192>, _years=0, _months=0, _days=XXX)

is called over and over again in steps of 7 (273,280,287)...

This is the loop that seems to be repeating over and over:

-[NSCalendarDate(misc) dateByAddingYears:months:days:] (self=0x555555f179b0, _cmd=0x7ffff7264780 <_OBJC_SELECTOR_TABLE+192>, _years=0, _months=0, _days=280)
    at NSCalendarDate+misc.m:440
0000440 NSCalendarDate+misc.m: No such file or directory.
(gdb)
0000442 in NSCalendarDate+misc.m
(gdb)
-[iCalWeeklyRecurrenceCalculator recurrenceRangesWithinCalendarDateRange:] (self=0x555555f23d00, _cmd=0x7ffff725f9e0 <_OBJC_SELECTOR_TABLE+192>,
    _r=0x555555f21b40) at iCalWeeklyRecurrenceCalculator.m:130
0000130 iCalWeeklyRecurrenceCalculator.m: No such file or directory.
(gdb)
0000133 in iCalWeeklyRecurrenceCalculator.m
(gdb)
-[NGCalendarDateRange duration] (self=0x555555f1f2d0, _cmd=0x7ffff7264790 <_OBJC_SELECTOR_TABLE+208>) at NGCalendarDateRange.m:156
0000156 NGCalendarDateRange.m: No such file or directory.
(gdb)
0000157 in NGCalendarDateRange.m
(gdb)
-[iCalWeeklyRecurrenceCalculator recurrenceRangesWithinCalendarDateRange:] (self=0x555555f23d00, _cmd=0x7ffff725f9e0 <_OBJC_SELECTOR_TABLE+192>,
    _r=0x555555f21b40) at iCalWeeklyRecurrenceCalculator.m:134
0000134 iCalWeeklyRecurrenceCalculator.m: No such file or directory.
(gdb)
0000138 in iCalWeeklyRecurrenceCalculator.m
(gdb)
0000139 in iCalWeeklyRecurrenceCalculator.m
(gdb)
0000138 in iCalWeeklyRecurrenceCalculator.m
(gdb)
+[NGCalendarDateRange calendarDateRangeWithStartDate:endDate:] (self=0x7ffff627c580 <_OBJC_Class_NGCalendarDateRange>,
    _cmd=0x7ffff72647e0 <_OBJC_SELECTOR_TABLE+288>, start=0x555555f27890, end=0x555555f278d0) at NGCalendarDateRange.m:33
0000033 NGCalendarDateRange.m: No such file or directory.
(gdb)
-[NGCalendarDateRange initWithStartDate:endDate:] (self=0x555555f27910, _cmd=0x7ffff627c610 <_OBJC_SELECTOR_TABLE+16>, start=0x555555f27890,
    end=0x555555f278d0) at NGCalendarDateRange.m:36
0000036 in NGCalendarDateRange.m
(gdb)
0000037 in NGCalendarDateRange.m
(gdb)
0000038 in NGCalendarDateRange.m
(gdb)
0000040 in NGCalendarDateRange.m
(gdb)
0000041 in NGCalendarDateRange.m
(gdb)
0000042 in NGCalendarDateRange.m
(gdb)
0000043 in NGCalendarDateRange.m
(gdb)
0000050 in NGCalendarDateRange.m
(gdb)
0000051 in NGCalendarDateRange.m
(gdb)
+[NGCalendarDateRange calendarDateRangeWithStartDate:endDate:] (self=0x7ffff627c580 <_OBJC_Class_NGCalendarDateRange>,
    _cmd=0x7ffff72647e0 <_OBJC_SELECTOR_TABLE+288>, start=0x555555f27890, end=0x555555f278d0) at NGCalendarDateRange.m:34
0000034 in NGCalendarDateRange.m
(gdb)
-[iCalWeeklyRecurrenceCalculator recurrenceRangesWithinCalendarDateRange:] (self=0x555555f23d00, _cmd=0x7ffff725f9e0 <_OBJC_SELECTOR_TABLE+192>,
    _r=0x555555f21b40) at iCalWeeklyRecurrenceCalculator.m:140
0000140 iCalWeeklyRecurrenceCalculator.m: No such file or directory.
(gdb)
0000142 in iCalWeeklyRecurrenceCalculator.m
(gdb)
0000145 in iCalWeeklyRecurrenceCalculator.m
(gdb)

Breakpoint 1, -[iCalWeeklyRecurrenceCalculator recurrenceRangesWithinCalendarDateRange:] (self=0x555555f23d00,
    _cmd=0x7ffff725f9e0 <_OBJC_SELECTOR_TABLE+192>, _r=0x555555f21b40) at iCalWeeklyRecurrenceCalculator.m:143
0000143 in iCalWeeklyRecurrenceCalculator.m
(gdb)
-[NSCalendarDate(misc) dateByAddingYears:months:days:] (self=0x555555f179b0, _cmd=0x7ffff7264780 <_OBJC_SELECTOR_TABLE+192>, _years=0, _months=0, _days=287)
User avatar (0013463)
ludovic (administrator)
2019-03-18 09:53

From your first stacktrace:

#0 0x00007ffff52df1a5 in ?? () from /usr/lib/libgnustep-base.so.1.25
0000001 0x00007ffff6034038 in -[NSCalendarDate(misc) dateByAddingYears:months:days:] (self=0x555555f179b0, _cmd=0x7ffff7264780 <_OBJC_SELECTOR_TABLE+192>,
    _years=0, _months=0, _days=2927351) at NSCalendarDate+misc.m:440
0000002 0x00007ffff703c9c0 in -[iCalWeeklyRecurrenceCalculator recurrenceRangesWithinCalendarDateRange:] (self=0x555555f23d00,
    _cmd=0x7ffff725f9e0 <_OBJC_SELECTOR_TABLE+192>, _r=0x555555f21b40) at iCalWeeklyRecurrenceCalculator.m:143
0000003 0x00007ffff7036364 in +[iCalRecurrenceCalculator _fillRanges:fromRules:withinRange:startingWithDate:] (
    self=0x7ffff725f8a0 <_OBJC_Class_iCalRecurrenceCalculator>, _cmd=0x7ffff725fb20 <_OBJC_SELECTOR_TABLE+512>, ranges=0x555555f22ff0,
    rrules=0x555555f22070, limits=0x555555f21b40, first=0x555555f1f2d0) at iCalRecurrenceCalculator.m:133
0000004 0x00007ffff7036b95 in +[iCalRecurrenceCalculator recurrenceRangesWithinCalendarDateRange:firstInstanceCalendarDateRange:recurrenceRules:exceptionRules:recurrenceDates:exceptionDates:] (self=0x7ffff725f8a0 <_OBJC_Class_iCalRecurrenceCalculator>, _cmd=0x7fffe9363980 <_OBJC_SELECTOR_TABLE+2272>,
    _r=0x555555f21b40, _fir=0x555555f1f2d0, _rRules=0x555555f22070, _exRules=0x555555f221e0, _rDates=0x555555f21d60, _exDates=0x555555f21b70)
    at iCalRecurrenceCalculator.m:268
0000005 0x00007fffe91204af in -[SOGoAppointmentFolder flattenCycleRecord:forRange:intoArray:withCalendar:] (self=0x555555b75200,
    _cmd=0x7fffe9363a00 <_OBJC_SELECTOR_TABLE+2400>, theRecord=0x555555ed96e0, theRange=0x555555ed8b00, theRecords=0x555555ed8ac0, calendar=0x555555f00fd0)
    at SOGoAppointmentFolder.m:1355

Reproduce it, and when that happens, do:

f 5
po theRecord
p *theRange

Basically, show use the variables' content in method -[SOGoAppointmentFolder flattenCycleRecord:forRange:intoArray:withCalendar:]
(0013464)
rongten (reporter)
2019-03-18 11:04

Here it is (I hope these are useful info..):

Program received signal SIGINT, Interrupt.
0x00007ffff52df147 in ?? () from /usr/lib/libgnustep-base.so.1.25
(gdb) f 5
0000005 0x00007fffe91204af in -[SOGoAppointmentFolder flattenCycleRecord:forRange:intoArray:withCalendar:] (self=0x5555561cfaa0,
    _cmd=0x7fffe9363a00 <_OBJC_SELECTOR_TABLE+2400>, theRecord=0x55555622b5a0, theRange=0x55555625e4f0, theRecords=0x55555625e4b0, calendar=0x55555629ade0)
    at SOGoAppointmentFolder.m:1355
1355 SOGoAppointmentFolder.m: No such file or directory.

(gdb) po theRecord
{"c_content" = "BEGIN:VCALENDAR
PRODID:-//Inverse inc./SOGo 4.0.7//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Brussels
X-LIC-LOCATION:Europe/Brussels
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:1696-5C8F5980-3-75EB6100
SUMMARY:Testing
CLASS:PUBLIC
RRULE:FREQ=WEEKLY
TRANSP:OPAQUE
DTSTART;TZID=Europe/Brussels:20190318T094500
DTEND;TZID=Europe/Brussels:20190318T104500
CREATED:20190318T084044Z
DTSTAMP:20190318T084044Z
LAST-MODIFIED:20190318T084044Z
END:VEVENT
END:VCALENDAR"; "c_cycleinfo" = "{rules = (\"FREQ=WEEKLY\"); }"; "c_enddate" = 1552902300; "c_isallday" = 0; "c_isopaque" = 1; "c_name" = "1696-5C8F5980-3-75EB6100.ics"; "c_orgmail" = ""; "c_partmails" = "<null>"; "c_partstates" = ""; "c_startdate" = 1552898700; "c_status" = 1; "c_uid" = "1696-5C8F5980-3-75EB6100"; }
(gdb) p *theRange
$1 = {{isa = 0x7ffff627c580 <_OBJC_Class_NGCalendarDateRange>}, startDate = 0x5555562628b0, endDate = 0x5555562627b0}
(gdb) ptype theRange
type = struct NGCalendarDateRange {
  protected:
    struct NSCalendarDate *startDate;
    struct NSCalendarDate *endDate;
} *
(gdb) ptype theRange.startDate
type = struct NSCalendarDate {
  protected:
    NSTimeInterval _seconds_since_ref;
    struct NSString *_calendar_format;
    struct NSTimeZone *_time_zone;
} *
(gdb) p theRange.startDate
$4 = (struct NSCalendarDate *) 0x5555562628b0
(gdb) p *theRange.startDate
$5 = {{{isa = 0x7ffff5815fe0}}, _seconds_since_ref = 575161200, _calendar_format = 0x7ffff5816b80, _time_zone = 0x555555ceebc0}
(gdb) p *theRange.endDate
$6 = {{{isa = 0x7ffff5815fe0}}, _seconds_since_ref = 371085748329600, _calendar_format = 0x7ffff5816b80, _time_zone = 0x555555ceebc0}
User avatar (0013465)
ludovic (administrator)
2019-03-18 11:06

do:

po theRange
(0013467)
rongten (reporter)
2019-03-18 11:22

That's easier! ;)

(gdb) po theRange
<NGCalendarDateRange[0x0x55555625e4f0]: startDate:2019-03-24 23:00:00 +0000 endDate: 11761240-03-30 00:00:00 +0000>

The horror!
(0013468)
rongten (reporter)
2019-03-18 11:28

For the moment in sogo.d the FreeBusy interval is commented out to use the defaults:

//SOGoFreeBusyDefaultInterval = (7,30);

If I remove the comment restarting the gdb session, I get:

(gdb) po theRange
<NGCalendarDateRange[0x0x555556224700]: startDate:2019-04-16 22:00:00 +0000 endDate: 11761240-03-30 00:00:00 +0000>
User avatar (0013469)
ludovic (administrator)
2019-03-18 11:33

As you can see, the end date is fucked up.

Do:

f 7
po r
po _startDate
po _endDate
po endDate
p delta
(0013470)
rongten (reporter)
2019-03-18 11:42

Here:
(gdb) f 7
0000007 0x00007fffe91218f6 in -[SOGoAppointmentFolder fetchFields:from:to:title:component:additionalFilters:includeProtectedInformation:] (self=0x5555561d0250,
    _cmd=0x7fffe9364300 <_OBJC_SELECTOR_TABLE+4704>, _fields=0x555556293f40, _startDate=0x555556262a60, _endDate=0x555556262fe0, title=0x0,
    _component=0x7fffe9360240 <_OBJC_INSTANCE_43>, filters=0x0, _includeProtectedInformation=1 '\001') at SOGoAppointmentFolder.m:1643
1643 in SOGoAppointmentFolder.m
(gdb) po r
<NGCalendarDateRange[0x0x5555561f84e0]: startDate:2019-04-16 22:00:00 +0000 endDate: 11761240-03-30 00:00:00 +0000>
(gdb) po _startDate
11761240-03-30 00:00:00 +0000
(gdb) po _endDate
2019-04-16 22:00:00 +0000
(gdb) po endDate
2019-04-16 22:00:00 +0000
(gdb) p delta
$1 = 1
User avatar (0013471)
ludovic (administrator)
2019-03-18 12:49

Ok do:

f 10
po startDate
po endDate
f 13
po today
po interval
po startDate
po endDate
(0013472)
rongten (reporter)
2019-03-18 14:20

(gdb) f 10
0000010 0x00007fffe91320bb in -[SOGoFreeBusyObject fetchFreeBusyInfosFrom:to:forContact:] (
    self=0x5555562ddf40, _cmd=0x7fffe936b390 <_OBJC_SELECTOR_TABLE+752>,
    startDate=0x555556262a60, endDate=0x555556262fe0, uid=0x0) at SOGoFreeBusyObject.m:300
300 SOGoFreeBusyObject.m: No such file or directory.
(gdb) po startDate
11761240-03-30 00:00:00 +0000
(gdb) po endDate
2019-04-16 22:00:00 +0000
(gdb) f 13
0000013 0x00007fffe9131cea in -[SOGoFreeBusyObject contentAsString] (self=0x5555562ddf40,
    _cmd=0x7fffe936b580 <_OBJC_SELECTOR_TABLE+1248>) at SOGoFreeBusyObject.m:222
222 in SOGoFreeBusyObject.m
(gdb) po today
2019-03-18 00:00:00 +0100
(gdb) po interval
(7, 30)
(gdb) po startDate
11761240-03-30 00:00:00 +0000
(gdb) po endDate
2019-04-16 22:00:00 +0000
User avatar (0013473)
ludovic (administrator)
2019-03-18 15:08

Do:

f 13
p start
p -start
po NSStringFromClass([interval class])
(0013474)
rongten (reporter)
2019-03-18 15:20

Here:

(gdb) f 13
0000013 0x00007fffe9131cea in -[SOGoFreeBusyObject contentAsString] (self=0x5555562ddf40,
    _cmd=0x7fffe936b580 <_OBJC_SELECTOR_TABLE+1248>) at SOGoFreeBusyObject.m:222
222 in SOGoFreeBusyObject.m
(gdb) p start
$2 = 7
(gdb) p -start
$3 = 4294967289
(gdb) po NSStringFromClass([interval class])

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5295736 in ?? () from /usr/lib/libgnustep-base.so.1.25
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(NSStringFromClass) will be abandoned.
When the function is done executing, GDB will silently stop.
User avatar (0013475)
ludovic (administrator)
2019-03-18 15:49

Try the upcoming nightly builds.
(0013476)
rongten (reporter)
2019-03-19 04:27

It works!!!

wget gets the proper info!

BEGIN:VCALENDAR
PRODID:-//Inverse inc./SOGo 4.0.7//EN
VERSION:2.0
BEGIN:VFREEBUSY
ATTENDEE:mailto:BLA@BLA.BLA
DTSTAMP:20190319T082002Z
DTSTART:20190304T230000Z
DTEND:20190417T220000Z
FREEBUSY;FBTYPE=BUSY:20190307T110000Z/20190307T120000Z
FREEBUSY;FBTYPE=BUSY:20190328T111500Z/20190328T121500Z
FREEBUSY;FBTYPE=BUSY:20190318T084500Z/20190318T094500Z
FREEBUSY;FBTYPE=BUSY:20190325T084500Z/20190325T094500Z
FREEBUSY;FBTYPE=BUSY:20190401T074500Z/20190401T084500Z
FREEBUSY;FBTYPE=BUSY:20190408T074500Z/20190408T084500Z
FREEBUSY;FBTYPE=BUSY:20190415T074500Z/20190415T084500Z
END:VFREEBUSY
END:VCALENDAR


Was it the signed-unsigned start end? Anyway, thank you!

I will check with the production server asap once the change is in the stable packages.
(0013479)
rongten (reporter)
2019-03-20 03:14

Actually, it is sufficient to set 0 as start date like

SOGoFreeBusyDefaultInterval = (0,90);

To fix the issue already in the existing installations, no need to wait!
User avatar (0013484)
ludovic (administrator)
2019-03-20 13:54

https://github.com/inverse-inc/sogo/commit/d75fe573b2802f08864858dd28cffe810c79d754 [^]

- Issue History
Date Modified Username Field Change
2017-09-15 09:06 rongten New Issue
2017-09-15 09:31 rongten Note Added: 0012293
2017-09-15 11:01 rongten Note Added: 0012294
2017-09-18 03:25 rongten Tag Attached: possible memory leak
2017-09-18 11:59 rongten Note Added: 0012306
2017-09-29 04:00 rongten Note Added: 0012340
2018-01-19 09:11 rongten Note Added: 0012526
2018-01-19 10:07 rongten Note Added: 0012527
2018-02-21 01:23 Nterowski Note Added: 0012615
2018-02-21 01:57 Nterowski Note Added: 0012616
2018-02-21 08:31 rongten Note Added: 0012617
2018-03-05 11:02 ludovic Note Added: 0012623
2018-03-09 11:48 sy-subrc Note Added: 0012646
2018-03-09 12:00 sy-subrc Note Edited: 0012646 View Revisions
2018-04-09 10:05 sy-subrc Note Added: 0012821
2018-08-09 11:25 sy-subrc Note Edited: 0012821 View Revisions
2018-08-09 11:27 sy-subrc Note Edited: 0012821 View Revisions
2018-08-09 11:27 sy-subrc Note Added: 0012993
2018-08-10 07:16 rongten Note Added: 0012994
2018-10-23 02:32 rongten Note Added: 0013124
2018-11-07 06:16 sy-subrc Note Added: 0013161
2019-01-08 10:13 sy-subrc Note Added: 0013238
2019-02-21 15:00 ludovic Note Added: 0013411
2019-03-05 06:20 rongten Note Added: 0013425
2019-03-05 08:34 rongten Note Added: 0013426
2019-03-08 08:26 sy-subrc Note Added: 0013432
2019-03-12 08:42 ludovic Note Added: 0013437
2019-03-12 10:04 sy-subrc Note Added: 0013438
2019-03-15 15:30 ludovic Note Added: 0013455
2019-03-18 04:21 rongten Note Added: 0013460
2019-03-18 04:50 rongten Note Added: 0013461
2019-03-18 05:14 rongten Note Added: 0013462
2019-03-18 09:53 ludovic Note Added: 0013463
2019-03-18 11:04 rongten Note Added: 0013464
2019-03-18 11:06 ludovic Note Added: 0013465
2019-03-18 11:22 rongten Note Added: 0013467
2019-03-18 11:28 rongten Note Added: 0013468
2019-03-18 11:33 ludovic Note Added: 0013469
2019-03-18 11:42 rongten Note Added: 0013470
2019-03-18 12:49 ludovic Note Added: 0013471
2019-03-18 14:20 rongten Note Added: 0013472
2019-03-18 15:08 ludovic Note Added: 0013473
2019-03-18 15:20 rongten Note Added: 0013474
2019-03-18 15:49 ludovic Note Added: 0013475
2019-03-19 04:27 rongten Note Added: 0013476
2019-03-20 03:14 rongten Note Added: 0013479
2019-03-20 13:54 ludovic Note Added: 0013484
2019-03-20 13:54 ludovic Status new => resolved
2019-03-20 13:54 ludovic Fixed in Version => 4.0.8
2019-03-20 13:54 ludovic Resolution open => fixed
2019-03-20 13:54 ludovic Assigned To => ludovic


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker