Mutt Segmentation Fault with MX Linux 21.3

[moh-kaos]

Hi all. New noob here.

Using MX Linux, set up Mutt with gmail.
Was initially successful. Emails and all.

Then at some point when trying to use again, it stuck at 4% giving a segmentation fault.
Using gdb it says:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7c2ea5f in ?? () from /lib/x86_64-linux-gnu/libtokyocabinet.so.9

(gdb) bt
#0  0x00007ffff7c2ea5f in ?? () from /lib/x86_64-linux-gnu/libtokyocabinet.so.9
#1  0x00007ffff7c2fca8 in tcbdbput () from /lib/x86_64-linux-gnu/libtokyocabinet.so.9
#2  0x000055555561e5da in ?? ()
#3  0x000055555561eded in ?? ()
#4  0x000055555562dfe3 in ?? ()
#5  0x000055555562bb1c in ?? ()
#6  0x000055555562893d in ?? ()
#7  0x00005555555b774e in ?? ()
#8  0x000055555556c3ea in ?? ()
#9  0x00007ffff795cd7a in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x000055555556d44a in ?? ()

What do I do?

[flatcap]

Welcome to NeoMutt, @moh-kaos.

Sorry this is your first experience of our program :-(

Was initially successful.

Great! Getting started is generally the hardest bit.

Which version of NeoMutt are you using? (The latest is 2024-12-12)
Finding a recent version of NeoMutt is important for bug-fixes (and features).

#4 0x000055555562dfe3 in ?? ()

OK, no debugging symbols...

#0 ... libtokyocabinet.so.9

OK, that's the header cache.
In the past, this has been a problem, but it shouldn't be now.

A couple of things you could try:

Disable the Header Cache

Temporarily comment out the config: set header_cache = "~/.cache/mutt/"
Does NeoMutt work now?

Delete the Header Cache

Re-enable the config.
Delete all the files in ~/.cache/mutt/ (wherever your cache is saved).
Does NeoMutt work now?

How about if you restart NeoMutt?

Better Caching

Bonus tip, use a better backend...
Have a look at the output of neomutt -v | grep storage

If you see lmdb listed, add this to your config:

set header_cache_backend = "lmdb"

LMDB is a modern database that's much faster than TokyoCabinet (the default).

[moh-kaos]

Thanks for the prompt reply. Pardon the ignorant question---but how do I find the config file? Is that via nano ~/.muttrc? I looked at the output of neomutt -v | grep storage but only tokyocabinet was listed. I went to the MX repo and installed LMDB (I think) but how do I config neomutt to use it? FWIW, mutt also stopped working. Exact same problem.

…

On Mon, Dec 30, 2024 at 7:01 AM Richard Russon ***@***.***> wrote: Welcome to NeoMutt, @moh-kaos <https://github.com/moh-kaos>. Sorry this is your first experience of our program :-( Was initially successful. Great! Getting started is generally the hardest bit. *Which version of NeoMutt are you using?* (The latest is 2024-12-12 <https://github.com/neomutt/neomutt/releases/tag/20241212>) Finding a recent version of NeoMutt is important for bug-fixes (and features). #4 0x000055555562dfe3 in ?? () OK, no debugging symbols... #0 ... libtokyocabinet.so.9 OK, that's the header cache. In the past, this has been a problem, but it shouldn't be now. A couple of things you could try: Disable the Header Cache Temporarily comment out the config: set header_cache = "~/.cache/mutt/" Does NeoMutt work now? Delete the Header Cache Re-enable the config. Delete all the files in ~/.cache/mutt/ (wherever your cache is saved). Does NeoMutt work now? How about if you restart NeoMutt? Better Caching Bonus tip, use a better backend... Have a look at the output of neomutt -v | grep storage If you see lmdb listed, add this to your config: set header_cache_backend = "lmdb" LMDB is a modern database that's much faster than TokyoCabinet (the default). — Reply to this email directly, view it on GitHub <#129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BOBFKJMVRJ3E3LKMBEQBEGD2IEY2VAVCNFSM6AAAAABUKCEFM6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRZGYZTGNY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[flatcap]

but how do I find the config file?

er, it's wherever you left it :-)

NeoMutt reads two config files on startup: system and user.
Here's a guide to the order it looks for them:

• https://neomutt.org/guide/configuration#files

but only tokyocabinet was listed.

Ah, OK.
The storage type is a compile-time option.
To get other types you'd need MX Linux to alter their build of NeoMutt.

FWIW, mutt also stopped working. Exact same problem.

Hmm... That is weird.

Which version of NeoMutt are you using?
Have you tried deleting the cache files?

[moh-kaos]

To get other types you'd need MX Linux to alter their build of NeoMutt.

…

--that seems like a tall order, no? Which version of NeoMutt are you using?

--how do i find out? Have you tried deleting the cache files? --how do i do that?

On Tue, Dec 31, 2024 at 6:45 AM Richard Russon ***@***.***> wrote: but how do I find the config file? er, it's wherever you left it :-) NeoMutt reads two config files on startup: system and user. Here's a guide to the order it looks for them: - https://neomutt.org/guide/configuration#files but only tokyocabinet was listed. Ah, OK. The storage type is a compile-time option. To get other types you'd need MX Linux to alter their build of NeoMutt. FWIW, mutt also stopped working. Exact same problem. Hmm... That *is* weird. Which version of NeoMutt are you using? Have you tried deleting the cache files? — Reply to this email directly, view it on GitHub <#129 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BOBFKJN2GHQCGZQM65QHJ4L2IJ7UPAVCNFSM6AAAAABUKCEFM6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNZQGUYTMMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[flatcap]

To get other types you'd need MX Linux to alter their build of NeoMutt.

that seems like a tall order, no?

Don't know.
MX Linux probably has a support community.
You might be able to find out who packages NeoMutt.

Which version of NeoMutt are you using?

how do i find out?

neomutt -v

Have you tried deleting the cache files?

how do i do that?

Look at the $header_cache config option, e.g. neomutt -Q header_cache
and delete the files at that location.