RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 885620 - imapd segfaults while stripping attachment using Horde 4/IMP 5 application
Summary: imapd segfaults while stripping attachment using Horde 4/IMP 5 application
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cyrus-imapd
Version: 6.3
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Pavel Šimerda (pavlix)
QA Contact: Radka Brychtova
URL:
Whiteboard:
Depends On:
Blocks: 1356054 1359261
TreeView+ depends on / blocked
 
Reported: 2012-12-10 09:02 UTC by Anant
Modified: 2017-03-21 11:24 UTC (History)
5 users (show)

Fixed In Version: cyrus-imapd-2.3.16-14.el6
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-21 11:24:35 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Coredump file after crash (179.36 KB, application/x-gzip)
2012-12-15 05:02 UTC, Anant
no flags Details
Messages file extract for the crash (151 bytes, application/octet-stream)
2012-12-15 05:03 UTC, Anant
no flags Details
mailog extract for the same crash (2.69 KB, application/octet-stream)
2012-12-15 05:04 UTC, Anant
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0742 0 normal SHIPPED_LIVE cyrus-imapd bug fix update 2017-03-21 12:44:41 UTC

Description Anant 2012-12-10 09:02:10 UTC
Description of problem:
We use Horde 4/IMP 5 application developed horde team.  (http://www.horde.org). When we use option strip an attachment from mail, imapd segfaults and I get abrt crash report.


Version-Release number of selected component (if applicable):
RHEL 6.3 cyrus-imapd-2.3.16-6.el6-2.5.x86_64


How reproducible:
Everytime I use option strip attachment from application. Currently I use php-5.3.3-3.el6-2.8.x86_64 for this application.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Attached file gets deleted and new mail gets created without attachment and original mail remains as it is.

Expected results:
Attached file gets deleted and new mail gets created without attachment.  but, original mail does not get deleted.


Additional info:

http://lists.horde.org/archives/imp/Week-of-Mon-20121203/054278.html
http://lists.horde.org/archives/imp/Week-of-Mon-20121203/054291.html

Comment 3 Michal Hlavinka 2012-12-14 11:46:56 UTC
Could you obtain core file and attach it to this bug (gziped) ?
Thanks

Comment 4 Anant 2012-12-15 05:02:48 UTC
Created attachment 663892 [details]
Coredump file after crash

As requested attaching the core file.

Comment 5 Anant 2012-12-15 05:03:27 UTC
Created attachment 663893 [details]
Messages file extract for the crash

Comment 6 Anant 2012-12-15 05:04:02 UTC
Created attachment 663894 [details]
mailog extract for the same crash

Comment 7 Michal Hlavinka 2012-12-18 17:08:17 UTC
Please try this package:
http://mhlavink.fedorapeople.org/bz885620/
It could fix this issue and if not, it has some extra assert checks. So if it does not work, attach new core file (no need for logs). Thanks

Comment 8 Anant 2012-12-19 06:27:44 UTC
(In reply to comment #7)
> Please try this package:
> http://mhlavink.fedorapeople.org/bz885620/
> It could fix this issue and if not, it has some extra assert checks. So if
> it does not work, attach new core file (no need for logs). Thanks

1. The server is in production.
2. Our earlier version of Horde 3/IMP 4 has no problems with the current version of Cyrus-imapd, problem comes when we use with Horde 4/IMP 5.


Please let me know,

If I upgrade the cyrus-imap, will it stop and restart cyrus-imapd?  In that case, I need to take some downtime.  Please let me know, possible impacts.

Regards,
Anant.

Comment 9 Michal Hlavinka 2012-12-19 11:46:22 UTC
Yes, every time you update some daemon, it's restarted. Despite the probability is extremely low, changes in that packages can have negative side effects. So it'd be better to test it in test environment, not the production one, if it's possible.

The best option would be to install cyrus-imapd (original version) on different machine, copy mail archive and try to reproduce. Then update to new packages and try to reproduce again.

If you don't know how to reproduce this, you can enable IMAP raw log for some affected user:
mkdir /var/lib/imap/log/<username>
chown cyrus /var/lib/imap/log/<username>

this will enable imap logging (only) for <username>

after problem shows again, log file should contain IMAP communication. 
You can try to reproduce the problem by sending the IMAP commands from the log using netcat, that way you should be able to reproduce it without the need of  setting up the horde webmail.

Comment 10 Anant 2012-12-20 06:28:06 UTC
OK. I will try.  Need some time to setup another machine for testing purpose.

-Anant.

Comment 11 Anant 2012-12-26 04:50:34 UTC
Yesterday, I setup a new server with RHEL 6.3.  Copied few mailboxes (copied /var/spool/imap/user/x and y) and created respective mailboxes (cm user.x and cm.user.y) and reconstrctured those mailboxes.  Tried to strip the attachments.  I am not facing any problem.  i.e. I am unable to reproduce the problem.

One more thing, I will try before giving up is "disable logging" and try. ie. removing the /var/lib/imap/log/<username> directory.  Becuase, this seems to be now the only difference.

BTW, let me give a history.

Earlier our cyrus was running on RHEL 5.3 having cyrus-imapd-2.3.7-2.el5 with EMC storage.  /var/lib/imap was on local OS disk, whereas /var/spool/imap came from EMC storage (as FC disk).

We migrated to RHEL 6.3 having cyrus-imapd-2.3.16-6.el6-2.5 with NetApp Storage. Here both /var/lib/imap and /var/spool/imap come from NetApp Storage (as FC disk).
I did follow the steps writeen in README.HOWTO-recover-mailboxes.db, so that all mailboxes are recreated.  This I did, since, it was mentioned in cyrus documentation (Upgrading from Previous Versions) that, Upgrading from 2.3.3 or later, Due to byte alignment issues in cyrus.index, all mailboxes will have to be reconstructed.

After this, I released it to the users. Same old Horde version is working fine, but in new version, I am getting problem.

But, right now, I am unable to reproduce it on another RHEL 6.3 server with local disk based cyrus-imap folders.

Any other hints to reproduce the problem?

Regards,
Anant.

Comment 12 Anant 2013-01-02 11:06:55 UTC
Now, I am able to reproduce the problem on another server using NetApp storage.  So, if I use local disk, problem does not come, where as, if I use NetApp OnTap 8.1 FC disk, the problem is seen.

I am yet to apply the rpm's given.  I will wait for a day, since, I have reported the same in cyrus-info mailing list under this thread

http://asg.andrew.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&msg=54436

Regards,
anant.

Comment 14 Anant 2013-01-03 07:06:35 UTC
As I am not any response on other mailing list, I decided to ahead with rpms provided.  Today, I upgraded to those rpms on a test system.  Though, there is no coredump, but, functionality is not working.  i.e. stripping attachment does not work. 

Following is the log entry.

Jan  3 10:40:09 imapserver imap[11495]: Fatal error: Internal error: assertion failed: mailbox.c: 1499: !message_guid_isnull(&record->guid)
Jan  3 10:40:09 imapserver master[11487]: process 11495 exited, status 75
Jan  3 10:40:09 imapserver master[11487]: service imap pid 11495 in BUSY state: terminated abnormally

-anant.

Comment 15 Michal Hlavinka 2013-01-08 13:08:46 UTC
This assert error looks like cyrus-imapd bug:
https://bugzilla.cyrusimap.org/show_bug.cgi?id=3754

I'll backport that fix and prepare new test package.

Comment 16 Michal Hlavinka 2013-01-08 17:31:02 UTC
New test packages can be found here:
http://mhlavink.fedorapeople.org/bz885620/

Comment 17 Anant 2013-01-10 07:08:46 UTC
I installed the new test packages.  Now, rpm -qa shows

rpm -qa |grep cyrus-imap
cyrus-imapd-debuginfo-2.3.16-10.el6.0.bz885620.1.x86_64
cyrus-imapd-devel-2.3.16-10.el6.0.bz885620.1.x86_64
cyrus-imapd-2.3.16-10.el6.0.bz885620.1.x86_64
cyrus-imapd-utils-2.3.16-10.el6.0.bz885620.1.x86_64


But, I see the same error as I saw in the previous fix.

Jan 10 12:14:19 imapserver imap[30530]: open: user asa opened INBOX
Jan 10 12:14:19 imapserver imap[30530]: Fatal error: Internal error: assertion failed: mailbox.c: 1499: !message_guid_isnull(&record->guid)
Jan 10 12:14:19 imapserver master[30526]: process 30530 exited, status 75
Jan 10 12:14:19 imapserver master[30526]: service imap pid 30530 in BUSY state: terminated abnormally

OK. Apart from this,

I have also tried the following

1. Compiled latest version of Cyrus-IMAPD 2.4.17 and found it working without any issue.
2. Used the src.rpm provided at invoca.ch and used rebuild and tested.  stripping attachment works fine.

I just thought to share this inputs with you.

BTW, are there no 2.4 versions of RPM with RHEL 6?

Regards,
Anant.

Comment 18 Anant 2013-01-18 11:15:31 UTC
Any updates for this from RedHat Team?  I am unable to release the new version due to this problem.  I request you to provide support as I still believe that, RPMs provided by RHEL will be very stable.

-anant.

Comment 19 Michal Hlavinka 2013-01-18 14:55:17 UTC
I don't see obvious reason why it fails now. Could you get core file for this new test package? Also, the best solution would be if you could prepare reproducer for this - configuration needed on fresh installation and some crashing mailbox.

(In reply to comment #18)
> I request you to provide support as ...

Beware, that bugzilla is bug tracking tool, nothing more. For support you should open support case at https://access.redhat.com/home
Support case has bigger priority and guaranteed response time, which bugzilla has not.

Comment 20 Anant 2013-01-21 05:30:48 UTC
There is no CORE file getting generated.  Only error is seen in the log.

Comment 21 Michal Hlavinka 2013-01-30 12:35:06 UTC
Were you able to create reproducer for this?

Comment 22 Anant 2013-01-31 04:59:01 UTC
I am always able to reproduce.  What I can definitely say is, if the disk used for IMAP is on local disk, no problems.  If the disk used for IMAP is from SAN, it is a problem.  Using NetApp SAN.

Comment 23 RHEL Program Management 2013-10-14 00:10:58 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 33 Radka Brychtova 2017-01-02 09:22:40 UTC
As I was not able to reproduce this bug, I did just Sanity testing.

Comment 35 errata-xmlrpc 2017-03-21 11:24:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0742.html


Note You need to log in before you can comment on or make changes to this bug.