zevlg / telega.el

GNU Emacs telegram client (unofficial)
https://zevlg.github.io/telega.el/
GNU General Public License v3.0
1.09k stars 85 forks source link

Telega-server coredump when I send a message #405

Closed kiddouk closed 1 year ago

kiddouk commented 1 year ago

Telega Setup

OS: Arch Linux Emacs: GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.17.6) Features: svg ffmpeg tgs2png Telega: telega v0.8.120 (TDLib v1.8.12-0c09070) (telega-server v0.8.2) MELPA: 20230315.1858

Current Behavior

I type a message in a chat, and I get the following error

[11]telega-server: segmentation fault (core dumped)
Error in post-command-hook (telega-chatbuf--post-command): (error "telega-server is not running")

Steps to Reproduce

  1. Start telega
  2. Browse to a chat and press enter
  3. Type something then press enter.
zevlg commented 1 year ago

Examine few trailing lines of the ~/.telega/telega-server.log to find out the reason of the crash.

Take into account that telega overwrites this log after restart, so you should examine it just after the crash

kiddouk commented 1 year ago

hmmm, the logs gives nothing. I doubt thattelega-server has time to log its exception.

I run emacs in daemon mode. I havent done any special except this config

  (use-package telega
    :init
    (setq telega-server-libs-prefix "/usr/")
    (setq telega-use-images t)
    )

For the sake of transparency, here are the last lines that shows that I input a text message.

[ 3][t 4][1679053089.854738235][Td.cpp:3997][#1][!Td][&td_requests] Sending result for request 22: ok {
}
[ 3][t 0][1679053089.854854583][Client.cpp:293][&td_requests]   End to wait for updates, returning object 22 0x7fce543eb020
[ 3][t 0][1679053089.854950904][Client.cpp:280][&td_requests]   Begin to wait for updates with timeout 10.000000
[ 3][t 4][1679053090.662424087][Td.cpp:2918][#1][!Td][&td_requests] Receive request 23: sendMessage {
  chat_id = 759554787
  message_thread_id = 0
  reply_to_message_id = 0
  options = null
  reply_markup = null
  input_message_content = inputMessageText {
    text = formattedText {
      text = "meh"
      entities = vector[0] {
      }
    }
    disable_web_page_preview = false
    clear_draft = true
  }
}
[ 3][t 4][1679053090.662447929][MessagesManager.cpp:26578][#1][!Td] Begin to send message to chat 759554787 in reply to invalid message 0
[ 3][t 4][1679053090.662455558][MessageContent.cpp:2246][#1][!Td]   Get input message content from inputMessageText {
  text = formattedText {
    text = "meh"
    entities = vector[0] {
    }
  }
  disable_web_page_preview = false
  clear_draft = true
}
[ 3][t 4][1679053090.662465333][MessageContent.cpp:1927][#1][!Td]   Create InputMessageContent with file 0(0) and thumbnail 0(0)
zevlg commented 1 year ago

In this case I'm afraid the only way to debug this is to examine coredump with gdb, i.e.

$ gdb ~/.telega/telega-server telega-server.core
...
(gdb) bt

this will give a backtrace at coredump time

zevlg commented 1 year ago

Another thing to try is to start with telega with fresh database directory

kiddouk commented 1 year ago

trying with an empty database directory (empty ~/.telega) results in the same behavior.

kiddouk commented 1 year ago

regarding the coredump, it seems that systemd-coredump is catching the stacktrace automagically. However, it seems that I compiled libtd without debug support.

Mar 17 15:14:55 lightspeed systemd-coredump[1118125]: [🡕] Process 1116666 (telega-server) of user 1000 dumped core.

                                                      Stack trace of thread 1116670:
                                                      #0  0x00007f2d49b72e80 n/a (libtdjson.so.1.8.12 + 0xcbfe80)
                                                      #1  0x00007f2d49cfbf7f n/a (libtdjson.so.1.8.12 + 0xe48f7f)
                                                      #2  0x00007f2d49363d38 n/a (libtdjson.so.1.8.12 + 0x4b0d38)
                                                      #3  0x00007f2d4942a6a5 n/a (libtdjson.so.1.8.12 + 0x5776a5)
                                                      #4  0x00007f2d4942ac11 n/a (libtdjson.so.1.8.12 + 0x577c11)
                                                      #5  0x00007f2d4912e246 n/a (libtdjson.so.1.8.12 + 0x27b246)
                                                      #6  0x00007f2d4912e414 n/a (libtdjson.so.1.8.12 + 0x27b414)
                                                      #7  0x00007f2d4912ad47 n/a (libtdjson.so.1.8.12 + 0x277d47)
                                                      #8  0x00007f2d4a012323 n/a (libtdjson.so.1.8.12 + 0x115f323)
                                                      #9  0x00007f2d4a00fa00 n/a (libtdjson.so.1.8.12 + 0x115ca00)
                                                      #10 0x00007f2d4a00fe5a n/a (libtdjson.so.1.8.12 + 0x115ce5a)
                                                      #11 0x00007f2d4a010065 n/a (libtdjson.so.1.8.12 + 0x115d065)
                                                      #12 0x00007f2d4a0102ce n/a (libtdjson.so.1.8.12 + 0x115d2ce)
                                                      #13 0x00007f2d4a008d73 n/a (libtdjson.so.1.8.12 + 0x1155d73)
                                                      #14 0x00007f2d49128f1c n/a (libtdjson.so.1.8.12 + 0x275f1c)
                                                      #15 0x00007f2d49127dbc n/a (libtdjson.so.1.8.12 + 0x274dbc)
                                                      #16 0x00007f2d48d528fd n/a (libc.so.6 + 0x868fd)
                                                      #17 0x00007f2d48dd4a60 n/a (libc.so.6 + 0x108a60)

                                                      Stack trace of thread 1116666:
                                                      #0  0x00007f2d48dc304c read (libc.so.6 + 0xf704c)
                                                      #1  0x00007f2d48d4b656 _IO_file_underflow (libc.so.6 + 0x7f656)
                                                      #2  0x00007f2d48d4c686 _IO_default_uflow (libc.so.6 + 0x80686)
                                                      #3  0x00007f2d48d4006b _IO_getline_info (libc.so.6 + 0x7406b)
                                                      #4  0x00007f2d48d3f142 _IO_fgets (libc.so.6 + 0x73142)
                                                      #5  0x000056061c4a8b3e n/a (/home/nodemo/.telega/telega-server + 0x6b3e)
                                                      #6  0x000056061c4a8fc9 n/a (/home/nodemo/.telega/telega-server + 0x6fc9)
                                                      #7  0x00007f2d48cef290 n/a (libc.so.6 + 0x23290)
                                                      #8  0x00007f2d48cef34a __libc_start_main (libc.so.6 + 0x2334a)
                                                      #9  0x000056061c4a8355 n/a (/home/nodemo/.telega/telega-server + 0x6355)
                                                      ELF object binary architecture: AMD x86-64
â–‘â–‘ Subject: Process 1116666 (telega-server) dumped core
â–‘â–‘ Defined-By: systemd
â–‘â–‘ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
â–‘â–‘ Documentation: man:core(5)
â–‘â–‘ 
â–‘â–‘ Process 1116666 (telega-server) crashed and dumped core.
â–‘â–‘ 
â–‘â–‘ This usually indicates a programming error in the crashing program and
â–‘â–‘ should be reported to its vendor as a bug.

I am tempted to install master branch of libtd and/or activating debug symbols so we can see a bit more what is going on there.

kiddouk commented 1 year ago

End of story, moving away from commit tdlib/td@0c09070ce5 has fixed it. Reading the history, I think that this is tdlib/td@7e4f349da80917a13dccbeb61dea0bdaa76752a3 that fixed it.

kiddouk commented 1 year ago

closing this as this was specific to my build.