panic: runtime error: index out of range in handleFetchMessages

When opening a message after switching folders, aerc sometimes crashes and the following is printed:

panic: runtime error: index out of range                                             
                                        goroutine 230 [running]:                     
                                                                git.sr.ht/~sircmpwn/aerc/worker/imap.(*IMAPWorker).handleFetchMessages.func1(0xc00060a2a0, 0xc0001d41c0, 0x1049d1a0, 0xc0003fce00, 0xc00000c180, 0xc00060a300)                                 
                                                        /home/shawnanastasio/opt/aerc/worker/imap/fetch.go:54 +0x494                                                      
                               created by git.sr.ht/~sircmpwn/aerc/worker/imap.(*IMAPWorker).handleFetchMessages                                                          
                                /home/shawnanastasio/opt/aerc/worker/imap/fetch.go:52 +0xa0
Assigned to
2 years ago
2 years ago

~epse 2 years ago

I am getting the same thing when opening HTML messages (in my case specifically reddit email verification messages). Other HTML emails work fine. I have the broken emails if needed for investigation.

~sircmpwn 2 years ago

Can you run :pipe tee /tmp/example.eml and upload that file somewhere for me?

~epse 2 years ago

Absolutely, it's right here https://gist.github.com/Epse/f629d5a846a82415feddd0b45ff5e298.

I will say that this appears to be a difficult bug to reproduce, as this same email now no longer causes the crash, while it was impossible to open previously.

~epse referenced this from #145 2 years ago

~vladimir 2 years ago

I see this very crash with any email.

To reproduce it it is enough to open aerc, switch to some folder, switch back to first one and open mail. Crashes everytime.

I have Archlinux AUR package "aerc" and I do connect to my personal Dovecot server via IMAPS (IMAP + STARTTLS didn't work...)

~epse 2 years ago

For me, it only crashes once per message, after restarting aerc I can look at that specific message again. I am on Arch too and tried both the aerc and the aerc-git package, both have the same issue.

~yashsriv 2 years ago

I think this is similar to #168 which was also only crashing once per message. The logs I captured for that might be relevant in this case as well.

~geemili 2 years ago

I get a very similar error on 702ad43bd2e5474669eae07eade44669f4f24b02:

panic: runtime error: index out of range                                                                                                                                                                                                                                         

                                        goroutine 64 [running]:
                                                               git.sr.ht/~sircmpwn/aerc/worker/imap.(*IMAPWorker).handleFetchMessages.func1(0xc0000a1620, 0xc0001841c0, 0x8e1b80, 0xc00075b140, 0xc000144780, 0xc0000a1680)
                                                                                                                                                                                                                           	/home/geemili/sources/git.sr.ht/sircmpwn/aerc/worker/imap/fetch.go:75 +0x96b
                           created by git.sr.ht/~sircmpwn/aerc/worker/imap.(*IMAPWorker).handleFetchMessages
                                                                                                            	/home/geemili/sources/git.sr.ht/sircmpwn/aerc/worker/imap/fetch.go:73 +0xbf

It happens whenever I switch to a different folder, switch back, and then try to open a message. Depending on the folders involved it doesn't always fail, but it consistently fails when I switch back to INBOX from a non-empty folder.

~geemili 2 years ago

I added some debug statements to try to shed some light on this issue:

diff --git a/worker/imap/fetch.go b/worker/imap/fetch.go
index 7d1bfcf..e9d0363 100644
--- a/worker/imap/fetch.go
+++ b/worker/imap/fetch.go
@@ -72,6 +72,8 @@ func (imapw *IMAPWorker) handleFetchMessages(
        go func() {
                for _msg := range messages {
+                       imapw.worker.Logger.Printf("seq num: %d, uid: %d", _msg.SeqNum, _msg.Uid)
+                       imapw.worker.Logger.Printf("seqMap len: %d", len(imapw.seqMap))
                        imapw.seqMap[_msg.SeqNum-1] = _msg.Uid
                        switch msg.(type) {
                        case *types.FetchMessageHeaders:

Relevant part of debug log:

# When switching from a folder with 1 item in it
2019/06/09 18:54:36 seq num: 408, uid: 4445
2019/06/09 18:54:36 seqMap len: 1

# When switch from a folder with 4 items
2019/06/09 18:58:39 seq num: 408, uid: 4445
2019/06/09 18:58:39 seqMap len: 4

~zachs 2 years ago

Hi, I'm interested in fixing this bug, as I've been experiencing this too.

Going off of ~geemili's debug statements, it appears seqMap is not updated after switching back to the first directory. In my quick glance at the code it seems like handleFetchDirectoryContents() is what's updating seqMap. But when I switch from INBOX to another folder and back to INBOX I don't see a third call to handleFetchDirectoryContents() so seqMap isn't updated, hence the index out of range error.

Does this seem plausible? This is just my first half hour of looking at the code and a little debugging. I'd love to work on a patch for this but I could use a little guidance on how this worker part of the code works and how these events are handled. Thanks

~ake 2 years ago

Applying this patch stops the issue for me:

diff --git lib/msgstore.go lib/msgstore.go
index a81f9ad..8855859 100644
--- lib/msgstore.go
+++ lib/msgstore.go
@@ -131,6 +131,10 @@ func (store *MessageStore) Update(msg types.WorkerMessage) {
                store.DirInfo = *msg
                if store.DirInfo.Exists != len(store.Uids) {
                        store.worker.PostAction(&types.FetchDirectoryContents{}, nil)
+               } else {
+                       // Todo: Fetch from cache, I presume that's what's neeed
+                       store.worker.Logger.Printf("Should fetch from cache here")
+                       store.worker.PostAction(&types.FetchDirectoryContents{}, nil)
                update = true
        case *types.DirectoryContents:

I think there might be some code missing to fetch the messages from a cache somewhere.

~zachs 2 years ago

That fixes it for me too.

Not sure what a proper fix should be for it though. From what I can tell it doesn't make a difference if store.DirInfo.Exists != len(store.Uids). What's causing the crash is the seqMap in the IMAP worker is not getting updated before handleFetchMessages() is called.

~zachs 2 years ago

Patch sent that removes the conditional entirely. My reasoning for this is that there is no other place where the IMAPWorker's seqMap is updated, so the FetchDirectoryContents action needs to happen regardless.


Register here or Log in to comment, or comment via email.