Re: Aw: [SOGo] 100% CPU sogod
Hi Daniel, Hi Emmanuel, How to find the faulty user ? I have currently 100 more mailboxes, and i'm experiencing a crash i suspect related to a misconfigured user, but i'm not actually able to see who. syslog / sogo.log are tracking all users, and the problem is shifted in time, it does not happen easily. I have to restart dovecot to free sogo processes (yes, how strange) and all is working fine again. Thank you if you have advices, CF Le 05/05/2015 12:03, Emmanuel d'Humières a écrit : Thanks Daniel for your reply. But I think problem has been now identified. It seems to be related to a user activesync synchronization via Android 5.1. I asked the user to remove his exchange account on his phone, and no more crazy sogod process running at 100%. If he enables again the synchronization, he can see his mails, but no calendar and sogod process start running at 100% CPU. I don't know if it's connected with https://code.google.com/p/android/issues/detail?id=79389 threads, telling that people with Android 5.1 can see their mails, but not the calendars. Has someone experienced successful calendar synchronizations with SOGo last version and Android 5.1 ? And regarding SOGo developers, is it useful to fill up a bug regarding sogod process looping at 100% CPU ? Thanks for your comments. Regards, Emmanuel Le mardi 05 mai 2015 à 10:20 +0200, Daniel Müller a écrit : So if SOGo behave like that in my environment there is a user which is misconfigured. Find out that user and delete all settings ex.: sogo-tool remove username. And all will be fine again. Greetings Daniel *Gesendet:* Montag, 04. Mai 2015 um 12:47 Uhr *Von:* Emmanuel d'Humières emmanuel.dhumie...@kelois.com *An:* users@sogo.nu *Betreff:* [SOGo] 100% CPU sogod Hi guys, first of all, many thanks to SOGo team for this brilliant project. I used SOGo for several years and I install it for my customers who are very happy with this exchange alternative ;-) Unfortunately, I have recently installed SOGo for one of my customers and we have a very strange behaviour. We start SOGo service and after a random time (few minutes or few hours), we observe via top linux command one, then several sogod processus running at 100% cpu. We see in SOGo log /pid has been hanging in the same request for x minutes / and then watchdog messages : /safety belt -- sending KILL signal to pid / /child exited/ /(terminated due to signal 9)/ /child spawned with pid '/ I know the meaning of previous messages which are finally quite normal, but in the meantime, 5 or 7 process SOGOd running at the same time at 100 % seem to be strange. I never encounter this kind of issue so I started to make some analysis. I first check with strace command to see system calls made by SOGOd process : nothing was displayed except the kill system call made by the watchdog. So it's 100% pure cpu usage. I have installed the debug tools in order to provide you some backtrace. You will find below 2 different backtraces done at 2 different moments. They are a little bit different, but the others traces I've made look similar. Please can you help me as I try to push this solution for this customer ? There are right now 5 test users and 5 activesync enabled. Thanks for your help, especially to indicate me if I need to open a bug. Regards, Emmanuel Here are 2 backtraces of the 100% sogod process : === trace 1 = #0 0x7fc8c8e87df1 in _wordcopy_fwd_dest_aligned (dstp=optimized out, srcp=optimized out, len=1964944) at wordcopy.c:207 #1 0x7fc8c8e82417 in __memmove_sse2 (dest=0x7fc8ac4bec00, src=optimized out, len=33734901) at ../string/memmove.c:79 #2 0x7fc8c9c93dd7 in memmove (__len=optimized out, __src=optimized out, __dest=optimized out) at /usr/include/x86_64-linux-gnu/bits/string3.h:57 #3 fillHole (size=1, index=977904, self=0x7fc8cefc34b8) at GSString.m:2161 #4 -[GSMutableString replaceCharactersInRange:withString:] (self=0x7fc8cefc34b8, _cmd=optimized out, aRange=..., aString=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at GSString.m:4998 #5 0x7fc8c9e4b019 in -[NSMutableString(GNUstepBase) replaceString:withString:] (self=0x7fc8cefc34b8, _cmd=optimized out, replace=0x7fc8bd7c2600 _OBJC_INSTANCE_2, by=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at NSMutableString+GNUstepBase.m:300 #6 0x7fc8c9e4c036 in -[NSString(GNUstepBase) stringByReplacingString:withString:] (self=0x7fc8cece46c8, _cmd=optimized out, replace=0x7fc8bd7c2600 _OBJC_INSTANCE_2, by=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at NSString+GNUstepBase.m:216 #7 0x7fc8bd5987af in -[NSData(ActiveSync) activeSyncRepresentationInContext:] (self=0x7fc8ceff7218, _cmd=0x7fc8bd7ca970 _OBJC_SELECTOR_TABLE+1648, context=0x7fc8ceb1a608) at NSData+ActiveSync.m:60
Re: [SOGo] 100% CPU sogod
Hello Please open a bug report for this at http://www.sogo.nu/bugs Kind regads, Christian Mack Am 2015-05-05 um 12:03 schrieb Emmanuel d'Humières: Thanks Daniel for your reply. But I think problem has been now identified. It seems to be related to a user activesync synchronization via Android 5.1. I asked the user to remove his exchange account on his phone, and no more crazy sogod process running at 100%. If he enables again the synchronization, he can see his mails, but no calendar and sogod process start running at 100% CPU. I don't know if it's connected with https://code.google.com/p/android/issues/detail?id=79389 threads, telling that people with Android 5.1 can see their mails, but not the calendars. Has someone experienced successful calendar synchronizations with SOGo last version and Android 5.1 ? And regarding SOGo developers, is it useful to fill up a bug regarding sogod process looping at 100% CPU ? Thanks for your comments. Regards, Emmanuel Le mardi 05 mai 2015 à 10:20 +0200, Daniel Müller a écrit : So if SOGo behave like that in my environment there is a user which is misconfigured. Find out that user and delete all settings ex.: sogo-tool remove username. And all will be fine again. Greetings Daniel Gesendet: Montag, 04. Mai 2015 um 12:47 Uhr Von: Emmanuel d'Humières emmanuel.dhumie...@kelois.com An: users@sogo.nu Betreff: [SOGo] 100% CPU sogod Hi guys, first of all, many thanks to SOGo team for this brilliant project. I used SOGo for several years and I install it for my customers who are very happy with this exchange alternative ;-) Unfortunately, I have recently installed SOGo for one of my customers and we have a very strange behaviour. We start SOGo service and after a random time (few minutes or few hours), we observe via top linux command one, then several sogod processus running at 100% cpu. We see in SOGo log pid has been hanging in the same request for x minutes and then watchdog messages : safety belt -- sending KILL signal to pid child exited (terminated due to signal 9) child spawned with pid ' I know the meaning of previous messages which are finally quite normal, but in the meantime, 5 or 7 process SOGOd running at the same time at 100 % seem to be strange. I never encounter this kind of issue so I started to make some analysis. I first check with strace command to see system calls made by SOGOd process : nothing was displayed except the kill system call made by the watchdog. So it's 100% pure cpu usage. I have installed the debug tools in order to provide you some backtrace. You will find below 2 different backtraces done at 2 different moments. They are a little bit different, but the others traces I've made look similar. Please can you help me as I try to push this solution for this customer ? There are right now 5 test users and 5 activesync enabled. Thanks for your help, especially to indicate me if I need to open a bug. Regards, Emmanuel __ Here are 2 backtraces of the 100% sogod process : === trace 1 = #0 0x7fc8c8e87df1 in _wordcopy_fwd_dest_aligned (dstp=optimized out, srcp=optimized out, len=1964944) at wordcopy.c:207 #1 0x7fc8c8e82417 in __memmove_sse2 (dest=0x7fc8ac4bec00, src=optimized out, len=33734901) at ../string/memmove.c:79 #2 0x7fc8c9c93dd7 in memmove (__len=optimized out, __src=optimized out, __dest=optimized out) at /usr/include/x86_64-linux-gnu/bits/string3.h:57 #3 fillHole (size=1, index=977904, self=0x7fc8cefc34b8) at GSString.m:2161 #4 -[GSMutableString replaceCharactersInRange:withString:] (self=0x7fc8cefc34b8, _cmd=optimized out, aRange=..., aString=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at GSString.m:4998 #5 0x7fc8c9e4b019 in -[NSMutableString(GNUstepBase) replaceString:withString:] (self=0x7fc8cefc34b8, _cmd=optimized out, replace=0x7fc8bd7c2600 _OBJC_INSTANCE_2, by=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at NSMutableString+GNUstepBase.m:300 #6 0x7fc8c9e4c036 in -[NSString(GNUstepBase) stringByReplacingString:withString:] (self=0x7fc8cece46c8, _cmd=optimized out, replace=0x7fc8bd7c2600 _OBJC_INSTANCE_2, by=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at NSString+GNUstepBase.m:216 #7 0x7fc8bd5987af in -[NSData(ActiveSync) activeSyncRepresentationInContext:] (self=0x7fc8ceff7218, _cmd=0x7fc8bd7ca970 _OBJC_SELECTOR_TABLE+1648, context=0x7fc8ceb1a608) at NSData+ActiveSync.m:60 #8 0x7fc8bd5a4eea in -[SOGoActiveSyncDispatcher processItemOperations:inResponse:] (self=0x7fc8cecf5208, _cmd=0x7fc8ceac7c00, theDocumentElement=0x7fc8cecc5738, theResponse=0x7fc8cf04b2b8) at SOGoActiveSyncDispatcher.m:1303 #9 0x7fc8bd5ab91a in -[SOGoActiveSyncDispatcher dispatchRequest:inResponse:context:] (self=0x7fc8cecf5208, _cmd
Aw: [SOGo] 100% CPU sogod
So if SOGo behave like that in my environment there is a user which is misconfigured. Find out that user and delete all settings ex.: sogo-tool remove username. And all will be fine again. Greetings Daniel Gesendet:Montag, 04. Mai 2015 um 12:47 Uhr Von:Emmanuel dHumires emmanuel.dhumie...@kelois.com An:users@sogo.nu Betreff:[SOGo] 100% CPU sogod Hi guys, first of all, many thanks to SOGo team for this brilliant project. I used SOGo for several years and I install it for my customers who are very happy with this exchange alternative Unfortunately, I have recently installed SOGo for one of my customers and we have a very strange behaviour. We start SOGo service and after a random time (few minutes or few hours), we observe via top linux command one, then several sogod processus running at 100% cpu. We see in SOGo log pid has been hanging in the same request for x minutes and then watchdog messages : safety belt -- sending KILL signal to pid child exited (terminated due to signal 9) child spawned with pid I know the meaning of previous messages which are finally quite normal, but in the meantime, 5 or 7 process SOGOd running at the same time at 100 % seem to be strange. I never encounter this kind of issue so I started to make some analysis. I first check with strace command to see system calls made by SOGOd process : nothing was displayed except the kill system call made by the watchdog. So its 100% pure cpu usage. I have installed the debug tools in order to provide you some backtrace. You will find below 2 different backtraces done at 2 different moments. They are a little bit different, but the others traces Ive made look similar. Please can you help me as I try to push this solution for this customer ? There are right now 5 test users and 5 activesync enabled. Thanks for your help, especially to indicate me if I need to open a bug. Regards, Emmanuel Here are 2 backtraces of the 100% sogod process : === trace 1 = #0 0x7fc8c8e87df1 in _wordcopy_fwd_dest_aligned (dstp=optimized out, srcp=optimized out, len=1964944) at wordcopy.c:207 #1 0x7fc8c8e82417 in __memmove_sse2 (dest=0x7fc8ac4bec00, src="" out, len=33734901) at ../string/memmove.c:79 #2 0x7fc8c9c93dd7 in memmove (__len=optimized out, __src=optimized out, __dest=optimized out) at /usr/include/x86_64-linux-gnu/bits/string3.h:57 #3 fillHole (size=1, index=977904, self=0x7fc8cefc34b8) at GSString.m:2161 #4 -[GSMutableString replaceCharactersInRange:withString:] (self=0x7fc8cefc34b8, _cmd=optimized out, aRange=..., aString=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at GSString.m:4998 #5 0x7fc8c9e4b019 in -[NSMutableString(GNUstepBase) replaceString:withString:] (self=0x7fc8cefc34b8, _cmd=optimized out, replace=0x7fc8bd7c2600 _OBJC_INSTANCE_2, by=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at NSMutableString+GNUstepBase.m:300 #6 0x7fc8c9e4c036 in -[NSString(GNUstepBase) stringByReplacingString:withString:] (self=0x7fc8cece46c8, _cmd=optimized out, replace=0x7fc8bd7c2600 _OBJC_INSTANCE_2, by=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at NSString+GNUstepBase.m:216 #7 0x7fc8bd5987af in -[NSData(ActiveSync) activeSyncRepresentationInContext:] (self=0x7fc8ceff7218, _cmd=0x7fc8bd7ca970 _OBJC_SELECTOR_TABLE+1648, context=0x7fc8ceb1a608) at NSData+ActiveSync.m:60 #8 0x7fc8bd5a4eea in -[SOGoActiveSyncDispatcher processItemOperations:inResponse:] (self=0x7fc8cecf5208, _cmd=0x7fc8ceac7c00, theDocumentElement=0x7fc8cecc5738, theResponse=0x7fc8cf04b2b8) at SOGoActiveSyncDispatcher.m:1303 #9 0x7fc8bd5ab91a in -[SOGoActiveSyncDispatcher dispatchRequest:inResponse:context:] (self=0x7fc8cecf5208, _cmd=0x7fc8be25c8a0 _OBJC_SELECTOR_TABLE+96, theRequest=0x7fc8cea9dfb8, theResponse=0x7fc8cf04b2b8, theContext=0x7fc8ceb1a608) at SOGoActiveSyncDispatcher.m:2638 #10 0x7fc8be055675 in -[SOGoMicrosoftActiveSyncActions microsoftServerActiveSyncAction] (self=0x7fc8ceccd738, _cmd=0x7fc8ceac7c40) at SOGoMicrosoftActiveSyncActions.m:57 #11 0x7fc8cb5c74d4 in -[SoActionInvocation callOnObject:withPositionalParametersWhenNotNil:inContext:] () from /usr/lib/libNGObjWeb.so.4.9 #12 0x7fc8cb5c2bf8 in -[SoObjectMethodDispatcher dispatchInContext:] () from /usr/lib/libNGObjWeb.so.4.9 #13 0x7fc8cb5c4bc9 in -[SoObjectRequestHandler handleRequest:inContext:session:application:] () ---Type return to continue, or q return to quit--- from /usr/lib/libNGObjWeb.so.4.9 #14 0x7fc8cb55acde in -[WORequestHandler handleRequest:] (self=0x7fc8ceaf1308, _cmd=optimized out, _request=0x7fc8cea9dfb8) at WORequestHandler.m:237 #15 0x7fc8cb52268c in -[WOCoreApplication dispatchRequest:usingHandler:] (self=0x7fc8ce9e5048, _cmd=optimized out, _request=0x7fc8cea9dfb8, handler=0x7fc8ceaf1308) at WOCoreApplication.m:712 #16 0x7fc8cc8d0822 in -[SOGo dispatchRequest:] (self=0x7fc8ce9e5048, _cmd=0x7fc8cb8cf8b0 _OBJC_SELECTOR_TABLE+1840, _request=0x7fc8cea9dfb8) at SOGo
Re: Aw: [SOGo] 100% CPU sogod
Thanks Daniel for your reply. But I think problem has been now identified. It seems to be related to a user activesync synchronization via Android 5.1. I asked the user to remove his exchange account on his phone, and no more crazy sogod process running at 100%. If he enables again the synchronization, he can see his mails, but no calendar and sogod process start running at 100% CPU. I don't know if it's connected with https://code.google.com/p/android/issues/detail?id=79389 threads, telling that people with Android 5.1 can see their mails, but not the calendars. Has someone experienced successful calendar synchronizations with SOGo last version and Android 5.1 ? And regarding SOGo developers, is it useful to fill up a bug regarding sogod process looping at 100% CPU ? Thanks for your comments. Regards, Emmanuel Le mardi 05 mai 2015 à 10:20 +0200, Daniel Müller a écrit : So if SOGo behave like that in my environment there is a user which is misconfigured. Find out that user and delete all settings ex.: sogo-tool remove username. And all will be fine again. Greetings Daniel Gesendet: Montag, 04. Mai 2015 um 12:47 Uhr Von: Emmanuel d'Humières emmanuel.dhumie...@kelois.com An: users@sogo.nu Betreff: [SOGo] 100% CPU sogod Hi guys, first of all, many thanks to SOGo team for this brilliant project. I used SOGo for several years and I install it for my customers who are very happy with this exchange alternative ;-) Unfortunately, I have recently installed SOGo for one of my customers and we have a very strange behaviour. We start SOGo service and after a random time (few minutes or few hours), we observe via top linux command one, then several sogod processus running at 100% cpu. We see in SOGo log pid has been hanging in the same request for x minutes and then watchdog messages : safety belt -- sending KILL signal to pid child exited (terminated due to signal 9) child spawned with pid ' I know the meaning of previous messages which are finally quite normal, but in the meantime, 5 or 7 process SOGOd running at the same time at 100 % seem to be strange. I never encounter this kind of issue so I started to make some analysis. I first check with strace command to see system calls made by SOGOd process : nothing was displayed except the kill system call made by the watchdog. So it's 100% pure cpu usage. I have installed the debug tools in order to provide you some backtrace. You will find below 2 different backtraces done at 2 different moments. They are a little bit different, but the others traces I've made look similar. Please can you help me as I try to push this solution for this customer ? There are right now 5 test users and 5 activesync enabled. Thanks for your help, especially to indicate me if I need to open a bug. Regards, Emmanuel __ Here are 2 backtraces of the 100% sogod process : === trace 1 = #0 0x7fc8c8e87df1 in _wordcopy_fwd_dest_aligned (dstp=optimized out, srcp=optimized out, len=1964944) at wordcopy.c:207 #1 0x7fc8c8e82417 in __memmove_sse2 (dest=0x7fc8ac4bec00, src=optimized out, len=33734901) at ../string/memmove.c:79 #2 0x7fc8c9c93dd7 in memmove (__len=optimized out, __src=optimized out, __dest=optimized out) at /usr/include/x86_64-linux-gnu/bits/string3.h:57 #3 fillHole (size=1, index=977904, self=0x7fc8cefc34b8) at GSString.m:2161 #4 -[GSMutableString replaceCharactersInRange:withString:] (self=0x7fc8cefc34b8, _cmd=optimized out, aRange=..., aString=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at GSString.m:4998 #5 0x7fc8c9e4b019 in -[NSMutableString(GNUstepBase) replaceString:withString:] (self=0x7fc8cefc34b8, _cmd=optimized out, replace=0x7fc8bd7c2600 _OBJC_INSTANCE_2, by=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at NSMutableString+GNUstepBase.m:300 #6 0x7fc8c9e4c036 in -[NSString(GNUstepBase) stringByReplacingString:withString:] (self=0x7fc8cece46c8, _cmd=optimized out, replace=0x7fc8bd7c2600 _OBJC_INSTANCE_2, by=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at NSString+GNUstepBase.m:216 #7 0x7fc8bd5987af in -[NSData(ActiveSync) activeSyncRepresentationInContext:] (self=0x7fc8ceff7218, _cmd=0x7fc8bd7ca970 _OBJC_SELECTOR_TABLE+1648, context=0x7fc8ceb1a608) at NSData+ActiveSync.m:60 #8 0x7fc8bd5a4eea in -[SOGoActiveSyncDispatcher processItemOperations:inResponse:] (self=0x7fc8cecf5208, _cmd=0x7fc8ceac7c00, theDocumentElement=0x7fc8cecc5738, theResponse=0x7fc8cf04b2b8) at SOGoActiveSyncDispatcher.m:1303 #9 0x7fc8bd5ab91a in -[SOGoActiveSyncDispatcher dispatchRequest:inResponse:context:] (self=0x7fc8cecf5208, _cmd=0x7fc8be25c8a0 _OBJC_SELECTOR_TABLE+96, theRequest=0x7fc8cea9dfb8, theResponse=0x7fc8cf04b2b8, theContext=0x7fc8ceb1a608) at SOGoActiveSyncDispatcher.m:2638
[SOGo] 100% CPU sogod
Hi guys, first of all, many thanks to SOGo team for this brilliant project. I used SOGo for several years and I install it for my customers who are very happy with this exchange alternative ;-) Unfortunately, I have recently installed SOGo for one of my customers and we have a very strange behaviour. We start SOGo service and after a random time (few minutes or few hours), we observe via top linux command one, then several sogod processus running at 100% cpu. We see in SOGo log pid has been hanging in the same request for x minutes and then watchdog messages : safety belt -- sending KILL signal to pid child exited (terminated due to signal 9) child spawned with pid ' I know the meaning of previous messages which are finally quite normal, but in the meantime, 5 or 7 process SOGOd running at the same time at 100 % seem to be strange. I never encounter this kind of issue so I started to make some analysis. I first check with strace command to see system calls made by SOGOd process : nothing was displayed except the kill system call made by the watchdog. So it's 100% pure cpu usage. I have installed the debug tools in order to provide you some backtrace. You will find below 2 different backtraces done at 2 different moments. They are a little bit different, but the others traces I've made look similar. Please can you help me as I try to push this solution for this customer ? There are right now 5 test users and 5 activesync enabled. Thanks for your help, especially to indicate me if I need to open a bug. Regards, Emmanuel Here are 2 backtraces of the 100% sogod process : === trace 1 = #0 0x7fc8c8e87df1 in _wordcopy_fwd_dest_aligned (dstp=optimized out, srcp=optimized out, len=1964944) at wordcopy.c:207 #1 0x7fc8c8e82417 in __memmove_sse2 (dest=0x7fc8ac4bec00, src=optimized out, len=33734901) at ../string/memmove.c:79 #2 0x7fc8c9c93dd7 in memmove (__len=optimized out, __src=optimized out, __dest=optimized out) at /usr/include/x86_64-linux-gnu/bits/string3.h:57 #3 fillHole (size=1, index=977904, self=0x7fc8cefc34b8) at GSString.m:2161 #4 -[GSMutableString replaceCharactersInRange:withString:] (self=0x7fc8cefc34b8, _cmd=optimized out, aRange=..., aString=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at GSString.m:4998 #5 0x7fc8c9e4b019 in -[NSMutableString(GNUstepBase) replaceString:withString:] (self=0x7fc8cefc34b8, _cmd=optimized out, replace=0x7fc8bd7c2600 _OBJC_INSTANCE_2, by=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at NSMutableString+GNUstepBase.m:300 #6 0x7fc8c9e4c036 in -[NSString(GNUstepBase) stringByReplacingString:withString:] (self=0x7fc8cece46c8, _cmd=optimized out, replace=0x7fc8bd7c2600 _OBJC_INSTANCE_2, by=0x7fc8bd7c2620 _OBJC_INSTANCE_3) at NSString+GNUstepBase.m:216 #7 0x7fc8bd5987af in -[NSData(ActiveSync) activeSyncRepresentationInContext:] (self=0x7fc8ceff7218, _cmd=0x7fc8bd7ca970 _OBJC_SELECTOR_TABLE+1648, context=0x7fc8ceb1a608) at NSData+ActiveSync.m:60 #8 0x7fc8bd5a4eea in -[SOGoActiveSyncDispatcher processItemOperations:inResponse:] (self=0x7fc8cecf5208, _cmd=0x7fc8ceac7c00, theDocumentElement=0x7fc8cecc5738, theResponse=0x7fc8cf04b2b8) at SOGoActiveSyncDispatcher.m:1303 #9 0x7fc8bd5ab91a in -[SOGoActiveSyncDispatcher dispatchRequest:inResponse:context:] (self=0x7fc8cecf5208, _cmd=0x7fc8be25c8a0 _OBJC_SELECTOR_TABLE+96, theRequest=0x7fc8cea9dfb8, theResponse=0x7fc8cf04b2b8, theContext=0x7fc8ceb1a608) at SOGoActiveSyncDispatcher.m:2638 #10 0x7fc8be055675 in -[SOGoMicrosoftActiveSyncActions microsoftServerActiveSyncAction] (self=0x7fc8ceccd738, _cmd=0x7fc8ceac7c40) at SOGoMicrosoftActiveSyncActions.m:57 #11 0x7fc8cb5c74d4 in -[SoActionInvocation callOnObject:withPositionalParametersWhenNotNil:inContext:] () from /usr/lib/libNGObjWeb.so.4.9 #12 0x7fc8cb5c2bf8 in -[SoObjectMethodDispatcher dispatchInContext:] () from /usr/lib/libNGObjWeb.so.4.9 #13 0x7fc8cb5c4bc9 in -[SoObjectRequestHandler handleRequest:inContext:session:application:] () ---Type return to continue, or q return to quit--- from /usr/lib/libNGObjWeb.so.4.9 #14 0x7fc8cb55acde in -[WORequestHandler handleRequest:] (self=0x7fc8ceaf1308, _cmd=optimized out, _request=0x7fc8cea9dfb8) at WORequestHandler.m:237 #15 0x7fc8cb52268c in -[WOCoreApplication dispatchRequest:usingHandler:] (self=0x7fc8ce9e5048, _cmd=optimized out, _request=0x7fc8cea9dfb8, handler=0x7fc8ceaf1308) at WOCoreApplication.m:712 #16 0x7fc8cc8d0822 in -[SOGo dispatchRequest:] (self=0x7fc8ce9e5048, _cmd=0x7fc8cb8cf8b0 _OBJC_SELECTOR_TABLE+1840, _request=0x7fc8cea9dfb8) at SOGo.m:453 #17 0x7fc8cb5b596d in -[WOHttpTransaction _run] (self=0x7fc8ced5b228, _cmd=optimized out) at WOHttpTransaction.m:596 #18 0x7fc8cb5b6e38 in -[WOHttpTransaction run] (self=0x7fc8ced5b228,
