I experienced more core dumps, but haven't had time to examine them.
In particular, at a time I had three core dumps in a row on Jul 14:
-rw------- 1 ale staff 6180864 Jul 14 17:10
core_epoch=1531581032_pid=5409_file=!usr!sbin!famd
-rw------- 1 ale staff 9302016 Jul 14 17:09
core_epoch=1531580943_pid=5317_file=!usr!sbin!famd
-rw------- 1 ale staff 26234880 Jul 14 17:05
core_epoch=1531580714_pid=26593_file=!usr!sbin!famd
The first of these only run for 1 minute. The "closure" in
TCP_Client::unblock_handler (closure=0x295ca20) at TCP_Client.c++:270
is always a LocalClient with a bad to_be_scanned element. In the first (short)
dump, it had:
to_be_scanned = {
<std::set<Interest*, std::less<Interest*>, std::allocator<Interest*> >> =
std::set with 251 elements = {
Elements 0 to 102 were bad memory pointers.
Elements 103 to 250 were entries of type DirEntry with a common parent
corresponding to
a courierimapkeywords directory of a Courier-MTA mail folder. The parent
had 1170
entries, and this batch matched entries 12 to 159 in the parent. Since
those file names
contain Unix epoch, I could check that most --not all-- of them were in
ascending order.
One file was listed twice, and was out of order.
Dates ranged from June to a few hours before crash.
}, <No data fields>}
Courier at times removes a bunch of those files and stores the corresponding
IMAP keywords
in a single ":list" file. I have to study the code better to understand how
parent and
clients can be notified of Interest* deletion. Maybe next month...
