Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok. I'm putting gmime back in charge of parsing for boundaries.

Currently testing the change.

On 21-07-14 15:42, Reindl Harald wrote:
>
> CLEAN - snapshot: a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
> _____________________________________________________
>
> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support wrapped
> boundaries during reconstruction
>
> there must be happening something bad in memory
>
> that is the guilty commit and sadly i remember that it fixed a bug
> rpeorted from myself in case of specific messages not proper
> re-constructed at least on Apple Mail
> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6468e2cb4d520789cd35156145c5f37
>
> no idea why a commit from 2014-02-10 took that long to get visible
> each day more
>
> Am 21.07.2014 15:08, schrieb Reindl Harald:
>> unbelieveable
>>
>> i am building and stressing serveral releases 3.1.10 is the last
>> one not suffering from the problem "--" instead "-- mime-id" and
>> i have clearly no idea why this started around June to affect
>> more and more users
>>
>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG -
>> 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG - 3.1.11:
>> aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN - 3.1.10:
>> 2e819d439c5e731b082bf83420f8ad20d89c0182
>>
>> with 3.1.10 it's impossible for me to produce enough concurrency
>> to get any single mismatch ___________________________________
>>
>> that below is expected because fixed with the following commit
>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214ae1d120581740020f4e73c3cf8d3a6c0
>>
>>
>>
Jul 21 15:04:55 IMAP 33: EXPECTED:
16292abceedfc6f37707cb1adf35e1e1a46d7d2b / FOUND:
>> 2703f68a52cc815e2d2944b046fcc3c07c0bc47f (Ostrava Tuesday
>> morning)
>>
>>
>>
>> _______________________________________________ DBmail mailing
>> list DBmail@dbmail.org
>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
>>
>
>
>
> _______________________________________________ DBmail mailing
> list DBmail@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
>

- --
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
www.nfg.nl/info@nfg.nl/+31.85.877.99.97
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPNHhIACgkQ8iITvBH4zTEU+ACfRWdyswaiWBZnYhhEpVrM2mD/
Zy4AoL6MmOL2qz37daoxYU/BIHnjj2ya
=Mu9W
-----END PGP SIGNATURE-----
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

"69c0592867ad012bd1b78b873b65f7e53064971c" looks way better

* high concurrency
* loop of 3000 times "Panel: E-Mail-Debug - IMAP-POP3-Download" with
POP3 and IMAP with no mismatch between both
* checksum of all testmessages for POP3 and IMAP correct
* see also attachment

not sure if the conlusion "putting gmime back in charge" is
entirely correct or the dbmail code just had some memory bug
but at least i see no current problems and can't find the context
of the 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive

only that below where i was too stupid to notice the regression
while other commits between 3.1.10 and 3.1.11 obviously are fine
__________________________________________________________________________________________

2014-02-26 version 3.1.11
2014-02-25 IMAP: add loop protection to cleanup callback
2014-02-24 Fixed wrong result check in change username function
2014-02-21 fix regression in utf7 mailbox matching
2014-02-18 IMAP: fix inverted logic during abort
2014-02-18 LMTP/TIMSIEVE: fix possible segfaults
2014-02-17 POP3: fix segfault; fixes bug #1043
2014-02-10 IMAP: EOF on stdin is not an error
2014-02-10 remove unused file

!! -- KILLER -- !! 2014-02-10 support wrapped boundaries during reconstruction !! -- KILLER -- !!

2014-02-07 boundary fix for sha512 passwords
2014-01-30 fix unit-tests after merge
2014-01-30 Merge branch 'dbmail_3_1_utf8_fix' of https://github.com/alyarskiy/dbmail
2014-01-30 Fixed long (>255) utf8 headers + unit-test
2014-01-28 Revert "IMAP: defer bailout in case of EOF"
2014-01-22 version 3.1.10
__________________________________________________________________________________________

Am 26.02.2014 22:48, schrieb Jorge Bastos:
> Anyone already using 3.1.11?
> Maybe this is the version that I'll use for my upgrade, but 'd like some
> feedback from anyone using it already

yes because there are only small well deserved bugfixes from 3.1.10 to 3.1.11
http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1

2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a big memory leak

Am 21.07.2014 16:05, schrieb Paul J Stevens:
> Ok. I'm putting gmime back in charge of parsing for boundaries.
>
> Currently testing the change.
>
> On 21-07-14 15:42, Reindl Harald wrote:
>
>> CLEAN - snapshot: a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
>> _____________________________________________________
>
>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support wrapped
>> boundaries during reconstruction
>
>> there must be happening something bad in memory
>
>> that is the guilty commit and sadly i remember that it fixed a bug
>> rpeorted from myself in case of specific messages not proper
>> re-constructed at least on Apple Mail
>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6468e2cb4d520789cd35156145c5f37
>
>> no idea why a commit from 2014-02-10 took that long to get visible
>> each day more
>
>> Am 21.07.2014 15:08, schrieb Reindl Harald:
>>> unbelieveable
>>>
>>> i am building and stressing serveral releases 3.1.10 is the last
>>> one not suffering from the problem "--" instead "-- mime-id" and
>>> i have clearly no idea why this started around June to affect
>>> more and more users
>>>
>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG -
>>> 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG - 3.1.11:
>>> aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN - 3.1.10:
>>> 2e819d439c5e731b082bf83420f8ad20d89c0182
>>>
>>> with 3.1.10 it's impossible for me to produce enough concurrency
>>> to get any single mismatch
>>>
>>> that below is expected because fixed with the following commit
>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214ae1d120581740020f4e73c3cf8d3a6c0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So, you think we're ready for 3.1.17?

On 21-07-14 17:10, Reindl Harald wrote:
> "69c0592867ad012bd1b78b873b65f7e53064971c" looks way better
>
> * high concurrency * loop of 3000 times "Panel: E-Mail-Debug -
> IMAP-POP3-Download" with POP3 and IMAP with no mismatch between
> both * checksum of all testmessages for POP3 and IMAP correct * see
> also attachment
>
> not sure if the conlusion "putting gmime back in charge" is
> entirely correct or the dbmail code just had some memory bug but at
> least i see no current problems and can't find the context of the
> 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive
>
> only that below where i was too stupid to notice the regression
> while other commits between 3.1.10 and 3.1.11 obviously are fine
> __________________________________________________________________________________________
>
> 2014-02-26 version 3.1.11 2014-02-25 IMAP: add loop protection to
> cleanup callback 2014-02-24 Fixed wrong result check in change
> username function 2014-02-21 fix regression in utf7 mailbox
> matching 2014-02-18 IMAP: fix inverted logic during abort
> 2014-02-18 LMTP/TIMSIEVE: fix possible segfaults 2014-02-17 POP3:
> fix segfault; fixes bug #1043 2014-02-10 IMAP: EOF on stdin is not
> an error 2014-02-10 remove unused file
>
> !! -- KILLER -- !! 2014-02-10 support wrapped boundaries during
> reconstruction !! -- KILLER -- !!
>
> 2014-02-07 boundary fix for sha512 passwords 2014-01-30 fix
> unit-tests after merge 2014-01-30 Merge branch
> 'dbmail_3_1_utf8_fix' of https://github.com/alyarskiy/dbmail
> 2014-01-30 Fixed long (>255) utf8 headers + unit-test 2014-01-28
> Revert "IMAP: defer bailout in case of EOF" 2014-01-22 version
> 3.1.10
> __________________________________________________________________________________________
>
> Am 26.02.2014 22:48, schrieb Jorge Bastos:
>> Anyone already using 3.1.11? Maybe this is the version that I'll
>> use for my upgrade, but 'd like some feedback from anyone using
>> it already
>
> yes because there are only small well deserved bugfixes from 3.1.10
> to 3.1.11 http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1
>
> 2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a big
> memory leak
>
> Am 21.07.2014 16:05, schrieb Paul J Stevens:
>> Ok. I'm putting gmime back in charge of parsing for boundaries.
>>
>> Currently testing the change.
>>
>> On 21-07-14 15:42, Reindl Harald wrote:
>>
>>> CLEAN - snapshot:
>>> a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
>>> _____________________________________________________
>>
>>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support
>>> wrapped boundaries during reconstruction
>>
>>> there must be happening something bad in memory
>>
>>> that is the guilty commit and sadly i remember that it fixed a
>>> bug rpeorted from myself in case of specific messages not
>>> proper re-constructed at least on Apple Mail
>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6468e2cb4d520789cd35156145c5f37
>>
>>>
>>>
no idea why a commit from 2014-02-10 took that long to get visible
>>> each day more
>>
>>> Am 21.07.2014 15:08, schrieb Reindl Harald:
>>>> unbelieveable
>>>>
>>>> i am building and stressing serveral releases 3.1.10 is the
>>>> last one not suffering from the problem "--" instead "--
>>>> mime-id" and i have clearly no idea why this started around
>>>> June to affect more and more users
>>>>
>>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG
>>>> - 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG -
>>>> 3.1.11: aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN -
>>>> 3.1.10: 2e819d439c5e731b082bf83420f8ad20d89c0182
>>>>
>>>> with 3.1.10 it's impossible for me to produce enough
>>>> concurrency to get any single mismatch
>>>>
>>>> that below is expected because fixed with the following
>>>> commit
>>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214ae1d120581740020f4e73c3cf8d3a6c0
>>>>
>>>>
>>>>
>>>>
_______________________________________________
>>>> DBmail mailing list DBmail@dbmail.org
>>>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

- --
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
www.nfg.nl/info@nfg.nl/+31.85.877.99.97
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPNOCAACgkQ8iITvBH4zTG6sQCfbxpK51myu1FJL93Bl7g0a282
S1EAoM13GWE6HFQEr0yKqRuAb75JoD7g
=VNeh
-----END PGP SIGNATURE-----
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

of course!

and please continue to notice about proposed release candidates so that at least your faithful testers have the chance to point out regressions like in 3.1.17

I had a WTF moment yesterday because as I woke up i saw your commit and while about build the Snapshot in the hope get the race bug solved the release announce followed by crying out "what he is smoking today this regression is catched within the first 30 seconds" :-)


-------- Ursprüngliche Nachricht --------
Von: Paul J Stevens <paul@nfg.nl>
Gesendet: 21. Juli 2014 17:56:16 MESZ
An: DBMail mailinglist <dbmail@dbmail.org>
Betreff: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct: 3.1.10 last clean version

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So, you think we're ready for 3.1.17?

On 21-07-14 17:10, Reindl Harald wrote:
> "69c0592867ad012bd1b78b873b65f7e53064971c" looks way better
>
> * high concurrency * loop of 3000 times "Panel: E-Mail-Debug -
> IMAP-POP3-Download" with POP3 and IMAP with no mismatch between
> both * checksum of all testmessages for POP3 and IMAP correct * see
> also attachment
>
> not sure if the conlusion "putting gmime back in charge" is
> entirely correct or the dbmail code just had some memory bug but at
> least i see no current problems and can't find the context of the
> 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive
>
> only that below where i was too stupid to notice the regression
> while other commits between 3.1.10 and 3.1.11 obviously are fine
> __________________________________________________________________________________________
>
> 2014-02-26 version 3.1.11 2014-02-25 IMAP: add loop protection to
> cleanup callback 2014-02-24 Fixed wrong result check in change
> username function 2014-02-21 fix regression in utf7 mailbox
> matching 2014-02-18 IMAP: fix inverted logic during abort
> 2014-02-18 LMTP/TIMSIEVE: fix possible segfaults 2014-02-17 POP3:
> fix segfault; fixes bug #1043 2014-02-10 IMAP: EOF on stdin is not
> an error 2014-02-10 remove unused file
>
> !! -- KILLER -- !! 2014-02-10 support wrapped boundaries during
> reconstruction !! -- KILLER -- !!
>
> 2014-02-07 boundary fix for sha512 passwords 2014-01-30 fix
> unit-tests after merge 2014-01-30 Merge branch
> 'dbmail_3_1_utf8_fix' of https://github.com/alyarskiy/dbmail
> 2014-01-30 Fixed long (>255) utf8 headers + unit-test 2014-01-28
> Revert "IMAP: defer bailout in case of EOF" 2014-01-22 version
> 3.1.10
> __________________________________________________________________________________________
>
> Am 26.02.2014 22:48, schrieb Jorge Bastos:
>> Anyone already using 3.1.11? Maybe this is the version that I'll
>> use for my upgrade, but 'd like some feedback from anyone using
>> it already
>
> yes because there are only small well deserved bugfixes from 3.1.10
> to 3.1.11 http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1
>
> 2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a big
> memory leak
>
> Am 21.07.2014 16:05, schrieb Paul J Stevens:
>> Ok. I'm putting gmime back in charge of parsing for boundaries.
>>
>> Currently testing the change.
>>
>> On 21-07-14 15:42, Reindl Harald wrote:
>>
>>> CLEAN - snapshot:
>>> a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
>>> _____________________________________________________
>>
>>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support
>>> wrapped boundaries during reconstruction
>>
>>> there must be happening something bad in memory
>>
>>> that is the guilty commit and sadly i remember that it fixed a
>>> bug rpeorted from myself in case of specific messages not
>>> proper re-constructed at least on Apple Mail
>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6468e2cb4d520789cd35156145c5f37
>>
>>>
>>>
no idea why a commit from 2014-02-10 took that long to get visible
>>> each day more
>>
>>> Am 21.07.2014 15:08, schrieb Reindl Harald:
>>>> unbelieveable
>>>>
>>>> i am building and stressing serveral releases 3.1.10 is the
>>>> last one not suffering from the problem "--" instead "--
>>>> mime-id" and i have clearly no idea why this started around
>>>> June to affect more and more users
>>>>
>>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG
>>>> - 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG -
>>>> 3.1.11: aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN -
>>>> 3.1.10: 2e819d439c5e731b082bf83420f8ad20d89c0182
>>>>
>>>> with 3.1.10 it's impossible for me to produce enough
>>>> concurrency to get any single mismatch
>>>>
>>>> that below is expected because fixed with the following
>>>> commit
>>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214ae1d120581740020f4e73c3cf8d3a6c0
>>>>
>>>>
>>>>
>>>>
_______________________________________________
>>>> DBmail mailing list DBmail@dbmail.org
>>>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

- --
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
www.nfg.nl/info@nfg.nl/+31.85.877.99.97
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPNOCAACgkQ8iITvBH4zTG6sQCfbxpK51myu1FJL93Bl7g0a282
S1EAoM13GWE6HFQEr0yKqRuAb75JoD7g
=VNeh
-----END PGP SIGNATURE-----
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail


--

Reindl Harald (mobile)
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / CISO / Software-Development
+43 (676) 40 221 40
http://www.thelounge.net
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

back at home, again verified

see attachment

that was a 5000 compare loop while concurrency stress-test
running and the same on the production server

the loop tests in both cases against the for Paul and me well
known "Panel: E-Mail-Debug - IMAP-POP3-Download" message
which is a multipart-message with two multipart messages
wrapped as eml attachment

Am 21.07.2014 18:12, schrieb Reindl Harald (mobile):
> of course!
>
> and please continue to notice about proposed release candidates so that
> at least your faithful testers have the chance to point out regressions
> like in 3.1.17

- 3.1.17
+ 3.1.16

> I had a WTF moment yesterday because as I woke up i saw your commit
> and while about build the Snapshot in the hope get the race bug solved
> the release announce followed by crying out "what he is smoking today
> this regression is catched within the first 30 seconds" :-)
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Paul J Stevens <paul@nfg.nl>
> Gesendet: 21. Juli 2014 17:56:16 MESZ
> An: DBMail mailinglist <dbmail@dbmail.org>
> Betreff: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct: 3.1.10 last clean version
>
> So, you think we're ready for 3.1.17?
>
> On 21-07-14 17:10, Reindl Harald wrote:
>> "69c0592867ad012bd1b78b873b65f7e53064971c" looks way better
>
>> * high concurrency * loop of 3000 times "Panel: E-Mail-Debug -
>> IMAP-POP3-Download" with POP3 and IMAP with no mismatch between
>> both * checksum of all testmessages for POP3 and IMAP correct * see
>> also attachment
>
>> not sure if the conlusion "putting gmime back in charge" is
>> entirely correct or the dbmail code just had some memory bug but at
>> least i see no current problems and can't find the context of the
>> 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive
>
>> only that below where i was too stupid to notice the regression
>> while other commits between 3.1.10 and 3.1.11 obviously are fine
>> __________________________________________________________________________________________
>
>> 2014-02-26 version 3.1.11 2014-02-25 IMAP: add loop protection to
>> cleanup callback 2014-02-24 Fixed wrong result check in change
>> username function 2014-02-21 fix regression in utf7 mailbox
>> matching 2014-02-18 IMAP: fix inverted logic during abort
>> 2014-02-18 LMTP/TIMSIEVE: fix possible segfaults 2014-02-17 POP3:
>> fix segfault; fixes bug #1043 2014-02-10 IMAP: EOF on stdin is not
>> an error 2014-02-10 remove unused file
>
>> !! -- KILLER -- !! 2014-02-10 support wrapped boundaries during
>> reconstruction !! -- KILLER -- !!
>
>> 2014-02-07 boundary fix for sha512 passwords 2014-01-30 fix
>> unit-tests after merge 2014-01-30 Merge branch
>> 'dbmail_3_1_utf8_fix' of https://github.com/alyarskiy/dbmail
>> 2014-01-30 Fixed long (>255) utf8 headers + unit-test 2014-01-28
>> Revert "IMAP: defer bailout in case of EOF" 2014-01-22 version
>> 3.1.10
>> __________________________________________________________________________________________
>
>> Am 26.02.2014 22:48, schrieb Jorge Bastos:
>>> Anyone already using 3.1.11? Maybe this is the version that I'll
>>> use for my upgrade, but 'd like some feedback from anyone using
>>> it already
>
>> yes because there are only small well deserved bugfixes from 3.1.10
>> to 3.1.11 http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1
>
>> 2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a big
>> memory leak
>
>> Am 21.07.2014 16:05, schrieb Paul J Stevens:
>>> Ok. I'm putting gmime back in charge of parsing for boundaries.
>>>
>>> Currently testing the change.
>>>
>>> On 21-07-14 15:42, Reindl Harald wrote:
>>>
>>>> CLEAN - snapshot:
>>>> a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
>>>> _____________________________________________________
>>>
>>>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support
>>>> wrapped boundaries during reconstruction
>>>
>>>> there must be happening something bad in memory
>>>
>>>> that is the guilty commit and sadly i remember that it fixed a
>>>> bug rpeorted from myself in case of specific messages not
>>>> proper re-constructed at least on Apple Mail
>>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6468e2cb4d520789cd35156145c5f37
>>>
>>>>
>>>>
> no idea why a commit from 2014-02-10 took that long to get visible
>>>> each day more
>>>
>>>> Am 21.07.2014 15:08, schrieb Reindl Harald:
>>>>> unbelieveable
>>>>>
>>>>> i am building and stressing serveral releases 3.1.10 is the
>>>>> last one not suffering from the problem "--" instead "--
>>>>> mime-id" and i have clearly no idea why this started around
>>>>> June to affect more and more users
>>>>>
>>>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG
>>>>> - 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG -
>>>>> 3.1.11: aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN -
>>>>> 3.1.10: 2e819d439c5e731b082bf83420f8ad20d89c0182
>>>>>
>>>>> with 3.1.10 it's impossible for me to produce enough
>>>>> concurrency to get any single mismatch
>>>>>
>>>>> that below is expected because fixed with the following
>>>>> commit
>>>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214ae1d120581740020f4e73c3cf8d3a6c0
--

Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / CISO / Software-Development
m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33
icq: 154546673, http://www.thelounge.net/

http://www.thelounge.net/signature.asc.what.htm

Runs fine for me, no customer complains since yesterday \o/


Am .07.2014, 17:56 Uhr, schrieb Paul J Stevens <paul@nfg.nl>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> So, you think we're ready for 3.1.17?
>
> On 21-07-14 17:10, Reindl Harald wrote:
>> "69c0592867ad012bd1b78b873b65f7e53064971c" looks way better
>>
>> * high concurrency * loop of 3000 times "Panel: E-Mail-Debug -
>> IMAP-POP3-Download" with POP3 and IMAP with no mismatch between
>> both * checksum of all testmessages for POP3 and IMAP correct * see
>> also attachment
>>
>> not sure if the conlusion "putting gmime back in charge" is
>> entirely correct or the dbmail code just had some memory bug but at
>> least i see no current problems and can't find the context of the
>> 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive
>>
>> only that below where i was too stupid to notice the regression
>> while other commits between 3.1.10 and 3.1.11 obviously are fine
>> __________________________________________________________________________________________
>>
>> 2014-02-26 version 3.1.11 2014-02-25 IMAP: add loop protection to
>> cleanup callback 2014-02-24 Fixed wrong result check in change
>> username function 2014-02-21 fix regression in utf7 mailbox
>> matching 2014-02-18 IMAP: fix inverted logic during abort
>> 2014-02-18 LMTP/TIMSIEVE: fix possible segfaults 2014-02-17 POP3:
>> fix segfault; fixes bug #1043 2014-02-10 IMAP: EOF on stdin is not
>> an error 2014-02-10 remove unused file
>>
>> !! -- KILLER -- !! 2014-02-10 support wrapped boundaries during
>> reconstruction !! -- KILLER -- !!
>>
>> 2014-02-07 boundary fix for sha512 passwords 2014-01-30 fix
>> unit-tests after merge 2014-01-30 Merge branch
>> 'dbmail_3_1_utf8_fix' of https://github.com/alyarskiy/dbmail
>> 2014-01-30 Fixed long (>255) utf8 headers + unit-test 2014-01-28
>> Revert "IMAP: defer bailout in case of EOF" 2014-01-22 version
>> 3.1.10
>> __________________________________________________________________________________________
>>
>> Am 26.02.2014 22:48, schrieb Jorge Bastos:
>>> Anyone already using 3.1.11? Maybe this is the version that I'll
>>> use for my upgrade, but 'd like some feedback from anyone using
>>> it already
>>
>> yes because there are only small well deserved bugfixes from 3.1.10
>> to 3.1.11 http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1
>>
>> 2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a big
>> memory leak
>>
>> Am 21.07.2014 16:05, schrieb Paul J Stevens:
>>> Ok. I'm putting gmime back in charge of parsing for boundaries.
>>>
>>> Currently testing the change.
>>>
>>> On 21-07-14 15:42, Reindl Harald wrote:
>>>
>>>> CLEAN - snapshot:
>>>> a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
>>>> _____________________________________________________
>>>
>>>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support
>>>> wrapped boundaries during reconstruction
>>>
>>>> there must be happening something bad in memory
>>>
>>>> that is the guilty commit and sadly i remember that it fixed a
>>>> bug rpeorted from myself in case of specific messages not
>>>> proper re-constructed at least on Apple Mail
>>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6468e2cb4d520789cd35156145c5f37
>>>
>>>>
>>>>
> no idea why a commit from 2014-02-10 took that long to get visible
>>>> each day more
>>>
>>>> Am 21.07.2014 15:08, schrieb Reindl Harald:
>>>>> unbelieveable
>>>>>
>>>>> i am building and stressing serveral releases 3.1.10 is the
>>>>> last one not suffering from the problem "--" instead "--
>>>>> mime-id" and i have clearly no idea why this started around
>>>>> June to affect more and more users
>>>>>
>>>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG
>>>>> - 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG -
>>>>> 3.1.11: aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN -
>>>>> 3.1.10: 2e819d439c5e731b082bf83420f8ad20d89c0182
>>>>>
>>>>> with 3.1.10 it's impossible for me to produce enough
>>>>> concurrency to get any single mismatch
>>>>>
>>>>> that below is expected because fixed with the following
>>>>> commit
>>>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214ae1d120581740020f4e73c3cf8d3a6c0
>>>>>
>>>>>
>>>>>
>>>>>
> _______________________________________________
>>>>> DBmail mailing list DBmail@dbmail.org
>>>>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
>
> - --
> ________________________________________________________________
> Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
> www.nfg.nl/info@nfg.nl/+31.85.877.99.97
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlPNOCAACgkQ8iITvBH4zTG6sQCfbxpK51myu1FJL93Bl7g0a282
> S1EAoM13GWE6HFQEr0yKqRuAb75JoD7g
> =VNeh
> -----END PGP SIGNATURE-----
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail


--
Harald Leithner

ITronic
Wiedner Hauptstraße 120/5.1, 1050 Wien, Austria
Tel: +43-1-545 0 604
Fax: +43-1-786 23 88 26
Mobil: +43-699-123 78 4 78
Mail: leithner@itronic.at | itronic.at
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Hi Harald,

So how is this, problem solved?

> -----Original Message-----
> From: dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org] On
> Behalf Of Harald Leithner
> Sent: terça-feira, 22 de Julho de 2014 08:39
> To: DBMail mailinglist
> Subject: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct: 3.1.10
> last clean version
>
> Runs fine for me, no customer complains since yesterday \o/
>
>
> Am .07.2014, 17:56 Uhr, schrieb Paul J Stevens <paul@nfg.nl>:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > So, you think we're ready for 3.1.17?
> >
> > On 21-07-14 17:10, Reindl Harald wrote:
> >> "69c0592867ad012bd1b78b873b65f7e53064971c" looks way better
> >>
> >> * high concurrency * loop of 3000 times "Panel: E-Mail-Debug -
> >> IMAP-POP3-Download" with POP3 and IMAP with no mismatch between both
> >> * checksum of all testmessages for POP3 and IMAP correct * see also
> >> attachment
> >>
> >> not sure if the conlusion "putting gmime back in charge" is entirely
> >> correct or the dbmail code just had some memory bug but at least i
> >> see no current problems and can't find the context of the
> >> 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive
> >>
> >> only that below where i was too stupid to notice the regression
> while
> >> other commits between 3.1.10 and 3.1.11 obviously are fine
> >>
> _____________________________________________________________________
> >> _____________________
> >>
> >> 2014-02-26 version 3.1.11 2014-02-25 IMAP: add loop protection to
> >> cleanup callback 2014-02-24 Fixed wrong result check in change
> >> username function 2014-02-21 fix regression in utf7 mailbox matching
> >> 2014-02-18 IMAP: fix inverted logic during abort
> >> 2014-02-18 LMTP/TIMSIEVE: fix possible segfaults 2014-02-17 POP3:
> >> fix segfault; fixes bug #1043 2014-02-10 IMAP: EOF on stdin is not
> an
> >> error 2014-02-10 remove unused file
> >>
> >> !! -- KILLER -- !! 2014-02-10 support wrapped boundaries during
> >> reconstruction !! -- KILLER -- !!
> >>
> >> 2014-02-07 boundary fix for sha512 passwords 2014-01-30 fix
> >> unit-tests after merge 2014-01-30 Merge branch 'dbmail_3_1_utf8_fix'
> >> of https://github.com/alyarskiy/dbmail
> >> 2014-01-30 Fixed long (>255) utf8 headers + unit-test 2014-01-28
> >> Revert "IMAP: defer bailout in case of EOF" 2014-01-22 version
> >> 3.1.10
> >>
> _____________________________________________________________________
> >> _____________________
> >>
> >> Am 26.02.2014 22:48, schrieb Jorge Bastos:
> >>> Anyone already using 3.1.11? Maybe this is the version that I'll
> use
> >>> for my upgrade, but 'd like some feedback from anyone using it
> >>> already
> >>
> >> yes because there are only small well deserved bugfixes from 3.1.10
> >> to 3.1.11 http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1
> >>
> >> 2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a big
> >> memory leak
> >>
> >> Am 21.07.2014 16:05, schrieb Paul J Stevens:
> >>> Ok. I'm putting gmime back in charge of parsing for boundaries.
> >>>
> >>> Currently testing the change.
> >>>
> >>> On 21-07-14 15:42, Reindl Harald wrote:
> >>>
> >>>> CLEAN - snapshot:
> >>>> a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
> >>>> _____________________________________________________
> >>>
> >>>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support wrapped
> >>>> boundaries during reconstruction
> >>>
> >>>> there must be happening something bad in memory
> >>>
> >>>> that is the guilty commit and sadly i remember that it fixed a bug
> >>>> rpeorted from myself in case of specific messages not proper
> >>>> re-constructed at least on Apple Mail
> >>>>
> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6
> >>>> 468e2cb4d520789cd35156145c5f37
> >>>
> >>>>
> >>>>
> > no idea why a commit from 2014-02-10 took that long to get visible
> >>>> each day more
> >>>
> >>>> Am 21.07.2014 15:08, schrieb Reindl Harald:
> >>>>> unbelieveable
> >>>>>
> >>>>> i am building and stressing serveral releases 3.1.10 is the last
> >>>>> one not suffering from the problem "--" instead "-- mime-id" and
> i
> >>>>> have clearly no idea why this started around June to affect more
> >>>>> and more users
> >>>>>
> >>>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG
> >>>>> - 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG -
> >>>>> 3.1.11: aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN -
> >>>>> 3.1.10: 2e819d439c5e731b082bf83420f8ad20d89c0182
> >>>>>
> >>>>> with 3.1.10 it's impossible for me to produce enough concurrency
> >>>>> to get any single mismatch
> >>>>>
> >>>>> that below is expected because fixed with the following commit
> >>>>>
> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214a
> >>>>> e1d120581740020f4e73c3cf8d3a6c0
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> > _______________________________________________
> >>>>> DBmail mailing list DBmail@dbmail.org
> >>>>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
> >
> > - --
> > ________________________________________________________________
> > Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
> > www.nfg.nl/info@nfg.nl/+31.85.877.99.97
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iEYEARECAAYFAlPNOCAACgkQ8iITvBH4zTG6sQCfbxpK51myu1FJL93Bl7g0a282
> > S1EAoM13GWE6HFQEr0yKqRuAb75JoD7g
> > =VNeh
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > DBmail mailing list
> > DBmail@dbmail.org
> > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
>
>
> --
> Harald Leithner
>
> ITronic
> Wiedner Hauptstraße 120/5.1, 1050 Wien, Austria
> Tel: +43-1-545 0 604
> Fax: +43-1-786 23 88 26
> Mobil: +43-699-123 78 4 78
> Mail: leithner@itronic.at | itronic.at
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

yes!

[root@mail:~]$ rpm -q dbmail
dbmail-3.1.16-5.fc19.20140721.rh.69c0592867ad012bd1b78b873b65f7e53064971c.x86_64

[root@mail:~]$ systemctl status dbmail-imapd.service dbmail-pop3d.service
dbmail-imapd.service - DBMail IMAP Server
Loaded: loaded (/usr/lib/systemd/system/dbmail-imapd.service; enabled)
Active: active (running) since Di 2014-07-22 21:57:51 CEST; 2 days ago
Main PID: 633 (dbmail-imapd)
CGroup: name=systemd:/system/dbmail-imapd.service
└─633 /usr/sbin/dbmail-imapd -D

Am 24.07.2014 22:06, schrieb Jorge Bastos:
> Hi Harald,
>
> So how is this, problem solved?
>
>> -----Original Message-----
>> From: dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org] On
>> Behalf Of Harald Leithner
>> Sent: terça-feira, 22 de Julho de 2014 08:39
>> To: DBMail mailinglist
>> Subject: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct: 3.1.10
>> last clean version
>>
>> Runs fine for me, no customer complains since yesterday \o/
>>
>>
>> Am .07.2014, 17:56 Uhr, schrieb Paul J Stevens <paul@nfg.nl>:
>>
> So, you think we're ready for 3.1.17?
>
> On 21-07-14 17:10, Reindl Harald wrote:
>>>>> "69c0592867ad012bd1b78b873b65f7e53064971c" looks way better
>>>>>
>>>>> * high concurrency * loop of 3000 times "Panel: E-Mail-Debug -
>>>>> IMAP-POP3-Download" with POP3 and IMAP with no mismatch between both
>>>>> * checksum of all testmessages for POP3 and IMAP correct * see also
>>>>> attachment
>>>>>
>>>>> not sure if the conlusion "putting gmime back in charge" is entirely
>>>>> correct or the dbmail code just had some memory bug but at least i
>>>>> see no current problems and can't find the context of the
>>>>> 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive
>>>>>
>>>>> only that below where i was too stupid to notice the regression
>>> while
>>>>> other commits between 3.1.10 and 3.1.11 obviously are fine
>>>>>
>>> _____________________________________________________________________
>>>>> _____________________
>>>>>
>>>>> 2014-02-26 version 3.1.11 2014-02-25 IMAP: add loop protection to
>>>>> cleanup callback 2014-02-24 Fixed wrong result check in change
>>>>> username function 2014-02-21 fix regression in utf7 mailbox matching
>>>>> 2014-02-18 IMAP: fix inverted logic during abort
>>>>> 2014-02-18 LMTP/TIMSIEVE: fix possible segfaults 2014-02-17 POP3:
>>>>> fix segfault; fixes bug #1043 2014-02-10 IMAP: EOF on stdin is not
>>> an
>>>>> error 2014-02-10 remove unused file
>>>>>
>>>>> !! -- KILLER -- !! 2014-02-10 support wrapped boundaries during
>>>>> reconstruction !! -- KILLER -- !!
>>>>>
>>>>> 2014-02-07 boundary fix for sha512 passwords 2014-01-30 fix
>>>>> unit-tests after merge 2014-01-30 Merge branch 'dbmail_3_1_utf8_fix'
>>>>> of https://github.com/alyarskiy/dbmail
>>>>> 2014-01-30 Fixed long (>255) utf8 headers + unit-test 2014-01-28
>>>>> Revert "IMAP: defer bailout in case of EOF" 2014-01-22 version
>>>>> 3.1.10
>>>>>
>>> _____________________________________________________________________
>>>>> _____________________
>>>>>
>>>>> Am 26.02.2014 22:48, schrieb Jorge Bastos:
>>>>>> Anyone already using 3.1.11? Maybe this is the version that I'll
>>> use
>>>>>> for my upgrade, but 'd like some feedback from anyone using it
>>>>>> already
>>>>>
>>>>> yes because there are only small well deserved bugfixes from 3.1.10
>>>>> to 3.1.11 http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1
>>>>>
>>>>> 2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a big
>>>>> memory leak
>>>>>
>>>>> Am 21.07.2014 16:05, schrieb Paul J Stevens:
>>>>>> Ok. I'm putting gmime back in charge of parsing for boundaries.
>>>>>>
>>>>>> Currently testing the change.
>>>>>>
>>>>>> On 21-07-14 15:42, Reindl Harald wrote:
>>>>>>
>>>>>>> CLEAN - snapshot:
>>>>>>> a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
>>>>>>> _____________________________________________________
>>>>>>
>>>>>>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support wrapped
>>>>>>> boundaries during reconstruction
>>>>>>
>>>>>>> there must be happening something bad in memory
>>>>>>
>>>>>>> that is the guilty commit and sadly i remember that it fixed a bug
>>>>>>> rpeorted from myself in case of specific messages not proper
>>>>>>> re-constructed at least on Apple Mail
>>>>>>>
>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6
>>>>>>> 468e2cb4d520789cd35156145c5f37
>>>>>>
>>>>>>>
>>>>>>>
> no idea why a commit from 2014-02-10 took that long to get visible
>>>>>>> each day more
>>>>>>
>>>>>>> Am 21.07.2014 15:08, schrieb Reindl Harald:
>>>>>>>> unbelieveable
>>>>>>>>
>>>>>>>> i am building and stressing serveral releases 3.1.10 is the last
>>>>>>>> one not suffering from the problem "--" instead "-- mime-id" and
>>> i
>>>>>>>> have clearly no idea why this started around June to affect more
>>>>>>>> and more users
>>>>>>>>
>>>>>>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG
>>>>>>>> - 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG -
>>>>>>>> 3.1.11: aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN -
>>>>>>>> 3.1.10: 2e819d439c5e731b082bf83420f8ad20d89c0182
>>>>>>>>
>>>>>>>> with 3.1.10 it's impossible for me to produce enough concurrency
>>>>>>>> to get any single mismatch
>>>>>>>>
>>>>>>>> that below is expected because fixed with the following commit
>>>>>>>>
>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214a
>>>>>>>> e1d120581740020f4e73c3cf8d3a6c0

(I HATE RPM's! :) )

Cool.. keep us posted on the list in the next 5 days if you don't mind.
I'm about to upgrade but still didn't and don't have time ATM to debug so want a version the most stable possible,

> -----Original Message-----
> From: dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org] On
> Behalf Of Reindl Harald
> Sent: quinta-feira, 24 de Julho de 2014 21:31
> To: dbmail@dbmail.org
> Subject: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct: 3.1.10
> last clean version
>
> yes!
>
> [root@mail:~]$ rpm -q dbmail
> dbmail-3.1.16-
> 5.fc19.20140721.rh.69c0592867ad012bd1b78b873b65f7e53064971c.x86_64
>
> [root@mail:~]$ systemctl status dbmail-imapd.service dbmail-
> pop3d.service dbmail-imapd.service - DBMail IMAP Server
> Loaded: loaded (/usr/lib/systemd/system/dbmail-imapd.service;
> enabled)
> Active: active (running) since Di 2014-07-22 21:57:51 CEST; 2 days
> ago Main PID: 633 (dbmail-imapd)
> CGroup: name=systemd:/system/dbmail-imapd.service
> └─633 /usr/sbin/dbmail-imapd -D
>
> Am 24.07.2014 22:06, schrieb Jorge Bastos:
> > Hi Harald,
> >
> > So how is this, problem solved?
> >
> >> -----Original Message-----
> >> From: dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org]
> On
> >> Behalf Of Harald Leithner
> >> Sent: terça-feira, 22 de Julho de 2014 08:39
> >> To: DBMail mailinglist
> >> Subject: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct:
> 3.1.10
> >> last clean version
> >>
> >> Runs fine for me, no customer complains since yesterday \o/
> >>
> >>
> >> Am .07.2014, 17:56 Uhr, schrieb Paul J Stevens <paul@nfg.nl>:
> >>
> > So, you think we're ready for 3.1.17?
> >
> > On 21-07-14 17:10, Reindl Harald wrote:
> >>>>> "69c0592867ad012bd1b78b873b65f7e53064971c" looks way better
> >>>>>
> >>>>> * high concurrency * loop of 3000 times "Panel: E-Mail-Debug -
> >>>>> IMAP-POP3-Download" with POP3 and IMAP with no mismatch between
> >>>>> both
> >>>>> * checksum of all testmessages for POP3 and IMAP correct * see
> >>>>> also attachment
> >>>>>
> >>>>> not sure if the conlusion "putting gmime back in charge" is
> >>>>> entirely correct or the dbmail code just had some memory bug but
> >>>>> at least i see no current problems and can't find the context of
> >>>>> the
> >>>>> 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive
> >>>>>
> >>>>> only that below where i was too stupid to notice the regression
> >>> while
> >>>>> other commits between 3.1.10 and 3.1.11 obviously are fine
> >>>>>
> >>>
> ____________________________________________________________________
> >>> _
> >>>>> _____________________
> >>>>>
> >>>>> 2014-02-26 version 3.1.11 2014-02-25 IMAP: add loop protection
> to
> >>>>> cleanup callback 2014-02-24 Fixed wrong result check in change
> >>>>> username function 2014-02-21 fix regression in utf7 mailbox
> >>>>> matching
> >>>>> 2014-02-18 IMAP: fix inverted logic during abort
> >>>>> 2014-02-18 LMTP/TIMSIEVE: fix possible segfaults 2014-02-17 POP3:
> >>>>> fix segfault; fixes bug #1043 2014-02-10 IMAP: EOF on stdin is
> not
> >>> an
> >>>>> error 2014-02-10 remove unused file
> >>>>>
> >>>>> !! -- KILLER -- !! 2014-02-10 support wrapped boundaries during
> >>>>> reconstruction !! -- KILLER -- !!
> >>>>>
> >>>>> 2014-02-07 boundary fix for sha512 passwords 2014-01-30 fix
> >>>>> unit-tests after merge 2014-01-30 Merge branch
> 'dbmail_3_1_utf8_fix'
> >>>>> of https://github.com/alyarskiy/dbmail
> >>>>> 2014-01-30 Fixed long (>255) utf8 headers + unit-test 2014-01-28
> >>>>> Revert "IMAP: defer bailout in case of EOF" 2014-01-22 version
> >>>>> 3.1.10
> >>>>>
> >>>
> ____________________________________________________________________
> >>> _
> >>>>> _____________________
> >>>>>
> >>>>> Am 26.02.2014 22:48, schrieb Jorge Bastos:
> >>>>>> Anyone already using 3.1.11? Maybe this is the version that I'll
> >>> use
> >>>>>> for my upgrade, but 'd like some feedback from anyone using it
> >>>>>> already
> >>>>>
> >>>>> yes because there are only small well deserved bugfixes from
> >>>>> 3.1.10 to 3.1.11
> >>>>> http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1
> >>>>>
> >>>>> 2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a
> >>>>> big memory leak
> >>>>>
> >>>>> Am 21.07.2014 16:05, schrieb Paul J Stevens:
> >>>>>> Ok. I'm putting gmime back in charge of parsing for boundaries.
> >>>>>>
> >>>>>> Currently testing the change.
> >>>>>>
> >>>>>> On 21-07-14 15:42, Reindl Harald wrote:
> >>>>>>
> >>>>>>> CLEAN - snapshot:
> >>>>>>> a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
> >>>>>>> _____________________________________________________
> >>>>>>
> >>>>>>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support
> wrapped
> >>>>>>> boundaries during reconstruction
> >>>>>>
> >>>>>>> there must be happening something bad in memory
> >>>>>>
> >>>>>>> that is the guilty commit and sadly i remember that it fixed a
> >>>>>>> bug rpeorted from myself in case of specific messages not
> proper
> >>>>>>> re-constructed at least on Apple Mail
> >>>>>>>
> >>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6
> >>>>>>> 468e2cb4d520789cd35156145c5f37
> >>>>>>
> >>>>>>>
> >>>>>>>
> > no idea why a commit from 2014-02-10 took that long to get visible
> >>>>>>> each day more
> >>>>>>
> >>>>>>> Am 21.07.2014 15:08, schrieb Reindl Harald:
> >>>>>>>> unbelieveable
> >>>>>>>>
> >>>>>>>> i am building and stressing serveral releases 3.1.10 is the
> >>>>>>>> last one not suffering from the problem "--" instead "--
> >>>>>>>> mime-id" and
> >>> i
> >>>>>>>> have clearly no idea why this started around June to affect
> >>>>>>>> more and more users
> >>>>>>>>
> >>>>>>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG
> >>>>>>>> - 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG -
> >>>>>>>> 3.1.11: aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN -
> >>>>>>>> 3.1.10: 2e819d439c5e731b082bf83420f8ad20d89c0182
> >>>>>>>>
> >>>>>>>> with 3.1.10 it's impossible for me to produce enough
> >>>>>>>> concurrency to get any single mismatch
> >>>>>>>>
> >>>>>>>> that below is expected because fixed with the following commit
> >>>>>>>>
> >>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214a
> >>>>>>>> e1d120581740020f4e73c3cf8d3a6c0


_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

I'll release 3.1.17 this weekend.

On 24-07-14 22:35, Jorge Bastos wrote:
> (I HATE RPM's! :) )
>
> Cool.. keep us posted on the list in the next 5 days if you don't mind.
> I'm about to upgrade but still didn't and don't have time ATM to debug so want a version the most stable possible,
>
>> -----Original Message-----
>> From: dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org] On
>> Behalf Of Reindl Harald
>> Sent: quinta-feira, 24 de Julho de 2014 21:31
>> To: dbmail@dbmail.org
>> Subject: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct: 3.1.10
>> last clean version
>>
>> yes!
>>
>> [root@mail:~]$ rpm -q dbmail
>> dbmail-3.1.16-
>> 5.fc19.20140721.rh.69c0592867ad012bd1b78b873b65f7e53064971c.x86_64
>>
>> [root@mail:~]$ systemctl status dbmail-imapd.service dbmail-
>> pop3d.service dbmail-imapd.service - DBMail IMAP Server
>> Loaded: loaded (/usr/lib/systemd/system/dbmail-imapd.service;
>> enabled)
>> Active: active (running) since Di 2014-07-22 21:57:51 CEST; 2 days
>> ago Main PID: 633 (dbmail-imapd)
>> CGroup: name=systemd:/system/dbmail-imapd.service
>> └─633 /usr/sbin/dbmail-imapd -D
>>
>> Am 24.07.2014 22:06, schrieb Jorge Bastos:
>>> Hi Harald,
>>>
>>> So how is this, problem solved?
>>>
>>>> -----Original Message-----
>>>> From: dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org]
>> On
>>>> Behalf Of Harald Leithner
>>>> Sent: terça-feira, 22 de Julho de 2014 08:39
>>>> To: DBMail mailinglist
>>>> Subject: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct:
>> 3.1.10
>>>> last clean version
>>>>
>>>> Runs fine for me, no customer complains since yesterday \o/
>>>>
>>>>
>>>> Am .07.2014, 17:56 Uhr, schrieb Paul J Stevens <paul@nfg.nl>:
>>>>
>>> So, you think we're ready for 3.1.17?
>>>
>>> On 21-07-14 17:10, Reindl Harald wrote:
>>>>>>> "69c0592867ad012bd1b78b873b65f7e53064971c" looks way better
>>>>>>>
>>>>>>> * high concurrency * loop of 3000 times "Panel: E-Mail-Debug -
>>>>>>> IMAP-POP3-Download" with POP3 and IMAP with no mismatch between
>>>>>>> both
>>>>>>> * checksum of all testmessages for POP3 and IMAP correct * see
>>>>>>> also attachment
>>>>>>>
>>>>>>> not sure if the conlusion "putting gmime back in charge" is
>>>>>>> entirely correct or the dbmail code just had some memory bug but
>>>>>>> at least i see no current problems and can't find the context of
>>>>>>> the
>>>>>>> 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive
>>>>>>>
>>>>>>> only that below where i was too stupid to notice the regression
>>>>> while
>>>>>>> other commits between 3.1.10 and 3.1.11 obviously are fine
>>>>>>>
>>>>>
>> ____________________________________________________________________
>>>>> _
>>>>>>> _____________________
>>>>>>>
>>>>>>> 2014-02-26 version 3.1.11 2014-02-25 IMAP: add loop protection
>> to
>>>>>>> cleanup callback 2014-02-24 Fixed wrong result check in change
>>>>>>> username function 2014-02-21 fix regression in utf7 mailbox
>>>>>>> matching
>>>>>>> 2014-02-18 IMAP: fix inverted logic during abort
>>>>>>> 2014-02-18 LMTP/TIMSIEVE: fix possible segfaults 2014-02-17 POP3:
>>>>>>> fix segfault; fixes bug #1043 2014-02-10 IMAP: EOF on stdin is
>> not
>>>>> an
>>>>>>> error 2014-02-10 remove unused file
>>>>>>>
>>>>>>> !! -- KILLER -- !! 2014-02-10 support wrapped boundaries during
>>>>>>> reconstruction !! -- KILLER -- !!
>>>>>>>
>>>>>>> 2014-02-07 boundary fix for sha512 passwords 2014-01-30 fix
>>>>>>> unit-tests after merge 2014-01-30 Merge branch
>> 'dbmail_3_1_utf8_fix'
>>>>>>> of https://github.com/alyarskiy/dbmail
>>>>>>> 2014-01-30 Fixed long (>255) utf8 headers + unit-test 2014-01-28
>>>>>>> Revert "IMAP: defer bailout in case of EOF" 2014-01-22 version
>>>>>>> 3.1.10
>>>>>>>
>>>>>
>> ____________________________________________________________________
>>>>> _
>>>>>>> _____________________
>>>>>>>
>>>>>>> Am 26.02.2014 22:48, schrieb Jorge Bastos:
>>>>>>>> Anyone already using 3.1.11? Maybe this is the version that I'll
>>>>> use
>>>>>>>> for my upgrade, but 'd like some feedback from anyone using it
>>>>>>>> already
>>>>>>>
>>>>>>> yes because there are only small well deserved bugfixes from
>>>>>>> 3.1.10 to 3.1.11
>>>>>>> http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1
>>>>>>>
>>>>>>> 2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a
>>>>>>> big memory leak
>>>>>>>
>>>>>>> Am 21.07.2014 16:05, schrieb Paul J Stevens:
>>>>>>>> Ok. I'm putting gmime back in charge of parsing for boundaries.
>>>>>>>>
>>>>>>>> Currently testing the change.
>>>>>>>>
>>>>>>>> On 21-07-14 15:42, Reindl Harald wrote:
>>>>>>>>
>>>>>>>>> CLEAN - snapshot:
>>>>>>>>> a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
>>>>>>>>> _____________________________________________________
>>>>>>>>
>>>>>>>>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support
>> wrapped
>>>>>>>>> boundaries during reconstruction
>>>>>>>>
>>>>>>>>> there must be happening something bad in memory
>>>>>>>>
>>>>>>>>> that is the guilty commit and sadly i remember that it fixed a
>>>>>>>>> bug rpeorted from myself in case of specific messages not
>> proper
>>>>>>>>> re-constructed at least on Apple Mail
>>>>>>>>>
>>>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6
>>>>>>>>> 468e2cb4d520789cd35156145c5f37
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> no idea why a commit from 2014-02-10 took that long to get visible
>>>>>>>>> each day more
>>>>>>>>
>>>>>>>>> Am 21.07.2014 15:08, schrieb Reindl Harald:
>>>>>>>>>> unbelieveable
>>>>>>>>>>
>>>>>>>>>> i am building and stressing serveral releases 3.1.10 is the
>>>>>>>>>> last one not suffering from the problem "--" instead "--
>>>>>>>>>> mime-id" and
>>>>> i
>>>>>>>>>> have clearly no idea why this started around June to affect
>>>>>>>>>> more and more users
>>>>>>>>>>
>>>>>>>>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG
>>>>>>>>>> - 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG -
>>>>>>>>>> 3.1.11: aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN -
>>>>>>>>>> 3.1.10: 2e819d439c5e731b082bf83420f8ad20d89c0182
>>>>>>>>>>
>>>>>>>>>> with 3.1.10 it's impossible for me to produce enough
>>>>>>>>>> concurrency to get any single mismatch
>>>>>>>>>>
>>>>>>>>>> that below is expected because fixed with the following commit
>>>>>>>>>>
>>>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214a
>>>>>>>>>> e1d120581740020f4e73c3cf8d3a6c0
>
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
>

--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
www.nfg.nl/info@nfg.nl/+31.85.877.99.97
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Am 24.07.2014 22:35, schrieb Jorge Bastos:
> (I HATE RPM's! :) )

why?
nothing easier to maintain a SPEC file and a src.rpm containing all
patches, SPEC, sources, init-sripts and put that in a VCS - if it's
not packaged it don't exist :-)

> Cool.. keep us posted on the list in the next 5 days if you don't mind

69c0592867ad012bd1b78b873b65f7e53064971c is running 3 days
and interesting curently dbmail-imapd consumes 89 MB RAM

dbmail-imapd.service - DBMail IMAP Server
Loaded: loaded (/usr/lib/systemd/system/dbmail-imapd.service; enabled)
Active: active (running) since Di 2014-07-22 21:57:51 CEST; 3 days ago
Main PID: 633 (dbmail-imapd)
CGroup: name=systemd:/system/dbmail-imapd.service
└─633 /usr/sbin/dbmail-imapd -D

> I'm about to upgrade but still didn't and don't have time ATM to debug so want a version the most stable possible,

http://git.dbmail.eu/paul/dbmail/snapshot/dbmail-69c0592867ad012bd1b78b873b65f7e53064971c.tar.bz2
it will be pretty sure 3.1.17 and the above is from production environment

>> -----Original Message-----
>> From: dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org] On
>> Behalf Of Reindl Harald
>> Sent: quinta-feira, 24 de Julho de 2014 21:31
>> To: dbmail@dbmail.org
>> Subject: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct: 3.1.10
>> last clean version
>>
>> yes!
>>
>> [root@mail:~]$ rpm -q dbmail
>> dbmail-3.1.16-
>> 5.fc19.20140721.rh.69c0592867ad012bd1b78b873b65f7e53064971c.x86_64
>>
>> [root@mail:~]$ systemctl status dbmail-imapd.service dbmail-
>> pop3d.service dbmail-imapd.service - DBMail IMAP Server
>> Loaded: loaded (/usr/lib/systemd/system/dbmail-imapd.service;
>> enabled)
>> Active: active (running) since Di 2014-07-22 21:57:51 CEST; 2 days
>> ago Main PID: 633 (dbmail-imapd)
>> CGroup: name=systemd:/system/dbmail-imapd.service
>> └─633 /usr/sbin/dbmail-imapd -D
>>
>> Am 24.07.2014 22:06, schrieb Jorge Bastos:
>>> Hi Harald,
>>>
>>> So how is this, problem solved?
>>>
>>>> -----Original Message-----
>>>> From: dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org]
>> On
>>>> Behalf Of Harald Leithner
>>>> Sent: terça-feira, 22 de Julho de 2014 08:39
>>>> To: DBMail mailinglist
>>>> Subject: Re: [Dbmail] GUILTY COMMIT FOUND -> Re: re-construct:
>> 3.1.10
>>>> last clean version
>>>>
>>>> Runs fine for me, no customer complains since yesterday \o/
>>>>
>>>>
>>>> Am .07.2014, 17:56 Uhr, schrieb Paul J Stevens <paul@nfg.nl>:
>>>>
>>> So, you think we're ready for 3.1.17?
>>>
>>> On 21-07-14 17:10, Reindl Harald wrote:
>>>>>>> "69c0592867ad012bd1b78b873b65f7e53064971c" looks way better
>>>>>>>
>>>>>>> * high concurrency * loop of 3000 times "Panel: E-Mail-Debug -
>>>>>>> IMAP-POP3-Download" with POP3 and IMAP with no mismatch between
>>>>>>> both
>>>>>>> * checksum of all testmessages for POP3 and IMAP correct * see
>>>>>>> also attachment
>>>>>>>
>>>>>>> not sure if the conlusion "putting gmime back in charge" is
>>>>>>> entirely correct or the dbmail code just had some memory bug but
>>>>>>> at least i see no current problems and can't find the context of
>>>>>>> the
>>>>>>> 8c612adbe6468e2cb4d520789cd35156145c5f37 commit in my archive
>>>>>>>
>>>>>>> only that below where i was too stupid to notice the regression
>>>>> while
>>>>>>> other commits between 3.1.10 and 3.1.11 obviously are fine
>>>>>>>
>>>>>
>> ____________________________________________________________________
>>>>> _
>>>>>>> _____________________
>>>>>>>
>>>>>>> 2014-02-26 version 3.1.11 2014-02-25 IMAP: add loop protection
>> to
>>>>>>> cleanup callback 2014-02-24 Fixed wrong result check in change
>>>>>>> username function 2014-02-21 fix regression in utf7 mailbox
>>>>>>> matching
>>>>>>> 2014-02-18 IMAP: fix inverted logic during abort
>>>>>>> 2014-02-18 LMTP/TIMSIEVE: fix possible segfaults 2014-02-17 POP3:
>>>>>>> fix segfault; fixes bug #1043 2014-02-10 IMAP: EOF on stdin is
>> not
>>>>> an
>>>>>>> error 2014-02-10 remove unused file
>>>>>>>
>>>>>>> !! -- KILLER -- !! 2014-02-10 support wrapped boundaries during
>>>>>>> reconstruction !! -- KILLER -- !!
>>>>>>>
>>>>>>> 2014-02-07 boundary fix for sha512 passwords 2014-01-30 fix
>>>>>>> unit-tests after merge 2014-01-30 Merge branch
>> 'dbmail_3_1_utf8_fix'
>>>>>>> of https://github.com/alyarskiy/dbmail
>>>>>>> 2014-01-30 Fixed long (>255) utf8 headers + unit-test 2014-01-28
>>>>>>> Revert "IMAP: defer bailout in case of EOF" 2014-01-22 version
>>>>>>> 3.1.10
>>>>>>>
>>>>>
>> ____________________________________________________________________
>>>>> _
>>>>>>> _____________________
>>>>>>>
>>>>>>> Am 26.02.2014 22:48, schrieb Jorge Bastos:
>>>>>>>> Anyone already using 3.1.11? Maybe this is the version that I'll
>>>>> use
>>>>>>>> for my upgrade, but 'd like some feedback from anyone using it
>>>>>>>> already
>>>>>>>
>>>>>>> yes because there are only small well deserved bugfixes from
>>>>>>> 3.1.10 to 3.1.11
>>>>>>> http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_1
>>>>>>>
>>>>>>> 2014-01-28 Revert "IMAP: defer bailout in case of EOF" closes a
>>>>>>> big memory leak
>>>>>>>
>>>>>>> Am 21.07.2014 16:05, schrieb Paul J Stevens:
>>>>>>>> Ok. I'm putting gmime back in charge of parsing for boundaries.
>>>>>>>>
>>>>>>>> Currently testing the change.
>>>>>>>>
>>>>>>>> On 21-07-14 15:42, Reindl Harald wrote:
>>>>>>>>
>>>>>>>>> CLEAN - snapshot:
>>>>>>>>> a3f2972ed0f3f4d16fed27418c2013c6094533ab.tar.bz2
>>>>>>>>> _____________________________________________________
>>>>>>>>
>>>>>>>>> BROKEN: 8c612adbe6468e2cb4d520789cd35156145c5f37 support
>> wrapped
>>>>>>>>> boundaries during reconstruction
>>>>>>>>
>>>>>>>>> there must be happening something bad in memory
>>>>>>>>
>>>>>>>>> that is the guilty commit and sadly i remember that it fixed a
>>>>>>>>> bug rpeorted from myself in case of specific messages not
>> proper
>>>>>>>>> re-constructed at least on Apple Mail
>>>>>>>>>
>>>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8c612adbe6
>>>>>>>>> 468e2cb4d520789cd35156145c5f37
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> no idea why a commit from 2014-02-10 took that long to get visible
>>>>>>>>> each day more
>>>>>>>>
>>>>>>>>> Am 21.07.2014 15:08, schrieb Reindl Harald:
>>>>>>>>>> unbelieveable
>>>>>>>>>>
>>>>>>>>>> i am building and stressing serveral releases 3.1.10 is the
>>>>>>>>>> last one not suffering from the problem "--" instead "--
>>>>>>>>>> mime-id" and
>>>>> i
>>>>>>>>>> have clearly no idea why this started around June to affect
>>>>>>>>>> more and more users
>>>>>>>>>>
>>>>>>>>>> BUG - 3.1.13: 7d23183993e0ad81b8b0fc1920ba8e651043669e BUG
>>>>>>>>>> - 3.1.12: 1801c11f9e18a80c5eb2ae272bcbeb6d5f634e74 BUG -
>>>>>>>>>> 3.1.11: aa751fa4f998993a911dbf7f19fb06a4aceea843 CLEAN -
>>>>>>>>>> 3.1.10: 2e819d439c5e731b082bf83420f8ad20d89c0182
>>>>>>>>>>
>>>>>>>>>> with 3.1.10 it's impossible for me to produce enough
>>>>>>>>>> concurrency to get any single mismatch
>>>>>>>>>>
>>>>>>>>>> that below is expected because fixed with the following commit
>>>>>>>>>>
>>>>> http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=8a042214a
>>>>>>>>>> e1d120581740020f4e73c3cf8d3a6c0