similar to: Crashing when run against OpenSSL 1.1.0c

On 15.11.2016 13:27, Michael Marley wrote: > Hi, > > I am running Dovecot 2.2.26.0 compiled against OpenSSL 1.1 and, since > upgrading to OpenSSL 1.1.0c, the "lmtp" process has been crashing with > SIGSEGV whenever it receives SIGINT. This always happens a minute or so > after the lmtp process handles a message. It can also be manually > reproduced by sending

Hi You can't think how glad I am that SSL issues rise again in a new Dovecot version with next Ubuntu release with a new OpenSSL library. Some days ago I have posted something similar about Ubuntu 14.04 - Dovecot 2.2.9 - OpenSSL 1.0 (Dovecot processes turning zombie) but noone cared about. I still think is somehow related to ssl-param process + config + auth + ...whatever (all of them

This fixes the long-standing crash on close when nbdkit exits. I did try first to fix threads so we're using a proper thread pool, but that's difficult to implement. So this does the minimal change needed to fix the crash instead. There are still two segfaults that happen during running the test suite. One is deliberately caused (tests/test-captive.sh). The other appears to be an

OpenSSL 1.1 features a cleanup function that is automatically run on shutdown using atexit(3). This function frees all OpenSSL-allocated resources. In dovecot, OpenSSL is loaded indirectly using dlopen(3) against the relevant dovecot crypto module and is finally unloaded using dlclose(3). Until OpenSSL 1.0.1c this worked fine, however OpenSSL 1.0.1c makes sure[1] that the library stays loaded

My project has a C++ library that I want to allow the user to use via some programming language to be JIT'd to call functions in said library. For the sake of simplicity, assume the library has classes like: class item { public: item(); item( int ); ~item(); // ... }; class item_iterator { public: virtual ~item_iterator(); virtual bool next( item *result ) = 0; };

On Mar 20, 2012, at 7:38 PM, Paul J. Lucas wrote: > To recap, on Mar 14, 2012, I wrote: > >> My project has a C++ library that I want to allow the user to use via some programming language to be JIT'd to call functions in said library. For the sake of simplicity, assume the library has classes like: >> >> class item_iterator { >> public: >> virtual

On Mar 22, 2012, at 12:28 AM, Bill Wendling wrote: > On Mar 20, 2012, at 7:38 PM, Paul J. Lucas wrote: > >> I've read the docs on LLVM exceptions, but I don't see any examples. A little help? > > I don't think this has anything to do with LLVM's IR-level exception system. It sounds to me like you just need a way to handle C++ exceptions inside of the C++ code

First of all, I apologize for my accidental empty message earlier. I just set up the SMTP submission proxy in Dovecot 2.3, but whenever I try to connect to it, it always returns "530 5.7.0 TLS required." for any sort of AUTH or MAIL command. This occurs even if TLS is being used. It also occurs regardless of whether I connect with a real client (Thunderbird) or manually with

On Mar 22, 2012, at 11:40 AM, Paul J. Lucas <paul at lucasmail.org> wrote: > On Mar 22, 2012, at 12:28 AM, Bill Wendling wrote: > >> On Mar 20, 2012, at 7:38 PM, Paul J. Lucas wrote: >> >>> I've read the docs on LLVM exceptions, but I don't see any examples. A little help? >> >> I don't think this has anything to do with LLVM's

To recap, on Mar 14, 2012, I wrote: > My project has a C++ library that I want to allow the user to use via some programming language to be JIT'd to call functions in said library. For the sake of simplicity, assume the library has classes like: > > class item_iterator { > public: > virtual ~item_iterator(); > virtual bool next( item *result ) = 0; > }; >

On Mar 22, 2012, at 5:29 PM, Bill Wendling wrote: > On Mar 22, 2012, at 11:40 AM, Paul J. Lucas <paul at lucasmail.org> wrote: > >> Unfortunately, I'm not following. How is having the code that catches all exceptions in a separate function different from what I proposed (putting the try/catch in the thunks)? (Ideally, I want to minimize layers of function calls.) Again

I think this might be caused by glibc 2.28. I saw a similar error with the "doveadm purge" command after upgrading my system to that version. Michael Marley On 2018-08-31 13:10, Aki Tuomi wrote: > I'll see if this is reproducible > > --- > Aki Tuomi > Dovecot oy > > -------- Original message -------- > From: Reuben Farrelly <reuben-dovecot at

Hi, This patch: On 15/11/2016 10:46 PM, Aki Tuomi wrote: > > > On 13.11.2016 20:04, Apollon Oikonomopoulos wrote: >> OpenSSL 1.1 features a cleanup function that is automatically run on shutdown >> using atexit(3). This function frees all OpenSSL-allocated resources. >> >> In dovecot, OpenSSL is loaded indirectly using dlopen(3) against the relevant >>

On 13.11.2016 20:04, Apollon Oikonomopoulos wrote: > OpenSSL 1.1 features a cleanup function that is automatically run on shutdown > using atexit(3). This function frees all OpenSSL-allocated resources. > > In dovecot, OpenSSL is loaded indirectly using dlopen(3) against the relevant > dovecot crypto module and is finally unloaded using dlclose(3). Until > OpenSSL 1.0.1c this

https://bugzilla.netfilter.org/show_bug.cgi?id=881 Summary: SIGSEGV on startup Product: nftables Version: unspecified Platform: x86_64 OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: nft AssignedTo: pablo at netfilter.org ReportedBy: shawn at churchofgit.com

> On October 21, 2016 at 6:27 AM Tamsy <dovecot-list at mohtex.net> wrote: > > > Timo Sirainen wrote on 20.10.2016 04:01: > > http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz > > http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz.sig > > > > There are quite a lot of changes since v2.2.25. Please try out this RC so we can get a good

Operating system - 64 bit CentOS 7 gcc-4.8.5-4.el7.x86_64 Building against LibreSSL which has been fine for other releases, but it is a crypto test that is fails. Tried with LibreSSL 2.4.2 and 2.3.6 - both the build completes but fails the make check Dovecot 2.2.24 passes make check on both. This is where it fails: Making check in lib-dcrypt make[2]: Entering directory

> On 1 Mar 2018, at 5:56 pm, Aki Tuomi <aki.tuomi at dovecot.fi <mailto:aki.tuomi at dovecot.fi>> wrote: > > > > On 01.03.2018 07:34, James Brown wrote: >> On 1 Mar 2018, at 4:09 pm, Aki Tuomi <aki.tuomi at dovecot.fi <mailto:aki.tuomi at dovecot.fi>> wrote: >>> >>> >>> What SSL library and version? >>> ---

It should work if you add it to apt. Directory listing is denied, which causes 403 if you access with browser. Aki -------- Original message --------From: Michael Marley <michael at michaelmarley.com> Date: 21/09/2018 18:00 (GMT+02:00) To: Dovecot Mailing List <dovecot at dovecot.org> Subject: Re: v2.3.3 release candidate released On 2018-09-21 09:45, Timo Sirainen wrote: >

?Reuben, could you try this: service auth-worker { ? executable = /usr/bin/strace -o /tmp/out /usr/libexec/dovecot/auth -w } and send the out file to me? I wasn't able to reproduce your problem with glibc-2.28. Aki On 31.08.2018 21:30, Aki Tuomi wrote: > Ah. Thanks for the pointer. > > --- > Aki Tuomi > Dovecot oy > > -------- Original message -------- > From: