Re: sync_client segmentation fault when using TLS

2010-04-12 Thread Wesley Craig
On 08 Apr 2010, at 16:32, Matt Selsky wrote: Can you add this patch to bugzilla? Is this the same as: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3174 My patch for that is below. :wes sync_client-tls-capability-response.diff Description: Binary data Cyrus Home Page: http:/

Re: sync_client segmentation fault when using TLS

2010-04-08 Thread Matt Selsky
Raphael, Can you add this patch to bugzilla? -- Matt Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: sync_client segmentation fault when using TLS

2010-03-31 Thread Raphael Jaffey
Dietmar Rieder wrote: Hi, we just updated our master + replication servers from 2.3.13 to 2.3.16 and discovered, that the sync_client is dying with a segfault when it connects to the replication server which has set "allowplaintext: no". We managed to trace down the problem and came up with

Re: sync_client segmentation fault when using TLS

2010-03-28 Thread Raphael Jaffey
Raphael Jaffey wrote: > > Dietmar Rieder wrote: >> Hi, >> >> we just updated our master + replication servers from 2.3.13 to 2.3.16 >> and discovered, that the sync_client is dying with a segfault when it >> connects to the replication server which has set "allowplaintext: no". >> >> We manage

Re: sync_client segmentation fault when using TLS

2010-03-28 Thread Raphael Jaffey
Dietmar Rieder wrote: > Hi, > > we just updated our master + replication servers from 2.3.13 to 2.3.16 > and discovered, that the sync_client is dying with a segfault when it > connects to the replication server which has set "allowplaintext: no". > > We managed to trace down the problem and

sync_client segmentation fault when using TLS

2010-01-12 Thread Dietmar Rieder
Hi, we just updated our master + replication servers from 2.3.13 to 2.3.16 and discovered, that the sync_client is dying with a segfault when it connects to the replication server which has set "allowplaintext: no". We managed to trace down the problem and came up with the following patch ag