| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a runtime error in the SeqMap.Pop function causing a
index-out-of-range panic:
Version: 0.18.2.r22.gfff69046 (go1.22.6 amd64 linux 2024-08-10)
Error: runtime error: index out of range [487] with length 487
goroutine 24430 [running]:
runtime/debug.Stack()
runtime/debug/stack.go:24 +0x5e
git.sr.ht/~rjarry/aerc/lib/log.PanicHandler()
git.sr.ht/~rjarry/aerc/lib/log/panic-logger.go:49 +0x66a
panic({0x5dbf5a688020?, 0xc002ab0d80?})
runtime/panic.go:770 +0x132
git.sr.ht/~rjarry/aerc/worker/imap.(*SeqMap).Pop(0xc0003d4940, 0x1e8)
git.sr.ht/~rjarry/aerc/worker/imap/seqmap.go:64 +0x17c
git.sr.ht/~rjarry/aerc/worker/imap.(*IMAPWorker).handleImapUpdate(0xc0003d4820, {0x5dbf5a6dbd00, 0xc002068708})
git.sr.ht/~rjarry/aerc/worker/imap/worker.go:296 +0x26c
git.sr.ht/~rjarry/aerc/worker/imap.(*IMAPWorker).drainUpdates.func1()
git.sr.ht/~rjarry/aerc/worker/imap/flags.go:29 +0x10c
created by git.sr.ht/~rjarry/aerc/worker/imap.(*IMAPWorker).drainUpdates in goroutine 52
git.sr.ht/~rjarry/aerc/worker/imap/flags.go:21 +0x78
SeqMap.Pop uses two locks in the same function: first lock grabs the
size of the slice, second lock removes the given index in the slice.
Combine the two locks to prevent a change of the slice size before the
index can be removed.
Reported-by: Moritz Poldrack <moritz@poldrack.dev>
Signed-off-by: Koni Marti <koni.marti@gmail.com>
Acked-by: Robin Jarry <robin@jarry.cc>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit fdfec2c07a8d seqmap: refactor seqmap to use slice instead of map
introduced a regression to imap sorting (if supported). The slice passed
to seqmap was being sorted in place by UID, thus breaking any sort order
sent by the server.
Create a copy of the slice to retain the sort order reported to the UI
while also keeping a correct map for seqnum -> UID in the worker.
Signed-off-by: Tim Culverhouse <tim@timculverhouse.com>
Acked-by: Robin Jarry <robin@jarry.cc>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The imap worker's seqmap is represented as a map of sequence number to
UID. This presents a problem when expunging group of messages from the
mailbox: each individual expunge decrements the sequence numbers by 1
(for every sequence number greater than the expunged). This requires a
looping around the map to update the keys. The use of a map also
requires that both the sequence number and the UID of a message be known
in order to insert it into the map. This is only discovered by fetching
individual message body parts (flags, headers, etc), leaving the seqmap
to be empty until we have fetched information about each message. In
certain instances (if a mailbox has recently been loaded), all
information is loaded in memory and no new information is fetched -
leaving the seqmap empty and the UI out of sync with the worker.
Refactor the seqmap as a slice, so that any expunge automatically
decrements the rest of the sequences.
Use the results of FetchDirectoryContents or FetchDirectoryThreaded to
initialize the seqmap with all discovered UIDs. Sort the UIDs in
ascending order: IMAP specification requires that sequence numbers start
at 1 increase in order of ascending UID.
Add individual messages to the map if they come via a MessageUpdate and
have a sequence number larger than our slice.
Update seqmap tests with new logic.
Reference: https://datatracker.ietf.org/doc/html/rfc3501#section-2.3.1.2
Fixes: https://todo.sr.ht/~rjarry/aerc/69
Signed-off-by: Tim Culverhouse <tim@timculverhouse.com>
Acked-by: Robin Jarry <robin@jarry.cc>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch updates the seqNums after an Expunge operation. When an
expunge operation occurs, the seqNum of the deleted message is reported.
The Imap spec [0] states that an immediate decrement of all seqnums greater
than the deleted occurs, even before the next reporting of an expunge
update.
[0]: https://datatracker.ietf.org/doc/html/rfc3501#section-7.4.1
Fixes: https://todo.sr.ht/~rjarry/aerc/61
Signed-off-by: Tim Culverhouse <tim@timculverhouse.com>
Signed-off-by: Robin Jarry <robin@jarry.cc>
|
|
There are concurrent threads that are accessing and modifying
IMAPWorker.seqMap (the mapping of sequence numbers to message UIDs).
This can lead to crashes when trying to add and remove a message ID.
panic: runtime error: index out of range [391] with length 390
goroutine 1834 [running]:
git.sr.ht/~rjarry/aerc/logging.PanicHandler()
logging/panic-logger.go:47 +0x6de
panic({0xa41760, 0xc0019b3290})
/usr/lib/golang/src/runtime/panic.go:838 +0x207
git.sr.ht/~rjarry/aerc/worker/imap.(*IMAPWorker).handleFetchMessages.func1()
worker/imap/fetch.go:214 +0x185
created by git.sr.ht/~rjarry/aerc/worker/imap.(*IMAPWorker).handleFetchMessages
worker/imap/fetch.go:209 +0x12b
Use a map which makes more sense than a simple array for random access
operations. Also, it allows better typing for the key values. Protect
the map with a mutex. Add internal API to access the map. Add basic unit
tests to ensure that concurrent access works.
Fixes: https://todo.sr.ht/~rjarry/aerc/49
Signed-off-by: Robin Jarry <robin@jarry.cc>
Acked-by: Moritz Poldrack <moritz@poldrack.dev>
|