[SOGo] Problem with recurring events
Hello sogo users, I have a problem with recurring events. If I create a recurring event on Outlook 2010, Sogo correctly save the data on the database. When I create an exception (I edit an instance of a recurring event), I see the exception on the client, but after folder update, the exception disappears and I go back to the original situation (no exceptions). This is my server situation: SO: Ubuntu server 11.10 amd64 SOGo: 2.0.0 release: 3960 Openchange: 1.0 IMAP server: dovecot 2.0.13 SMTP server: Postfix 2.8.5 Database server: MySQL 5.1 (all data saved here) --- Fabio Onorini -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
En/na Luca Olivetti ha escrit: Al 18/09/10 14:28, En/na Luca Olivetti ha escrit: I now tried to initialize ranges with ranges = [[NSMutableArray alloc] initWithCapacity: numberOfMonthsInRange] instead of ranges = [NSMutableArray] arrayWithCapacity: numberOfMonthsInRange] that gets rid of the 4294967295 issue, but it still smashes the stack when the method returns (i.e. on the closing bracket at line 433). That was surely a red-herring (a gdb glitch maybe?). Now with the original file the count is one. It seems that during the exit of the method it tries to free some already freed object. Since I don't understand what's happening, this is the state of the locals between the return ranges and the }: Well, I managed to compile sogo with -fno-stack-protector and the problem went away. Of course I'm quite scared to deploy it: it could be that objective-c/gnustep/sogo doesn't play well with -fstack-protector (but notice that everything else but sogo has been built with -fstack-protector, since it's a default in mandriva 2010.0) or that there's really some stack corruption in that methodcd and masking the problem will lead to data corruption later on. What do you think? Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
Al 17/09/10 22:10, En/na Luca Olivetti ha escrit:
Al 17/09/10 17:37, En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
Since I still have the RPMs built under mandriva 2009.1, I replaced
everything with the old versions (gnustep-base included) and the stack
smashing is still there, so it's either another library causing it (it
happens in libc) or an underlying problem in sope/sogo.
Well, I really need some help here (not knowing much about objective c
and gdb).
google helped ;-)
I loaded the database with just one of the events causing the crash, I
attached the debugger to the running sogo and I can inspect the full
backtrace.
The problem appears to be here:
...
#7 0xb757cfd0 in -[iCalMonthlyRecurrenceCalculator
recurrenceRangesWithinCalendarDateRange:] (self=0xa2bdcf0,
_cmd=0xb759f9f0,
_r=0xa5c6c20) at iCalMonthlyRecurrenceCalculator.m:433
433 }
Current language: auto; currently objective-c
(gdb)
Not very helpful (to me) since line 433 is the closing bracket of the
method, so let's see with what parameters it was called:
Well, that's actually the point. It appears that ranges gets messed up.
I stepped in the program, and when it calls the method
_addInstanceWithStartDate (line 418 of
iCalMonthlyRecurrenceCalculator.m), inside that method at line 170 it
does:
[_ranges addObject: r]
Just before that line:
(gdb) p -[_ranges count]
$9 = 0
But right after executing it:
(gdb) p -[_ranges count]
$11 = 4294967295
I also stepped into the -[GSMutableArray addObject:] method and it seems
to do the right thing:
(gdb) break iCalMonthlyRecurrenceCalculator.m:170
Breakpoint 1 at 0xb757c08a: file iCalMonthlyRecurrenceCalculator.m, line
170.
(gdb) c
Continuing.
Breakpoint 1, -[iCalMonthlyRecurrenceCalculator
_addInstanceWithStartDate:limitDate:limitRange:toArray:] (self=0xa48bdd8,
_cmd=0xb759b138, _startDate=0xa6199d0, _until=0x0, _r=0x925cf68,
_ranges=0xa619970) at iCalMonthlyRecurrenceCalculator.m:170
170 [_ranges addObject: r];
(gdb) s
-[GSMutableArray addObject:] (self=0xb759247c, _cmd=0xa48bdd8,
anObject=0xb70050c0) at GSArray.m:408
408 {
(gdb) s
409 if (anObject == nil)
(gdb) s
414 if (_count = _capacity)
(gdb) s
429 _contents_array[_count] = RETAIN(anObject);
(gdb) p _count
$1 = 0
(gdb) p _capacity
$2 = 2
(gdb) next
430 _count++; /* Do this AFTER we have retained the object. */
(gdb) p _count
$3 = 0
(gdb) next
431 }
(gdb) p _count
$4 = 1
(gdb) next
-[iCalMonthlyRecurrenceCalculator
_addInstanceWithStartDate:limitDate:limitRange:toArray:]
(self=0xa48bdd8, _cmd=0xb759b138,
_startDate=0xa6199d0, _until=0x0, _r=0x925cf68, _ranges=0xa619970) at
iCalMonthlyRecurrenceCalculator.m:171
171 [r release];
(gdb) p _count
No symbol _count in current context.
(gdb) p -[_ranges count]
$5 = 4294967295
BTW, that's UINT_MAX (or 0x).
Any idea of what could corrupt ranges here?
I suspected a mismatch in the layout of the structures due to
differences in the compiler used (I don't know if it applies to
objective c).
It appears that the gnustep-base rpm was built with gcc-4.4.0, while the
currently installed gcc is 4.4.1, so I rebuilt the gnustep-base rpms.
NSMutableArray is used extensively in sogo but I can only see it failing
here.
I now rebuilt everything with gnustep-base-1.20.1 but the problem persists.
Bye
--
Luca Olivetti
Wetron Automatización S.A. http://www.wetron.es/
Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007
--
users@sogo.nu
https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
Al 18/09/10 11:55, En/na Luca Olivetti ha escrit:
Al 17/09/10 22:10, En/na Luca Olivetti ha escrit:
Al 17/09/10 17:37, En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
Since I still have the RPMs built under mandriva 2009.1, I replaced
everything with the old versions (gnustep-base included) and the stack
smashing is still there, so it's either another library causing it (it
happens in libc) or an underlying problem in sope/sogo.
Well, I really need some help here (not knowing much about objective c
and gdb).
google helped ;-)
I loaded the database with just one of the events causing the crash, I
attached the debugger to the running sogo and I can inspect the full
backtrace.
The problem appears to be here:
...
#7 0xb757cfd0 in -[iCalMonthlyRecurrenceCalculator
recurrenceRangesWithinCalendarDateRange:] (self=0xa2bdcf0,
_cmd=0xb759f9f0,
_r=0xa5c6c20) at iCalMonthlyRecurrenceCalculator.m:433
433 }
Current language: auto; currently objective-c
(gdb)
Not very helpful (to me) since line 433 is the closing bracket of the
method, so let's see with what parameters it was called:
Well, that's actually the point. It appears that ranges gets messed
up.
I stepped in the program, and when it calls the method
_addInstanceWithStartDate (line 418 of
iCalMonthlyRecurrenceCalculator.m), inside that method at line 170 it
does:
[_ranges addObject: r]
Just before that line:
(gdb) p -[_ranges count]
$9 = 0
But right after executing it:
(gdb) p -[_ranges count]
$11 = 4294967295
I also stepped into the -[GSMutableArray addObject:] method and it seems
to do the right thing:
(gdb) break iCalMonthlyRecurrenceCalculator.m:170
Breakpoint 1 at 0xb757c08a: file iCalMonthlyRecurrenceCalculator.m, line
170.
(gdb) c
Continuing.
Breakpoint 1, -[iCalMonthlyRecurrenceCalculator
_addInstanceWithStartDate:limitDate:limitRange:toArray:]
(self=0xa48bdd8,
_cmd=0xb759b138, _startDate=0xa6199d0, _until=0x0, _r=0x925cf68,
_ranges=0xa619970) at iCalMonthlyRecurrenceCalculator.m:170
170 [_ranges addObject: r];
(gdb) s
-[GSMutableArray addObject:] (self=0xb759247c, _cmd=0xa48bdd8,
anObject=0xb70050c0) at GSArray.m:408
408 {
(gdb) s
409 if (anObject == nil)
(gdb) s
414 if (_count = _capacity)
(gdb) s
429 _contents_array[_count] = RETAIN(anObject);
(gdb) p _count
$1 = 0
(gdb) p _capacity
$2 = 2
(gdb) next
430 _count++; /* Do this AFTER we have retained the object. */
(gdb) p _count
$3 = 0
(gdb) next
431 }
(gdb) p _count
$4 = 1
(gdb) next
-[iCalMonthlyRecurrenceCalculator
_addInstanceWithStartDate:limitDate:limitRange:toArray:]
(self=0xa48bdd8, _cmd=0xb759b138,
_startDate=0xa6199d0, _until=0x0, _r=0x925cf68, _ranges=0xa619970) at
iCalMonthlyRecurrenceCalculator.m:171
171 [r release];
(gdb) p _count
No symbol _count in current context.
(gdb) p -[_ranges count]
$5 = 4294967295
BTW, that's UINT_MAX (or 0x).
Any idea of what could corrupt ranges here?
I suspected a mismatch in the layout of the structures due to
differences in the compiler used (I don't know if it applies to
objective c).
It appears that the gnustep-base rpm was built with gcc-4.4.0, while the
currently installed gcc is 4.4.1, so I rebuilt the gnustep-base rpms.
NSMutableArray is used extensively in sogo but I can only see it failing
here.
I now rebuilt everything with gnustep-base-1.20.1 but the problem persists.
I now tried to initialize ranges with
ranges = [[NSMutableArray alloc] initWithCapacity: numberOfMonthsInRange]
instead of
ranges = [NSMutableArray] arrayWithCapacity: numberOfMonthsInRange]
that gets rid of the 4294967295 issue, but it still smashes the stack
when the method returns (i.e. on the closing bracket at line 433).
Bye
--
Luca Olivetti
Wetron Automatización S.A. http://www.wetron.es/
Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007
--
users@sogo.nu
https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
Al 18/09/10 14:28, En/na Luca Olivetti ha escrit: I now tried to initialize ranges with ranges = [[NSMutableArray alloc] initWithCapacity: numberOfMonthsInRange] instead of ranges = [NSMutableArray] arrayWithCapacity: numberOfMonthsInRange] that gets rid of the 4294967295 issue, but it still smashes the stack when the method returns (i.e. on the closing bracket at line 433). That was surely a red-herring (a gdb glitch maybe?). Now with the original file the count is one. It seems that during the exit of the method it tries to free some already freed object. Since I don't understand what's happening, this is the state of the locals between the return ranges and the }: Breakpoint 1, -[iCalMonthlyRecurrenceCalculator recurrenceRangesWithinCalendarDateRange:] (self=0xb385340, _cmd=0xb767f7d0, _r=0xb570b18) at iCalMonthlyRecurrenceCalculator.m:433 433 } (gdb) info locals ranges = (class NSMutableArray *) 0xb496370 timeZone = (class NSTimeZone *) 0xa083a30 eventStartDate = (class NSCalendarDate *) 0xaa50608 rStart = (class NSCalendarDate *) 0xb385378 rEnd = (class NSCalendarDate *) 0xb495ec0 until = (class NSCalendarDate *) 0x0 referenceDate = (class NSCalendarDate *) 0xb496398 eventDayOfMonth = 4 monthIdxInRange = 2 numberOfMonthsInRange = 2 interval = 1 repeatCount = 0 diff = 108 count = 0 byMonthList = \000\000\000\000\000\000\000\000\001\000\000 byMonth = (class NSArray *) 0xb496028 byMonthDay = (class NSArray *) 0x0 byPositiveMonthDaySet = @\e(�xs8\...@!\000\000�\000\000\000@\e(�\030X\020�\000U\023��\031\000 byNegativeMonthDaySet = �O\f��\002��xS8\013\004B \224\r��w\020�\030\013w\...@\000\000 byDayMask = (class iCalByDayMask *) 0x0 (gdb) p [ranges count] $1 = 1 (gdb) p [ranges retainCount] $2 = 1 (gdb) p [timeZones retainCount] No symbol timeZones in current context. (gdb) p [timeZone retainCount] $3 = 92 (gdb) p [eventStartDate retainCount] $4 = 3 (gdb) p [rStart retainCount] $5 = 2 (gdb) p [rEnd retainCount] $6 = 2 (gdb) p [until retainCount] $7 = 0 (gdb) p [referenceDate retainCount] $8 = 1 (gdb) p [byMonth retainCount] $9 = 1 (gdb) p [byMonthDay retainCount] $10 = 0 (gdb) p [byDayMask retainCount] $11 = 0 (gdb) What other information could I provide to try and fix this issue? Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
Al 17/09/10 17:37, En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
Since I still have the RPMs built under mandriva 2009.1, I replaced
everything with the old versions (gnustep-base included) and the stack
smashing is still there, so it's either another library causing it (it
happens in libc) or an underlying problem in sope/sogo.
Well, I really need some help here (not knowing much about objective c
and gdb).
google helped ;-)
I loaded the database with just one of the events causing the crash, I
attached the debugger to the running sogo and I can inspect the full
backtrace.
The problem appears to be here:
...
#7 0xb757cfd0 in -[iCalMonthlyRecurrenceCalculator
recurrenceRangesWithinCalendarDateRange:] (self=0xa2bdcf0,
_cmd=0xb759f9f0,
_r=0xa5c6c20) at iCalMonthlyRecurrenceCalculator.m:433
433 }
Current language: auto; currently objective-c
(gdb)
Not very helpful (to me) since line 433 is the closing bracket of the
method, so let's see with what parameters it was called:
Well, that's actually the point. It appears that ranges gets messed up.
I stepped in the program, and when it calls the method
_addInstanceWithStartDate (line 418 of
iCalMonthlyRecurrenceCalculator.m), inside that method at line 170 it does:
[_ranges addObject: r]
Just before that line:
(gdb) p -[_ranges count]
$9 = 0
But right after executing it:
(gdb) p -[_ranges count]
$11 = 4294967295
I also stepped into the -[GSMutableArray addObject:] method and it seems
to do the right thing:
(gdb) break iCalMonthlyRecurrenceCalculator.m:170
Breakpoint 1 at 0xb757c08a: file iCalMonthlyRecurrenceCalculator.m, line
170.
(gdb) c
Continuing.
Breakpoint 1, -[iCalMonthlyRecurrenceCalculator
_addInstanceWithStartDate:limitDate:limitRange:toArray:] (self=0xa48bdd8,
_cmd=0xb759b138, _startDate=0xa6199d0, _until=0x0, _r=0x925cf68,
_ranges=0xa619970) at iCalMonthlyRecurrenceCalculator.m:170
170 [_ranges addObject: r];
(gdb) s
-[GSMutableArray addObject:] (self=0xb759247c, _cmd=0xa48bdd8,
anObject=0xb70050c0) at GSArray.m:408
408 {
(gdb) s
409 if (anObject == nil)
(gdb) s
414 if (_count = _capacity)
(gdb) s
429 _contents_array[_count] = RETAIN(anObject);
(gdb) p _count
$1 = 0
(gdb) p _capacity
$2 = 2
(gdb) next
430 _count++; /* Do this AFTER we have retained the object. */
(gdb) p _count
$3 = 0
(gdb) next
431 }
(gdb) p _count
$4 = 1
(gdb) next
-[iCalMonthlyRecurrenceCalculator
_addInstanceWithStartDate:limitDate:limitRange:toArray:]
(self=0xa48bdd8, _cmd=0xb759b138,
_startDate=0xa6199d0, _until=0x0, _r=0x925cf68, _ranges=0xa619970) at
iCalMonthlyRecurrenceCalculator.m:171
171 [r release];
(gdb) p _count
No symbol _count in current context.
(gdb) p -[_ranges count]
$5 = 4294967295
BTW, that's UINT_MAX (or 0x).
Any idea of what could corrupt ranges here?
I suspected a mismatch in the layout of the structures due to
differences in the compiler used (I don't know if it applies to
objective c).
It appears that the gnustep-base rpm was built with gcc-4.4.0, while the
currently installed gcc is 4.4.1, so I rebuilt the gnustep-base rpms.
NSMutableArray is used extensively in sogo but I can only see it failing
here.
Bye
--
Luca Olivetti
Wetron Automatización S.A. http://www.wetron.es/
Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007
--
users@sogo.nu
https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
En/na Luca Olivetti ha escrit: The funny (not really) thing is that the stack smashing is back :-( I upgraded the test server with the same version of the distribution as the production server. The test server previously was mandriva 2009.1: gcc-3.4.2 gnustep-base-1.18.0 gnustep-make-2.0.8 now it is mandriva 2010.0: gcc-4.4.1 gnustep-base-1.18.0 gnustep-make-2.2.0 The RPMs I used are the same but rebuilt with the new set of tools. I checked the RHEL5 RPMs and they have gnustep-base 1.16.3 and gnustep-make 2.0.6. Could it be that sope/sogo has some problems with a newer gcc/gnustep? Since I still have the RPMs built under mandriva 2009.1, I replaced everything with the old versions (gnustep-base included) and the stack smashing is still there, so it's either another library causing it (it happens in libc) or an underlying problem in sope/sogo. Btw, I'll try to debug it further, but it seems that the events causing the stack smashing are yearly events (birthdays actually), apparently imported from outlook (which automatically creates an event when you put a birthday in a contact). The rule actually causing the problem is this: RRULE:FREQ=YEARLY;BYMONTH=11;COUNT=0 if I change that to RRULE:FREQ=YEARLY there's no stack smashing (though I still cannot see the event in the calendar). This is one such event: BEGIN:VCALENDAR VERSION:1.0 TZ:+0100 DAYLIGHT:TRUE;+0200;19570331T02;19571027T03;; DAYLIGHT:TRUE;+0200;19580330T02;19581026T03;; DAYLIGHT:TRUE;+0200;19590329T02;19591025T03;; DAYLIGHT:TRUE;+0200;19600327T02;19601030T03;; DAYLIGHT:TRUE;+0200;19610326T02;19611029T03;; DAYLIGHT:TRUE;+0200;19620325T02;19621028T03;; DAYLIGHT:TRUE;+0200;19630331T02;19631027T03;; BEGIN:VEVENT UID:1073742929 X-FUNAMBOL-ALLDAY:1 DTSTART:19571107 DTEND:19571108 X-MICROSOFT-CDO-BUSYSTATUS:0 CATEGORIES: DESCRIPTION: LOCATION: STATUS:0 SUMMARY:xx CLASS:PUBLIC RRULE:FREQ=YEARLY;BYMONTH=11;COUNT=0 X-FUNAMBOL-AALARMOPTIONS:4 END:VEVENT END:VCALENDAR Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
On Lunes 30 Agosto 2010 16.11 CEST, Luca Olivetti l...@wetron.es wrote: Been away from sogo for a while. Now I'm testing 1.3.1. Still working on this on and off :-( I took a backup with sogo-tool and restored it in a test server with 1.3.1 (using -F to use the same data). There's no problem with the stack now (but note that the test server is i586 while the production server is x86_64) but I still have problems with recurring events. The funny (not really) thing is that the stack smashing is back :-( I upgraded the test server with the same version of the distribution as the production server. The test server previously was mandriva 2009.1: gcc-3.4.2 gnustep-base-1.18.0 gnustep-make-2.0.8 now it is mandriva 2010.0: gcc-4.4.1 gnustep-base-1.18.0 gnustep-make-2.2.0 The RPMs I used are the same but rebuilt with the new set of tools. I checked the RHEL5 RPMs and they have gnustep-base 1.16.3 and gnustep-make 2.0.6. Could it be that sope/sogo has some problems with a newer gcc/gnustep? Btw, I'll try to debug it further, but it seems that the events causing the stack smashing are yearly events (birthdays actually), apparently imported from outlook (which automatically creates an event when you put a birthday in a contact). The rule actually causing the problem is this: RRULE:FREQ=YEARLY;BYMONTH=11;COUNT=0 if I change that to RRULE:FREQ=YEARLY there's no stack smashing (though I still cannot see the event in the calendar). This is one such event: BEGIN:VCALENDAR VERSION:1.0 TZ:+0100 DAYLIGHT:TRUE;+0200;19570331T02;19571027T03;; DAYLIGHT:TRUE;+0200;19580330T02;19581026T03;; DAYLIGHT:TRUE;+0200;19590329T02;19591025T03;; DAYLIGHT:TRUE;+0200;19600327T02;19601030T03;; DAYLIGHT:TRUE;+0200;19610326T02;19611029T03;; DAYLIGHT:TRUE;+0200;19620325T02;19621028T03;; DAYLIGHT:TRUE;+0200;19630331T02;19631027T03;; BEGIN:VEVENT UID:1073742929 X-FUNAMBOL-ALLDAY:1 DTSTART:19571107 DTEND:19571108 X-MICROSOFT-CDO-BUSYSTATUS:0 CATEGORIES: DESCRIPTION: LOCATION: STATUS:0 SUMMARY:xx CLASS:PUBLIC RRULE:FREQ=YEARLY;BYMONTH=11;COUNT=0 X-FUNAMBOL-AALARMOPTIONS:4 END:VEVENT END:VCALENDAR Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
En/na Ludovic Marcotte ha escrit: On 31/08/10 11:39 AM, Luca Olivetti wrote: Probably, in fact he's using a windows mobile device :-/ but I doubt he's the only one. But, shouldn't the funambol connector filter/massage those entries, For massaging, we generally point folks to http://sogo.ca/ :-) But I was referring to definition 2 of http://en.wiktionary.org/wiki/massage#Verb To manipulate (data or a document) to make it more presentable or more convenient to work with avoiding them entering the database in the first place? And now that they are there, is there a way for sogo to be more lenient/fix those entries? Besides, the EXDATE is only part of the problem, sogo also chokes on the RRULE (i.e, fixing the EXDATE doesn't fix the problem). Yes - open a ticket and attach the culprit event to it. Ok, done http://www.sogo.nu/bugs/view.php?id=797 Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
On 31/08/10 11:39 AM, Luca Olivetti wrote: Probably, in fact he's using a windows mobile device :-/ but I doubt he's the only one. But, shouldn't the funambol connector filter/massage those entries, For massaging, we generally point folks to http://sogo.ca/ avoiding them entering the database in the first place? And now that they are there, is there a way for sogo to be more lenient/fix those entries? Besides, the EXDATE is only part of the problem, sogo also chokes on the RRULE (i.e, fixing the EXDATE doesn't fix the problem). Yes - open a ticket and attach the culprit event to it. Regards, -- Ludovic Marcotte lmarco...@inverse.ca :: +1.514.755.3630 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
En/na Luca Olivetti ha escrit: En/na Luca Olivetti ha escrit: While doing the restore, I see a bunch of these messages: 2010-08-30 15:19:25.843 sogo-tool[18846] restoring record '1073742958' 2010-08-30 15:19:25.850 sogo-tool[18846] File NSCalendarDate.m: 1440. In [NSCalendarDate -initWithYear:month:day:hour:minute:second:timeZone:] invalid month given - 4294967295 This is record 1073742958 in the backup file (the summary is not the original one but it doesn't matter, I tested it both ways): c_content = BEGIN:VCALENDAR VERSION:1.0 TZ:+0100 DAYLIGHT:TRUE;+0200;20090329T02;20091025T03;; DAYLIGHT:TRUE;+0200;20100328T02;20101031T03;; DAYLIGHT:TRUE;+0200;20110327T02;20111030T03;; DAYLIGHT:TRUE;+0200;20120325T02;20121028T03;; DAYLIGHT:TRUE;+0200;20130331T02;20131027T03;; DAYLIGHT:TRUE;+0200;20140330T02;20141026T03;; DAYLIGHT:TRUE;+0200;20150329T02;20151025T03;; BEGIN:VEVENT UID:1073742958 X-FUNAMBOL-ALLDAY:1 DTSTART:20090522 DTEND:20090523 X-MICROSOFT-CDO-BUSYSTATUS:0 CATEGORIES: DESCRIPTION: LOCATION: STATUS:0 SUMMARY:XX CLASS:PUBLIC RRULE:FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=22;COUNT=0 EXDATE:2009-11-22;2010-05-22 This is the line causing the invalid month given. If I change it to EXDATE:20091122,20100522 it doesn't give that error message anymore, but it still cannot be edited on the webinterface (it gives a 404 right away). To fix it completely I have to remove both the INTERVAL=1 and the COUNT=0 from the RRULE line. Does anybody know how that (wrong?) data could possibly enter the database (accessed only through sogo and the funambol connector) and, more importantly, how to fix it now that it's already there? Bye RDATE: X-FUNAMBOL-AALARMOPTIONS:4 END:VEVENT END:VCALENDAR ; c_name = 1073742958; }, Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
Does anybody know how that (wrong?) data could possibly enter the database (accessed only through sogo and the funambol connector) and, more importantly, how to fix it now that it's already there? It's likely one of your funambol devices that generates those bad EXDATE entries. Mobile devices are well known for not respecting standards or inventing variations thereof. -- Wolfgang Sourdeau :: +1 (514) 447-4918 ext. 125 :: wsourd...@inverse.ca Inverse inc. Leaders behind SOGo (sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
En/na Wolfgang Sourdeau ha escrit: Does anybody know how that (wrong?) data could possibly enter the database (accessed only through sogo and the funambol connector) and, more importantly, how to fix it now that it's already there? It's likely one of your funambol devices that generates those bad EXDATE entries. Mobile devices are well known for not respecting standards or inventing variations thereof. Probably, in fact he's using a windows mobile device :-/ but I doubt he's the only one. But, shouldn't the funambol connector filter/massage those entries, avoiding them entering the database in the first place? And now that they are there, is there a way for sogo to be more lenient/fix those entries? Besides, the EXDATE is only part of the problem, sogo also chokes on the RRULE (i.e, fixing the EXDATE doesn't fix the problem). Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] Problem with recurring events [was Re: stack smashing detected]
En/na Luca Olivetti ha escrit: En/na Wolfgang Sourdeau ha escrit: Any hint? There is likely one particular event that causes the issue. What you might want to do is to extract the event in question. Since the crash occurs in the reccurence code, you need to search for an element in your boss's tables where the c_cycleinfo column is not null and where the c_creationdate column is recent enough. There is a bunch of those, may I assume that, since the crash occurs in iCalMonthlyRecurrenceCalculator, that the event causing the problem is a monthly one? The columns c_startdate and c_enddate are unix timestamps? Finally, I don't think that the c_creationdate matters, after all it still works with the version of sogo that I'm running now, so it could be and old entry. If you wish, you could send us a dump of your boss's tables so that we can debug this from here... If I cannot debug it myself I'll ask for permission, thanks. Been away from sogo for a while. Now I'm testing 1.3.1. I took a backup with sogo-tool and restored it in a test server with 1.3.1 (using -F to use the same data). There's no problem with the stack now (but note that the test server is i586 while the production server is x86_64) but I still have problems with recurring events. While doing the restore, I see a bunch of these messages: 2010-08-30 15:19:25.843 sogo-tool[18846] restoring record '1073742958' 2010-08-30 15:19:25.850 sogo-tool[18846] File NSCalendarDate.m: 1440. In [NSCalendarDate -initWithYear:month:day:hour:minute:second:timeZone:] invalid month given - 4294967295 This is record 1073742958 in the backup file (the summary is not the original one but it doesn't matter, I tested it both ways): c_content = BEGIN:VCALENDAR VERSION:1.0 TZ:+0100 DAYLIGHT:TRUE;+0200;20090329T02;20091025T03;; DAYLIGHT:TRUE;+0200;20100328T02;20101031T03;; DAYLIGHT:TRUE;+0200;20110327T02;20111030T03;; DAYLIGHT:TRUE;+0200;20120325T02;20121028T03;; DAYLIGHT:TRUE;+0200;20130331T02;20131027T03;; DAYLIGHT:TRUE;+0200;20140330T02;20141026T03;; DAYLIGHT:TRUE;+0200;20150329T02;20151025T03;; BEGIN:VEVENT UID:1073742958 X-FUNAMBOL-ALLDAY:1 DTSTART:20090522 DTEND:20090523 X-MICROSOFT-CDO-BUSYSTATUS:0 CATEGORIES: DESCRIPTION: LOCATION: STATUS:0 SUMMARY:XX CLASS:PUBLIC RRULE:FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=22;COUNT=0 EXDATE:2009-11-22;2010-05-22 RDATE: X-FUNAMBOL-AALARMOPTIONS:4 END:VEVENT END:VCALENDAR ; c_name = 1073742958; }, When I try to edit the event in the web interface, it opens the window where the confirmation message should appear (edit this instance, edit all instances), but it either times out or it shows that the object doesn't exist right away. This is an example of a time out: 2010-08-30 16:04:52.371 sogod[19835] File NSCalendarDate.m: 1440. In [NSCalendarDate -initWithYear:month:day:hour:minute:second:timeZone:] invalid month given - 4294967295 2010-08-30 16:04:52.420 sogod[19836] File NSCalendarDate.m: 1440. In [NSCalendarDate -initWithYear:month:day:hour:minute:second:timeZone:] invalid month given - 4294967295 2010-08-30 16:05:16.283 sogod[18146] File NSCalendarDate.m: 1440. In [NSCalendarDate -initWithYear:month:day:hour:minute:second:timeZone:] invalid month given - 4294967295 2010-08-30 16:05:17.936 sogod[18152] File NSCalendarDate.m: 1440. In [NSCalendarDate -initWithYear:month:day:hour:minute:second:timeZone:] invalid month given - 4294967295 127.0.0.1 - - [30/Aug/2010:16:05:47 GMT] POST /SOGo/so/luca/Calendar/personal/1073742958/occurence1285106400/view HTTP/1.1 404 208/0 288.824 - - 0 Aug 30 16:05:48 sogod: SOGo watchdog [18145]: 0x0x8281900[WOWatchDogChild] child 18147 exited 127.0.0.1 - - [30/Aug/2010:16:05:51 GMT] GET /SOGo/so/luca/Calendar/personal/1073742958/occurence1285106400/confirmEditing HTTP/1.1 404 208/0 291.575 - - 0 Aug 30 16:05:52 sogod: SOGo watchdog [18145]: 0x0x82818d0[WOWatchDogChild] child 18148 exited 2010-08-30 16:07:52.647 sogod[19836] File NSCalendarDate.m: 1440. In [NSCalendarDate -initWithYear:month:day:hour:minute:second:timeZone:] invalid month given - 4294967295 2010-08-30 16:07:52.754 sogod[19835] File NSCalendarDate.m: 1440. In [NSCalendarDate -initWithYear:month:day:hour:minute:second:timeZone:] invalid month given - 4294967295 0x0xa1eae30[WOHttpTransaction] client disconnected during delivery of response for WORequest[0x0xa1ba760]: method=POST uri=/SOGo/so/luca/Calendar/personal/1073742958/occurence1285106400/view app=SOGo rqKey=so rqPath=luca/Calendar/personal/1073742958/occurence1285106400/view (len=208): the socket was shutdown 127.0.0.1 - - [30/Aug/2010:16:08:07 GMT] POST /SOGo/so/luca/Calendar/personal/1073742958/occurence1285106400/view HTTP/1.1 404 208/0 358.782 - - 0 Aug 30 16:08:08 sogod: SOGo watchdog [18145]: 0x0x8281930[WOWatchDogChild] child 18146 exited 0x0x9994458[WOHttpTransaction] client disconnected during
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
En/na Luca Olivetti ha escrit: While doing the restore, I see a bunch of these messages: 2010-08-30 15:19:25.843 sogo-tool[18846] restoring record '1073742958' 2010-08-30 15:19:25.850 sogo-tool[18846] File NSCalendarDate.m: 1440. In [NSCalendarDate -initWithYear:month:day:hour:minute:second:timeZone:] invalid month given - 4294967295 This is record 1073742958 in the backup file (the summary is not the original one but it doesn't matter, I tested it both ways): c_content = BEGIN:VCALENDAR VERSION:1.0 TZ:+0100 DAYLIGHT:TRUE;+0200;20090329T02;20091025T03;; DAYLIGHT:TRUE;+0200;20100328T02;20101031T03;; DAYLIGHT:TRUE;+0200;20110327T02;20111030T03;; DAYLIGHT:TRUE;+0200;20120325T02;20121028T03;; DAYLIGHT:TRUE;+0200;20130331T02;20131027T03;; DAYLIGHT:TRUE;+0200;20140330T02;20141026T03;; DAYLIGHT:TRUE;+0200;20150329T02;20151025T03;; BEGIN:VEVENT UID:1073742958 X-FUNAMBOL-ALLDAY:1 DTSTART:20090522 DTEND:20090523 X-MICROSOFT-CDO-BUSYSTATUS:0 CATEGORIES: DESCRIPTION: LOCATION: STATUS:0 SUMMARY:XX CLASS:PUBLIC RRULE:FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=22;COUNT=0 EXDATE:2009-11-22;2010-05-22 This is the line causing the invalid month given. If I change it to EXDATE:20091122,20100522 it doesn't give that error message anymore, but it still cannot be edited on the webinterface (it gives a 404 right away). To fix it completely I have to remove both the INTERVAL=1 and the COUNT=0 from the RRULE line. RDATE: X-FUNAMBOL-AALARMOPTIONS:4 END:VEVENT END:VCALENDAR ; c_name = 1073742958; }, Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Problem with recurring events [was Re: stack smashing detected]
En/na Luca Olivetti ha escrit: RRULE:FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=22;COUNT=0 EXDATE:2009-11-22;2010-05-22 This is the line causing the invalid month given. If I change it to EXDATE:20091122,20100522 it doesn't give that error message anymore, but it still cannot be edited on the webinterface (it gives a 404 right away). To fix it completely I have to remove both the INTERVAL=1 and the COUNT=0 from the RRULE line. Well, actually it doesn't, it gives a 404 right away :-( Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 -- users@sogo.nu https://inverse.ca/sogo/lists
