Core dumped at the moment of switching to a new unread chat

[dvragulin]

Description:

8272 IOT instruction (core dumped)  nchat -d /home/dvragulin/.config/chat/telegram -ee

This behavior occurred after the transition from version 3.67 to 4.13. Unfortunately, I can't figure out how this behavior will be properly debugged. There is no information in the logs on this issue.

How to reproduce it:
I press ctrl+F and move on to the next chat. At this point, the application crashes. It does not fall every time, but with a frequency that I could not establish.

Environment:

• Version: v4.13
• OS / distro: Arch Linux x86_64 / zsh 5.9

[dvragulin]

Now I'm faced with the fact that it crashes at startup. Can you tell me how to debug this behavior? '-e` does not give any output to stdout...

upd:
The current log was in the directory with configs, here is the output of the log:

2023-12-28 22:00:22.555 | INFO  | starting nchat v4.13  (main.cpp:239)
2023-12-28 22:00:22.564 | INFO  | entering ui loop  (ui.cpp:95)

I think it's important to know that I'm using alacritty 0.13.0 (78fa4d6f)

upd: See the attachment for the -ee output, sorry for not providing it right away.
log.txt

[d99kris]

Hi @dvragulin - thanks for reporting the bug. Unfortunately the logs do not provide sufficient insight for this crash.

Could you help to get the callstack of the first crash you encountered?

1. Determine PID of the crashed nchat instance
List nchat core dumps:

coredumpctl list nchat

It will output something like:

TIME                         PID  UID  GID SIG     COREFILE EXE                
Fri 2023-12-29 10:36:42 +08 1651 1000 1000 SIGSEGV present  /usr/local/bin/nchat
Fri 2023-12-29 10:37:25 +08 1666 1000 1000 SIGSEGV present  /usr/local/bin/nchat

Find the timestamp which matches when you encountered the crash and take note of the PID column. (Based on the provided log.txt your crash timestamp should be around 2023-12-28 22:03:22.)

2. Get the callstack of the crash
Use the PID obtained from previous step, e.g. 1666, and use coredumpctl to start gdb:

coredumpctl debug 1666

Get callstacks of all threads in the process:

thread apply all bt

Copy all text starting from Program terminated with signal ... and save in a text file and please help to upload here. See attached crash-callstack-example.txt for an example. Finally quit gdb:

quit

[dvragulin]

Of course, here's the stdout: stdout.log

[d99kris]

Thank you 👍
I still can't say with certainty what is causing it, but I see some things I can improve in the code path where it crashes (mainly adding null pointer checks).

If you are free to try one more thing, it would be very useful if you could build a debug build, reproduce the crash and get callstack (above steps). To build a debug build one can run the following from the source clone of nchat:

./make.sh debug

And then you could run it without installing, like this

./dbgbuild/bin/nchat -d ~/.config/chat/telegram

Once crashed one can follow the steps in above comment (using coredumpctl).

In any case I will prepare some code changes to improve the robustness, which may or may not fix the crash you're seeing.

I'll update here again once the "blind" robustness fixes are available.

[d99kris]

The above commit adds some "blind" robustness fixes which may or may not address the crash you are seeing.

In case you still see the crash after above fix, it would be very useful to get callstack from a debug build.

[dvragulin]

That's it, here's the result of the first run in the debug mode: stdout.log

[d99kris]

Thank you 👍 This is very useful information!
It seems like it's a bug in tdlib (which nchat uses for Telegram), more specifically its markdown conversion code.

If you could open your debug core dump again coredumpctl debug nnnnn and run the following it would be very useful:

set print elements 0
f 17
p text
f 11
p text
p result
quit

Getting above info (basically what markdown message it's trying to convert) can help me determine if tdlib has fixed this in its latest code, or whether I should report a bug in the their project. Note: The output from the commands will contain message content, so if you don't want to share it here publicly, you can email it to me (d99kris at gmail dot com) or perhaps censor it (just try not to change the number of characters).

As a temporary workaround for this bug you can try disabling markdown conversion for Telegram. Edit the following file:

~/.nchat/profiles/Telegram_+nnnnnnnnn/telegram.conf 

And set:

markdown_enabled=0

[dvragulin]

@d99kris Indeed, the markdown shutdown solution helped solve the problem. Frankly, I don't even see much difference in the text.

Here I suggest you take a look: stdout.log

I have replaced sensitive text sentences with SomeText in the hope that only the syntax will be enough for you.
Thank you very much for your help and support! ❤️

[d99kris]

Hi again, many thanks for providing the information! 👍
I was now able to reproduce the crash on my machine. It appears the markdown conversion crashes when a link text is bold, underlined and in a block quote. I tested latest version of tdlib, and the crash appears to be fixed there. I've updated nchat to use latest tdlib in b4d1fa5. You should be able to re-enable markdown conversion if you like and use latest nchat. Feel free to re-open this issue if you're still encountering the issue.

FYI - with markdown conversion disabled, all messages look like plain text. For example if someone sends a message:
Message with bold and italic text.

Then nchat will display it as:

Message with bold and italic text.

Whereas if you have markdown conversion enabled, nchat will show it as:

Message with *bold* and _italic_ text.

And similarly when sending messages, with markdown conversion enabled one can do basic formatting and send text like:

Message with *bold* and _italic_ text.

And it should show up in the mobile app like:
Message with bold and italic text.