Bug 123022 - dovecot segfaults w/maildir
Summary: dovecot segfaults w/maildir
Alias: None
Product: Fedora
Classification: Fedora
Component: dovecot
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John Dennis
QA Contact:
Depends On:
Blocks: FC2Update
TreeView+ depends on / blocked
Reported: 2004-05-11 13:28 UTC by Neal Becker
Modified: 2014-01-21 22:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-01-05 19:55:11 UTC

Attachments (Terms of Use)
Last 1000 lines of strace output (47.53 KB, text/plain)
2004-05-26 09:41 UTC, David Woodhouse
no flags Details

Description Neal Becker 2004-05-11 13:28:16 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)

Description of problem:
Latest dovecot is totally broken.  Segfaults.

Went back to dovecot-, and it's OK.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.run kmail

Additional info:

Comment 1 Warren Togami 2004-05-19 10:44:30 UTC
dovecot- added these three patches.

User claims that this caused his dovecot to crash.  User supplies
dovecot.conf file.

I supplied test dovecot packages that disabled this the maildir patch

User confirms that my test packages with maildir patch disabled
prevents the crash on his server.  User has not sent any more
debugging information.

So if the user's reports are accurate, the maildir patch causes a rare
corner case segfault in dovecot, perhaps only triggerable from kmail
with certain message contents within the maildir.

Can the user supply a compressed maildir that reproduces this issue? 
Without the ability to reproduce the issue, or other debug information
like gdb backtraces, it is highly unlikely we will be able to solve
the user's problem.  Since nobody else has complained and maildir
works for me, I will not revert the patch in -4 unless the user
responsibly proves that this is a reproducible problem, with a
distributable test-case.

Comment 2 Neal Becker 2004-05-19 14:36:42 UTC
I'd love to help, but I can't do that.  This mail would include 
confidential information. 
I am quite sure that dovecot crashed every time with this patch, that 
the previous version did not crash, and that the reverted patch 
version is still working right now. 
If it makes you feel better, I have 20+ years experience in unix 
programming and open source software. 

Comment 3 Warren Togami 2004-05-19 19:22:35 UTC
Can you create a NEW maildir that contains test mail that reproduces
this crash with -4 version?   Either that or copy your maildir into
another user account on a test server, and delete messages until you
isolate a single message that causes this?

I appreciate that you filed the report, but there is possibly no way
we can fix this without your debugging information.

Comment 4 David Woodhouse 2004-05-26 09:41:03 UTC
I can reproduce it on my linux-kernel mailing list folder.
Not private, but not small either.

I had a mail outage recently and I have the distinct impression that
it was happening a lot more while the queue from the MX backup machine
was being flushed.... could it be related to a race with mail delivery?

Will attach the last 1000 lines of strace output last time it died,
and try to catch it in gdb next time. 

Comment 5 David Woodhouse 2004-05-26 09:41:44 UTC
Created attachment 100569 [details]
Last 1000 lines of strace output

Comment 6 David Woodhouse 2004-05-26 11:10:53 UTC
Well I've attached to it but I'm not sure I'm going to get anything
useful when it crashes.... 

(I see the same if I run 'gdb
/usr/lib/debug/usr/libexec/dovecot/imap.debug 8536' too)

Attaching to program: /usr/libexec/dovecot/imap, process 8536
Error while mapping shared library sections:
: Success.
Error while reading shared library symbols:
: No such file or directory.
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x00464402 in ?? ()

Comment 7 David Woodhouse 2004-05-27 13:27:02 UTC
Program received signal SIGSEGV, Segmentation fault.
maildir_hash (p=0xf57ac710) at maildir-sync.c:254
254             while (*s != ':' && *s != '\0') {
(gdb) p/x s
$1 = 0xf57ac710
(gdb) bt
#0  maildir_hash (p=0xf57ac710) at maildir-sync.c:254
#1  0x08087f68 in hash_lookup (table=0x92c21e8, key=0xf57ac710) at
#2  0x08060602 in maildir_index_sync_readonly (index=0x92c21e8,
fname=0x92c21e8 "@�\t\bP\026,\t",
    found=0xfef1cbc8) at maildir-sync.c:1356
#3  0x0805e436 in maildir_open_mail (index=0x92c2298, rec=0xf589a108,
    deleted=0xfef1cc74) at maildir-open.c:72
#4  0x0806bd6a in index_mail_next (mail=0x92c155c, rec=0x1) at
#5  0x0806a813 in index_storage_fetch_next (ctx=0x92c1550) at
#6  0x08055e1c in imap_fetch (client=0x92bab40, fetch_data=53,
    bodies=0x92b20e8, messageset=0x92c21e8 "@�\t\bP\026,\t",
uidset=153887208) at imap-fetch.c:285
#7  0x0805245a in cmd_fetch (client=0x92bab40) at cmd-fetch.c:351
#8  0x08054170 in cmd_uid (client=0x92bab40) at cmd-uid.c:19
#9  0x08054959 in client_handle_input (client=0x92bab40) at client.c:314
#10 0x080549e8 in _client_input (context=0x92bab40) at client.c:350
#11 0x0808adc8 in io_loop_handler_run (ioloop=0x92ba1c0) at
#12 0x0808a758 in io_loop_run (ioloop=0x92ba1c0) at ioloop.c:258
#13 0x0805aa19 in main (argc=1, argv=0x92c21e8, envp=0x92c21e8) at

Comment 8 David Woodhouse 2004-05-27 13:53:26 UTC
This is happening for me with Evolution. Changing summary.

Looks like severe memory corruption...

(gdb) up 2
#2  0x08060602 in maildir_index_sync_readonly (index=0x92c21e8,
fname=0x92c21e8 "@�\t\bP\026,\t",
    found=0xfef1cbc8) at maildir-sync.c:1356
1356                    hash_rec = hash_lookup(ctx->files, fname);
(gdb) p *index
$2 = {open = 0x809ab40 <static_system_pool>, free = 0x92c1650,
set_lock = 0, try_lock = 0x6d,
  set_lock_notify_callback = 0x1, rebuild = 0, fsck = 0x6d,
sync_and_lock = 0x92c6230,
  get_header = 0xf4a67868, lookup = 0x805e5d0 <maildir_hash>, next =
0x805e630 <maildir_cmp>,
  lookup_uid_range = 0x21, lookup_field = 0x92c1448, lookup_field_raw
= 0x63b7e0 <main_arena+96>,
  cache_fields_later = 0x692e2f76, open_mail = 0x2e70616d,
get_internal_date = 0x65646e69,
  expunge = 0x6f6c2e78, update_flags = 0x20, append_begin = 0x38,
append_end = 0x6d6f682f,
  append_abort = 0x77642f65, update_begin = 0x2f32776d, update_end =
  update_abort = 0x2f726964, update_field = 0x73696c2e,
update_field_raw = 0x6d2e7374,
  get_last_error = 0x2f6b3836, get_last_error_text = 0x616d692e, data
= 0x6e692e70,
  tree = 0x2e786564, modifylog = 0x65657274, custom_flags = 0x0,
  dir = 0x29 <Address 0x29 out of bounds>,
  filepath = 0x92c2aa0
  mailbox_path = 0x4 <Address 0x4 out of bounds>,
  control_dir = 0x92c2d40
  default_cache_fields = 4111347712, never_cache_fields = 10264,
indexid = 760,
  sync_id = 4111347712, excl_lock_counter = 0, mbox_fd = 0,
mbox_stream = 0x141,
  mbox_lock_type = 134600064, mbox_dotlock = {dev =
578449631533718672, ino = 578450043850658064,
    mtime = 134603952}, mbox_lock_counter = 134687552,
mbox_sync_counter = 134612512,
  mbox_size = 578451074642809312, mbox_dev = 578453548543972288,
mbox_ino = 578455610128274912,
  last_new_mtime = 134682400, last_uidlist_mtime = 134603520,
maildir_cur_dirty = 134602256,
  next_dirty_flush = 134683344, maildir_lock_fd = 134615840,
new_filename_pool = 0x8071f00,
  new_filenames = 0x8072020, fd = 134684944,
  error = 0x8074c90 "U\211�WVS\203�\034\213}\b\203�\034\001",
mmap_base = 0x80753a0,
  mmap_used_length = 134698160, mmap_full_length = 134698688, header =
  lock_type = 134685136, file_sync_stamp = 134685216, first_recent_uid
= 153886568,
  lock_notify_cb = 0x92c1ae8, lock_notify_context = 0x92c16b8,
set_flags = 153885000,
  set_cache_fields = 153884304, anon_mmap = 0, opened = 0, rebuilding
= 0, mail_read_mmaped = 0,
  inconsistent = 1, nodiskspace = 0, index_lock_timeout = 0,
allow_new_custom_flags = 0,
  mailbox_readonly = 0, mailbox_lock_timeout = 1, maildir_keep_new =
0, maildir_have_new = 1}

Comment 9 Timo Sirainen 2004-05-27 15:23:14 UTC
Found it, it's all because I use pointers to mmaped .imap.index.data file. If it grows, the 
pointers get broken. fixes this, I'll release it now :)

Comment 10 David Woodhouse 2004-05-27 17:14:55 UTC
dovecot- built in rawhide. Leaving the bug open cos someone
needs to babysit me through the process of releasing an erratum for

Comment 11 John Dennis 2004-06-15 17:56:03 UTC
pushed to FC2 testing

Comment 12 Warren Togami 2004-06-16 00:46:35 UTC
IMHO, we do not need any further testing.  This package has more than
proven itself at this point.  Also I notice that you didn't rebuild
for FC1.  I am preparing updates for FC1 and FC2 now, with a different
NVR than rawhide.

Comment 13 Warren Togami 2004-06-16 00:52:08 UTC
Argh... the package pushed to FC2 updates/testing is identical in
N-V-R to rawhide, which is a bit problematic.  I am pushing the -0.FCX
packages that were in testing for the past two weeks.

Comment 15 David Woodhouse 2004-09-16 15:31:36 UTC
dovecot- did it today. Same backtrace.

Comment 16 John Dennis 2004-09-16 16:04:23 UTC
David, dovecot-0.99.11 is the current upstream release and has a
number of bug fixes beyond what you're running, its in rawhide and
FC3, perhaps you might want to upgrade to 0.99.11 and see if you
continue hit the same problem.

Comment 17 David Woodhouse 2004-09-17 12:25:35 UTC
Yes, that works -- at least it does as soon as I kill the gdb and the
instance of 'imap' which was locking the folder in question.

Are we going to ship it as an erratum for FC2 then?

Comment 18 John Dennis 2005-01-05 19:55:11 UTC
Closing this as 0.99.11 was shipped in FC3. Shortly I'll push a
0.99.11 version to FC2.

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