Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
Am 20.03.19 um 17:11 schrieb Patrick Goetz: Jakob has already updated the AUR package, which appears to have resolved this issue. The related upstream bug is #2629. After looking at the new PKGBUILD I knew it works because it's identical to my solution ;-) I appreciate your detailed explanation about the packaging but please let's stop here and not hijack this mailing list for arch linux or AUR topics, maybe we read again at https://aur.archlinux.org/packages/cyrus-imapd/ Best Regards, -ap smime.p7s Description: S/MIME Cryptographic Signature Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
Am 20.03.19 um 13:39 schrieb Patrick Goetz: It would appear that --disable-pcre is a configuration option you can't actually use. yes, it seems so. the defines in the header: #ifdef ENABLE_REGEX # ifdef HAVE_PCREPOSIX_H # include # include # else /* !HAVE_PCREPOSIX_H */ # ifdef HAVE_RXPOSIX_H # include # else /* !HAVE_RXPOSIX_H */ # include # endif /* HAVE_RXPOSIX_H */ # endif /* HAVE_PCREPOSIX_H */ #endif /* ENABLE_REGEX */ configure.ac: if test "$enable_pcre" != "no"; then AC_CHECK_HEADER(pcreposix.h) if test "$ac_cv_header_pcreposix_h" = "yes"; then AC_MSG_CHECKING(for utf8 enabled pcre) AC_CACHE_VAL(cyrus_cv_pcre_utf8, AC_TRY_CPP([#include #ifndef REG_UTF8 #include #endif],cyrus_cv_pcre_utf8=yes,cyrus_cv_pcre_utf8=no)) AC_MSG_RESULT($cyrus_cv_pcre_utf8) else cyrus_cv_pcre_utf8="no" fi if test "$cyrus_cv_pcre_utf8" = "yes"; then LIBS="$LIBS -lpcre -lpcreposix"; AC_DEFINE(ENABLE_REGEX, [], [Do we have a regex library?]) AC_DEFINE(HAVE_PCREPOSIX_H, [], [Do we have usable pcre library?]) else AC_CHECK_HEADERS(rxposix.h) if test "$ac_cv_header_rxposix_h" = "yes"; then LIBS="$LIBS -lrx" AC_DEFINE(ENABLE_REGEX, [], [Do we have a regex library?]) else AC_SEARCH_LIBS(regcomp, regex, AC_DEFINE(ENABLE_REGEX, [], [Do we have a regex library?]), []) fi fi fi the whole block depends on "$enable_pcre", so if I disable pcre, i disable regexp conpletely. I think, it should look like this: if test "$enable_pcre" != "no"; then AC_CHECK_HEADER(pcreposix.h) if test "$ac_cv_header_pcreposix_h" = "yes"; then AC_MSG_CHECKING(for utf8 enabled pcre) AC_CACHE_VAL(cyrus_cv_pcre_utf8, AC_TRY_CPP([#include #ifndef REG_UTF8 #include #endif],cyrus_cv_pcre_utf8=yes,cyrus_cv_pcre_utf8=no)) AC_MSG_RESULT($cyrus_cv_pcre_utf8) else cyrus_cv_pcre_utf8="no" fi if test "$cyrus_cv_pcre_utf8" = "yes"; then LIBS="$LIBS -lpcre -lpcreposix"; AC_DEFINE(ENABLE_REGEX, [], [Do we have a regex library?]) AC_DEFINE(HAVE_PCREPOSIX_H, [], [Do we have usable pcre library?]) fi else cyrus_cv_pcre_utf8="no" AC_CHECK_HEADERS(rxposix.h) if test "$ac_cv_header_rxposix_h" = "yes"; then LIBS="$LIBS -lrx" AC_DEFINE(ENABLE_REGEX, [], [Do we have a regex library?]) else AC_SEARCH_LIBS(regcomp, regex, AC_DEFINE(ENABLE_REGEX, [], [Do we have a regex libra ry?]), []) fi fi if you don't disable pcre, you must have pcre available, otherwise no regexp because there's no fallback. if you disable pcre, it checks for rposix.h and fallsback to anything providing regcomp. if nothing is found, no regexp support. As diff: --- configure.ac.org2019-03-15 01:31:20.0 +0100 +++ configure.ac2019-03-20 19:19:05.077550582 +0100 @@ -674,18 +674,16 @@ if test "$enable_pcre" != "no"; then LIBS="$LIBS -lpcre -lpcreposix"; AC_DEFINE(ENABLE_REGEX, [], [Do we have a regex library?]) AC_DEFINE(HAVE_PCREPOSIX_H, [], [Do we have usable pcre library?]) -else -AC_CHECK_HEADERS(rxposix.h) -if test "$ac_cv_header_rxposix_h" = "yes"; then -LIBS="$LIBS -lrx" -AC_DEFINE(ENABLE_REGEX, [], - [Do we have a regex library?]) -else -AC_SEARCH_LIBS(regcomp, regex, -AC_DEFINE(ENABLE_REGEX, [], -[Do we have a regex library?]), []) -fi fi +else + cyrus_cv_pcre_utf8="no" + AC_CHECK_HEADERS(rxposix.h) + if test "$ac_cv_header_rxposix_h" = "yes"; then + LIBS="$LIBS -lrx" + AC_DEFINE(ENABLE_REGEX, [], [Do we have a regex library?]) + else + AC_SEARCH_LIBS(regcomp, regex, AC_DEFINE(ENABLE_REGEX, [], [Do we have a regex library?]), []) + fi fi dnl look for an option to disable sign-comparison warnings (needed for with this change: ./configure --disable-pcre $ egrep 'REGEX|PCRE' config.h #define ENABLE_REGEX /**/ /* #undef HAVE_PCREPOSIX_H */ ./configure --disable-pcre $ egrep 'REGEX|PCRE' config.h #define ENABLE_REGEX /**/ #define HAVE_PCREPOSIX_H /**/ seems to work, but as I said, I'm not a software guy and i don't know autotools, there's probably a better solution. Regards, -ap smime.p7s Description: S/MIME Cryptographic Signature
Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
Hi Andreas - Jakob has already updated the AUR package, which appears to have resolved this issue. The related upstream bug is #2629. Regarding the dependencies in the cyrus-imapd PKGBUILD. I recommend starting with Jakob's PKGBUILD and just stripping out the stuff you don't need. I've spent so much time looking at it at this point, if you tell me what you don't want, I can probably post a PKGBUILD that works for your requirements. In any case, please try cyrus-imapd 3.0.9-2 and let me know if this resolves the issue for you, too. Here is an explanation (provided by the AUR package maintainer) of the purpose of the various dependencies he's included (also the ones listed as requirements which he did not include). We had pre-agreed that there is no harm in compiling in all the authentication hooks and CalDAV/CalCard dependencies. Without the authentication hooks, the package isn't really general purpose. - gperf seems to be useful for development only (maintainer mode) - libbsd is only required for krb5afspts which is disabled (because IIRC it looks for static libraries which Arch doesn’t package) - ICU: This seems to be genuinely missing, though as you noticed it is already required indirectly. It is probably still a good idea to make that dependency explicit. But since it’s a relatively minor problem I’ll wait to see if anything else comes up in our conversation so I can “bundle” the changes. - clamav is in fact already in optdepends, however in order to build against it it needs to be in makedepends as well - xapian-core provides efficient indexed search, which I’d argue is quite a useful feature to have in a mail server. It is linked into libcyrus_imap.so though, which is in turn linked into imapd (unlike clamav), therefore it is a hard dependency. - libcap allows Cyrus’s services to restrict their own capabilities(7) for enhanced security - libnghttp2 and brotli add support for HTTP/2 and Brotli compression of HTTP responses, respectively; which is relevant to CalDAV, CardDAV and other HTTP services (including JMAP in future versions) - shapelib allows Cyrus’s Time Zone Distribution Service[2] to associate time zones with geographical locations - python-sphinx, perl-pod-pom-view-restructured: required for generation of some manpages (which are included in the regular package, not the -docs one. I’d argue that manpages are actually useful to have around). These are only needed at buildtime and need not be present on the actual server system. On 3/19/19 5:37 PM, Andreas Piesk wrote: Am 19.03.19 um 22:00 schrieb Patrick Goetz: Have you tried the 3.0.9 AUR package? https://aur.archlinux.org/packages/cyrus-imapd Once you get the dependencies down, this one compiles and runs. I noticed the package, it's good to see a recent version in AUR but it has too many dependecies for my taste, I need a stripped down version. Unfortunately the AUR package doesn't work for me either, i build it in a VM with a fresh installed arch and it has the same problem: Starting program: /usr/bin/cyrdump user/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x77c76205 in re_compile_internal () from /usr/lib/libc.so.6 (gdb) bt #0 0x77c76205 in re_compile_internal () from /usr/lib/libc.so.6 #1 0x77c77511 in regcomp () from /usr/lib/libc.so.6 #2 0x77e3d980 in glob_init () from /usr/lib/libcyrus.so.0 #3 0x77f38276 in ?? () from /usr/lib/libcyrus_imap.so.0 #4 0x77f3e5b7 in mboxlist_findallmulti () from /usr/lib/libcyrus_imap.so.0 #5 0x61aa in ?? () #6 0x77bbb223 in __libc_start_main () from /usr/lib/libc.so.6 #7 0x61ee in ?? () Best Regards, -ap Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
Hi - I can confirm this segmentation fault on my own Arch VM with cyrus installed from the AUR package. As an experiment, I tried building the package with --disable-pcre but then I can't even get the program to compile: In file included from lib/glob.c:50: lib/glob.h:57:5: error: unknown type name ‘regex_t’ regex_t regex; ^~~ lib/glob.c: In function ‘glob_init’: lib/glob.c:112:5: warning: implicit declaration of function ‘regcomp’; did you mean ‘memcmp’? [-Wimplicit-function-declaration] regcomp(>regex, buf_cstring(), REG_EXTENDED); ^~~ memcmp lib/glob.c:112:43: error: ‘REG_EXTENDED’ undeclared (first use in this function) regcomp(>regex, buf_cstring(), REG_EXTENDED); ^~~~ It would appear that --disable-pcre is a configuration option you can't actually use. On 3/19/19 5:37 PM, Andreas Piesk wrote: Am 19.03.19 um 22:00 schrieb Patrick Goetz: Have you tried the 3.0.9 AUR package? https://aur.archlinux.org/packages/cyrus-imapd Once you get the dependencies down, this one compiles and runs. I noticed the package, it's good to see a recent version in AUR but it has too many dependecies for my taste, I need a stripped down version. Unfortunately the AUR package doesn't work for me either, i build it in a VM with a fresh installed arch and it has the same problem: Starting program: /usr/bin/cyrdump user/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x77c76205 in re_compile_internal () from /usr/lib/libc.so.6 (gdb) bt #0 0x77c76205 in re_compile_internal () from /usr/lib/libc.so.6 #1 0x77c77511 in regcomp () from /usr/lib/libc.so.6 #2 0x77e3d980 in glob_init () from /usr/lib/libcyrus.so.0 #3 0x77f38276 in ?? () from /usr/lib/libcyrus_imap.so.0 #4 0x77f3e5b7 in mboxlist_findallmulti () from /usr/lib/libcyrus_imap.so.0 #5 0x61aa in ?? () #6 0x77bbb223 in __libc_start_main () from /usr/lib/libc.so.6 #7 0x61ee in ?? () Best Regards, -ap Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
Am 19.03.19 um 22:00 schrieb Patrick Goetz: Have you tried the 3.0.9 AUR package? https://aur.archlinux.org/packages/cyrus-imapd Once you get the dependencies down, this one compiles and runs. I noticed the package, it's good to see a recent version in AUR but it has too many dependecies for my taste, I need a stripped down version. Unfortunately the AUR package doesn't work for me either, i build it in a VM with a fresh installed arch and it has the same problem: Starting program: /usr/bin/cyrdump user/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x77c76205 in re_compile_internal () from /usr/lib/libc.so.6 (gdb) bt #0 0x77c76205 in re_compile_internal () from /usr/lib/libc.so.6 #1 0x77c77511 in regcomp () from /usr/lib/libc.so.6 #2 0x77e3d980 in glob_init () from /usr/lib/libcyrus.so.0 #3 0x77f38276 in ?? () from /usr/lib/libcyrus_imap.so.0 #4 0x77f3e5b7 in mboxlist_findallmulti () from /usr/lib/libcyrus_imap.so.0 #5 0x61aa in ?? () #6 0x77bbb223 in __libc_start_main () from /usr/lib/libc.so.6 #7 0x61ee in ?? () Best Regards, -ap smime.p7s Description: S/MIME Cryptographic Signature Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
Hi Andreas -
Have you tried the 3.0.9 AUR package?
https://aur.archlinux.org/packages/cyrus-imapd
Once you get the dependencies down, this one compiles and runs.
On 3/19/19 3:38 PM, Andreas Piesk wrote:
Am 19.03.19 um 19:47 schrieb Jason L Tibbitts III:
"AP" == Andreas Piesk writes:
AP> Hello list, i'm trying to get cyrus-imapd 3.0.9 (testet 3.0.8 too)
AP> running on latest arch linux. Here's the configure summary:
AP> External dependencies: ldap: no openssl: yes zlib: yes pcre: yes
AP> #6 0x7fc4aa385050 re_acquire_state_context (libc.so.6)
AP> #7 0x7fc4aa3907d4 re_compile_internal (libc.so.6)
AP> #8 0x7fc4aa391511 regcomp (libc.so.6)
You have pcre enabled but you are calling glibc regex functions. You
may wish to double check that you are linking properly. Fedora went
through a similar issue a while back when --Wl,--as-needed was added to
the default set of compiler flags, which caused subtle variations in the
link order. The end result was that Fedora picked up a set of pcre
patches similar to what some other distros have to avoid duplicating the
glibc symbol names.
These are the default LDFLAGS Arch Linux uses:
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
If I link without '--as-needed' crydump etc. do work without segfaulting.
"configure --disable-pcre" does not work:
lib/glob.h:57:5: error: unknown type name ‘regex_t’
I have no idea how to change the linkage order to put pcre before glibc
(don't know if and how this is possible, I'm a hardware guy), I'm just
building with
autoreconf -f
./configure
so I think my only option is to drop '--as-needed' from LDFLAGS and execute
./configure LDFLAGS=${LDFLAGS/,--as-needed/}
Thanks for pointing me in the right direction, highly appreciated.
Best Regards,
-ap
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
Am 19.03.19 um 19:47 schrieb Jason L Tibbitts III:
"AP" == Andreas Piesk writes:
AP> Hello list, i'm trying to get cyrus-imapd 3.0.9 (testet 3.0.8 too)
AP> running on latest arch linux. Here's the configure summary:
AP> External dependencies: ldap: no openssl: yes zlib: yes pcre: yes
AP> #6 0x7fc4aa385050 re_acquire_state_context (libc.so.6)
AP> #7 0x7fc4aa3907d4 re_compile_internal (libc.so.6)
AP> #8 0x7fc4aa391511 regcomp (libc.so.6)
You have pcre enabled but you are calling glibc regex functions. You
may wish to double check that you are linking properly. Fedora went
through a similar issue a while back when --Wl,--as-needed was added to
the default set of compiler flags, which caused subtle variations in the
link order. The end result was that Fedora picked up a set of pcre
patches similar to what some other distros have to avoid duplicating the
glibc symbol names.
These are the default LDFLAGS Arch Linux uses:
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
If I link without '--as-needed' crydump etc. do work without segfaulting.
"configure --disable-pcre" does not work:
lib/glob.h:57:5: error: unknown type name ‘regex_t’
I have no idea how to change the linkage order to put pcre before glibc (don't
know if and how this is possible, I'm a hardware guy), I'm just building with
autoreconf -f
./configure
so I think my only option is to drop '--as-needed' from LDFLAGS and execute
./configure LDFLAGS=${LDFLAGS/,--as-needed/}
Thanks for pointing me in the right direction, highly appreciated.
Best Regards,
-ap
smime.p7s
Description: S/MIME Cryptographic Signature
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
> "AP" == Andreas Piesk writes: AP> Hello list, i'm trying to get cyrus-imapd 3.0.9 (testet 3.0.8 too) AP> running on latest arch linux. Here's the configure summary: AP> External dependencies: ldap: no openssl: yes zlib: yes pcre: yes AP> #6 0x7fc4aa385050 re_acquire_state_context (libc.so.6) AP> #7 0x7fc4aa3907d4 re_compile_internal (libc.so.6) AP> #8 0x7fc4aa391511 regcomp (libc.so.6) You have pcre enabled but you are calling glibc regex functions. You may wish to double check that you are linking properly. Fedora went through a similar issue a while back when --Wl,--as-needed was added to the default set of compiler flags, which caused subtle variations in the link order. The end result was that Fedora picked up a set of pcre patches similar to what some other distros have to avoid duplicating the glibc symbol names. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
segfaults with cyrus-imapd 3.0.9 on latest arch linux
Hello list, i'm trying to get cyrus-imapd 3.0.9 (testet 3.0.8 too) running on latest arch linux. Here's the configure summary: Cyrus Server configured components event notification: yes gssapi: yes autocreate: no idled: yes httpd: yes kerberos V4:no murder: yes nntpd: yes replication:yes sieve: yes calalarmd: yes objectstore:no backup: yes com_err: External dependencies: ldap: no openssl:yes zlib: yes pcre: yes clamav: no --- caringo:no openio: no --- nghttp2:yes brotli: no xml2: yes ical: yes icu4c: yes shapelib: no Database support: mysql: no postgresql: no sqlite: yes lmdb: no Search engine: squat: yes sphinx: no xapian: no xapian_flavor: none Hardware support: SSE4.2: yes Installation directories: prefix: /usr sysconfdir: /etc The software builds succesful but executing commands with cyradm produces core dumps like this one: localhost.localdomain> cm user.test localhost.localdomain> lm localhost.localdomain> cyrus/master[20901]: process type:SERVICE name:imap path:/usr/lib/cyrus/imapd age:33.405s pid:20904 signaled to death by signal 6 (Aborted, core dumped) systemd-coredump[20913]: Process 20904 (imapd) of user 1001 dumped core. Stack trace of thread 20904: #0 0x7fc4aa2e8d7f raise (libc.so.6) #1 0x7fc4aa2d3672 abort (libc.so.6) #2 0x7fc4aa32b878 __libc_message (libc.so.6) #3 0x7fc4aa33218a malloc_printerr (libc.so.6) #4 0x7fc4aa3354ac _int_malloc (libc.so.6) #5 0x7fc4aa337736 __libc_calloc (libc.so.6) #6 0x7fc4aa385050 re_acquire_state_context (libc.so.6) #7 0x7fc4aa3907d4 re_compile_internal (libc.so.6) #8 0x7fc4aa391511 regcomp (libc.so.6) #9 0x7fc4aaaf09a0 glob_init (libcyrus.so.0) #10 0x7fc4aabe2c46 mboxlist_do_find (libcyrus_imap.so.0) #11 0x7fc4aabe8f87 mboxlist_findallmulti (libcyrus_imap.so.0) #12 0x5558cc431ef6 list_data (imapd) #13 0x5558cc43e37f cmdloop (imapd) #14 0x5558cc44282f service_main (imapd) #15 0x5558cc41f823 main (imapd) #16 0x7fc4aa2d5223 __libc_start_main (libc.so.6) #17 0x5558cc41fe3e _start (imapd) # cyrdump -v user.test Segmentation fault in gdb: Starting program: /usr/bin/cyrdump user.test [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x77c90205 in re_compile_internal () from /usr/lib/libc.so.6 (gdb) bt #0 0x77c90205 in re_compile_internal () from /usr/lib/libc.so.6 #1 0x77c91511 in regcomp () from /usr/lib/libc.so.6 #2 0x77e549a0 in glob_init (str=, sep=sep@entry=47 '/') at lib/glob.c:112 #3 0x77f46c46 in mboxlist_do_find (rock=rock@entry=0x7fffeaf0, patterns=patterns@entry=0x55571680) at imap/mboxlist.c:2723 #4 0x77f4cf87 in mboxlist_findallmulti (namespace=, patterns=0x55571680, isadmin=, userid=0x0, auth_state=, proc=, rock=0x7fffebb4) at imap/mboxlist.c:2942 #5 0x61aa in main (argc=, argv=0x7fffecc8) at
