khyperia / weechat-discord

Unmaintained! And also apparently this is against their TOS so DON'T USE THIS -- Weechat plugin for Discord support - https://weechat.org/ https://discordapp.com/
MIT License
51 stars 24 forks source link

Weechat immediately crashes on /discord connect #28

Closed FredrIQ closed 7 years ago

FredrIQ commented 7 years ago

See above. I tried to set up this plugin earlier on 1.4 which was apparently too old. So I ended up compiling 2.0-dev from weechat repos (the "default" way, just 'mkdir build && cd build && cmake .. && make && sudo make install') and then build weecord. This seemed to work, but when I fired up weechat and did /discord connect (after supplying token), the client immediately proceeded to crash. Tried 1.9 and 1.8 as well with the same result (rebuilding weecord each time with cargo clean && cargo build --release). Using Ubuntu 16.04LTS. There didn't appear to be anything wrong with weechat setup besides this after version change.

[2151][fiq@fiq ~/weechat-discord]$ cargo --version
cargo 0.20.0 (a60d185c8 2017-07-13)
[2152][fiq@fiq ~/weechat-discord]$ rustc --version
rustc 1.19.0 (0ade33941 2017-07-17)
khyperia commented 7 years ago

Oh boy. That sounds... bad.

A couple things that will hopefully help us track down the problem:

A couple other guesses can be ruled out by the fact it crashes on connect, not at plugin init - for example, a missing .so dependency isn't the problem, and I do a couple weechat calls at plugin init (for example, "register command", which I think is the incompatible one everyone's been reporting from 1.4), so it's not basic ffi that's broken.

If you have any other information or ideas to try, let me know. Thanks for reporting the issue!

FredrIQ commented 7 years ago

Before setting up weechat 2.0-dev (etc), I removed the existing weechat, weechat-core, weechat-curses, weechat-plugins packages just in case they were to interfere. I then, once I built 2.0-dev, ran cargo clean followed by cargo build --release. I did this for every version change as well. Also, sorry, I should have clarified -- it doesn't crash with sigsegv/similar but rather just seems to freeze, consuming 100%CPU, and ignoring sigterm (so I just killed it). The only log file in .weechat is a weechat.log that doesn't seem to contain anything useful:

[2017-07-25 10:43:03] WeeChat 2.0-dev (git: v1.9-216-gef019b6) (compiled on Jul 24 2017 23:57:47) [2017-07-25 10:43:03] Reading configuration file sec.conf [2017-07-25 10:43:03] Reading configuration file weechat.conf [2017-07-25 10:43:03] Reading configuration file plugins.conf [2017-07-25 10:43:03] Reading configuration file charset.conf [2017-07-25 10:43:03] Reading configuration file logger.conf [2017-07-25 10:43:03] Reading configuration file exec.conf [2017-07-25 10:43:03] Reading configuration file trigger.conf [2017-07-25 10:43:03] Reading configuration file alias.conf [2017-07-25 10:43:03] Reading configuration file buflist.conf [2017-07-25 10:43:03] Reading configuration file fifo.conf [2017-07-25 10:43:03] Reading configuration file xfer.conf [2017-07-25 10:43:03] Reading configuration file irc.conf [2017-07-25 10:43:03] Reading configuration file relay.conf [2017-07-25 10:43:03] Reading configuration file buffers.conf [2017-07-25 10:43:03] Reading configuration file iset.conf [2017-07-25 10:43:04] Reading configuration file colorize_nicks.conf [2017-07-25 10:43:04] Reading configuration file script.conf [2017-07-25 10:43:04] Reading configuration file fset.conf [2017-07-25 10:43:04] irc: connecting to server 127.0.0.1/6667... [2017-07-25 10:43:04] irc: connecting to server 127.0.0.1/6667... [2017-07-25 10:43:04] irc: connecting to server 127.0.0.1/6667... [2017-07-25 10:43:04] irc: connecting to server fiq.se/6667...

khyperia commented 7 years ago

Okay, locking up is way different than crashing :) - basically all of my previous advice is invalid/irrelevant.

I think probably the best way to fix this is to attach with a debugger and show a backtrace to find out where it's locking up. If you're comfortable with gdb, use that (for some reason I couldn't get gdb to display symbol names, lldb displays them without me doing anything), but:

# terminal 1
weechat
# terminal 2
sudo lldb -p $(pgrep weechat)
thread backtrace all

Should look something like:

(lldb) thread backtrace -c 5 all
* thread #1, name = 'weechat', stop reason = signal SIGSTOP
  * frame #0: 0x00007fdf24aece9d libc.so.6`__GI___poll + 45
    frame #1: 0x00000000004455b6 weechat`hook_fd_exec + 198
    frame #2: 0x000000000048e1f7 weechat`gui_main_loop + 151
    frame #3: 0x0000000000421055 weechat`main + 21
    frame #4: 0x00007fdf24a294ca libc.so.6`__libc_start_main + 234
  thread #2, name = 'weechat'
    frame #0: 0x00007fdf2534c1ad libpthread.so.0`__pthread_cond_wait + 509
    frame #1: 0x00007fdf1acc2d67 libgc.so.1`___lldb_unnamed_symbol283$$libgc.so.1 + 23
    frame #2: 0x00007fdf1acb88aa libgc.so.1`___lldb_unnamed_symbol130$$libgc.so.1 + 106
    frame #3: 0x00007fdf1acc2d37 libgc.so.1`___lldb_unnamed_symbol282$$libgc.so.1 + 135
    frame #4: 0x00007fdf25346049 libpthread.so.0`start_thread + 217
  thread #3, name = 'Discord Keepali'
    frame #0: 0x00007fdf2534fd8d libpthread.so.0`__GI___nanosleep + 45
    frame #1: 0x00007fdf1ef73e50 libweecord.so`std::sys::imp::thread::Thread::sleep::h88857e006ce0b71a + 96
    frame #2: 0x00007fdf1ef399ce libweecord.so`std::thread::sleep::he790e2df1e699409 + 30
    frame #3: 0x00007fdf1eccce2c libweecord.so`discord::connection::keepalive::h4f44a291b3dd1ae3 + 332
    frame #4: 0x00007fdf1ec31a01 libweecord.so`std::sys_common::backtrace::__rust_begin_short_backtrace::hcb26a3223277f351 + 49
  thread #4, name = 'weechat'
    frame #0: 0x00007fdf2534fa8a libpthread.so.0`__libc_recv + 106
    frame #1: 0x00007fdf1ef71753 libweecord.so`std::sys::imp::net::Socket::recv_with_flags::h5a2143a78518c94b + 51
    frame #2: 0x00007fdf1ef717e1 libweecord.so`std::sys::imp::net::Socket::read::h29439e051ff22ed5 + 17
    frame #3: 0x00007fdf1ef4b9fe libweecord.so`std::sys_common::net::TcpStream::read::h32a674b879a14185 + 14
    frame #4: 0x00007fdf1ef4128e libweecord.so`_$LT$std..net..tcp..TcpStream$u20$as$u20$std..io..Read$GT$::read::h3fed58fc5ad2a951 + 14

(which is what mine looks like when working)

FredrIQ commented 7 years ago

Here's a GDB backtrace

(gdb) bt
#0  0x080a81e1 in utf8_next_char ()
#1  0x080a8754 in utf8_strlen ()
#2  0x0809f6a2 in string_match ()
#3  0x080912a7 in hook_signal_send ()
#4  0x080d3729 in gui_nicklist_send_signal ()
#5  0x080d3fb0 in gui_nicklist_add_nick ()
#6  0xb6156dcf in wdc_nicklist_add_nick () from /home/fiq/.weechat/plugins/libweecord.so
#7  0xb614b0f0 in weecord::connection::ChannelData::sync::h37417e3420c2943e ()
   from /home/fiq/.weechat/plugins/libweecord.so
#8  0xb61534de in weecord::event_proc::open_and_sync_buffers::hbd20373681a5b580 ()
   from /home/fiq/.weechat/plugins/libweecord.so
#9  0xb614d5e0 in weecord::connection::MyConnection::new::_$u7b$$u7b$closure$u7d$$u7d$::hc94331bc0e998b4e ()
   from /home/fiq/.weechat/plugins/libweecord.so
#10 0xb613e793 in std::panicking::try::do_call::h6c692662d2507aa1 ()
   from /home/fiq/.weechat/plugins/libweecord.so
#11 0xb64b62f3 in panic_unwind::__rust_maybe_catch_panic () at /checkout/src/libpanic_unwind/lib.rs:98
#12 0xb6148087 in weecord::ffi::PokeableFd::new::callback_fn::h5a56891316a0bc29 ()
   from /home/fiq/.weechat/plugins/libweecord.so
#13 0x0808f593 in hook_fd_exec ()
#14 0x080e34d6 in gui_main_loop ()
#15 0x08064c88 in main ()
khyperia commented 7 years ago

Hmm... are you in any ridiculously large servers, by chance? I am guessing this may be a dupe of #19 - it's not crashing/freezing, it's just taking a really long time to process all of the usernames.

I would really appreciate it if you tested that theory by going into this code here and commenting out / deleting the if statement / for loop / nested if statement. It would remove your weechat nicklist (the discord list of users + mentioning + nick highlighting + etc would still function), but it would at least let you use weechat-discord (and if that does fix it, then we know that's for sure what the problem is).

Thank you so much for your time getting that stack trace! I really appreciate it.

FredrIQ commented 7 years ago

That works. Obviously not optimal, but at least that explains the issue.

khyperia commented 7 years ago

Closing this as a dupe of #19, as a workaround was found and the root cause is that issue (and my terrible code :P )