segfault causes system freeze

[steve]

Hi There,

I have a new box for about two months and it appears that each time mutt
segfaults, the console freezes and I have to hard stop the machine. Here
is what I have in /var/log/kernel.log:

Nov 19 15:54:17 box kernel: [ 7970.303276] mutt[13832]: segfault at 8 ip 000055a9d9996c68 sp 00007fff5e7f47c0 error 4 in mutt[55a9d9963000+115000]
Nov 19 15:54:17 box kernel: [ 7970.303284] Code: e1 00 01 41 89 cb 0f 84 c6 00 00 00 8b 4a 2c 03 8a 90 00 00 00 48 63 52 1c 39 d1 0f 8e cc 00 00 00 45 8b
54 92 fc 49 8b 58 68 <48> 8b 53 08 48 85 d2 75 26 eb 3d 0f 1f 44 00 00 44 3b 51 38 41 0f

I don't understand the above message.


I'm using NeoMutt 20170113 (1.7.2) from Debian stretch.

What should I do/try?

Thanks.

Best,
Steve

[Patrick Shanahan]

Post by steve
Hi There,
I have a new box for about two months and it appears that each time mutt
segfaults, the console freezes and I have to hard stop the machine. Here
Nov 19 15:54:17 box kernel: [ 7970.303276] mutt[13832]: segfault at 8 ip 000055a9d9996c68 sp 00007fff5e7f47c0 error 4 in mutt[55a9d9963000+115000]
Nov 19 15:54:17 box kernel: [ 7970.303284] Code: e1 00 01 41 89 cb 0f 84 c6 00 00 00 8b 4a 2c 03 8a 90 00 00 00 48 63 52 1c 39 d1 0f 8e cc 00 00 00 45 8b
54 92 fc 49 8b 58 68 <48> 8b 53 08 48 85 d2 75 26 eb 3d 0f 1f 44 00 00 44 3b 51 38 41 0f
I don't understand the above message.
I'm using NeoMutt 20170113 (1.7.2) from Debian stretch.
What should I do/try?

contact the providers of neomutt as it is a different project than mutt.

[Jörg Sommer]

Post by steve
Hi There,
I have a new box for about two months and it appears that each time mutt
segfaults, the console freezes and I have to hard stop the machine. Here
Nov 19 15:54:17 box kernel: [ 7970.303276] mutt[13832]: segfault at 8 ip 000055a9d9996c68 sp 00007fff5e7f47c0 error 4 in mutt[55a9d9963000+115000]
Nov 19 15:54:17 box kernel: [ 7970.303284] Code: e1 00 01 41 89 cb 0f 84 c6 00 00 00 8b 4a 2c 03 8a 90 00 00 00 48 63 52 1c 39 d1 0f 8e cc 00 00 00 45 8b
54 92 fc 49 8b 58 68 <48> 8b 53 08 48 85 d2 75 26 eb 3d 0f 1f 44 00 00 44 3b 51 38 41 0f

Do you use systemd? Can you install the packages systemd-coredump and
mutt-dbgsym? After a crash you can run `coredumpctl info -1` and post the
output here. The backtrace might help to see what's wrong.

Regards Jörg

[steve]

Post by Jörg Sommer

Post by steve
Hi There,
I have a new box for about two months and it appears that each time mutt
segfaults, the console freezes and I have to hard stop the machine. Here
Nov 19 15:54:17 box kernel: [ 7970.303276] mutt[13832]: segfault at 8 ip 000055a9d9996c68 sp 00007fff5e7f47c0 error 4 in mutt[55a9d9963000+115000]
Nov 19 15:54:17 box kernel: [ 7970.303284] Code: e1 00 01 41 89 cb 0f 84 c6 00 00 00 8b 4a 2c 03 8a 90 00 00 00 48 63 52 1c 39 d1 0f 8e cc 00 00 00 45 8b
54 92 fc 49 8b 58 68 <48> 8b 53 08 48 85 d2 75 26 eb 3d 0f 1f 44 00 00 44 3b 51 38 41 0f

Do you use systemd? Can you install the packages systemd-coredump and
mutt-dbgsym? After a crash you can run `coredumpctl info -1` and post the

There is no mutt-dbgsym in stretch, only jessie and sid. I installed
systemd-coredump. Will launch the command after next freeze.

Thank you

Steve

[Jörg Sommer]

Post by steve

Post by Jörg Sommer

Post by steve
Hi There,
I have a new box for about two months and it appears that each time mutt
segfaults, the console freezes and I have to hard stop the machine. Here
Nov 19 15:54:17 box kernel: [ 7970.303276] mutt[13832]: segfault at 8 ip 000055a9d9996c68 sp 00007fff5e7f47c0 error 4 in mutt[55a9d9963000+115000]
Nov 19 15:54:17 box kernel: [ 7970.303284] Code: e1 00 01 41 89 cb 0f 84 c6 00 00 00 8b 4a 2c 03 8a 90 00 00 00 48 63 52 1c 39 d1 0f 8e cc 00 00 00 45 8b
54 92 fc 49 8b 58 68 <48> 8b 53 08 48 85 d2 75 26 eb 3d 0f 1f 44 00 00 44 3b 51 38 41 0f

Do you use systemd? Can you install the packages systemd-coredump and
mutt-dbgsym? After a crash you can run `coredumpctl info -1` and post the

There is no mutt-dbgsym in stretch, only jessie and sid. I installed
systemd-coredump. Will launch the command after next freeze.

You have to add the following line to /etc/apt/sources.list

deb http://ftp.de.debian.org/debian-debug/ stable-debug main non-free contrib

Regards Jörg

[steve]

Post by Jörg Sommer

Post by steve

Post by Jörg Sommer
Do you use systemd? Can you install the packages systemd-coredump and
mutt-dbgsym? After a crash you can run `coredumpctl info -1` and post the

There is no mutt-dbgsym in stretch, only jessie and sid. I installed
systemd-coredump. Will launch the command after next freeze.

You have to add the following line to /etc/apt/sources.list
deb http://ftp.de.debian.org/debian-debug/ stable-debug main non-free contrib

Thanks, I didn't know about that repo. Installed now, waiting for the
next freeze. Can I run the command after a reboot?

[Jörg Sommer]

Post by steve

Post by Jörg Sommer

Post by steve

Post by Jörg Sommer
Do you use systemd? Can you install the packages systemd-coredump and
mutt-dbgsym? After a crash you can run `coredumpctl info -1` and post the

There is no mutt-dbgsym in stretch, only jessie and sid. I installed
systemd-coredump. Will launch the command after next freeze.

You have to add the following line to /etc/apt/sources.list
deb http://ftp.de.debian.org/debian-debug/ stable-debug main non-free contrib

Thanks, I didn't know about that repo. Installed now, waiting for the
next freeze. Can I run the command after a reboot?

Yes. Coredumpctl should capture the crash dump and you can inspect it
later, if it was successful. But maybe the crash causes the kernel can not
even write the core dump out to disk.

[steve]

Post by Jörg Sommer

Post by steve

Post by Jörg Sommer

Post by steve

Post by Jörg Sommer
Do you use systemd? Can you install the packages systemd-coredump and
mutt-dbgsym? After a crash you can run `coredumpctl info -1` and post the

There is no mutt-dbgsym in stretch, only jessie and sid. I installed
systemd-coredump. Will launch the command after next freeze.

You have to add the following line to /etc/apt/sources.list
deb http://ftp.de.debian.org/debian-debug/ stable-debug main non-free contrib

Thanks, I didn't know about that repo. Installed now, waiting for the
next freeze. Can I run the command after a reboot?

Yes. Coredumpctl should capture the crash dump and you can inspect it
later, if it was successful. But maybe the crash causes the kernel can not
even write the core dump out to disk.

Thank you for the explanations.

Best,
Steve

[steve]

This post might be inappropriate. Click to display it.

[Jörg Sommer]

Post by steve
# coredumpctl info
PID: 1678 (mutt)
UID: 1000 (steve)
GID: 1000 (steve)
Signal: 11 (SEGV)
Timestamp: Wed 2018-11-21 19:45:57 CET (17s ago)
Command Line: mutt -y -n
Executable: /usr/bin/mutt
Control Group: /user.slice/user-1000.slice/session-3.scope
Unit: session-3.scope
Slice: user-1000.slice
Session: 3
Owner UID: 1000 (steve)
Boot ID: 75e02422e0584081937ef6fe13f1e8ba
Machine ID: 63a22f7a1c2437b0703353c75343f80e
Hostname: box.maison.mrs
Storage: /var/lib/systemd/coredump/core.mutt.1000.75e02422e0584081937ef6fe13f1e8ba.1678.1542825957000000.lz4
Message: Process 1678 (mutt) of user 1000 dumped core.
#0 0x00005592c9a59c68 index_make_entry (mutt)
#1 0x00005592c9a822bc menu_redraw_index (mutt)
#2 0x00005592c9a90d3b mutt_pager (mutt)
#3 0x00005592c9a4ea85 mutt_display_message (mutt)
#4 0x00005592c9a5df9c mutt_index_menu (mutt)
#5 0x00005592c9a3ef16 main (mutt)
#6 0x00007f002ec182e1 __libc_start_main (libc.so.6)
#7 0x00005592c9a3ef8a _start (mutt)
This does not tell me anything (I'm not a developer). Do you think I should
open a bug report on the Debian BTS?

Yes, this would be helpful. Do you have gdb installed? Can you run
`coredumpctl debug` and run `bt full` on the gdb prompt? This output would
be very helpful for the developer to see, what was the state before the
crash.

Regards Jörg

[steve]

Post by Jörg Sommer

Post by steve
# coredumpctl info
PID: 1678 (mutt)
UID: 1000 (steve)
GID: 1000 (steve)
Signal: 11 (SEGV)
Timestamp: Wed 2018-11-21 19:45:57 CET (17s ago)
Command Line: mutt -y -n
Executable: /usr/bin/mutt
Control Group: /user.slice/user-1000.slice/session-3.scope
Unit: session-3.scope
Slice: user-1000.slice
Session: 3
Owner UID: 1000 (steve)
Boot ID: 75e02422e0584081937ef6fe13f1e8ba
Machine ID: 63a22f7a1c2437b0703353c75343f80e
Hostname: box.maison.mrs
Storage: /var/lib/systemd/coredump/core.mutt.1000.75e02422e0584081937ef6fe13f1e8ba.1678.1542825957000000.lz4
Message: Process 1678 (mutt) of user 1000 dumped core.
#0 0x00005592c9a59c68 index_make_entry (mutt)
#1 0x00005592c9a822bc menu_redraw_index (mutt)
#2 0x00005592c9a90d3b mutt_pager (mutt)
#3 0x00005592c9a4ea85 mutt_display_message (mutt)
#4 0x00005592c9a5df9c mutt_index_menu (mutt)
#5 0x00005592c9a3ef16 main (mutt)
#6 0x00007f002ec182e1 __libc_start_main (libc.so.6)
#7 0x00005592c9a3ef8a _start (mutt)
This does not tell me anything (I'm not a developer). Do you think I should
open a bug report on the Debian BTS?

Yes, this would be helpful. Do you have gdb installed? Can you run
`coredumpctl debug` and run `bt full` on the gdb prompt? This output would
be very helpful for the developer to see, what was the state before the
crash.

I will do this this afternoon.

Thank you.

Steve

[steve]

Post by Jörg Sommer

Post by steve
This does not tell me anything (I'm not a developer). Do you think I should
open a bug report on the Debian BTS?

Yes, this would be helpful. Do you have gdb installed? Can you run
`coredumpctl debug` and run `bt full` on the gdb prompt? This output would
be very helpful for the developer to see, what was the state before the
crash.

Ok, I attached the output of 'bt full' in gdb. Doesn't speak to me :)

Thanks.

Steve

[Jörg Sommer]

Post by steve

Post by Jörg Sommer

Post by steve
This does not tell me anything (I'm not a developer). Do you think I should
open a bug report on the Debian BTS?

Yes, this would be helpful. Do you have gdb installed? Can you run
`coredumpctl debug` and run `bt full` on the gdb prompt? This output would
be very helpful for the developer to see, what was the state before the
crash.

Ok, I attached the output of 'bt full' in gdb. Doesn't speak to me :)
Thanks.
Steve
#0 0x00005592c9a59c68 in index_make_entry (s=0x7fff20afb090 "", l=1024, menu=<optimized out>, num=<optimized out>) at ../../curs_main.c:300
h = 0x5592cbef1670
flag = (MUTT_FORMAT_TREE | MUTT_FORMAT_MAKEPRINT | MUTT_FORMAT_ARROWCURSOR | MUTT_FORMAT_INDEX)
edgemsgno = 40
reverse = <optimized out>
tmp = <optimized out>

This is here
https://sources.debian.org/src/mutt/1.7.2-1+deb9u1/curs_main.c/#L300 and
in the current version (of neomutt) here
https://salsa.debian.org/mutt-team/neomutt/blob/master/curs_main.c#L550

The best would be to create a bug report and if you don't care too much, I
can send the developer the coredump in a *private* mail. He might dig out
something more.

I would guess that one of the thread chains is broken. Does the crash
happen everytime in the same mailbox?

Jörg

[steve]

Post by Jörg Sommer

Post by steve
#0 0x00005592c9a59c68 in index_make_entry (s=0x7fff20afb090 "", l=1024, menu=<optimized out>, num=<optimized out>) at ../../curs_main.c:300
h = 0x5592cbef1670
flag = (MUTT_FORMAT_TREE | MUTT_FORMAT_MAKEPRINT | MUTT_FORMAT_ARROWCURSOR | MUTT_FORMAT_INDEX)
edgemsgno = 40
reverse = <optimized out>
tmp = <optimized out>

This is here
https://sources.debian.org/src/mutt/1.7.2-1+deb9u1/curs_main.c/#L300 and
in the current version (of neomutt) here
https://salsa.debian.org/mutt-team/neomutt/blob/master/curs_main.c#L550
The best would be to create a bug report and if you don't care too much, I
can send the developer the coredump in a *private* mail. He might dig out
something more.

That would be really nice of you. But does it mean I also have to open a
bug report?

Post by Jörg Sommer
I would guess that one of the thread chains is broken. Does the crash
happen everytime in the same mailbox?

That's a question I also asked myself. I don't know for now. I'll have
to investigate a bit more. The problem is that it doesn't happen so
often.


Thank you very much for your help

Best,
Steve

[Kevin J. McCarthy]

Post by steve

Post by Jörg Sommer
I would guess that one of the thread chains is broken. Does the crash
happen everytime in the same mailbox?

That's a question I also asked myself. I don't know for now. I'll have
to investigate a bit more. The problem is that it doesn't happen so
often.

I'm not familiar with the changes NeoMutt may have made to their
version, but if you can duplicate with a recent Mutt, I may be able
investigate further.

However, I do have a couple questions that may (or may not) be relevant.
Do you always see the crashes in the pager, or is it random? Also, are
you using IMAP?

[steve]

Hi Kevin,

Post by Kevin J. McCarthy

Post by steve

Post by Jörg Sommer
I would guess that one of the thread chains is broken. Does the
crash happen everytime in the same mailbox?

That's a question I also asked myself. I don't know for now. I'll
have to investigate a bit more. The problem is that it doesn't
happen so often.

I'm not familiar with the changes NeoMutt may have made to their
version, but if you can duplicate with a recent Mutt, I may be able
investigate further.

I'm trying to duplicate but no occurrence for the last three days.

Post by Kevin J. McCarthy
However, I do have a couple questions that may (or may not) be
relevant. Do you always see the crashes in the pager, or is it random?

I think it's when I just go back from editing with vim to the pager.

Post by Kevin J. McCarthy
Also, are you using IMAP?

Yes I do via offlineimap.

Thank you.

Best,
Steve

[Kevin J. McCarthy]

Post by steve
I think it's when I just go back from editing with vim to the pager.

Post by Kevin J. McCarthy
Also, are you using IMAP?

Yes I do via offlineimap.

It sounds like this may be triggered by offlineimap updating while you
are in the middle of composing the message.

NeoMutt checks for new mail in the pager too, but it looks like in 1.7.2
they botched the redraw-data updates, setting "max" before the index
data structures were updated.

It looks like this is fixed in the latest version link posted by Jörg.
However, I think it would be tricky to get Debian/Ubuntu to patch this
for a non-security issue. Your best bet would be to update. Another
workaround might be turning off $pager_index_lines.

[steve]

Post by Kevin J. McCarthy

Post by steve
I think it's when I just go back from editing with vim to the pager.

Post by Kevin J. McCarthy
Also, are you using IMAP?

Yes I do via offlineimap.

It sounds like this may be triggered by offlineimap updating while you
are in the middle of composing the message.
NeoMutt checks for new mail in the pager too, but it looks like in
1.7.2 they botched the redraw-data updates, setting "max" before the
index data structures were updated.
It looks like this is fixed in the latest version link posted by Jörg.
However, I think it would be tricky to get Debian/Ubuntu to patch this
for a non-security issue. Your best bet would be to update.

You mean compiling myself the last git version? I'd like to stick to
Debian's version if possible.

Post by Kevin J. McCarthy
Another workaround might be turning off $pager_index_lines.

Currently it's set to
pager_index_lines=9
which I find useful.

Since the problem hasn't occurred for the 4 last days, I'll wait a bit
before your suggested workaround.

Thanks a lot for your help.

Have a nice weekend.

Steve

[Jörg Sommer]

Post by steve

Post by Jörg Sommer

Post by steve
#0 0x00005592c9a59c68 in index_make_entry (s=0x7fff20afb090 "", l=1024, menu=<optimized out>, num=<optimized out>) at ../../curs_main.c:300
h = 0x5592cbef1670
flag = (MUTT_FORMAT_TREE | MUTT_FORMAT_MAKEPRINT | MUTT_FORMAT_ARROWCURSOR | MUTT_FORMAT_INDEX)
edgemsgno = 40
reverse = <optimized out>
tmp = <optimized out>

This is here
https://sources.debian.org/src/mutt/1.7.2-1+deb9u1/curs_main.c/#L300 and
in the current version (of neomutt) here
https://salsa.debian.org/mutt-team/neomutt/blob/master/curs_main.c#L550
The best would be to create a bug report and if you don't care too much, I
can send the developer the coredump in a *private* mail. He might dig out
something more.

That would be really nice of you. But does it mean I also have to open a
bug report?

I think that's the best to do. Do you have reportbug installed? This eases
the creation of bug reports.

Kind regards Jörg

[steve]

Post by Jörg Sommer

Post by steve

Post by Jörg Sommer

Post by steve
#0 0x00005592c9a59c68 in index_make_entry (s=0x7fff20afb090 "", l=1024, menu=<optimized out>, num=<optimized out>) at ../../curs_main.c:300
h = 0x5592cbef1670
flag = (MUTT_FORMAT_TREE | MUTT_FORMAT_MAKEPRINT | MUTT_FORMAT_ARROWCURSOR | MUTT_FORMAT_INDEX)
edgemsgno = 40
reverse = <optimized out>
tmp = <optimized out>

This is here
https://sources.debian.org/src/mutt/1.7.2-1+deb9u1/curs_main.c/#L300 and
in the current version (of neomutt) here
https://salsa.debian.org/mutt-team/neomutt/blob/master/curs_main.c#L550
The best would be to create a bug report and if you don't care too much, I
can send the developer the coredump in a *private* mail. He might dig out
something more.

That would be really nice of you. But does it mean I also have to open a
bug report?

I think that's the best to do. Do you have reportbug installed? This eases
the creation of bug reports.

Yes I have. Problem, it asks me if I really want to report a bug since
my version is said to be outdated. Moreover, looking at the already
reported bug, some might be the same, or very close, as mine. And other
problem, I can not reproduce it at will. So not enough information yet.
And as Kevin said, it might be related to offlineimap.

With therefore wait a bit and try to collect more info before opening a
bug.

[Nathan Stratton Treadway]

Post by steve
I have a new box for about two months and it appears that each time mutt
segfaults, the console freezes and I have to hard stop the machine. Here

When you say "the console freezes": are you able to log in normally
using another virtual terminal or ssh session or anything? Or is the
system fully locked up, no longer responding to pings, etc.? Does the
syslog file show any activity at all between the mutt segfault and the
restart-after-reboot messages?

If a Mutt segfault is really able to lock up the system entirely, that
is a sign of a bigger problem with your kernel and/or hardware (i.e. a
user process such as Mutt should not be able to lock up the entire
system, no matter how it crashes). Tracking down the Mutt coredump may
help you narrow down what part of the broader system is failing, but
really it seems like you are trying to figure out what system-wide
problem Mutt happens to be tickling....

Nathan

[steve]

Hi,

Post by Nathan Stratton Treadway

Post by steve
I have a new box for about two months and it appears that each time mutt
segfaults, the console freezes and I have to hard stop the machine. Here

When you say "the console freezes": are you able to log in normally
using another virtual terminal or ssh session or anything?

No. If switch to another console, and launch a 'ls' for example, the
cursor goes to the line and then nothing happens. Ctlr-x doesn't do
anything. Opening a new one and launching htop for example freeze the
terminal. But was it funny, is that I can firefox still works as
expected. At this stage I normally shutdown the computer physically.

Post by Nathan Stratton Treadway
Or is the
system fully locked up, no longer responding to pings, etc.? Does the
syslog file show any activity at all between the mutt segfault and the
restart-after-reboot messages?

No, nothing in syslog I think.

Post by Nathan Stratton Treadway
If a Mutt segfault is really able to lock up the system entirely, that
is a sign of a bigger problem with your kernel and/or hardware (i.e. a
user process such as Mutt should not be able to lock up the entire
system, no matter how it crashes). Tracking down the Mutt coredump may
help you narrow down what part of the broader system is failing, but
really it seems like you are trying to figure out what system-wide
problem Mutt happens to be tickling....

Yes, I think it might be a hardware problem triggered by a mutt
segfault. Still looking around.

Thank you,
Steve

[Nathan Stratton Treadway]

Post by steve
No. If switch to another console, and launch a 'ls' for example, the
cursor goes to the line and then nothing happens. Ctlr-x doesn't do
anything. Opening a new one and launching htop for example freeze the
terminal. But was it funny, is that I can firefox still works as
expected. At this stage I normally shutdown the computer physically.

Hmmm, interesting... the system is not truely locked up, but perhaps
it's now unable to launch new processes, or something like that. (It
would be interesting to know if an instance of "htop" running on another
console continues keep running even after the segfault, for example.)

[...]

Post by steve
No, nothing in syslog I think.

(It might be worth double-checking to make sure -- if for example [Byour
follow-on attempts to run "ls" and "htop" also show up as segfaults in
the log, that would certainly tell you something.)

Post by steve
Yes, I think it might be a hardware problem triggered by a mutt
segfault. Still looking around.

(The distinction may not matter in the end, but off hand I'd suspect the
hardware fault [or whatever it is] is causing both the mutt segfault and
the other symptoms you are seeing.)

Anyway, good luck tracking it down...

Nathan

[steve]

Post by Nathan Stratton Treadway

Post by steve
No. If switch to another console, and launch a 'ls' for example, the
cursor goes to the line and then nothing happens. Ctlr-x doesn't do
anything. Opening a new one and launching htop for example freeze the
terminal. But was it funny, is that I can firefox still works as
expected. At this stage I normally shutdown the computer physically.

Hmmm, interesting... the system is not truely locked up, but perhaps
it's now unable to launch new processes, or something like that. (It
would be interesting to know if an instance of "htop" running on another
console continues keep running even after the segfault, for example.)

I'll leave an htop running just in case.

Post by Nathan Stratton Treadway
[...]

Post by steve
No, nothing in syslog I think.

(It might be worth double-checking to make sure -- if for example [Byour
follow-on attempts to run "ls" and "htop" also show up as segfaults in
the log, that would certainly tell you something.)

Double checked and I'm pretty sure there is nothing else.

Post by Nathan Stratton Treadway

Post by steve
Yes, I think it might be a hardware problem triggered by a mutt
segfault. Still looking around.

(The distinction may not matter in the end, but off hand I'd suspect the
hardware fault [or whatever it is] is causing both the mutt segfault and
the other symptoms you are seeing.)

It's really only mutt (or neomutt…) that triggers the problem, no other
program.

Post by Nathan Stratton Treadway
Anyway, good luck tracking it down...

Thank you, I hope I can succeed (with your and Jörg nice help).

Best,
Steve

[Felix Finch]

Post by Nathan Stratton Treadway

Post by steve
No. If switch to another console, and launch a 'ls' for example, the
cursor goes to the line and then nothing happens. Ctlr-x doesn't do
anything. Opening a new one and launching htop for example freeze the
terminal. But was it funny, is that I can firefox still works as
expected. At this stage I normally shutdown the computer physically.

Hmmm, interesting... the system is not truely locked up, but perhaps
it's now unable to launch new processes, or something like that. (It
would be interesting to know if an instance of "htop" running on another
console continues keep running even after the segfault, for example.)

I have seen screen (the command!) leave the tty in a very confused state, where
it thinks the usable area is less than full size, such that scrolls for instance
only operate on a subsection.

Try "stty sane^J". If using screen or tmux, try ^D to exit and ^A^C or ^B^C to
open a new session. Sometimes I have cat'd a binary file by mistake and left
the tty so confused that I have to log out and back in. Do you have ssh set up,
and do you have a second computer you can ssh in from? Try ssh on that other
compputer just to have an independent tty available, and see if it behaves
normally after mutt locks things up.

One problem with power cycling is the file system recovery after a power loss;
you can avoid that by starting a root sleep+reboot in the background, which you
abort if you don't need it, otherwise let it reboot for you if possible.

sudo su -
(sleep 300; reboot) &
^D

and on to your mutt crashing. If mutt locks up, wait 5 minutes and see it it
reboots on its own. If not, power cycle. You can use "shutdown -h now" instead
of reboot if you want.

If nutt locks up but the other suggestions leave you with a working tty, or if
mutt doesn't lock up, you have 5 minutes to "sudo su -" again and kill the
sleep+reboot job.

Adjust the 300 second sleep to your patience; how quickly can you make mutt
lockup? How often do you wnat to kill and restart that sleeper, and how long do
you want to wait for it to reboot after a lockup?

You can start similar background jobs to report interesting data and wait a few
minutes, then on reboot, check its logged output.

while :; do date >>~/loggy; sleep 10; done &

You may need a nohup in there; try logging out with that running and make sure
it remans running. If mutt locks up, not the exact time, wiat 5 minutes, power
cycle, and check ~/loggy to see how long it kept logging.

[Felix Finch]

Post by Felix Finch
Try "stty sane^J".

I should have clarified; someimes the tty gets in such a state that it doesn't echo any characters nor recognize <ENTER>; you have to type this on blind faith it's getting through to the shell, and the ^J works when <ENTER> doesn't. You may need a ^C or ^Z beforehand to abort any existing command.

[steve]

Post by Felix Finch

Post by Nathan Stratton Treadway

Post by steve
No. If switch to another console, and launch a 'ls' for example, the
cursor goes to the line and then nothing happens. Ctlr-x doesn't do
anything. Opening a new one and launching htop for example freeze the
terminal. But was it funny, is that I can firefox still works as
expected. At this stage I normally shutdown the computer physically.

Hmmm, interesting... the system is not truely locked up, but perhaps
it's now unable to launch new processes, or something like that. (It
would be interesting to know if an instance of "htop" running on another
console continues keep running even after the segfault, for example.)

I have seen screen (the command!) leave the tty in a very confused state, where
it thinks the usable area is less than full size, such that scrolls for instance
only operate on a subsection.
Try "stty sane^J". If using screen or tmux, try ^D to exit and ^A^C or ^B^C to
open a new session. Sometimes I have cat'd a binary file by mistake and left
the tty so confused that I have to log out and back in. Do you have ssh set up,
and do you have a second computer you can ssh in from? Try ssh on that other
compputer just to have an independent tty available, and see if it behaves
normally after mutt locks things up.

I of course tried sshing the machine, but after password prompt, nothing
happened (I waited 3 minutes or so).

Post by Felix Finch
One problem with power cycling is the file system recovery after a power loss;
you can avoid that by starting a root sleep+reboot in the background, which you
abort if you don't need it, otherwise let it reboot for you if possible.
sudo su -
(sleep 300; reboot) &
^D

su was blocked too. In fact opening any new terminal left me with no
possibility to enter commands.

Post by Felix Finch
and on to your mutt crashing. If mutt locks up, wait 5 minutes and see it it
reboots on its own. If not, power cycle. You can use "shutdown -h now" instead
of reboot if you want.

Doesn't work either.

Post by Felix Finch
If nutt locks up but the other suggestions leave you with a working tty, or if
mutt doesn't lock up, you have 5 minutes to "sudo su -" again and kill the
sleep+reboot job.
Adjust the 300 second sleep to your patience; how quickly can you make mutt
lockup? How often do you wnat to kill and restart that sleeper, and how long do
you want to wait for it to reboot after a lockup?
You can start similar background jobs to report interesting data and wait a few
minutes, then on reboot, check its logged output.
while :; do date >>~/loggy; sleep 10; done &
You may need a nohup in there; try logging out with that running and make sure
it remans running. If mutt locks up, not the exact time, wiat 5 minutes, power
cycle, and check ~/loggy to see how long it kept logging.

Thanks Felix for this lengthy help, but it looks a bit too much for me
of an action. I'm getting too old for this kind of fun  ;) That's why I
love Debian, it's so rock solid and stable that I don't need to go in
that kind of things (any more).


Best,
Steve

[steve]

Hi There,

Just an update on this issue.

My machine just froze while NOT using mutt. I was in the terminal, typed
the few first letters of a command, then hit <TAB> and the machine
froze. So to my big despair, it is not a mutt issue; I bet it's more a
hardware issue, and that is bad.

Have a nice day,
Steve