http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz.sig
Some small fixes and changes to v2.2.14. This release is mainly in the hope that it could still make it into the next Debian stable instead of v2.2.14 - mainly because of a couple of new assert crashes that started happening in v2.2.14 and should be fixed now.
* Plugins can now print a banner comment in doveconf output
(typically the plugin version)
* Replication plugin now triggers low (instead of high) priority for
mail copying operations.
* IMAP/POP3/ManageSieve proxy: If destination server can't be
connected to, retry connecting once per second up to the value of
proxy_timeout. This allows quick restarts/upgrades on the backend
server without returning login failures.
* Internal passdb lookups (e.g. done by lmtp/doveadm proxy) wasn't
returning failure in some situations where it should have (e.g.
allow_nets mismatch)
* LMTP uses mail_log_prefix now for logging mail deliveries instead of
a hardcoded prefix. The non-delivery log prefix is still hardcoded
though.
+ passdb allow_nets=local matches lookups that don't contain an IP
address (internally done by Dovecot services)
+ Various debug logging and error logging improvements
- Various race condition fixes to LAYOUT=index
- v2.2.14 virtual plugin crashed in some situationsOn Fri, 24 Oct 2014, Timo Sirainen wrote:
Some small fixes and changes to v2.2.14. This release is mainly in the hope that it could still make it into the next Debian stable instead of v2.2.14 - mainly because of a couple of new assert crashes that started happening in v2.2.14 and should be fixed now.
Timo,
FYI at the moment we think we will probably go with 2.2.13. That there are still assert crashes in the latest release makes us a little bit concerned if we should use that so close to the freeze. (Effectively this Sunday for new upstream releases.)
In your honest opinion are we being overcautious? Are there any compelling reasons we must go with 2.2.15 for Jessie or will 2.2.13 be adequate?
Also I have one minor issue to report. dovecot broke API from 2.2.13 to 2.2.14 but it only provides version macros for the first two components of the version number. This has caused a small upgrade problem for the antispam plugin which is in a separate package (dovecot-antispam.) Was that addressed in 2.2.15?
-- Jaldhar H. Vyas jaldhar@debian.org
Am 25.10.2014 um 08:50 schrieb Jaldhar H. Vyas:
On Fri, 24 Oct 2014, Timo Sirainen wrote:
Some small fixes and changes to v2.2.14. This release is mainly in the hope that it could still make it into the next Debian stable instead of v2.2.14 - mainly because of a couple of new assert crashes that started happening in v2.2.14 and should be fixed now.
Timo,
FYI at the moment we think we will probably go with 2.2.13. That there are still assert crashes in the latest release makes us a little bit concerned if we should use that so close to the freeze. (Effectively this Sunday for new upstream releases.)
In your honest opinion are we being overcautious? Are there any compelling reasons we must go with 2.2.15 for Jessie or will 2.2.13 be adequate?
Also I have one minor issue to report. dovecot broke API from 2.2.13 to 2.2.14 but it only provides version macros for the first two components of the version number. This has caused a small upgrade problem for the antispam plugin which is in a separate package (dovecot-antispam.) Was that addressed in 2.2.15?
my opinion go 2.2.15, lots of people want to use debian sources only , but ask for help on this list for allready fixed stuff if debian versions are much older then recent versions. Dovecot is used in simple up to very complex setups, so no wonder there will be patches ever.
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
On 24 Oct 2014, at 23:50, Jaldhar H. Vyas jaldhar@debian.org wrote:
On Fri, 24 Oct 2014, Timo Sirainen wrote:
Some small fixes and changes to v2.2.14. This release is mainly in the hope that it could still make it into the next Debian stable instead of v2.2.14 - mainly because of a couple of new assert crashes that started happening in v2.2.14 and should be fixed now.
Timo,
FYI at the moment we think we will probably go with 2.2.13. That there are still assert crashes in the latest release makes us a little bit concerned if we should use that so close to the freeze. (Effectively this Sunday for new upstream releases.)
In your honest opinion are we being overcautious? Are there any compelling reasons we must go with 2.2.15 for Jessie or will 2.2.13 be adequate?
2.2.13 has many bugs that are definitely bad. I was going to make v2.2.14 only a few weeks afterwards, but then I just got more and more busy and it took forever to do the release. If you want to go with it, please use the dovecot-ee 2.2.13.31 release instead with many many important patches. I can put the .tar.gz somewhere if needed.
Also I have one minor issue to report. dovecot broke API from 2.2.13 to 2.2.14 but it only provides version macros for the first two components of the version number. This has caused a small upgrade problem for the antispam plugin which is in a separate package (dovecot-antispam.) Was that addressed in 2.2.15?
I only remember an ABI problem with antispam. Recompiling fixed that AFAIK. (And no Dovecot version guarantees ABI compatibility.) Is there some API problem also?
Also I have one minor issue to report. dovecot broke API from 2.2.13 to 2.2.14 but it only provides version macros for the first two components of the version number. This has caused a small upgrade problem for the antispam plugin which is in a separate package (dovecot-antispam.) Was that addressed in 2.2.15? I only remember an ABI problem with antispam. Recompiling fixed that AFAIK. (And no Dovecot version guarantees ABI compatibility.) Is there some API problem also?
On 25 Oct 2014, at 04:59, Gedalya gedalya@gedalya.net wrote:
Also I have one minor issue to report. dovecot broke API from 2.2.13 to 2.2.14 but it only provides version macros for the first two components of the version number. This has caused a small upgrade problem for the antispam plugin which is in a separate package (dovecot-antispam.) Was that addressed in 2.2.15? I only remember an ABI problem with antispam. Recompiling fixed that AFAIK. (And no Dovecot version guarantees ABI compatibility.) Is there some API problem also?
Oh, it uses the really old way to do things. In v1.1+ T_BEGIN { .. } T_END should have been used instead. Patch attached.
On 10/25/2014 11:43 AM, Timo Sirainen wrote:
On 25 Oct 2014, at 04:59, Gedalya gedalya@gedalya.net wrote:
Also I have one minor issue to report. dovecot broke API from 2.2.13 to 2.2.14 but it only provides version macros for the first two components of the version number. This has caused a small upgrade problem for the antispam plugin which is in a separate package (dovecot-antispam.) Was that addressed in 2.2.15? I only remember an ABI problem with antispam. Recompiling fixed that AFAIK. (And no Dovecot version guarantees ABI compatibility.) Is there some API problem also? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765943 Oh, it uses the really old way to do things. In v1.1+ T_BEGIN { .. } T_END should have been used instead. Patch attached.
OK, it's not working as it is.
This little bit seems like a typo:
- t_pop();
- } T_POP;
Gives me:
pipe.c:315:4: error: ‘T_POP’ undeclared (first use in this function) } T_POP;
I tried T_END and I still get:
pipe.c: In function ‘backend_handle_mail’: pipe.c:314:2: error: label at end of compound statement out: ^
I got it to compile, see the attached. I don't really know C
On Sat, Oct 25, 2014 at 04:39:29PM -0400, Gedalya wrote:
On 10/25/2014 11:43 AM, Timo Sirainen wrote:
On 25 Oct 2014, at 04:59, Gedalya gedalya@gedalya.net wrote:
Also I have one minor issue to report. dovecot broke API from 2.2.13 to 2.2.14 but it only provides version macros for the first two components of the version number. This has caused a small upgrade problem for the antispam plugin which is in a separate package (dovecot-antispam.) Was that addressed in 2.2.15? I only remember an ABI problem with antispam. Recompiling fixed that AFAIK. (And no Dovecot version guarantees ABI compatibility.) Is there some API problem also? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765943 Oh, it uses the really old way to do things. In v1.1+ T_BEGIN { .. } T_END should have been used instead. Patch attached.
The header file could admittedly have been a little more persuasive in weaning people off the old interface.
However, it was my bad that I didn't consider the old interface may still be in use. Apologies.
OK, it's not working as it is.
This little bit seems like a typo:
- t_pop();
- } T_POP;
Gives me:
pipe.c:315:4: error: ?T_POP? undeclared (first use in this function) } T_POP;
I tried T_END and I still get:
pipe.c: In function ?backend_handle_mail?: pipe.c:314:2: error: label at end of compound statement out: ^
I got it to compile, see the attached. I don't really know C ... out:
- t_pop();
- ;
- } T_END;
That is the correct fix. C is quirky about labels, you can only label statements, nothing else. As Timo mentioned, the t_push()/t_pop() interface hasn't been the recommended interface since about 2008, so this definitely is the correct way to go.
If upstream is out there somewhere, for your patch: Acked-by: Phil Carmody phil@dovecot.fi
Phil
Hi Phil,
On Wed, Oct 29, 2014 at 03:07:54PM +0200, Phil Carmody wrote:
On Sat, Oct 25, 2014 at 04:39:29PM -0400, Gedalya wrote:
On 10/25/2014 11:43 AM, Timo Sirainen wrote:
On 25 Oct 2014, at 04:59, Gedalya gedalya@gedalya.net wrote:
Also I have one minor issue to report. dovecot broke API from 2.2.13 to 2.2.14 but it only provides version macros for the first two components of the version number. This has caused a small upgrade problem for the antispam plugin which is in a separate package (dovecot-antispam.) Was that addressed in 2.2.15? I only remember an ABI problem with antispam. Recompiling fixed that AFAIK. (And no Dovecot version guarantees ABI compatibility.) Is there some API problem also?
Oh, it uses the really old way to do things. In v1.1+ T_BEGIN { .. } T_END should have been used instead. Patch attached.
The header file could admittedly have been a little more persuasive in weaning people off the old interface.
However, it was my bad that I didn't consider the old interface may still be in use. Apologies.
Part of the catch here is that the dovecot-antispam code has tried to remain compatible with earlier versions of dovecot too, since there is always going to be some spread of versions in the wild at any given time. But if this just means dropping support for versions < 1.1 now, that might not be such a big deal anymore.
The original patch we looked at for this was basically quite simple: http://anonscm.debian.org/cgit/users/ron/dovecot-antispam.git/commit/?id=2aa...
The main catch being dovecot only exports version macros for the MAJOR and MINOR version components, not for the final "patch level" component, so we need to parse the full version string to get that. That wasn't really a problem while the API only changed with a minor version bump, but this change changed that.
It would be nice (in the long term) if dovecot itself provided macros that let us avoid what we (and other plugins) are doing here: http://anonscm.debian.org/cgit/users/ron/dovecot-antispam.git/tree/dovecot-v...
OK, it's not working as it is.
This little bit seems like a typo:
- t_pop();
- } T_POP;
Gives me:
pipe.c:315:4: error: ?T_POP? undeclared (first use in this function) } T_POP;
I tried T_END and I still get:
pipe.c: In function ?backend_handle_mail?: pipe.c:314:2: error: label at end of compound statement out: ^
I got it to compile, see the attached. I don't really know C ... out:
- t_pop();
- ;
- } T_END;
That is the correct fix. C is quirky about labels, you can only label statements, nothing else. As Timo mentioned, the t_push()/t_pop() interface hasn't been the recommended interface since about 2008, so this definitely is the correct way to go.
Yeah, or we can just move the label outside the extra brace scope for the couple of places that's a problem here.
If upstream is out there somewhere, for your patch: Acked-by: Phil Carmody phil@dovecot.fi
I've added Johannes to the CC for this.
Thanks! Ron
On Saturday 25 of October 2014, Timo Sirainen wrote:
http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz.sig
Test suite passes but at the end:
fatal_printf_format_fix .............................................. : ok 0 / 190 tests failed ==6098== Invalid read of size 16 ==6098== at 0x317B880804: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A93B6: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== Address 0x5d22690 is 16 bytes inside a block of size 20 alloc'd ==6098== at 0x4A05C00: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6098== by 0x317B8A93CB: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== ==6098== Invalid read of size 8 ==6098== at 0x317B88032A: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A93B6: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== Address 0x5d22690 is 16 bytes inside a block of size 20 alloc'd ==6098== at 0x4A05C00: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6098== by 0x317B8A93CB: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== ==6098== Invalid read of size 8 ==6098== at 0x317B880333: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A93B6: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== Address 0x5d22698 is 4 bytes after a block of size 20 alloc'd ==6098== at 0x4A05C00: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6098== by 0x317B8A93CB: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== ==6098== Conditional jump or move depends on uninitialised value(s) ==6098== at 0x317B8817ED: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A93ED: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== ==6098== Invalid read of size 8 ==6098== at 0x317B88032A: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A93B6: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA9D: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== Address 0x5d22690 is 16 bytes inside a block of size 20 alloc'd ==6098== at 0x4A05C00: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6098== by 0x317B8A93CB: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== ==6098== Invalid read of size 8 ==6098== at 0x317B880333: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A93B6: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA9D: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== Address 0x5d22698 is 4 bytes after a block of size 20 alloc'd ==6098== at 0x4A05C00: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6098== by 0x317B8A93CB: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39) ==6098== by 0x41340B: iso8601_date_do_parse (iso8601-date.c:250) ==6098== by 0x4134C0: iso8601_date_parse_tm (iso8601-date.c:274) ==6098== by 0x4062B2: test_iso8601_date_valid (test-iso8601-date.c:75) ==6098== by 0x4062B2: test_iso8601_date (test-iso8601-date.c:145) ==6098== by 0x40D3E0: test_run_funcs (test-common.c:305) ==6098== by 0x40DA5C: test_run_with_fatals (test-common.c:362) ==6098== by 0x317B821C14: (below main) (in /lib64/libc-2.20.so) ==6098== Makefile:1877: recipe for target 'check-test' failed make[2]: *** [check-test] Error 1
-- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
On 25 Oct 2014, at 06:11, Arkadiusz Miśkiewicz arekm@maven.pl wrote:
fatal_printf_format_fix .............................................. : ok 0 / 190 tests failed ==6098== Invalid read of size 16 ==6098== at 0x317B880804: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A93B6: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39)
That's inside gmtime() call. Looks to me like a libc bug. What OS / libc / CPU is this with?
Anyway this code hasn't changed for years.
On Saturday 25 of October 2014, Timo Sirainen wrote:
On 25 Oct 2014, at 06:11, Arkadiusz Miśkiewicz arekm@maven.pl wrote:
fatal_printf_format_fix .............................................. : ok 0 / 190 tests failed ==6098== Invalid read of size 16 ==6098== at 0x317B880804: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A93B6: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8AAA21: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9C0F: ??? (in /lib64/libc-2.20.so) ==6098== by 0x317B8A9F94: ??? (in /lib64/libc-2.20.so) ==6098== by 0x42A0D7: utc_mktime (utc-mktime.c:39)
That's inside gmtime() call. Looks to me like a libc bug. What OS / libc / CPU is this with?
Anyway this code hasn't changed for years.
Ok, looks like that was valgrind fault.
linux, glibc 2.20, x86_64
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
On Fri, 24 Oct 2014, Timo Sirainen wrote:
http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz.sig
When building an rpm with dovecot 2.2.15. one test in the pigeonhole-0.4.3 test suite causes a segmentation fault:
Test case: ./tests/extensions/editheader/deleteheader.svtest:
1: Test 'Deleteheader - nonexistent' SUCCEEDED make: *** [tests/extensions/editheader/deleteheader.svtest] Segmentation fault error: Bad exit status from /var/tmp/rpm-tmp.kap6R7 (%check)
If I just replace the dovecot with the 2.2.14 soure the error disappears.
I am compiling on Scientific Linux 6, gcc 4.4.7, but there is no change with 4.8.2. The configure used was
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info INSTALL_DATA=install -c -p -m644 --docdir=/usr/share/doc/dovecot --disable-static --disable-rpath --with-nss --with-shadow --with-pam --with-gssapi=plugin --with-ldap=plugin --with-sql=plugin --with-pgsql --with-mysql --with-sqlite --with-zlib --without-lzma --with-libcap --with-ssl=openssl --with-ssldir=/etc/pki/dovecot --with-solr --with-docs
I am using --without-lzma as also the xz compression test fails, but this is hopefully because the liblzma is coming from a very old xz-4.999.9-0.3.beta package.
-- Best regards Wolfgang Friebel
On 25 Oct 2014, at 10:13, Wolfgang.Friebel@desy.de wrote:
On Fri, 24 Oct 2014, Timo Sirainen wrote:
http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz.sig
When building an rpm with dovecot 2.2.15. one test in the pigeonhole-0.4.3 test suite causes a segmentation fault:
Yeah. http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/15b2910b145c fixes it. I was considering also if I should change this to Dovecot and make yet another v2.2.16 release, but maybe it's ok to require a new Pigeonhole. Stephan hopefully releases 0.4.4 soon.
participants (8)
-
Arkadiusz Miśkiewicz
-
Gedalya
-
Jaldhar H. Vyas
-
Phil Carmody
-
Robert Schetterer
-
Ron
-
Timo Sirainen
-
Wolfgang.Friebel＠desy.de