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

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: [email protected] [mailto:[email protected]] On
>> Behalf Of Reindl Harald
>> Sent: quinta-feira, 24 de Julho de 2014 21:31
>> To: [email protected]
>> 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: [email protected] [mailto:[email protected]]
>> 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 <[email protected]>:
>>>>
>>> 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
[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/

iEYEARECAAYFAlPThrMACgkQhmBjz394AnlHjACfQWCjP+rbU/QP1adgsYKcr8/I
GjoAn2L5LsIsq6GCyKf+ao3ajQz7Z+pQ
=HcZv
-----END PGP SIGNATURE-----