Re: GUILTY COMMIT FOUND -> Re: re-construct: 3.1.10 last clean version

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 <[email protected]>
> Gesendet: 21. Juli 2014 17:56:16 MESZ
> An: DBMail mailinglist <[email protected]>
> 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

_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPNUjUACgkQhmBjz394AnkYkgCfVdGtbE3+M7wWdOLBOzoiO4JY
13cAnjdcyWDaaxgGpQjqObU0SMXD01iV
=fuWq
-----END PGP SIGNATURE-----