View Issue Details

IDProjectCategoryView StatusLast Update
0002227SOGoWeb Calendarpublic2013-02-08 10:12
Reporterpepelton Assigned Tofrancis  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionno change required 
Product Version2.0.4b 
Target VersionFixed in Version 
Summary0002227: Loading user's calendar in web UI causes core dump
Description
I upgraded two separate SOGo servers to sogo-2.0.4a-1.centos6.i686
from 1.3.15a using yum.

After the upgrade on both servers at least one user noticed that his
calendar is empty. If I login to SOGo with this account I can see the
following error in the logs:

"
77.86.207.83 - - [04/Feb/2013:20:42:38 GMT] "POST
/SOGo/so/juha@domainremoved.eu/Calendar/taskslist?show-completed=0&asc=true&sort=end
HTTP/1.1" 200 710/0 0.024 - - 1M
2013-02-04 20:42:39.224 sogod[10801] WOCompoundElement: pool embedding is on.
2013-02-04 20:42:39.224 sogod[10801] WOCompoundElement: id logging is on.
77.86.207.83 - - [04/Feb/2013:20:42:39 GMT] "POST
/SOGo/so/juha@domainremoved.eu/Calendar/weekview HTTP/1.1" 200 1954/0
0.330 22374 91% 1M
EXCEPTION: <NSException: 0xb609966c> NAME:NSInvalidArgumentException
REASON:GSTimeZone(instance) does not recognize computedDateForDate:
INFO:(null)
Feb 04 20:42:39 sogod [1953]: <0x0xb63ebd94[WOWatchDogChild]> child 10801 exited
Feb 04 20:42:39 sogod [1953]: <0x0xb63ebd94[WOWatchDogChild]>
(terminated due to signal 6, coredump)
Feb 04 20:42:39 sogod [1953]: <0x0xb63ebd94[WOWatchDogChild]> avoiding
to respawn child before 2013-02-04 20:42:43 +0200
Feb 04 20:42:43 sogod [1953]: <0x0xb62ce01c[WOWatchDog]> child spawned
with pid 10817
"

After upgrading to 2.0.4b the problem persists.
Additional InformationWhat is common with both users experiencing the problem is that they have been syncing events
from their old Nokia phones with Funambol. But I have other users
doing this as well who do not experience this problem.

I managed to subscribe to one of the users' calendar in Thunderbird although
its not shown in the SOGo web UI.

I exported then the calendar to ICS and used an ICS validator, which reported:

"
Error: Error was: Error at line 24: Cannot set timezone for UTC properties
Cause: Caused by: Cannot set timezone for UTC properties

Context for line 24:
21: END:VTIMEZONE
22: BEGIN:VEVENT
23: LAST-MODIFIED:20111024T062103Z
24: DTSTAMP;TZID=Europe/Helsinki:20120510T105656
25: UID:7464-4FAB7380-5-4559CA80
26: SUMMARY:Notaarintie 32\, hulevesisuunnitelman hyväksyntä
27: PRIORITY:0
"

If I compare it to a working calendar I see the difference that there
is no TZID on DTSTAMP lines. Instead they look like this:

"
DTSTAMP:20120214T125104Z
"

Is the DTSTAMP with TZID perhaps something Sogo cannot handle?
TagsNo tags attached.

Activities

francis

francis

2013-02-06 08:37

administrator   ~0005353

Can you attach the vCalendar of the event (it should contain the vTimezone and the vEvent)?
pepelton

pepelton

2013-02-06 15:12

reporter   ~0005363

Here is what I found:

If I backup the calendar with sogo-tool, remove the calendar and try to restore it, the restore chokes (dumps as well) on some events:

"
2013-02-06 19:25:31.705 sogo-tool[12952] restoring record '00000000A04B7D0493165C4D9FBCC00594B3C989A49A2B00'
sogo-tool: Uncaught exception NSInvalidArgumentException, reason: iCalRecurrenceRule(instance) does not recognize orderOfValueKeys
Aborted (core dumped)
"

Here is the event's vCalendar entry:

"
{
                    "c_content" = "BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Istanbul
BEGIN:DAYLIGHT
DTSTART:20120325T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:Europe/Istanbul
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20121028T040000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:Europe/Istanbul
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
TZID:GMT
BEGIN:STANDARD
DTSTART:19700101T000000
RDATE:19700101T000000
TZOFFSETFROM:+0000
TZOFFSETTO:+0000
TZNAME:GMT
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:00000000A04B7D0493165C4D9FBCC00594B3C989A49A2B00
SUMMARY:Marjatta
DESCRIPTION:
LOCATION:
CATEGORIES:Birthday
CLASS:PRIVATE
DTSTART;VALUE=DATE:20120420
DTEND;VALUE=DATE:20120421
PRIORITY:5
STATUS:0
RRULE;VALUE=DATE:FREQ=YEARLY;INTERVAL=1;BYMONTH=4;BYMONTHDAY=20;UNTIL=20300419
X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
X-FUNAMBOL-ALLDAY:1
X-FUNAMBOL-FOLDER:DEFAULT_FOLDER
X-MICROSOFT-CDO-BUSYSTATUS:0
X-MICROSOFT-CDO-REPLYTIME:
X-FUNAMBOL-BILLINGINFO:
X-FUNAMBOL-COMPANIES:
X-FUNAMBOL-MILEAGE:
X-FUNAMBOL-NOAGING:0
END:VEVENT
END:VCALENDAR
";
                    "c_name" = 00000000A04B7D0493165C4D9FBCC00594B3C989A49A2B00;
                },
"

Here is another from other user's calendar:

                    "c_content" = "BEGIN:VCALENDAR
BEGIN:VEVENT
UID:19C8-4F87FC00-21-45C8D680
LAST-MODIFIED:20070605T123101Z
SUMMARY:Kes\U00E4loma
DESCRIPTION:Kes\U00E4loma
CLASS:PUBLIC
STATUS:CONFIRMED
ATTENDEE;CN=John Doe;ROLE=CHAIR;PARTSTAT=ACCEPTED:MAILTO:john.doe@domainremoved.fi
DTSTART;VALUE=DATE:20070716
DTSTAMP:20120413T095852Z
DTEND;VALUE=DATE:20070716
RRULE:UNTIL=20070721T000000Z;FREQ=DAILY
END:VEVENT
END:VCALENDAR";
                    "c_name" = "19C8-4F87FC00-21-45C8D680";
                },

If I delete the events from the backup file and then restore with sogo-tool, the calendar starts working. But some of the users have quite many of these kind of events so fixing them manually isn't really a good option...

Can you identify what the problem is from these events or should I produce more examples?
pepelton

pepelton

2013-02-06 17:07

reporter   ~0005368

Going through the calendar entries I found broken ones that were generated via SOGo as well (I think the ones I reported earlier were originally from other sources like Funambol). Here is an example:

        {
            "c_content" = "BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Inverse inc./SOGo 1.3.12//EN
BEGIN:VEVENT
UID:3692-4FA3A180-359-2DB5B280
SUMMARY:Oma meno
DESCRIPTION:Bohemia / KO
CREATED:20120504T093050Z
DTSTAMP:20120504T093050Z
LAST-MODIFIED:20120507T055506Z
DTSTART;TZID=Europe/Helsinki:20120515T140000
DTEND;TZID=Europe/Helsinki:20120515T160000
TRANSP:OPAQUE
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Helsinki
X-LIC-LOCATION:Europe/Helsinki
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:EEST
DTSTART:19700329T030000
RRULE:BYDAY=-1SU;FREQ=YEARLY;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:EET
DTSTART:19701025T040000
RRULE:BYDAY=-1SU;FREQ=YEARLY;BYMONTH=10
END:STANDARD
END:VTIMEZONE
END:VCALENDAR";
            "c_name" = "3692-4FA3A180-359-2DB5B280.ics";
        },
francis

francis

2013-02-07 11:11

administrator   ~0005370

Have you updated all the SOPE packages?
pepelton

pepelton

2013-02-07 15:46

reporter   ~0005372

These are the packages I have installed:

gnustep-base-1.23.0-1.i686
gnustep-make-2.6.1-1.i686
lasso-2.3.6-1.centos6.i686
libffi-3.0.10-1.i686
libmemcached-0.49-1.i686
python-lxml-2.3.3-1.centos6.i686
sogo-2.0.4b-1.centos6.i686
sogo-ealarms-notify-2.0.4b-1.centos6.i686
sogo-tool-2.0.4b-1.centos6.i686
sope49-appserver-4.9-20130204_1664.el6.1.i686
sope49-core-4.9-20130204_1664.el6.1.i686
sope49-gdl1-mysql-4.9-20130204_1664.el6.1.i686
sope49-xml-4.9-20130204_1664.el6.1.i686
sope49-ldap-4.9-20130204_1664.el6.1.i686
sope49-cards-2.0_20120418-1.centos6.i686
sope49-gdl1-contentstore-2.0.4b-1.centos6.i686
sope49-sbjson-2.3.1-20130204_1664.el6.1.i686
sope49-gdl1-4.9-20130204_1664.el6.1.i686
sope49-gdl1-postgresql-4.9-20130204_1664.el6.1.i686
sope49-mime-4.9-20130204_1664.el6.1.i686

Comparing this to the packages listed on the download page for CentOS6 I notice one difference:

I have sope49-cards-2.0_20120418-1.centos6.i686 when what is available on the download site is sope49-cards-2.0.4b-1.centos6.x86_64.rpm. I guess I have updated the servers at some point to use a nightly package and then have forgotten about it.

I upgraded to the sope49-cards-2.0.4b package and the problem appears to be solved.

Thanks for pointing me to the right direction.

Issue History

Date Modified Username Field Change
2013-02-04 18:21 pepelton New Issue
2013-02-06 08:37 francis Note Added: 0005353
2013-02-06 15:12 pepelton Note Added: 0005363
2013-02-06 17:07 pepelton Note Added: 0005368
2013-02-07 11:11 francis Note Added: 0005370
2013-02-07 15:46 pepelton Note Added: 0005372
2013-02-07 15:50 ludovic Status new => closed
2013-02-07 15:50 ludovic Resolution open => no change required
2013-02-08 10:12 francis Status closed => resolved
2013-02-08 10:12 francis Assigned To => francis