search for: start_po

...15:10:29 Error: 23648 imap(username): mbox sync: UID inserted in the middle of mailbox /mailhome/new/s/h/username/DONE (1591 > 19, seq=19, idx_msgs=1593) dovecot: Dec 14 15:10:33 Error: 23648 imap(username): file mbox-sync-rewrite.c: line 106 (mbox_sync_headers_add_space): assertion failed: (start_pos < data_size) dovecot: Dec 14 15:10:40 Error: child 23648 (imap) killed with signal 6 (gdb) bt full #0 0xffffe410 in ?? () No symbol table info available. #1 0xbffff348 in ?? () No symbol table info available. #2 0x00000006 in ?? () No symbol table info available. #3 0x00005c60 in ?? () No...

...7 ++++- 6 files changed, 78 insertions(+), 41 deletions(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 3591e8f..3c790ef 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1280,6 +1280,7 @@ again: } wait_on_page_writeback(pages[i]); } + faili = num_pages - 1; err = 0; if (start_pos < inode->i_size) { struct btrfs_ordered_extent *ordered; @@ -1298,8 +1299,10 @@ again: unlock_page(pages[i]); page_cache_release(pages[i]); } - btrfs_wait_ordered_range(inode, start_pos, - last_pos - start_pos); + err = btrfs_wait_ordered_range(inode, start_pos, +...

...d3f1>] should_remove_suid+0x1/0x50 SS:ESP 0068:e6439eac [ 899.119427] ---[ end trace 74da89b64662263c ]--- --- [3] file.c static ssize_t btrfs_file_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { loff_t pos; loff_t start_pos; ssize_t num_written = 0; ssize_t err = 0; int ret = 0; struct inode *inode = fdentry(file)->d_inode; struct btrfs_root *root = BTRFS_I(inode)->root; struct page **pages = NULL; int nrptrs; struct page *pinned[2]; unsign...

We're in a bit of a panic here as we're getting a lot of errors along the lines of: May 2 12:39:00 lenny dovecot: IMAP(XXXXX): file mbox-sync-rewrite.c: line 106 (mbox_sync_headers_add_space): assertion failed: (start_pos < data_size) We didn't see this until our mail servers went under a full load and now we've trashed the ability of nearly all our users to read email. We saw this first under 1.0Beta3 and we've tried building 1.0Beta7 and its made no difference. I've tried fiddling with th...

Hi, An assertion that I haven't seen before: Apr 20 11:15:32 emerald dovecot: [ID 107833 mail.error] IMAP(user): file mbox-sync-rewrite.c: line 106 (mbox_sync_headers_add_space): assertion failed: (start_pos < data_size) gdb output from the core file of imap is attached. My setup: Solaris 9, mbox format, INBOX is NFS mounted from a Solaris 10 system, imap and imaps only. Jeff Earickson Colby College -------------- next part -------------- %gdb imap core.hacaraba GNU gdb 6.3 Copyright 2004 Free S...

...000, Michael Stevens wrote: > Hi. > > I'm running 1.0alpha5 on FreeBSD 5.3. I'm using mbox mailboxes. > > I keep getting: > > Jan 8 18:53:12 saigo dovecot: imap(mstevens): file > mbox-sync-rewrite.c: line 106 (mbox_sync_headers_add_space): assertion > failed: (start_pos < data_size) > Jan 8 18:53:13 saigo dovecot: child 88663 (imap) killed with signal 6 This happens all the time with one specific mbox? Could you send it and the index files to me? You could put the mbox though http://dovecot.org/tools/mboxcrypt.pl -------------- next part -------------- A...

...t working. Neither the 1.0.alpha4 (Debian testing) nor the 1.0.beta2 (Debian unstable) do. in /var/log/mail.err I get following error message over and over again: Feb 7 07:12:02 harmserv dovecot: imap(duerkop): file mbox-sync-rewrite.c: line 106 (mbox_sync_headers_add_space): assertion failed: (start_pos < data_size) Feb 7 07:12:02 harmserv dovecot: child 21001 (imap) killed with signal 6 Please notice the client reads the index but cannot access the contents themself! What does this errormessage mean, and how can I get rid of her? Saluti! Ludwig -- Open WebMail Project (http://o...

Mar 9 16:15:19 bob dovecot: imap(username): file mbox-sync-rewrite.c: line 106(mbox_sync_headers_add_space): assertion failed: (start_pos < data_size) Getting these errors like crazy. Any ideas? Thanks! Regards, Matt Juszczak

Hi, Dovecot 1.0 beta7 is dying on me. My logfile shows: May 10 15:54:28 hermes dovecot: IMAP(alden): UIDs broken with partial sync in mbox file /var/mail/alden May 10 15:54:28 hermes dovecot: IMAP(alden): file mbox-sync-rewrite.c: line 106 (mbox_sync_headers_add_space): assertion failed: (start_pos < data_size) May 10 15:54:28 hermes dovecot: child 14185 (imap) killed with signal 6 I'm running this on a RHEL 3U7 system. I created a core file, but it doesn't look like it's too helpful (I've attached the gdb output to this message). I tried recompiling with "--enable...

Hi all - The following 9 patches add more error handling to the btrfs code: - Add btrfs_panic - Catch locking failures in {set,clear}_extent_bit - Push up set_extent_bit errors to callers - Push up lock_extent errors to callers - Push up clear_extent_bit errors to callers - Push up unlock_extent errors to callers - Make pin_down_extent return void - Push up btrfs_pin_extent errors to

...tem); diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 431b565..f0da02b 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1404,7 +1404,6 @@ static ssize_t btrfs_file_aio_write(struct kiocb *iocb, mutex_unlock(&inode->i_mutex); goto out; } - BTRFS_I(inode)->sequence++; start_pos = round_down(pos, root->sectorsize); if (start_pos > i_size_read(inode)) { diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 7a084fb..7d3dd2f 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -2510,7 +2510,7 @@ static void btrfs_read_locked_inode(struct inode *inode) inode_s...

V1->V2: Check to see if our current ppos is >= i_size after a short DIO read, just in case it was actually a short read and we need to just return. This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the rest via buffered IO. BTRFS needs this because if we encounter a compressed or

...p=0x80be9b0) at ioloop.c:230 #8 0x08060877 in main (argc=1, argv=0xbffffa44, envp=0xbffffa4c) at main.c:229 (gdb) p *data $1 = {flags = 0, date = 0, received_date = 1124608407, virtual_size = 2870, physical_size = 2856, sent_date = {time = -1, timezone = 0}, parse_line = { field_idx = 0, start_pos = 0, end_pos = 0, line_num = 0, cache = 0}, parse_line_num = 0, parts = 0x0, envelope = 0x0, body = 0x0, bodystructure = 0x0, uid_string = 0x0, envelope_data = 0x0, seq = 11473, rec = 0xb7de7088, cache_flags = 0, access_part = 3, stream = 0x80cc224, filter_stream = 0x0, hdr_size = {phy...

...x_mail_expunge>}, pool = 0xbb940, module_contexts = {buffer = 0xbbad8, element_size = 4}}, data = { flags = MAIL_SEEN, date = 0, received_date = 1138391916, virtual_size = 35917, physical_size = 35337, sent_date = {time = -1, timezone = 0}, parse_line = {field_idx = 4294967295, start_pos = 168, end_pos = 201, line_num = 32, cache = 1}, parse_line_num = 41, parts = 0x0, envelope = 0xc0f10 "\"Fri, 27 Jan 2006 14:58:13 -0500 (EST)\" \"Your Order Confirmation\" ((NIL NIL \"customerservice\" \"studentuniverse.com\")) ((NIL NIL...

...@@ static ssize_t btrfs_file_aio_write(stru nrptrs = min((iov_iter_count(&i) + PAGE_CACHE_SIZE - 1) / PAGE_CACHE_SIZE, PAGE_CACHE_SIZE / (sizeof(struct page *))); - pages = kmalloc(nrptrs * sizeof(struct page *), GFP_KERNEL); /* generic_write_checks can change our pos */ start_pos = pos; --- ./fs/btrfs/inode.c 2010-07-28 08:11:33.000000000 +0400 +++ /tmp/cocci-output-7824-c1d367-inode.c 2010-07-28 18:43:15.000000000 +0400 @@ -284,7 +284,6 @@ static noinline int add_async_extent(str { struct async_extent *async_extent; - async_extent = kmalloc(sizeof(*async_extent), GFP...

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 6 Jan 2011 20:59:08 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=26242 > > Summary: BUG: unable to handle kernel NULL pointer dereference > at (null) > Product: Memory Management >

Just installed the version from CVS as of Oct. 27. I noticed three problems quite quickly: Still seeing "(imap) killed with signal 14" My INBOX closed with "access error" after reading it for a bit. There's nothing in the logs or anything, but this hasn't happened for quite a while now. There where quite a lot of incoming messages at the time and I was marking

...9b0) at ioloop.c:218 #8 0x08060587 in main (argc=1, argv=0xbffffa44, envp=0xbffffa4c) at main.c:228 (gdb) p *data $2 = {flags = 0, date = 0, received_date = 1117844856, virtual_size = 2735, physical_size = 2721, sent_date = {time = -1, timezone = 0}, parse_line = { field_idx = 4294967295, start_pos = 67, end_pos = 118, line_num = 29, cache = 1}, parse_line_num = 53, parts = 0x80cb018, envelope = 0x0, body = 0x0, bodystructure = 0x0, uid_string = 0x0, envelope_data = 0x0, seq = 9276, rec = 0xb7dd3854, cache_flags = 0, stream = 0x80f53c4, filter_stream = 0x0, hdr_size = {physical...

...d; double elapsed; @@ -125,8 +127,10 @@ refresh_progress_meter(void) off_t bytes_left; int cur_speed; int hours, minutes, seconds; - int i, len; - int file_len; + int width, size, buf_width, buf_size; + int i; + int file_width; + wchar_t wc; transferred = *counter - (cur_pos ? cur_pos : start_pos); cur_pos = *counter; @@ -157,16 +161,33 @@ refresh_progress_meter(void) /* filename */ buf[0] = '\0'; - file_len = win_size - 35; - if (file_len > 0) { - len = snprintf(buf, file_len + 1, "\r%s", file); - if (len < 0) - len = 0; - if (len >= file_len + 1) -...

Hi all - Here''s my current error handling patchset, against 3.1-rc8. Almost all of this patchset is preparing for actual error handling. Before we start in on that work, I''m trying to reduce the surface we need to worry about. It turns out that there is a ton of code that returns an error code but never actually reports an error. The patchset has grown to 65 patches. 46 of them