majn / telegram-purple

Adds support for Telegram to Pidgin, Adium, Finch and other Libpurple based messengers.
GNU General Public License v2.0
735 stars 81 forks source link

Random crashes and disconnects. #162

Closed Silent-Hunter closed 8 years ago

Silent-Hunter commented 8 years ago

I was having problems with random crashes, so I just updated less than an hour ago, and now it also disconnects randomly, as well as not receiving messages and still crashing. I'm not sure what exactly is happening, but since no one else has reported this, can I assume it's only happening to me?

majn commented 8 years ago

Hi, a little more info about those crashes? Bug reports like that can make me aware of the fact that there is an issue, but they will help me very little actually fixing it.

I need core dumps, distribution, pidgin logs, basically any information about your environment and the crashes I can get.

Silent-Hunter commented 8 years ago

Absolutely and thank you for replying to this so quickly! I was a little frustrated earlier, but I'm more calm and able to troubleshoot now.

What command should I use to get this information? I have the debug symbols built into Pidgin, so it prints a LOT of information to the console. Does Pidgin save a log in /tmp or somewhere? Or shall I use gdb?

majn commented 8 years ago

pidgin -d will start in debug mode, the log would be useful. Otherwise start it with gdb and use it until it crashes. If it crashes, enter the command "bt" in gdb

Silent-Hunter commented 8 years ago

Alright! I will not have time for this tonight, because it can take a while before it does it, so I will do that tomorrow. Thank you for your help, and thanks for the plugin, until now it's been lovely!

On Sun, Nov 22, 2015 at 5:15 PM, mj notifications@github.com wrote:

pidgin -d will start in debug mode, the log would be useful. Otherwise start it with gdb and use it until it crashes.

— Reply to this email directly or view it on GitHub https://github.com/majn/telegram-purple/issues/162#issuecomment-158808094 .

Silent-Hunter commented 8 years ago

OK, I've been using it for over six hours with no problems, so I don't know what to do. Either starting it with -d fixed it somehow, or it was a fluke. I'll get back to you if it ever happens again.

Silent-Hunter commented 8 years ago

It crashed! Where do I find the log file that starting Pidgin with -d created?

majn commented 8 years ago

In your terminal, when you execute pidgin

majn commented 8 years ago

Btw, depending on your linux distribution there may be other places where crash reports are stored. If you use something based on Gnome3 the tool gnome-abrt shows you the last crashes including stack trace.

Silent-Hunter commented 8 years ago

Oh crap, well the terminal didn't log far enough, I thought it would store it in a file. Can I use the usual funnel method to get it into a file?

majn commented 8 years ago

Just do the following:

gdb pidgin

When gdb is loaded start the application with:

run

Once it crashes you can get the backtrace with, copy/paste the output here.

bt
EionRobb commented 8 years ago

@majn in future, might be easier to point to https://developer.pidgin.im/wiki/GetABacktrace which has instructions about the debug logging and backtracing

Silent-Hunter commented 8 years ago

Yeah it didn't crash all day. I would close this, I'm not sure what happened but it's stable now, or at least seems so. Can running something with gdb change its behaviour?

Silent-Hunter commented 8 years ago

Well, it crashed, does this tell you anything?

0 0x00007ffff4c153b7 in raise () from /lib64/libc.so.6

1 0x00007ffff4c1674a in abort () from /lib64/libc.so.6

2 0x00007ffff4c54030 in ?? () from /lib64/libc.so.6

3 0x00007ffff4c594fe in ?? () from /lib64/libc.so.6

4 0x00007ffff4c59ceb in ?? () from /lib64/libc.so.6

5 0x00007ffff5d5e060 in purple_imgstore_unref () from /usr/lib64/libpurple.so.0

6 0x0000000000473259 in ?? ()

7 0x00007ffff57e325a in g_object_unref () from /usr/lib64/libgobject-2.0.so.0

8 0x00007ffff6dc63ae in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

9 0x00007ffff6cf1e7f in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

10 0x00007ffff57de20f in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0

11 0x00007ffff57f03f6 in ?? () from /usr/lib64/libgobject-2.0.so.0

12 0x00007ffff57f86c8 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0

13 0x00007ffff57f8927 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0

14 0x00007ffff6d8da30 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

15 0x00007ffff57e4be8 in g_object_run_dispose () from /usr/lib64/libgobject-2.0.so.0

16 0x00007ffff6cbea8a in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

17 0x00007ffff6cf1e7f in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

18 0x00007ffff57de20f in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0

19 0x00007ffff57f03f6 in ?? () from /usr/lib64/libgobject-2.0.so.0

20 0x00007ffff57f86c8 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0

21 0x00007ffff57f8927 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0

22 0x00007ffff6d8da30 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

---Type to continue, or q to quit---

23 0x00007ffff57e4be8 in g_object_run_dispose () from /usr/lib64/libgobject-2.0.so.0

24 0x00007ffff6d2d6cb in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

25 0x00007ffff6cf1e7f in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

26 0x00007ffff57de20f in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0

27 0x00007ffff57f03f6 in ?? () from /usr/lib64/libgobject-2.0.so.0

28 0x00007ffff57f86c8 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0

29 0x00007ffff57f8927 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0

30 0x00007ffff6d8da30 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

31 0x00007ffff57e4be8 in g_object_run_dispose () from /usr/lib64/libgobject-2.0.so.0

32 0x00007ffff6cbea8a in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

33 0x00007ffff6cf1e7f in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

34 0x00007ffff57de20f in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0

35 0x00007ffff57f03f6 in ?? () from /usr/lib64/libgobject-2.0.so.0

36 0x00007ffff57f86c8 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0

37 0x00007ffff57f8927 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0

38 0x00007ffff6d8da30 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

39 0x00007ffff57e4be8 in g_object_run_dispose () from /usr/lib64/libgobject-2.0.so.0

40 0x00007ffff6cbea8a in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

41 0x00007ffff6cf1e7f in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

42 0x00007ffff57de2b5 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0

43 0x00007ffff57f03f6 in ?? () from /usr/lib64/libgobject-2.0.so.0

44 0x00007ffff57f86c8 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0

45 0x00007ffff57f8927 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0

---Type to continue, or q to quit---

46 0x00007ffff6d8da30 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

47 0x00007ffff57e4be8 in g_object_run_dispose () from /usr/lib64/libgobject-2.0.so.0

48 0x000000000045e87d in ?? ()

49 0x00007ffff5d55ac5 in purple_conversation_destroy () from /usr/lib64/libpurple.so.0

50 0x00007ffff54d9d3d in g_list_foreach () from /usr/lib64/libglib-2.0.so.0

51 0x0000000000450e2c in ?? ()

52 0x000000000045df71 in ?? ()

53 0x00007ffff57de4e4 in ?? () from /usr/lib64/libgobject-2.0.so.0

54 0x00007ffff57f7fda in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0

55 0x00007ffff57f8927 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0

56 0x00007ffff6cc8365 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

57 0x00007ffff57de4e4 in ?? () from /usr/lib64/libgobject-2.0.so.0

58 0x00007ffff57f7fda in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0

59 0x00007ffff57f8927 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0

60 0x00007ffff6cc7269 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

61 0x00007ffff6d692a5 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

62 0x00007ffff57de2b5 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0

63 0x00007ffff57efef7 in ?? () from /usr/lib64/libgobject-2.0.so.0

64 0x00007ffff57f81d8 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0

65 0x00007ffff57f8927 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0

66 0x00007ffff6e78e44 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0

67 0x00007ffff6d67a54 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0

68 0x00007ffff6d67e0b in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0

---Type to continue, or q to quit---

69 0x00007ffff69e3b9c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0

70 0x00007ffff54dd8fd in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0

71 0x00007ffff54ddbe0 in ?? () from /usr/lib64/libglib-2.0.so.0

72 0x00007ffff54ddf02 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0

73 0x00007ffff6d66ef7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0

74 0x000000000043183d in main ()

Sorry about all the trouble.

Silent-Hunter commented 8 years ago

It seems to often happen on closing a tab actually.

BenWiederhake commented 8 years ago

#5 0x00007ffff5d5e060 in purple_imgstore_unref () from /usr/lib64/libpurple.so.0 together with "crash on closing a tab" sounds a lot like there's a double-free (or "not allocated using g_malloc or whatever glib expects") of an image. As far as I remember, tgp knows three types of images:

majn commented 8 years ago

Your telegram-purple version would be nice to know

Silent-Hunter commented 8 years ago

How do I check the version? I just checked out the repo and built it. On Nov 27, 2015 5:30 AM, "mj" notifications@github.com wrote:

Your telegram-purple version would be nice to know

— Reply to this email directly or view it on GitHub https://github.com/majn/telegram-purple/issues/162#issuecomment-160107811 .

BenWiederhake commented 8 years ago

Execute git log HEAD^.. and tell us the result. That's the most detailed version information one can obtain.

Silent-Hunter commented 8 years ago

commit 6cfeeb4835481e544a05a81f253dec8e6f63ca84 Merge: 09339c7 2e3951f Author: mj mtthsjntsch@gmail.com Date: Sat Nov 21 09:27:22 2015 +0100

Merge pull request #159 from tuxmaster/master

Fix rpm spec file.

commit 2e3951f5a5a6fc3050923c6a019aa22e12f7daed Author: tuxmaster frank@familie-büttner.de Date: Wed Nov 18 15:05:10 2015 +0100

Add missing space.

commit f7b01583fc34c8125d52d6785a5cf891e9f7202d Author: tuxmaster frank@familie-büttner.de Date: Wed Nov 18 15:03:40 2015 +0100

Add required version for libgcrypt.

commit 2f5c70b04bed231fdce035464bef511d38500712 Author: tuxmaster frank@familie-büttner.de Date: Tue Nov 17 18:53:09 2015 +0100

-Fix date for rpm spec file.

There ya go! I hope it helps.

On Fri, Nov 27, 2015 at 8:05 AM, Ben Wiederhake notifications@github.com wrote:

Execute git log HEAD^.. and tell us the result. That's the most detailed version information one can obtain.

— Reply to this email directly or view it on GitHub https://github.com/majn/telegram-purple/issues/162#issuecomment-160135800 .

BenWiederhake commented 8 years ago

Then you have a new version (not the newest, but new enough) from master.

This bug is bad, and we're interested in resolving it. (Just to reassure you :P)

Do you recall what you were sending each other? Stickers, or other images?

Silent-Hunter commented 8 years ago

Well, no stickers, there was one the other day but there was no crash that day. Images yes, but the crashes are unrelated to those, seemingly. It seems like it's related to using Ctrl+W to close a tab.

On Fri, Nov 27, 2015 at 10:02 AM, Ben Wiederhake notifications@github.com wrote:

Then you have a new version (not the newest, but new enough) from master.

This bug is bad, and we're interested in resolving it. (Just to reassure you :P)

Do you recall what you were sending each other? Stickers, or other images?

— Reply to this email directly or view it on GitHub https://github.com/majn/telegram-purple/issues/162#issuecomment-160155723 .

BenWiederhake commented 8 years ago

@Silent-Hunter: Sorry for my lack of response. If you have sent images, then the theory "tried to double-free an image-ref" makes sense.

Does this still occur in 1.2.5?

Silent-Hunter commented 8 years ago

It doesn't happen anymore, no. Thanks for fixing that!

On Sat, Feb 20, 2016 at 10:17 AM Ben Wiederhake notifications@github.com wrote:

@Silent-Hunter https://github.com/Silent-Hunter: Sorry for my lack of response. If you have sent images, then the theory "tried to double-free an image-ref" makes sense.

Does this still occur in 1.2.5?

— Reply to this email directly or view it on GitHub https://github.com/majn/telegram-purple/issues/162#issuecomment-186623271 .