Mailing List Archive

We tried to switch to 3.2.0 on an older machine but it segfaults the same…

Please, we need some help!

-------
Andrea Brancatelli
Schema 31 S.p.a.
Responsabile IT

ROMA - FIRENZE - PALERMO
ITALY
Tel: +39. 06.98.358.472
Cell: +39 331.2488468
Fax: +39. 055.71.880.466
Società del Gruppo SC31 ITALIA


Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli (abrancatelli@schema31.it) ha scritto:

 
Hello everybody.

We recently upgraded from 3.1.17 to 3.2.1 on two different machines and we’re now facing continuous segmentation faults both in dbmail-imapd and dbmail-lmtpd (on both machines).

We don’t have dbmail-pop3d active but I suppose that would be crashing too :-)

The machine is a FreeBSD 10.1, I suspect there’s something strange going on with libzdb. Last line in dbmail.err is always the same when dbmail crashes:

Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0] connection cleared
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT MAX(message_idnr)+1 FROM dbmail_messages WHERE mailbox_idnr=?]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+973): checking ACL [read_flag] for user [137] on mailbox [1142]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [.SELECT * FROM dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[137]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 2:[1142]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+1007): mailbox [1142] is owned by user [137]and no ACL in place. Giving all rights
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access granted
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT name,seq FROM dbmail_mailboxes WHERE mailbox_idnr=?]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878): id: [1142] name: [Drafts] seq [11334]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool

There’s no dbmail-imapd.core or anything. 

The chain is the usual one: stunnel -> dbmail -> mysql 5.6

The machine is pretty busy but not super busy, after all it’s 29 dic.

What can I look for?

Thank you.

-------
Andrea Brancatelli

Perhaps something else has changed?

You might try rebuilding/reinstalling dependent libraries including zdb
and the database libraries, I understand that PostgreSQL has recently
been updated to 9.3 which may have had an affect. That you have the
same segfault with 3.2.0 suggests it is a related library rather than
dbmail.

You can check to see which libraries are linked using ldd
/usr/local/sbin/dbmail-imapd

I run my own poudriere build so can only confirm that my experience with
3.2.1 is that it is the most stable release to date and have not seen
any segfaults.

Regards,
Alan

On 02/01/2015 15:09, Andrea Brancatelli wrote:
> We tried to switch to 3.2.0 on an older machine but it segfaults the same…
>
> Please, we need some help!
>
> -------
> *Andrea Brancatelli*
> Schema 31 S.p.a.
> Responsabile IT
>
> ROMA - FIRENZE - PALERMO
> ITALY
> Tel: +39. 06.98.358.472
> Cell: +39 331.2488468
> Fax: +39. 055.71.880.466
> Società del GruppoSC31 ITALIA
>
>
> Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli
> (abrancatelli@schema31.it <mailto:abrancatelli@schema31.it>) ha scritto:
>
>>
>> Hello everybody.
>>
>> We recently upgraded from 3.1.17 to 3.2.1 on two different machines
>> and we’re now facing continuous segmentation faults both in
>> dbmail-imapd and dbmail-lmtpd (on both machines).
>>
>> We don’t have dbmail-pop3d active but I suppose that would be
>> crashing too :-)
>>
>> The machine is a FreeBSD 10.1, I suspect there’s something strange
>> going on with libzdb. Last line in dbmail.err is always the same when
>> dbmail crashes:
>>
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_con_clear(+349): [0x80506f6f0] connection cleared
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT
>> MAX(message_idnr)+1 FROM dbmail_messages WHERE mailbox_idnr=?]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_commit_transaction(+606): COMMIT
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Debug:[MailboxState] MailboxState_hasPermission(+973): checking ACL
>> [read_flag] for user [137] on mailbox [1142]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [.SELECT * FROM
>> dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[137]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 2:[1142]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Debug:[MailboxState] MailboxState_hasPermission(+1007): mailbox
>> [1142] is owned by user [137]and no ACL in place. Giving all rights
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Debug:[imap] mailbox_check_acl(+369): access granted
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT name,seq
>> FROM dbmail_mailboxes WHERE mailbox_idnr=?]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Debug:[MailboxState] db_getmailbox_seq(+878): id: [1142] name:
>> [Drafts] seq [11334]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540]
>> Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
>>
>> There’s no dbmail-imapd.core or anything.
>>
>> The chain is the usual one: stunnel -> dbmail -> mysql 5.6
>>
>> The machine is pretty busy but not super busy, after all it’s 29 dic.
>>
>> What can I look for?
>>
>> Thank you.
>>
>> -------
>> Andrea Brancatelli
>>
>
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: +44 79 3030 5004
Tel: +44 20 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon
Company blog https://plus.google.com/+PoCoUkLondon/posts
LinkedIn https://uk.linkedin.com/in/alanhickslondon/
GitHub https://github.com/alan-hicks

Andrea,



Do you have the seq column in dbmail_mailboxes?



From: dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org] On Behalf Of Alan Hicks
Sent: sábado, 3 de Janeiro de 2015 10:22
To: DBMail mailinglist
Subject: Re: [Dbmail] Segmentation Fault with dbmail 3.2.1 (FreeBSD)



Perhaps something else has changed?

You might try rebuilding/reinstalling dependent libraries including zdb and the database libraries, I understand that PostgreSQL has recently been updated to 9.3 which may have had an affect. That you have the same segfault with 3.2.0 suggests it is a related library rather than dbmail.

You can check to see which libraries are linked using ldd /usr/local/sbin/dbmail-imapd

I run my own poudriere build so can only confirm that my experience with 3.2.1 is that it is the most stable release to date and have not seen any segfaults.

Regards,
Alan

On 02/01/2015 15:09, Andrea Brancatelli wrote:

We tried to switch to 3.2.0 on an older machine but it segfaults the same…



Please, we need some help!



-------

Andrea Brancatelli
Schema 31 S.p.a.
Responsabile IT

ROMA - FIRENZE - PALERMO
ITALY
Tel: +39. 06.98.358.472
Cell: +39 331.2488468
Fax: +39. 055.71.880.466
Società del Gruppo SC31 ITALIA





Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli (abrancatelli@schema31.it) ha scritto:


Hello everybody.

We recently upgraded from 3.1.17 to 3.2.1 on two different machines and we’re now facing continuous segmentation faults both in dbmail-imapd and dbmail-lmtpd (on both machines).

We don’t have dbmail-pop3d active but I suppose that would be crashing too :-)

The machine is a FreeBSD 10.1, I suspect there’s something strange going on with libzdb. Last line in dbmail.err is always the same when dbmail crashes:

Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0] connection cleared
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT MAX(message_idnr)+1 FROM dbmail_messages WHERE mailbox_idnr=?]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+973): checking ACL [read_flag] for user [137] on mailbox [1142]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [.SELECT * FROM dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[137]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 2:[1142]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+1007): mailbox [1142] is owned by user [137]and no ACL in place. Giving all rights
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access granted
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT name,seq FROM dbmail_mailboxes WHERE mailbox_idnr=?]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878): id: [1142] name: [Drafts] seq [11334]
Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool

There’s no dbmail-imapd.core or anything.

The chain is the usual one: stunnel -> dbmail -> mysql 5.6

The machine is pretty busy but not super busy, after all it’s 29 dic.

What can I look for?

Thank you.

-------
Andrea Brancatelli






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





--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: +44 79 3030 5004
Tel: +44 20 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon
Company blog https://plus.google.com/+PoCoUkLondon/posts
LinkedIn https://uk.linkedin.com/in/alanhickslondon/
GitHub https://github.com/alan-hicks

Won't hurt to check, but a SQLException would normally be raised in that
case.

On 03-01-15 11:29, Jorge Bastos wrote:
> Andrea,
>
>
>
> Do you have the seq column in dbmail_mailboxes?
>
>
>
> *From:*dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org] *On
> Behalf Of *Alan Hicks
> *Sent:* sábado, 3 de Janeiro de 2015 10:22
> *To:* DBMail mailinglist
> *Subject:* Re: [Dbmail] Segmentation Fault with dbmail 3.2.1 (FreeBSD)
>
>
>
> Perhaps something else has changed?
>
> You might try rebuilding/reinstalling dependent libraries including zdb
> and the database libraries, I understand that PostgreSQL has recently
> been updated to 9.3 which may have had an affect. That you have the
> same segfault with 3.2.0 suggests it is a related library rather than
> dbmail.
>
> You can check to see which libraries are linked using ldd
> /usr/local/sbin/dbmail-imapd
>
> I run my own poudriere build so can only confirm that my experience with
> 3.2.1 is that it is the most stable release to date and have not seen
> any segfaults.
>
> Regards,
> Alan
>
> On 02/01/2015 15:09, Andrea Brancatelli wrote:
>
> We tried to switch to 3.2.0 on an older machine but it segfaults the
> same…
>
>
>
> Please, we need some help!
>
>
>
> -------
>
> *Andrea Brancatelli*
>
> Schema 31 S.p.a.
>
> Responsabile IT
>
>
>
> ROMA - FIRENZE - PALERMO
>
> ITALY
>
> Tel: +39. 06.98.358.472
>
> Cell: +39 331.2488468
>
> Fax: +39. 055.71.880.466
>
> Società del Gruppo SC31 ITALIA
>
>
>
>
>
> Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli
> (abrancatelli@schema31.it <mailto:abrancatelli@schema31.it>) ha scritto:
>
>
> Hello everybody.
>
> We recently upgraded from 3.1.17 to 3.2.1 on two different
> machines and we’re now facing continuous segmentation faults
> both in dbmail-imapd and dbmail-lmtpd (on both machines).
>
> We don’t have dbmail-pop3d active but I suppose that would be
> crashing too :-)
>
> The machine is a FreeBSD 10.1, I suspect there’s something
> strange going on with libzdb. Last line in dbmail.err is always
> the same when dbmail crashes:
>
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0]
> connection cleared
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0]
> [SELECT MAX(message_idnr)+1 FROM dbmail_messages WHERE
> mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20]
> 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0]
> connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Debug:[MailboxState]
> MailboxState_hasPermission(+973): checking ACL [read_flag] for
> user [137] on mailbox [1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0]
> connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0]
> [.SELECT * FROM dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20]
> 1:[137]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20]
> 2:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0]
> connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Debug:[MailboxState]
> MailboxState_hasPermission(+1007): mailbox [1142] is owned by
> user [137]and no ACL in place. Giving all rights
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access granted
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0]
> connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0]
> [SELECT name,seq FROM dbmail_mailboxes WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20]
> 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878): id:
> [1142] name: [Drafts] seq [11334]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
> [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0]
> connection to pool
>
> There’s no dbmail-imapd.core or anything.
>
> The chain is the usual one: stunnel -> dbmail -> mysql 5.6
>
> The machine is pretty busy but not super busy, after all it’s 29
> dic.
>
> What can I look for?
>
> Thank you.
>
> -------
> Andrea Brancatelli
>
>
>
>
> _______________________________________________
>
> DBmail mailing list
>
> DBmail@dbmail.org <mailto:DBmail@dbmail.org>
>
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
>
>
>
> --
>
> Persistent Objects Ltd
>
> 128 Lilleshall Road
>
> Morden SM4 6DR
>
>
>
> The Home of Lasting Solutions
>
>
>
> Mobile: +44 79 3030 5004
>
> Tel: +44 20 8544 5292
>
> Web: p-o.co.uk
>
> Skype: alan-hicks-london
>
> Personal blog https://plus.google.com/+AlanHicksLondon
>
> Company blog https://plus.google.com/+PoCoUkLondon/posts
>
> LinkedIn https://uk.linkedin.com/in/alanhickslondon/
>
> GitHub https://github.com/alan-hicks
>
>
>
> _______________________________________________
> 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

Andrea,

Could you send this same log, but with a bit more history? I'm mostly
interested in the exact IMAP command that precedes this.

Same goes for the lmtp trace.

On 29-12-14 10:35, Andrea Brancatelli wrote:
>
> Hello everybody.
>
> We recently upgraded from 3.1.17 to 3.2.1 on two different machines and we’re now facing continuous segmentation faults both in dbmail-imapd and dbmail-lmtpd (on both machines).
>
> We don’t have dbmail-pop3d active but I suppose that would be crashing too :-)
>
> The machine is a FreeBSD 10.1, I suspect there’s something strange going on with libzdb. Last line in dbmail.err is always the same when dbmail crashes:
>
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0] connection cleared
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT MAX(message_idnr)+1 FROM dbmail_messages WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+973): checking ACL [read_flag] for user [137] on mailbox [1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [.SELECT * FROM dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[137]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 2:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+1007): mailbox [1142] is owned by user [137]and no ACL in place. Giving all rights
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access granted
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT name,seq FROM dbmail_mailboxes WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878): id: [1142] name: [Drafts] seq [11334]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
>
> There’s no dbmail-imapd.core or anything.
>
> The chain is the usual one: stunnel -> dbmail -> mysql 5.6
>
> The machine is pretty busy but not super busy, after all it’s 29 dic.
>
> What can I look for?
>
> Thank you.
>
> -------
> Andrea Brancatelli
>
>
> _______________________________________________
> 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

Sure Paul, I’m sending you privately at your mailbox. Thanks.

-- 
Andrea Brancatelli
Schema31 S.p.a.
Responsabile IT

ROMA - FIRENZE - PALERMO
ITALY
Tel: +39. 06.98.358.472
Cell: +39 331.2488468
Fax: +39. 055.71.880.466
Società del Gruppo SC31 ITALIA

Il giorno 03 gennaio 2015 @ 12:03:02, Paul J Stevens (paul@nfg.nl) ha scritto:

db_getmailbox_seq(+878)

Hello Alan.

We're using MySQL, not pgSQL. We have three different machines all
exposing the same behavior. One of them (the main one) has DBMail
compiled from ports against MySQL 5.6, and this is it's LDD:

root@rubidio:/home/abrancatelli # ldd /usr/local/sbin/dbmail-imapd

/usr/local/sbin/dbmail-imapd:

libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)

libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)


libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)

libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)

libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)


libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)


libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)

libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)

libm.so.5 => /lib/libm.so.5 (0x801b83000)

libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)

libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5
(0x801fd3000)

libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)

libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)

libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x80262a000)

libthr.so.3 => /lib/libthr.so.3 (0x8028a0000)

libc.so.7 => /lib/libc.so.7 (0x802ac5000)

libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e5e000)

libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x803157000)

libz.so.6 => /lib/libz.so.6 (0x8033c4000)

libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035d9000)

libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18
(0x8037e0000)

libssl.so.7 => /usr/lib/libssl.so.7 (0x803db9000)

libcrypto.so.7 => /lib/libcrypto.so.7 (0x804023000)

libc++.so.1 => /usr/lib/libc++.so.1 (0x80440e000)

libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8046c9000)

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8048e3000)

The other two machines were it was segfaulting had DBMail installed from
PKG against MySQL 5.5.We tried to upgrade those as well to 3.2.1 but the
problem is still there. That's the LDD from these machines.

root@sc31-mx-01:~ # ldd /usr/local/sbin/dbmail-imapd

/usr/local/sbin/dbmail-imapd:

libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)

libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)


libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)

libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)

libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)


libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)


libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)

libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)

libm.so.5 => /lib/libm.so.5 (0x801b83000)

libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)

libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5
(0x801fd3000)

libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)

libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)

libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x802632000)

libthr.so.3 => /lib/libthr.so.3 (0x8028a8000)

libc.so.7 => /lib/libc.so.7 (0x802acd000)

libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e76000)

libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80316f000)

libz.so.6 => /lib/libz.so.6 (0x8033dc000)

libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035f1000)

libpq.so.5 => /usr/local/lib/libpq.so.5 (0x8037f8000)

libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x803a25000)

libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18
(0x803d16000)

libssl.so.7 => /usr/lib/libssl.so.7 (0x804283000)

libcrypto.so.7 => /lib/libcrypto.so.7 (0x8044ee000)

libc++.so.1 => /usr/lib/libc++.so.1 (0x8048e1000)

libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804b9c000)

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804db6000)

I didn't read it but I suppose it to be pretty similar (the same?).

BTW, if I can point my finger toward something external to dbmail, my
guess would be gmime26-2.6.20.

Thanks

---

Andrea Brancatelli
Schema31 S.p.a.
Responsabile IT

ROMA - FIRENZE - PALERMO
ITALY
Tel: +39. 06.98.358.472
Cell: +39 331.2488468
Fax: +39. 055.71.880.466
Società del Gruppo SC31 ITALIA

Il 2015-01-03 11:22 Alan Hicks ha scritto:

> Perhaps something else has changed?
>
> You might try rebuilding/reinstalling dependent libraries including zdb and the database libraries, I understand that PostgreSQL has recently been updated to 9.3 which may have had an affect. That you have the same segfault with 3.2.0 suggests it is a related library rather than dbmail.
>
> You can check to see which libraries are linked using ldd /usr/local/sbin/dbmail-imapd
>
> I run my own poudriere build so can only confirm that my experience with 3.2.1 is that it is the most stable release to date and have not seen any segfaults.
>
> Regards,
> Alan
>
> On 02/01/2015 15:09, Andrea Brancatelli wrote:
> We tried to switch to 3.2.0 on an older machine but it segfaults the same...
>
> Please, we need some help!
>
> -------
>
> ANDREA BRANCATELLI
> Schema 31 S.p.a. Responsabile IT ROMA - FIRENZE - PALERMO ITALY Tel: +39. 06.98.358.472 Cell: +39 331.2488468 Fax: +39. 055.71.880.466 Società del Gruppo SC31 ITALIA
>
> Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli (abrancatelli@schema31.it) ha scritto:
>
> Hello everybody.
>
> We recently upgraded from 3.1.17 to 3.2.1 on two different machines and we're now facing continuous segmentation faults both in dbmail-imapd and dbmail-lmtpd (on both machines).
>
> We don't have dbmail-pop3d active but I suppose that would be crashing too :-)
>
> The machine is a FreeBSD 10.1, I suspect there's something strange going on with libzdb. Last line in dbmail.err is always the same when dbmail crashes:
>
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0] connection cleared
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT MAX(message_idnr)+1 FROM dbmail_messages WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+973): checking ACL [read_flag] for user [137] on mailbox [1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [.SELECT * FROM dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[137]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 2:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+1007): mailbox [1142] is owned by user [137]and no ACL in place. Giving all rights
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access granted
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT name,seq FROM dbmail_mailboxes WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878): id: [1142] name: [Drafts] seq [11334]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
>
> There's no dbmail-imapd.core or anything.
>
> The chain is the usual one: stunnel -> dbmail -> mysql 5.6
>
> The machine is pretty busy but not super busy, after all it's 29 dic.
>
> What can I look for?
>
> Thank you.
>
> -------
> Andrea Brancatelli
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail [1]

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: +44 79 3030 5004
Tel: +44 20 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon [2]
Company blog https://plus.google.com/+PoCoUkLondon/posts [3]
LinkedIn https://uk.linkedin.com/in/alanhickslondon/ [4]
GitHub https://github.com/alan-hicks [5]

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



Links:
------
[1] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
[2] https://plus.google.com/+AlanHicksLondon
[3] https://plus.google.com/+PoCoUkLondon/posts
[4] https://uk.linkedin.com/in/alanhickslondon/
[5] https://github.com/alan-hicks

We do.

mysql [localhost] {root} (dbmail) > desc dbmail_mailboxes;

+---------------+---------------------+------+-----+---------+----------------+


| Field | Type | Null | Key | Default | Extra |

+---------------+---------------------+------+-----+---------+----------------+


| mailbox_idnr | bigint(20) unsigned | NO | PRI | NULL | auto_increment
|

| owner_idnr | bigint(20) unsigned | NO | MUL | 0 | |

| name | varchar(255) | NO | MUL | | |

| seen_flag | tinyint(1) | NO | | 0 | |

| answered_flag | tinyint(1) | NO | | 0 | |

| deleted_flag | tinyint(1) | NO | | 0 | |

| flagged_flag | tinyint(1) | NO | | 0 | |

| recent_flag | tinyint(1) | NO | | 0 | |

| draft_flag | tinyint(1) | NO | | 0 | |

| no_inferiors | tinyint(1) | NO | | 0 | |

| no_select | tinyint(1) | NO | | 0 | |

| permission | tinyint(1) | YES | | 2 | |

| seq | bigint(20) | NO | MUL | 0 | |

+---------------+---------------------+------+-----+---------+----------------+


13 rows in set (0.02 sec)

---

Andrea Brancatelli
Schema31 S.p.a.
Responsabile IT

ROMA - FIRENZE - PALERMO
ITALY
Tel: +39. 06.98.358.472
Cell: +39 331.2488468
Fax: +39. 055.71.880.466
Società del Gruppo SC31 ITALIA

Il 2015-01-03 11:29 Jorge Bastos ha scritto:

> Andrea,
>
> Do you have the seq column in dbmail_mailboxes?
>
> FROM: dbmail-bounces@dbmail.org [mailto:dbmail-bounces@dbmail.org] ON BEHALF OF Alan Hicks
> SENT: sábado, 3 de Janeiro de 2015 10:22
> TO: DBMail mailinglist
> SUBJECT: Re: [Dbmail] Segmentation Fault with dbmail 3.2.1 (FreeBSD)
>
> Perhaps something else has changed?
>
> You might try rebuilding/reinstalling dependent libraries including zdb and the database libraries, I understand that PostgreSQL has recently been updated to 9.3 which may have had an affect. That you have the same segfault with 3.2.0 suggests it is a related library rather than dbmail.
>
> You can check to see which libraries are linked using ldd /usr/local/sbin/dbmail-imapd
>
> I run my own poudriere build so can only confirm that my experience with 3.2.1 is that it is the most stable release to date and have not seen any segfaults.
>
> Regards,
> Alan
>
> On 02/01/2015 15:09, Andrea Brancatelli wrote:
>
> We tried to switch to 3.2.0 on an older machine but it segfaults the same...
>
> Please, we need some help!
>
> -------
>
> ANDREA BRANCATELLI
>
> Schema 31 S.p.a.
>
> Responsabile IT
>
> ROMA - FIRENZE - PALERMO
>
> ITALY
>
> Tel: +39. 06.98.358.472
>
> Cell: +39 331.2488468
>
> Fax: +39. 055.71.880.466
>
> Società del Gruppo SC31 ITALIA
>
> Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli (abrancatelli@schema31.it) ha scritto:
>
> Hello everybody.
>
> We recently upgraded from 3.1.17 to 3.2.1 on two different machines and we're now facing continuous segmentation faults both in dbmail-imapd and dbmail-lmtpd (on both machines).
>
> We don't have dbmail-pop3d active but I suppose that would be crashing too :-)
>
> The machine is a FreeBSD 10.1, I suspect there's something strange going on with libzdb. Last line in dbmail.err is always the same when dbmail crashes:
>
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0] connection cleared
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT MAX(message_idnr)+1 FROM dbmail_messages WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+973): checking ACL [read_flag] for user [137] on mailbox [1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [.SELECT * FROM dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[137]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 2:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+1007): mailbox [1142] is owned by user [137]and no ACL in place. Giving all rights
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access granted
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT name,seq FROM dbmail_mailboxes WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878): id: [1142] name: [Drafts] seq [11334]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
>
> There's no dbmail-imapd.core or anything.
>
> The chain is the usual one: stunnel -> dbmail -> mysql 5.6
>
> The machine is pretty busy but not super busy, after all it's 29 dic.
>
> What can I look for?
>
> Thank you.
>
> -------
> Andrea Brancatelli
>
> _______________________________________________
>
> DBmail mailing list
>
> DBmail@dbmail.org
>
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail [1]

--

Persistent Objects Ltd

128 Lilleshall Road

Morden SM4 6DR

The Home of Lasting Solutions

Mobile: +44 79 3030 5004

Tel: +44 20 8544 5292

Web: p-o.co.uk

Skype: alan-hicks-london

Personal blog https://plus.google.com/+AlanHicksLondon [2]

Company blog https://plus.google.com/+PoCoUkLondon/posts [3]

LinkedIn https://uk.linkedin.com/in/alanhickslondon/ [4]

GitHub https://github.com/alan-hicks [5]

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



Links:
------
[1] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
[2] https://plus.google.com/+AlanHicksLondon
[3] https://plus.google.com/+PoCoUkLondon/posts
[4] https://uk.linkedin.com/in/alanhickslondon/
[5] https://github.com/alan-hicks

Hello eveybody.

So I was able to get a dbmail-imapd crash while running inside gdb.

It run for about 4 hours and served about 380 sessions (from dbmail_authlog) before crashing.

I wasn’t able to recompile with symbols yet, but maybe the stack trace can already give you any hint of what’s happening. Here it is:



root@rubidio:~ # gdb /usr/local/sbin/dbmail-imapd
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)...
(gdb) run -D
Starting program: /usr/local/sbin/dbmail-imapd -D
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 101472]
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 805006400 (LWP 101472/dbmail-imapd)]
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
[New Thread 80500cc00 (LWP 101021/dbmail-imapd)]
[New Thread 80500ac00 (LWP 100266/dbmail-imapd)]
(no debugging symbols found)...[New Thread 80500d000 (LWP 101069/dbmail-imapd)]
[New Thread 80500b800 (LWP 100394/dbmail-imapd)]
(no debugging symbols found)...[New Thread 80500c800 (LWP 100932/dbmail-imapd)]
[New Thread 80500c000 (LWP 100691/dbmail-imapd)]
[New Thread 80500c400 (LWP 100754/dbmail-imapd)]
[New Thread 80500b400 (LWP 100320/dbmail-imapd)]
[New Thread 80500bc00 (LWP 100401/dbmail-imapd)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 80500bc00 (LWP 100401/dbmail-imapd)]
0x000000000040c3c1 in _ic_status ()
(gdb) bt
#0 0x000000000040c3c1 in _ic_status ()
#1 0x00000008016e8a42 in g_thread_pool_get_max_idle_time () from /usr/local/lib/libglib-2.0.so.0
#2 0x00000008016e7baa in g_thread_unref () from /usr/local/lib/libglib-2.0.so.0
#3 0x00000008028a94a4 in pthread_create () from /lib/libthr.so.3
#4 0x0000000000000000 in ?? ()
(gdb)
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Hello Andrea,

Your libraries glib, gettext-runtime, mhash, libevent2, libzdb,
libiconv, pcre, libffi and mysql56-client appear ok, the only difference
is you have libc++, libcssrt and libgcc_s and I have ldap and
postgresql. I assume everything is build using clang. Also I'm running
ancient 32bit hardware.

Do you have IPv6, I remember getting an error as the authlog table
needed larger columns for src_ip and dst_ip when I started using IPv6.

Other than that it may be an edge case with data in which case Paul is
better able to help.

Kind regards,
Alan

% ldd /usr/local/sbin/dbmail-imapd
/usr/local/sbin/dbmail-imapd:
libcrypt.so.5 => /lib/libcrypt.so.5 (0x2808b000)
libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0
(0x280af000)
libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x280b2000)
libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x28115000)
libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0
(0x28252000)
libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0
(0x28291000)
libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x28293000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28387000)
libm.so.5 => /lib/libm.so.5 (0x28390000)
libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x283b6000)
libevent_pthreads-2.0.so.5 =>
/usr/local/lib/libevent_pthreads-2.0.so.5 (0x283e4000)
libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x283e6000)
libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x28423000)
libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x28435000)
libldap_r-2.4.so.2 => /usr/local/lib/libldap_r-2.4.so.2
(0x284a9000)
libthr.so.3 => /lib/libthr.so.3 (0x284f1000)
libc.so.7 => /lib/libc.so.7 (0x28513000)
libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x28686000)
libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x2877a000)
libz.so.6 => /lib/libz.so.6 (0x287ef000)
libffi.so.6 => /usr/local/lib/libffi.so.6 (0x28803000)
libpq.so.5 => /usr/local/lib/libpq.so.5 (0x28809000)
libssl.so.7 => /usr/lib/libssl.so.7 (0x28830000)
libcrypto.so.7 => /lib/libcrypto.so.7 (0x2888c000)
liblber-2.4.so.2 => /usr/local/lib/liblber-2.4.so.2 (0x28a1b000)


On 03/01/2015 17:21, Andrea Brancatelli wrote:
>
> Hello Alan.
>
> We're using MySQL, not pgSQL. We have three different machines all
> exposing the same behavior. One of them (the main one) has DBMail
> compiled from ports against MySQL 5.6, and this is it's LDD:
>
> root@rubidio:/home/abrancatelli # ldd /usr/local/sbin/dbmail-imapd
>
> /usr/local/sbin/dbmail-imapd:
>
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)
>
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)
>
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)
>
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)
>
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)
>
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)
>
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)
>
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)
>
> libm.so.5 => /lib/libm.so.5 (0x801b83000)
>
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)
>
> libevent_pthreads-2.0.so.5 =>
> /usr/local/lib/libevent_pthreads-2.0.so.5 (0x801fd3000)
>
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)
>
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)
>
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x80262a000)
>
> libthr.so.3 => /lib/libthr.so.3 (0x8028a0000)
>
> libc.so.7 => /lib/libc.so.7 (0x802ac5000)
>
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e5e000)
>
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x803157000)
>
> libz.so.6 => /lib/libz.so.6 (0x8033c4000)
>
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035d9000)
>
> libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18
> (0x8037e0000)
>
> libssl.so.7 => /usr/lib/libssl.so.7 (0x803db9000)
>
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x804023000)
>
> libc++.so.1 => /usr/lib/libc++.so.1 (0x80440e000)
>
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8046c9000)
>
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8048e3000)
>
> The other two machines were it was segfaulting had DBMail installed
> from PKG against MySQL 5.5.We tried to upgrade those as well to 3.2.1
> but the problem is still there. That's the LDD from these machines.
>
> root@sc31-mx-01:~ # ldd /usr/local/sbin/dbmail-imapd
>
> /usr/local/sbin/dbmail-imapd:
>
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)
>
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)
>
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)
>
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)
>
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)
>
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)
>
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)
>
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)
>
> libm.so.5 => /lib/libm.so.5 (0x801b83000)
>
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)
>
> libevent_pthreads-2.0.so.5 =>
> /usr/local/lib/libevent_pthreads-2.0.so.5 (0x801fd3000)
>
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)
>
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)
>
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x802632000)
>
> libthr.so.3 => /lib/libthr.so.3 (0x8028a8000)
>
> libc.so.7 => /lib/libc.so.7 (0x802acd000)
>
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e76000)
>
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80316f000)
>
> libz.so.6 => /lib/libz.so.6 (0x8033dc000)
>
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035f1000)
>
> libpq.so.5 => /usr/local/lib/libpq.so.5 (0x8037f8000)
>
> libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x803a25000)
>
> libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18
> (0x803d16000)
>
> libssl.so.7 => /usr/lib/libssl.so.7 (0x804283000)
>
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x8044ee000)
>
> libc++.so.1 => /usr/lib/libc++.so.1 (0x8048e1000)
>
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804b9c000)
>
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804db6000)
>
> I didn't read it but I suppose it to be pretty similar (the same?).
>
> BTW, if I can point my finger toward something external to dbmail, my
> guess would be gmime26-2.6.20.
>
> Thanks
>
> ---
> *Andrea Brancatelli
> Schema31 S.p.a.
> Responsabile IT
> *
> ROMA - FIRENZE - PALERMO
> ITALY
> Tel: +39. 06.98.358.472
> Cell: +39 331.2488468
> Fax: +39. 055.71.880.466
> Società del Gruppo*SC31 ITALIA*
>
> Il 2015-01-03 11:22 Alan Hicks ha scritto:
>
>> Perhaps something else has changed?
>>
>> You might try rebuilding/reinstalling dependent libraries including
>> zdb and the database libraries, I understand that PostgreSQL has
>> recently been updated to 9.3 which may have had an affect. That you
>> have the same segfault with 3.2.0 suggests it is a related library
>> rather than dbmail.
>>
>> You can check to see which libraries are linked using ldd
>> /usr/local/sbin/dbmail-imapd
>>
>> I run my own poudriere build so can only confirm that my experience
>> with 3.2.1 is that it is the most stable release to date and have not
>> seen any segfaults.
>>
>> Regards,
>> Alan
>>
>> On 02/01/2015 15:09, Andrea Brancatelli wrote:
>>
>> We tried to switch to 3.2.0 on an older machine but it segfaults
>> the same...
>> Please, we need some help!
>>
>> -------
>>
>> *Andrea Brancatelli*
>>
>> Schema 31 S.p.a. Responsabile IT ROMA - FIRENZE - PALERMO ITALY
>> Tel: +39. 06.98.358.472 Cell: +39 331.2488468 Fax: +39.
>> 055.71.880.466 Società del Gruppo SC31 ITALIA
>>
>> Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli
>> (abrancatelli@schema31.it <mailto:abrancatelli@schema31.it>) ha
>> scritto:
>>
>>
>> Hello everybody.
>>
>> We recently upgraded from 3.1.17 to 3.2.1 on two different
>> machines and we're now facing continuous segmentation faults
>> both in dbmail-imapd and dbmail-lmtpd (on both machines).
>>
>> We don't have dbmail-pop3d active but I suppose that would be
>> crashing too :-)
>>
>> The machine is a FreeBSD 10.1, I suspect there's something
>> strange going on with libzdb. Last line in dbmail.err is
>> always the same when dbmail crashes:
>>
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0]
>> connection cleared
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_stmt_prepare(+477):
>> [0x80506f6f0] [SELECT MAX(message_idnr)+1 FROM
>> dbmail_messages WHERE mailbox_idnr=?]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_stmt_set_u64(+497):
>> [0x80516cd20] 1:[1142]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0]
>> connection to pool
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Debug:[MailboxState]
>> MailboxState_hasPermission(+973): checking ACL [read_flag]
>> for user [137] on mailbox [1142]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0]
>> connection from pool
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_stmt_prepare(+477):
>> [0x80506f6f0] [.SELECT * FROM dbmail_acl WHERE user_id = ? AND
>> mailbox_id = ?]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_stmt_set_u64(+497):
>> [0x80516cd20] 1:[137]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_stmt_set_u64(+497):
>> [0x80516cd20] 2:[1142]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0]
>> connection to pool
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Debug:[MailboxState]
>> MailboxState_hasPermission(+1007): mailbox [1142] is owned by
>> user [137]and no ACL in place. Giving all rights
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access
>> granted
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0]
>> connection from pool
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_stmt_prepare(+477):
>> [0x80506f6f0] [SELECT name,seq FROM dbmail_mailboxes WHERE
>> mailbox_idnr=?]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_stmt_set_u64(+497):
>> [0x80516cd20] 1:[1142]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878):
>> id: [1142] name: [Drafts] seq [11334]
>> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]:
>> [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0]
>> connection to pool
>>
>> There's no dbmail-imapd.core or anything.
>>
>> The chain is the usual one: stunnel -> dbmail -> mysql 5.6
>>
>> The machine is pretty busy but not super busy, after all it's
>> 29 dic.
>>
>> What can I look for?
>>
>> Thank you.
>>
>> -------
>> Andrea Brancatelli
>>
>>
>>
>> _______________________________________________
>> DBmail mailing list
>> DBmail@dbmail.org
>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
>>
>>
>> --
>> Persistent Objects Ltd
>> 128 Lilleshall Road
>> Morden SM4 6DR
>>
>> The Home of Lasting Solutions
>>
>> Mobile: +44 79 3030 5004
>> Tel: +44 20 8544 5292
>> Web: p-o.co.uk
>> Skype: alan-hicks-london
>> Personal bloghttps://plus.google.com/+AlanHicksLondon
>> Company bloghttps://plus.google.com/+PoCoUkLondon/posts
>> LinkedInhttps://uk.linkedin.com/in/alanhickslondon/
>> GitHubhttps://github.com/alan-hicks
>>
>> _______________________________________________
>> DBmail mailing list
>> DBmail@dbmail.org <mailto:DBmail@dbmail.org>
>> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: 079 3030 5004
Tel: 020 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon
Company blog https://plus.google.com/+PoCoUkLondon/posts
LinkedIn https://uk.linkedin.com/in/alanhickslondon/
GitHub https://github.com/alan-hicks

Yes, everything in on AMD64 and built with Clang...

FreeBSD is 10.1
---

Andrea Brancatelli
Schema31 S.p.a.

Il 2015-01-04 16:26 Alan Hicks ha scritto:

> Hello Andrea,
>
> Your libraries glib, gettext-runtime, mhash, libevent2, libzdb, libiconv, pcre, libffi and mysql56-client appear ok, the only difference is you have libc++, libcssrt and libgcc_s and I have ldap and postgresql. I assume everything is build using clang. Also I'm running ancient 32bit hardware.
>
> Do you have IPv6, I remember getting an error as the authlog table needed larger columns for src_ip and dst_ip when I started using IPv6.
>
> Other than that it may be an edge case with data in which case Paul is better able to help.
>
> Kind regards,
> Alan
>
> % ldd /usr/local/sbin/dbmail-imapd
> /usr/local/sbin/dbmail-imapd:
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x2808b000)
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x280af000)
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x280b2000)
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x28115000)
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x28252000)
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x28291000)
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x28293000)
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28387000)
> libm.so.5 => /lib/libm.so.5 (0x28390000)
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x283b6000)
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x283e4000)
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x283e6000)
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x28423000)
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x28435000)
> libldap_r-2.4.so.2 => /usr/local/lib/libldap_r-2.4.so.2 (0x284a9000)
> libthr.so.3 => /lib/libthr.so.3 (0x284f1000)
> libc.so.7 => /lib/libc.so.7 (0x28513000)
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x28686000)
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x2877a000)
> libz.so.6 => /lib/libz.so.6 (0x287ef000)
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x28803000)
> libpq.so.5 => /usr/local/lib/libpq.so.5 (0x28809000)
> libssl.so.7 => /usr/lib/libssl.so.7 (0x28830000)
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x2888c000)
> liblber-2.4.so.2 => /usr/local/lib/liblber-2.4.so.2 (0x28a1b000)
>
> On 03/01/2015 17:21, Andrea Brancatelli wrote:
>
> Hello Alan.
>
> We're using MySQL, not pgSQL. We have three different machines all exposing the same behavior. One of them (the main one) has DBMail compiled from ports against MySQL 5.6, and this is it's LDD:
>
> root@rubidio:/home/abrancatelli # ldd /usr/local/sbin/dbmail-imapd
>
> /usr/local/sbin/dbmail-imapd:
>
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)
>
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)
>
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)
>
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)
>
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)
>
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)
>
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)
>
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)
>
> libm.so.5 => /lib/libm.so.5 (0x801b83000)
>
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)
>
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x801fd3000)
>
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)
>
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)
>
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x80262a000)
>
> libthr.so.3 => /lib/libthr.so.3 (0x8028a0000)
>
> libc.so.7 => /lib/libc.so.7 (0x802ac5000)
>
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e5e000)
>
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x803157000)
>
> libz.so.6 => /lib/libz.so.6 (0x8033c4000)
>
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035d9000)
>
> libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x8037e0000)
>
> libssl.so.7 => /usr/lib/libssl.so.7 (0x803db9000)
>
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x804023000)
>
> libc++.so.1 => /usr/lib/libc++.so.1 (0x80440e000)
>
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8046c9000)
>
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8048e3000)
>
> The other two machines were it was segfaulting had DBMail installed from PKG against MySQL 5.5.We tried to upgrade those as well to 3.2.1 but the problem is still there. That's the LDD from these machines.
>
> root@sc31-mx-01:~ # ldd /usr/local/sbin/dbmail-imapd
>
> /usr/local/sbin/dbmail-imapd:
>
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)
>
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)
>
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)
>
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)
>
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)
>
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)
>
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)
>
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)
>
> libm.so.5 => /lib/libm.so.5 (0x801b83000)
>
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)
>
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x801fd3000)
>
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)
>
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)
>
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x802632000)
>
> libthr.so.3 => /lib/libthr.so.3 (0x8028a8000)
>
> libc.so.7 => /lib/libc.so.7 (0x802acd000)
>
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e76000)
>
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80316f000)
>
> libz.so.6 => /lib/libz.so.6 (0x8033dc000)
>
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035f1000)
>
> libpq.so.5 => /usr/local/lib/libpq.so.5 (0x8037f8000)
>
> libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x803a25000)
>
> libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x803d16000)
>
> libssl.so.7 => /usr/lib/libssl.so.7 (0x804283000)
>
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x8044ee000)
>
> libc++.so.1 => /usr/lib/libc++.so.1 (0x8048e1000)
>
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804b9c000)
>
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804db6000)
>
> I didn't read it but I suppose it to be pretty similar (the same?).
>
> BTW, if I can point my finger toward something external to dbmail, my guess would be gmime26-2.6.20.
>
> Thanks
>
> ---
>
> Andrea Brancatelli
> Schema31 S.p.a.
> Responsabile IT
>
> ROMA - FIRENZE - PALERMO
> ITALY
> Tel: +39. 06.98.358.472
> Cell: +39 331.2488468
> Fax: +39. 055.71.880.466
> Società del Gruppo SC31 ITALIA
>
> Il 2015-01-03 11:22 Alan Hicks ha scritto: Perhaps something else has changed?
>
> You might try rebuilding/reinstalling dependent libraries including zdb and the database libraries, I understand that PostgreSQL has recently been updated to 9.3 which may have had an affect. That you have the same segfault with 3.2.0 suggests it is a related library rather than dbmail.
>
> You can check to see which libraries are linked using ldd /usr/local/sbin/dbmail-imapd
>
> I run my own poudriere build so can only confirm that my experience with 3.2.1 is that it is the most stable release to date and have not seen any segfaults.
>
> Regards,
> Alan
>
> On 02/01/2015 15:09, Andrea Brancatelli wrote:
> We tried to switch to 3.2.0 on an older machine but it segfaults the same...
>
> Please, we need some help!
>
> -------
>
> ANDREA BRANCATELLI
> Schema 31 S.p.a. Responsabile IT ROMA - FIRENZE - PALERMO ITALY Tel: +39. 06.98.358.472 Cell: +39 331.2488468 Fax: +39. 055.71.880.466 Società del Gruppo SC31 ITALIA
>
> Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli (abrancatelli@schema31.it) ha scritto:
>
> Hello everybody.
>
> We recently upgraded from 3.1.17 to 3.2.1 on two different machines and we're now facing continuous segmentation faults both in dbmail-imapd and dbmail-lmtpd (on both machines).
>
> We don't have dbmail-pop3d active but I suppose that would be crashing too :-)
>
> The machine is a FreeBSD 10.1, I suspect there's something strange going on with libzdb. Last line in dbmail.err is always the same when dbmail crashes:
>
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0] connection cleared
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT MAX(message_idnr)+1 FROM dbmail_messages WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+973): checking ACL [read_flag] for user [137] on mailbox [1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [.SELECT * FROM dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[137]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 2:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+1007): mailbox [1142] is owned by user [137]and no ACL in place. Giving all rights
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access granted
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT name,seq FROM dbmail_mailboxes WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878): id: [1142] name: [Drafts] seq [11334]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
>
> There's no dbmail-imapd.core or anything.
>
> The chain is the usual one: stunnel -> dbmail -> mysql 5.6
>
> The machine is pretty busy but not super busy, after all it's 29 dic.
>
> What can I look for?
>
> Thank you.
>
> -------
> Andrea Brancatelli
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail [1]

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: +44 79 3030 5004
Tel: +44 20 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon [2]
Company blog https://plus.google.com/+PoCoUkLondon/posts [3]
LinkedIn https://uk.linkedin.com/in/alanhickslondon/ [4]
GitHub https://github.com/alan-hicks [5]

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

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: 079 3030 5004
Tel: 020 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon [2]
Company blog https://plus.google.com/+PoCoUkLondon/posts [3]
LinkedIn https://uk.linkedin.com/in/alanhickslondon/ [4]
GitHub https://github.com/alan-hicks [5]


Links:
------
[1] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
[2] https://plus.google.com/+AlanHicksLondon
[3] https://plus.google.com/+PoCoUkLondon/posts
[4] https://uk.linkedin.com/in/alanhickslondon/
[5] https://github.com/alan-hicks

P.S.:

Yes, I have IPV6 enabled and working. I'll take a look at the authlog
table and maybe just try to disable the authlog function.

---

Andrea Brancatelli
Schema31 S.p.a.
Responsabile IT

ROMA - FIRENZE - PALERMO
ITALY
Tel: +39. 06.98.358.472
Cell: +39 331.2488468
Fax: +39. 055.71.880.466
Società del Gruppo SC31 ITALIA

Il 2015-01-04 16:26 Alan Hicks ha scritto:

> Hello Andrea,
>
> Your libraries glib, gettext-runtime, mhash, libevent2, libzdb, libiconv, pcre, libffi and mysql56-client appear ok, the only difference is you have libc++, libcssrt and libgcc_s and I have ldap and postgresql. I assume everything is build using clang. Also I'm running ancient 32bit hardware.
>
> Do you have IPv6, I remember getting an error as the authlog table needed larger columns for src_ip and dst_ip when I started using IPv6.
>
> Other than that it may be an edge case with data in which case Paul is better able to help.
>
> Kind regards,
> Alan
>
> % ldd /usr/local/sbin/dbmail-imapd
> /usr/local/sbin/dbmail-imapd:
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x2808b000)
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x280af000)
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x280b2000)
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x28115000)
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x28252000)
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x28291000)
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x28293000)
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28387000)
> libm.so.5 => /lib/libm.so.5 (0x28390000)
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x283b6000)
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x283e4000)
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x283e6000)
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x28423000)
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x28435000)
> libldap_r-2.4.so.2 => /usr/local/lib/libldap_r-2.4.so.2 (0x284a9000)
> libthr.so.3 => /lib/libthr.so.3 (0x284f1000)
> libc.so.7 => /lib/libc.so.7 (0x28513000)
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x28686000)
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x2877a000)
> libz.so.6 => /lib/libz.so.6 (0x287ef000)
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x28803000)
> libpq.so.5 => /usr/local/lib/libpq.so.5 (0x28809000)
> libssl.so.7 => /usr/lib/libssl.so.7 (0x28830000)
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x2888c000)
> liblber-2.4.so.2 => /usr/local/lib/liblber-2.4.so.2 (0x28a1b000)
>
> On 03/01/2015 17:21, Andrea Brancatelli wrote:
>
> Hello Alan.
>
> We're using MySQL, not pgSQL. We have three different machines all exposing the same behavior. One of them (the main one) has DBMail compiled from ports against MySQL 5.6, and this is it's LDD:
>
> root@rubidio:/home/abrancatelli # ldd /usr/local/sbin/dbmail-imapd
>
> /usr/local/sbin/dbmail-imapd:
>
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)
>
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)
>
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)
>
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)
>
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)
>
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)
>
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)
>
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)
>
> libm.so.5 => /lib/libm.so.5 (0x801b83000)
>
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)
>
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x801fd3000)
>
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)
>
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)
>
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x80262a000)
>
> libthr.so.3 => /lib/libthr.so.3 (0x8028a0000)
>
> libc.so.7 => /lib/libc.so.7 (0x802ac5000)
>
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e5e000)
>
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x803157000)
>
> libz.so.6 => /lib/libz.so.6 (0x8033c4000)
>
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035d9000)
>
> libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x8037e0000)
>
> libssl.so.7 => /usr/lib/libssl.so.7 (0x803db9000)
>
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x804023000)
>
> libc++.so.1 => /usr/lib/libc++.so.1 (0x80440e000)
>
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8046c9000)
>
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8048e3000)
>
> The other two machines were it was segfaulting had DBMail installed from PKG against MySQL 5.5.We tried to upgrade those as well to 3.2.1 but the problem is still there. That's the LDD from these machines.
>
> root@sc31-mx-01:~ # ldd /usr/local/sbin/dbmail-imapd
>
> /usr/local/sbin/dbmail-imapd:
>
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)
>
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)
>
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)
>
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)
>
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)
>
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)
>
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)
>
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)
>
> libm.so.5 => /lib/libm.so.5 (0x801b83000)
>
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)
>
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x801fd3000)
>
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)
>
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)
>
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x802632000)
>
> libthr.so.3 => /lib/libthr.so.3 (0x8028a8000)
>
> libc.so.7 => /lib/libc.so.7 (0x802acd000)
>
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e76000)
>
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80316f000)
>
> libz.so.6 => /lib/libz.so.6 (0x8033dc000)
>
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035f1000)
>
> libpq.so.5 => /usr/local/lib/libpq.so.5 (0x8037f8000)
>
> libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x803a25000)
>
> libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x803d16000)
>
> libssl.so.7 => /usr/lib/libssl.so.7 (0x804283000)
>
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x8044ee000)
>
> libc++.so.1 => /usr/lib/libc++.so.1 (0x8048e1000)
>
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804b9c000)
>
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804db6000)
>
> I didn't read it but I suppose it to be pretty similar (the same?).
>
> BTW, if I can point my finger toward something external to dbmail, my guess would be gmime26-2.6.20.
>
> Thanks
>
> ---
>
> Andrea Brancatelli
> Schema31 S.p.a.
> Responsabile IT
>
> ROMA - FIRENZE - PALERMO
> ITALY
> Tel: +39. 06.98.358.472
> Cell: +39 331.2488468
> Fax: +39. 055.71.880.466
> Società del Gruppo SC31 ITALIA
>
> Il 2015-01-03 11:22 Alan Hicks ha scritto: Perhaps something else has changed?
>
> You might try rebuilding/reinstalling dependent libraries including zdb and the database libraries, I understand that PostgreSQL has recently been updated to 9.3 which may have had an affect. That you have the same segfault with 3.2.0 suggests it is a related library rather than dbmail.
>
> You can check to see which libraries are linked using ldd /usr/local/sbin/dbmail-imapd
>
> I run my own poudriere build so can only confirm that my experience with 3.2.1 is that it is the most stable release to date and have not seen any segfaults.
>
> Regards,
> Alan
>
> On 02/01/2015 15:09, Andrea Brancatelli wrote:
> We tried to switch to 3.2.0 on an older machine but it segfaults the same...
>
> Please, we need some help!
>
> -------
>
> ANDREA BRANCATELLI
> Schema 31 S.p.a. Responsabile IT ROMA - FIRENZE - PALERMO ITALY Tel: +39. 06.98.358.472 Cell: +39 331.2488468 Fax: +39. 055.71.880.466 Società del Gruppo SC31 ITALIA
>
> Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli (abrancatelli@schema31.it) ha scritto:
>
> Hello everybody.
>
> We recently upgraded from 3.1.17 to 3.2.1 on two different machines and we're now facing continuous segmentation faults both in dbmail-imapd and dbmail-lmtpd (on both machines).
>
> We don't have dbmail-pop3d active but I suppose that would be crashing too :-)
>
> The machine is a FreeBSD 10.1, I suspect there's something strange going on with libzdb. Last line in dbmail.err is always the same when dbmail crashes:
>
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0] connection cleared
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT MAX(message_idnr)+1 FROM dbmail_messages WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+973): checking ACL [read_flag] for user [137] on mailbox [1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [.SELECT * FROM dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[137]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 2:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+1007): mailbox [1142] is owned by user [137]and no ACL in place. Giving all rights
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access granted
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT name,seq FROM dbmail_mailboxes WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878): id: [1142] name: [Drafts] seq [11334]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
>
> There's no dbmail-imapd.core or anything.
>
> The chain is the usual one: stunnel -> dbmail -> mysql 5.6
>
> The machine is pretty busy but not super busy, after all it's 29 dic.
>
> What can I look for?
>
> Thank you.
>
> -------
> Andrea Brancatelli
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail [1]

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: +44 79 3030 5004
Tel: +44 20 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon [2]
Company blog https://plus.google.com/+PoCoUkLondon/posts [3]
LinkedIn https://uk.linkedin.com/in/alanhickslondon/ [4]
GitHub https://github.com/alan-hicks [5]

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

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: 079 3030 5004
Tel: 020 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon [2]
Company blog https://plus.google.com/+PoCoUkLondon/posts [3]
LinkedIn https://uk.linkedin.com/in/alanhickslondon/ [4]
GitHub https://github.com/alan-hicks [5]


Links:
------
[1] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
[2] https://plus.google.com/+AlanHicksLondon
[3] https://plus.google.com/+PoCoUkLondon/posts
[4] https://uk.linkedin.com/in/alanhickslondon/
[5] https://github.com/alan-hicks

You're right, src_ip and dst_ip are VARCHAR(16), that wouldn't work with
an IPV6 Address, but I don't know if this could cause a Segmentation
Fault.

I guess dbmail_authlog needs tuning anyhow.

---

Andrea Brancatelli
Schema31 S.p.a.
Responsabile IT

ROMA - FIRENZE - PALERMO
ITALY
Tel: +39. 06.98.358.472
Cell: +39 331.2488468
Fax: +39. 055.71.880.466
Società del Gruppo SC31 ITALIA

Il 2015-01-04 18:39 Andrea Brancatelli ha scritto:

> P.S.:
>
> Yes, I have IPV6 enabled and working. I'll take a look at the authlog table and maybe just try to disable the authlog function.
>
> ---
>
> Andrea Brancatelli
> Schema31 S.p.a.
> Responsabile IT
>
> ROMA - FIRENZE - PALERMO
> ITALY
> Tel: +39. 06.98.358.472
> Cell: +39 331.2488468
> Fax: +39. 055.71.880.466
> Società del Gruppo SC31 ITALIA
>
> Il 2015-01-04 16:26 Alan Hicks ha scritto: Hello Andrea,
>
> Your libraries glib, gettext-runtime, mhash, libevent2, libzdb, libiconv, pcre, libffi and mysql56-client appear ok, the only difference is you have libc++, libcssrt and libgcc_s and I have ldap and postgresql. I assume everything is build using clang. Also I'm running ancient 32bit hardware.
>
> Do you have IPv6, I remember getting an error as the authlog table needed larger columns for src_ip and dst_ip when I started using IPv6.
>
> Other than that it may be an edge case with data in which case Paul is better able to help.
>
> Kind regards,
> Alan
>
> % ldd /usr/local/sbin/dbmail-imapd
> /usr/local/sbin/dbmail-imapd:
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x2808b000)
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x280af000)
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x280b2000)
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x28115000)
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x28252000)
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x28291000)
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x28293000)
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28387000)
> libm.so.5 => /lib/libm.so.5 (0x28390000)
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x283b6000)
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x283e4000)
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x283e6000)
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x28423000)
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x28435000)
> libldap_r-2.4.so.2 => /usr/local/lib/libldap_r-2.4.so.2 (0x284a9000)
> libthr.so.3 => /lib/libthr.so.3 (0x284f1000)
> libc.so.7 => /lib/libc.so.7 (0x28513000)
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x28686000)
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x2877a000)
> libz.so.6 => /lib/libz.so.6 (0x287ef000)
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x28803000)
> libpq.so.5 => /usr/local/lib/libpq.so.5 (0x28809000)
> libssl.so.7 => /usr/lib/libssl.so.7 (0x28830000)
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x2888c000)
> liblber-2.4.so.2 => /usr/local/lib/liblber-2.4.so.2 (0x28a1b000)
>
> On 03/01/2015 17:21, Andrea Brancatelli wrote:
>
> Hello Alan.
>
> We're using MySQL, not pgSQL. We have three different machines all exposing the same behavior. One of them (the main one) has DBMail compiled from ports against MySQL 5.6, and this is it's LDD:
>
> root@rubidio:/home/abrancatelli # ldd /usr/local/sbin/dbmail-imapd
>
> /usr/local/sbin/dbmail-imapd:
>
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)
>
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)
>
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)
>
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)
>
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)
>
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)
>
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)
>
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)
>
> libm.so.5 => /lib/libm.so.5 (0x801b83000)
>
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)
>
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x801fd3000)
>
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)
>
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)
>
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x80262a000)
>
> libthr.so.3 => /lib/libthr.so.3 (0x8028a0000)
>
> libc.so.7 => /lib/libc.so.7 (0x802ac5000)
>
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e5e000)
>
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x803157000)
>
> libz.so.6 => /lib/libz.so.6 (0x8033c4000)
>
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035d9000)
>
> libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x8037e0000)
>
> libssl.so.7 => /usr/lib/libssl.so.7 (0x803db9000)
>
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x804023000)
>
> libc++.so.1 => /usr/lib/libc++.so.1 (0x80440e000)
>
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8046c9000)
>
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8048e3000)
>
> The other two machines were it was segfaulting had DBMail installed from PKG against MySQL 5.5.We tried to upgrade those as well to 3.2.1 but the problem is still there. That's the LDD from these machines.
>
> root@sc31-mx-01:~ # ldd /usr/local/sbin/dbmail-imapd
>
> /usr/local/sbin/dbmail-imapd:
>
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)
>
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)
>
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)
>
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)
>
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)
>
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)
>
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)
>
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)
>
> libm.so.5 => /lib/libm.so.5 (0x801b83000)
>
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)
>
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x801fd3000)
>
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)
>
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)
>
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x802632000)
>
> libthr.so.3 => /lib/libthr.so.3 (0x8028a8000)
>
> libc.so.7 => /lib/libc.so.7 (0x802acd000)
>
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e76000)
>
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80316f000)
>
> libz.so.6 => /lib/libz.so.6 (0x8033dc000)
>
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035f1000)
>
> libpq.so.5 => /usr/local/lib/libpq.so.5 (0x8037f8000)
>
> libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x803a25000)
>
> libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x803d16000)
>
> libssl.so.7 => /usr/lib/libssl.so.7 (0x804283000)
>
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x8044ee000)
>
> libc++.so.1 => /usr/lib/libc++.so.1 (0x8048e1000)
>
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804b9c000)
>
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804db6000)
>
> I didn't read it but I suppose it to be pretty similar (the same?).
>
> BTW, if I can point my finger toward something external to dbmail, my guess would be gmime26-2.6.20.
>
> Thanks
>
> ---
>
> Andrea Brancatelli
> Schema31 S.p.a.
> Responsabile IT
>
> ROMA - FIRENZE - PALERMO
> ITALY
> Tel: +39. 06.98.358.472
> Cell: +39 331.2488468
> Fax: +39. 055.71.880.466
> Società del Gruppo SC31 ITALIA
>
> Il 2015-01-03 11:22 Alan Hicks ha scritto: Perhaps something else has changed?
>
> You might try rebuilding/reinstalling dependent libraries including zdb and the database libraries, I understand that PostgreSQL has recently been updated to 9.3 which may have had an affect. That you have the same segfault with 3.2.0 suggests it is a related library rather than dbmail.
>
> You can check to see which libraries are linked using ldd /usr/local/sbin/dbmail-imapd
>
> I run my own poudriere build so can only confirm that my experience with 3.2.1 is that it is the most stable release to date and have not seen any segfaults.
>
> Regards,
> Alan
>
> On 02/01/2015 15:09, Andrea Brancatelli wrote:
> We tried to switch to 3.2.0 on an older machine but it segfaults the same...
>
> Please, we need some help!
>
> -------
>
> ANDREA BRANCATELLI
> Schema 31 S.p.a. Responsabile IT ROMA - FIRENZE - PALERMO ITALY Tel: +39. 06.98.358.472 Cell: +39 331.2488468 Fax: +39. 055.71.880.466 Società del Gruppo SC31 ITALIA
>
> Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli (abrancatelli@schema31.it) ha scritto:
>
> Hello everybody.
>
> We recently upgraded from 3.1.17 to 3.2.1 on two different machines and we're now facing continuous segmentation faults both in dbmail-imapd and dbmail-lmtpd (on both machines).
>
> We don't have dbmail-pop3d active but I suppose that would be crashing too :-)
>
> The machine is a FreeBSD 10.1, I suspect there's something strange going on with libzdb. Last line in dbmail.err is always the same when dbmail crashes:
>
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0] connection cleared
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT MAX(message_idnr)+1 FROM dbmail_messages WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+973): checking ACL [read_flag] for user [137] on mailbox [1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [.SELECT * FROM dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[137]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 2:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+1007): mailbox [1142] is owned by user [137]and no ACL in place. Giving all rights
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access granted
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT name,seq FROM dbmail_mailboxes WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878): id: [1142] name: [Drafts] seq [11334]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
>
> There's no dbmail-imapd.core or anything.
>
> The chain is the usual one: stunnel -> dbmail -> mysql 5.6
>
> The machine is pretty busy but not super busy, after all it's 29 dic.
>
> What can I look for?
>
> Thank you.
>
> -------
> Andrea Brancatelli
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail [1]

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: +44 79 3030 5004
Tel: +44 20 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon [2]
Company blog https://plus.google.com/+PoCoUkLondon/posts [3]
LinkedIn https://uk.linkedin.com/in/alanhickslondon/ [4]
GitHub https://github.com/alan-hicks [5]

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

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: 079 3030 5004
Tel: 020 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon [2]
Company blog https://plus.google.com/+PoCoUkLondon/posts [3]
LinkedIn https://uk.linkedin.com/in/alanhickslondon/ [4]
GitHub https://github.com/alan-hicks [5]

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



Links:
------
[1] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
[2] https://plus.google.com/+AlanHicksLondon
[3] https://plus.google.com/+PoCoUkLondon/posts
[4] https://uk.linkedin.com/in/alanhickslondon/
[5] https://github.com/alan-hicks

I enlarged the column to VARCHAR(255) and tried a IPV6 connection and
didn't seem to cause any problem, apart from the ip in the "dst_ip"
being reported wrong.

It says: 2001:470:28:12b:1000:: instead of 2001:470:28:12b::27

Also the source IP is wrong, it says 2001:470:28:12b:1000:0:1c1c:6e
instead of 2001:470:27:12b::2

---

Andrea Brancatelli
Schema31 S.p.a.
Responsabile IT

ROMA - FIRENZE - PALERMO
ITALY
Tel: +39. 06.98.358.472
Cell: +39 331.2488468
Fax: +39. 055.71.880.466
Società del Gruppo SC31 ITALIA

Il 2015-01-04 18:42 Andrea Brancatelli ha scritto:

> You're right, src_ip and dst_ip are VARCHAR(16), that wouldn't work with an IPV6 Address, but I don't know if this could cause a Segmentation Fault.
>
> I guess dbmail_authlog needs tuning anyhow.
>
> ---
>
> Andrea Brancatelli
> Schema31 S.p.a.
> Responsabile IT
>
> ROMA - FIRENZE - PALERMO
> ITALY
> Tel: +39. 06.98.358.472
> Cell: +39 331.2488468
> Fax: +39. 055.71.880.466
> Società del Gruppo SC31 ITALIA
>
> Il 2015-01-04 18:39 Andrea Brancatelli ha scritto:
>
> P.S.:
>
> Yes, I have IPV6 enabled and working. I'll take a look at the authlog table and maybe just try to disable the authlog function.
>
> ---
>
> Andrea Brancatelli
> Schema31 S.p.a.
> Responsabile IT
>
> ROMA - FIRENZE - PALERMO
> ITALY
> Tel: +39. 06.98.358.472
> Cell: +39 331.2488468
> Fax: +39. 055.71.880.466
> Società del Gruppo SC31 ITALIA
>
> Il 2015-01-04 16:26 Alan Hicks ha scritto: Hello Andrea,
>
> Your libraries glib, gettext-runtime, mhash, libevent2, libzdb, libiconv, pcre, libffi and mysql56-client appear ok, the only difference is you have libc++, libcssrt and libgcc_s and I have ldap and postgresql. I assume everything is build using clang. Also I'm running ancient 32bit hardware.
>
> Do you have IPv6, I remember getting an error as the authlog table needed larger columns for src_ip and dst_ip when I started using IPv6.
>
> Other than that it may be an edge case with data in which case Paul is better able to help.
>
> Kind regards,
> Alan
>
> % ldd /usr/local/sbin/dbmail-imapd
> /usr/local/sbin/dbmail-imapd:
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x2808b000)
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x280af000)
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x280b2000)
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x28115000)
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x28252000)
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x28291000)
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x28293000)
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28387000)
> libm.so.5 => /lib/libm.so.5 (0x28390000)
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x283b6000)
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x283e4000)
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x283e6000)
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x28423000)
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x28435000)
> libldap_r-2.4.so.2 => /usr/local/lib/libldap_r-2.4.so.2 (0x284a9000)
> libthr.so.3 => /lib/libthr.so.3 (0x284f1000)
> libc.so.7 => /lib/libc.so.7 (0x28513000)
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x28686000)
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x2877a000)
> libz.so.6 => /lib/libz.so.6 (0x287ef000)
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x28803000)
> libpq.so.5 => /usr/local/lib/libpq.so.5 (0x28809000)
> libssl.so.7 => /usr/lib/libssl.so.7 (0x28830000)
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x2888c000)
> liblber-2.4.so.2 => /usr/local/lib/liblber-2.4.so.2 (0x28a1b000)
>
> On 03/01/2015 17:21, Andrea Brancatelli wrote:
>
> Hello Alan.
>
> We're using MySQL, not pgSQL. We have three different machines all exposing the same behavior. One of them (the main one) has DBMail compiled from ports against MySQL 5.6, and this is it's LDD:
>
> root@rubidio:/home/abrancatelli # ldd /usr/local/sbin/dbmail-imapd
>
> /usr/local/sbin/dbmail-imapd:
>
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)
>
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)
>
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)
>
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)
>
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)
>
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)
>
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)
>
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)
>
> libm.so.5 => /lib/libm.so.5 (0x801b83000)
>
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)
>
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x801fd3000)
>
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)
>
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)
>
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x80262a000)
>
> libthr.so.3 => /lib/libthr.so.3 (0x8028a0000)
>
> libc.so.7 => /lib/libc.so.7 (0x802ac5000)
>
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e5e000)
>
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x803157000)
>
> libz.so.6 => /lib/libz.so.6 (0x8033c4000)
>
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035d9000)
>
> libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x8037e0000)
>
> libssl.so.7 => /usr/lib/libssl.so.7 (0x803db9000)
>
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x804023000)
>
> libc++.so.1 => /usr/lib/libc++.so.1 (0x80440e000)
>
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8046c9000)
>
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8048e3000)
>
> The other two machines were it was segfaulting had DBMail installed from PKG against MySQL 5.5.We tried to upgrade those as well to 3.2.1 but the problem is still there. That's the LDD from these machines.
>
> root@sc31-mx-01:~ # ldd /usr/local/sbin/dbmail-imapd
>
> /usr/local/sbin/dbmail-imapd:
>
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800835000)
>
> libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x800a55000)
>
> libgmime-2.6.so.0 => /usr/local/lib/libgmime-2.6.so.0 (0x800c58000)
>
> libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x800ec7000)
>
> libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80122b000)
>
> libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x801473000)
>
> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801674000)
>
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801979000)
>
> libm.so.5 => /lib/libm.so.5 (0x801b83000)
>
> libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x801da9000)
>
> libevent_pthreads-2.0.so.5 => /usr/local/lib/libevent_pthreads-2.0.so.5 (0x801fd3000)
>
> libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8021d5000)
>
> libzdb.so.11 => /usr/local/lib/libzdb.so.11 (0x802416000)
>
> libdbmail.so.0 => /usr/local/lib/dbmail/libdbmail.so.0 (0x802632000)
>
> libthr.so.3 => /lib/libthr.so.3 (0x8028a8000)
>
> libc.so.7 => /lib/libc.so.7 (0x802acd000)
>
> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x802e76000)
>
> libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80316f000)
>
> libz.so.6 => /lib/libz.so.6 (0x8033dc000)
>
> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x8035f1000)
>
> libpq.so.5 => /usr/local/lib/libpq.so.5 (0x8037f8000)
>
> libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x803a25000)
>
> libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x803d16000)
>
> libssl.so.7 => /usr/lib/libssl.so.7 (0x804283000)
>
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x8044ee000)
>
> libc++.so.1 => /usr/lib/libc++.so.1 (0x8048e1000)
>
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804b9c000)
>
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x804db6000)
>
> I didn't read it but I suppose it to be pretty similar (the same?).
>
> BTW, if I can point my finger toward something external to dbmail, my guess would be gmime26-2.6.20.
>
> Thanks
>
> ---
>
> Andrea Brancatelli
> Schema31 S.p.a.
> Responsabile IT
>
> ROMA - FIRENZE - PALERMO
> ITALY
> Tel: +39. 06.98.358.472
> Cell: +39 331.2488468
> Fax: +39. 055.71.880.466
> Società del Gruppo SC31 ITALIA
>
> Il 2015-01-03 11:22 Alan Hicks ha scritto: Perhaps something else has changed?
>
> You might try rebuilding/reinstalling dependent libraries including zdb and the database libraries, I understand that PostgreSQL has recently been updated to 9.3 which may have had an affect. That you have the same segfault with 3.2.0 suggests it is a related library rather than dbmail.
>
> You can check to see which libraries are linked using ldd /usr/local/sbin/dbmail-imapd
>
> I run my own poudriere build so can only confirm that my experience with 3.2.1 is that it is the most stable release to date and have not seen any segfaults.
>
> Regards,
> Alan
>
> On 02/01/2015 15:09, Andrea Brancatelli wrote:
> We tried to switch to 3.2.0 on an older machine but it segfaults the same...
>
> Please, we need some help!
>
> -------
>
> ANDREA BRANCATELLI
> Schema 31 S.p.a. Responsabile IT ROMA - FIRENZE - PALERMO ITALY Tel: +39. 06.98.358.472 Cell: +39 331.2488468 Fax: +39. 055.71.880.466 Società del Gruppo SC31 ITALIA
>
> Il giorno 29 dicembre 2014 @ 10:35:54, Andrea Brancatelli (abrancatelli@schema31.it) ha scritto:
>
> Hello everybody.
>
> We recently upgraded from 3.1.17 to 3.2.1 on two different machines and we're now facing continuous segmentation faults both in dbmail-imapd and dbmail-lmtpd (on both machines).
>
> We don't have dbmail-pop3d active but I suppose that would be crashing too :-)
>
> The machine is a FreeBSD 10.1, I suspect there's something strange going on with libzdb. Last line in dbmail.err is always the same when dbmail crashes:
>
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_clear(+349): [0x80506f6f0] connection cleared
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT MAX(message_idnr)+1 FROM dbmail_messages WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_commit_transaction(+606): COMMIT
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+973): checking ACL [read_flag] for user [137] on mailbox [1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [.SELECT * FROM dbmail_acl WHERE user_id = ? AND mailbox_id = ?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[137]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 2:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] MailboxState_hasPermission(+1007): mailbox [1142] is owned by user [137]and no ACL in place. Giving all rights
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[imap] mailbox_check_acl(+369): access granted
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_get(+314): [0x80506f6f0] connection from pool
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_prepare(+477): [0x80506f6f0] [SELECT name,seq FROM dbmail_mailboxes WHERE mailbox_idnr=?]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_stmt_set_u64(+497): [0x80516cd20] 1:[1142]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Debug:[MailboxState] db_getmailbox_seq(+878): id: [1142] name: [Drafts] seq [11334]
> Dec 29 10:30:30 rubidio.roma.sc dbmail-imapd[49852]: [0x80500a540] Database:[db] db_con_close(+342): [0x80506f6f0] connection to pool
>
> There's no dbmail-imapd.core or anything.
>
> The chain is the usual one: stunnel -> dbmail -> mysql 5.6
>
> The machine is pretty busy but not super busy, after all it's 29 dic.
>
> What can I look for?
>
> Thank you.
>
> -------
> Andrea Brancatelli
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail [1]

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: +44 79 3030 5004
Tel: +44 20 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon [2]
Company blog https://plus.google.com/+PoCoUkLondon/posts [3]
LinkedIn https://uk.linkedin.com/in/alanhickslondon/ [4]
GitHub https://github.com/alan-hicks [5]

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

--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: 079 3030 5004
Tel: 020 8544 5292
Web: p-o.co.uk
Skype: alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon [2]
Company blog https://plus.google.com/+PoCoUkLondon/posts [3]
LinkedIn https://uk.linkedin.com/in/alanhickslondon/ [4]
GitHub https://github.com/alan-hicks [5]

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

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



Links:
------
[1] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
[2] https://plus.google.com/+AlanHicksLondon
[3] https://plus.google.com/+PoCoUkLondon/posts
[4] https://uk.linkedin.com/in/alanhickslondon/
[5] https://github.com/alan-hicks