Hi Harald, So how is this, problem solved?
> -----Original Message----- > From: dbmail-boun...@dbmail.org [mailto:dbmail-boun...@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 <p...@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/i...@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: leith...@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
