Como posso depurar o Mutt quando ele congela?

2

Minha instalação do Mutt parece funcionar bem em todos os aspectos, exceto que ele trava se eu deixá-lo aberto por muito tempo. Enquanto eu continuar interagindo com a interface, ela parece permanecer viva. Mas se eu começar a escrever um email ou deixá-lo ficar ocioso por muito tempo, ele congela. Ctrl+c não mata, então eu só tenho que suspendê-lo com Ctrl+z e matá-lo com kill <pid> .

Em vez de perguntar sobre o que pode estar errado com a minha instalação, gostaria de saber como esse tipo de problema seria depurado. (Embora qualquer sugestão seja super útil!) Como a tela do Mutt está congelada, não tenho a menor ideia do que está acontecendo. Qual é a melhor maneira de depurar algo assim?

    
por Sauce McBoss 11.11.2016 / 17:21

2 respostas

0

mutt pode ser iniciado no modo de depuração. Isso produzirá um arquivo de depuração .muttdebug0 que pode ajudar na depuração.

Na página mutt man:

-d level
      If mutt was complied with +DEBUG log debugging output to ~/.muttdebug0.  
      Level can range from 1-5 and effects verbosity. 
      A value of 2 is recommended.

Outra abordagem é abrir duas sessões de terminal, lado a lado. Execute top ou htop em um. No outro, execute mutt . Quando o problema aparecer, dê uma olhada no que top exibe. (Se top também congela, o problema pode ser maior que mutt .)

Você também pode editar sua postagem para incluir mais informações sobre o seu sistema e o que ele está fazendo.

  1. Se mutt trava ao mesmo tempo todos os dias, é outro trabalho algo com E / S naquela época?
  2. Se mutt sempre trava após N número de minutos após o login, você tem alguma outra tarefa que inicia no login e consome muitos recursos? (Executar mutt no modo de depuração várias vezes ajudará a identificar padrões nos arquivos de log.)
  3. Você tem acesso a /var/log/messages ou outros registros ou sar ?

Pode ser mutt ou mutt de congelamento pode ser um sintoma de outra coisa.

    
por 01.12.2016 / 23:01
0

Eu anexado a um processo mutt congelado com o gdb. Aqui está o que eu encontrei:

(gdb) bt

#0  0x00007f8327de76b0 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f832899014b in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2  0x00007f832898e16b in BIO_read () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#3  0x00007f8328cadb54 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#4  0x00007f8328caed55 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#5  0x00007f8328cac174 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#6  0x0000000000484365 in ssl_socket_read (conn=<optimized out>, buf=<optimized out>, len=<optimized out>) at mutt_ssl.c:304
#7  0x0000000000485bb7 in mutt_sasl_conn_read (conn=0xa1d660, 
    buf=0xa1d7f0 "+ idling\r\nDLE terminated (Success)\r\n38441 INTERNALDATE \"15-Oct-2017 12:27:13 +0000\" FLAGS () BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY"..., len=1024) at mutt_sasl.c:555
#8  0x00000000004836b9 in mutt_socket_readchar (conn=conn@entry=0xa1d660, c=c@entry=0x7ffc9ee890cf "") at mutt_socket.c:172
#9  0x00000000004837d2 in mutt_socket_readln_d (buf=0xa266a0 "+ idling", buflen=512, conn=0xa1d660, dbg=dbg@entry=2) at mutt_socket.c:202
#10 0x0000000000490328 in imap_cmd_step (idata=idata@entry=0x9fe990) at command.c:112
#11 0x0000000000491188 in imap_exec (idata=0x9fe990, cmdstr=cmdstr@entry=0x0, flags=flags@entry=1) at command.c:244
#12 0x00000000004912fc in cmd_queue (cmdstr=0x4b3de5 "IDLE", idata=0x9fe990) at command.c:377
#13 cmd_start (idata=0x9fe990, cmdstr=0x4b3de5 "IDLE", flags=0) at command.c:402
#14 0x0000000000491370 in imap_cmd_start (cmdstr=0x4b3de5 "IDLE", idata=idata@entry=0x9fe990) at command.c:76
#15 imap_cmd_idle (idata=idata@entry=0x9fe990) at command.c:313
#16 0x0000000000493328 in imap_check_mailbox (ctx=ctx@entry=0xa37ba0, index_hint=index_hint@entry=0x7ffc9ee89214, force=force@entry=0) at imap.c:1401
#17 0x0000000000442d2a in mx_check_mailbox (ctx=0xa37ba0, index_hint=index_hint@entry=0x7ffc9ee89214, lock=<optimized out>, lock@entry=0) at mx.c:1336
#18 0x000000000041e1b8 in mutt_index_menu () at curs_main.c:555
#19 0x000000000040833c in main (argc=1, argv=<optimized out>) at main.c:1061

Ele estava esperando infinitamente em uma leitura de bloqueio. Para consertar isso, deve-se ler com um tempo limite ou tornar a chamada cancelável, de modo que ela seja interrompida ao receber um sinal como SIGINT.

    
por 17.10.2017 / 09:28