Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfaults #12

Closed
conceptlane opened this issue Aug 24, 2016 · 5 comments
Closed

Segfaults #12

conceptlane opened this issue Aug 24, 2016 · 5 comments

Comments

@conceptlane
Copy link

conceptlane commented Aug 24, 2016

Hi, thanks for this wonderful replacement.
I run 3 Yahoo accounts on Pidgin, and have noticed the following.

(23:16:37) yahoo: sending frame: {"seq":3,"ack":1,"data":[[{"msg":"SyncAck","pushId":"EA6KEOHFCBFZDCOQ5FINNDF3MY"}]]}
(23:16:37) blist: Updating buddy status for C4ODZC7FOCRIRJEQWK73HGVQV4 (Yahoo (2016))
(23:16:37) yahoo: sending frame: {"seq":4,"ack":1,"data":[]}
(23:16:37) dnsquery: Performing DNS lookup for prod.iris.yahoo.com
(23:16:37) dns: Successfully sent DNS request to child 20965
(23:16:37) dns: Got response for 'prod.iris.yahoo.com'
(23:16:37) dnsquery: IP resolved for prod.iris.yahoo.com
(23:16:37) proxy: Attempting connection to 72.30.2.181
(23:16:37) proxy: Connecting to prod.iris.yahoo.com:443 with no proxy
(23:16:37) proxy: Connection in progress
(23:16:37) proxy: Connecting to prod.iris.yahoo.com:443.
(23:16:37) proxy: Connected to prod.iris.yahoo.com:443.
(23:16:38) g_log: purple_ssl_read: assertion `data != NULL' failed
(23:16:38) yahoo: sending frame: (null)
(23:16:38) nss: SSL version 3.2 using 128-bit AES with 160-bit SHA1 MAC
Server Auth: 2048-bit RSA, Key Exchange: 2048-bit DHE, Compression: NULL
Cipher Suite Name: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
(23:16:38) nss: subject=CN=*.iris.yahoo.com,OU=Information Technology,O=Yahoo Inc.,L=Sunnyvale,ST=California,C=US issuer=CN=Symantec Class 3 Secure Server CA - G4,OU=Symantec Trust Network,O=Symantec Corporation,C=US
(23:16:38) nss: partial certificate chain
(23:16:38) certificate/x509/tls_cached: Starting verify for prod.iris.yahoo.com
(23:16:38) certificate/x509/tls_cached: Checking for cached cert...
(23:16:38) certificate/x509/tls_cached: ...Found cached cert
(23:16:38) nss/x509: Loading certificate from /home/user/.purple/certificates/x509/tls_peers/prod.iris.yahoo.com
(23:16:38) certificate/x509/tls_cached: Peer cert matched cached
(23:16:38) nss/x509: Exporting certificate to /home/user/.purple/certificates/x509/tls_peers/prod.iris.yahoo.com
(23:16:38) util: Writing file /home/user/.purple/certificates/x509/tls_peers/prod.iris.yahoo.com
(23:16:38) nss: Trusting CN=*.iris.yahoo.com,OU=Information Technology,O=Yahoo Inc.,L=Sunnyvale,ST=California,C=US
(23:16:38) certificate: Successfully verified certificate for prod.iris.yahoo.com
(23:16:38) yahoo: frame_len: 72
(23:16:38) yahoo: got frame data: {"seq":1,"ack":1,"data":[[{"msg":"SyncComplete"}]],"time":1471965397952}
(23:16:38) yahoo: sending frame: {"seq":4,"ack":2,"data":[]}
(23:16:38) yahoo: frame_len: 115
(23:16:38) yahoo: got frame data: {"msg":"ChannelProtocolError","reason":"Client skipped ahead (frame.seq=4, numResent=-3, numAcked=1, clientSeq=1)"}
(23:16:38) dnsquery: Performing DNS lookup for prod.iris.yahoo.com
Pidgin 2.10.10 has segfaulted and attempted to dump a core file.
This is a bug in the software and has happened through
no fault of your own.

If you can reproduce the crash, please notify the developers
by reporting a bug at:
http://developer.pidgin.im/simpleticket/

Please make sure to specify what you were doing at the time
and post the backtrace from the core file.  If you do not know
how to get the backtrace, please read the instructions at
http://developer.pidgin.im/wiki/GetABacktrace
dns[20965]: Oops, father has gone, wait for me, wait...!
Aborted

This has been the only change in usage (switching from the Yahoo plugin to your replacement), so I figured it should be related to this plugin. If you have some time, please have a look at it and let me know if you need anything else.

Thanks again!

Roy

@EionRobb
Copy link
Owner

Can you also attach the backtrace: https://developer.pidgin.im/wiki/GetABacktrace ?

@conceptlane
Copy link
Author

conceptlane commented Aug 24, 2016

Here it is.
I could get it to segfault simply by sending a message to one of my Yahoo accounts.
Once it crashes on its own again, I'll attach another backtrace.

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/pidgin...Reading symbols from /usr/lib/debug/usr/bin/pidgin...done.
done.
(gdb) handle SIGPIPE nostop noprint
Signal        Stop  Print   Pass to program Description
SIGPIPE       No    No  Yes     Broken pipe
(gdb) run
Starting program: /usr/bin/pidgin 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdaeaf700 (LWP 7527)]

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe9d04465 in ssl_nss_read (gsc=0x5555561bd6e0, data=0x55555625824c, len=1) at /tmp/buildd/pidgin-2.10.10/./libpurple/plugins/ssl/ssl-nss.c:520
520 /tmp/buildd/pidgin-2.10.10/./libpurple/plugins/ssl/ssl-nss.c: No such file or directory.
(gdb) bt full
#0  0x00007fffe9d04465 in ssl_nss_read (gsc=0x5555561bd6e0, data=0x55555625824c, len=1) at /tmp/buildd/pidgin-2.10.10/./libpurple/plugins/ssl/ssl-nss.c:520
        ret = <optimized out>
        nss_data = 0x0
#1  0x00007fffee91ca17 in yahoo_socket_got_data (userdata=0x555556258210, conn=0x5555561bd6e0, cond=<optimized out>) at libyahoo-plusplus.c:1354
        ya = 0x555556258210
        length_code = 126 '~'
        read_len = <optimized out>
        done_some_reads = <optimized out>
#2  0x00005555555cf09d in pidgin_io_invoke (source=<optimized out>, condition=<optimized out>, data=0x555556284c30)
    at /tmp/buildd/pidgin-2.10.10/./pidgin/gtkeventloop.c:73
        closure = 0x555556284c30
        purple_cond = PURPLE_INPUT_READ
#3  0x00007ffff55cf355 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4  0x00007ffff55cf688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#5  0x00007ffff55cfa82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#6  0x00007ffff6845797 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
No symbol table info available.
#7  0x0000555555593c87 in main (argc=1, argv=0x7fffffffe348) at /tmp/buildd/pidgin-2.10.10/./pidgin/gtkmain.c:937
        opt_force_online = 0
        opt_help = <optimized out>
        opt_login = 0
        opt_nologin = 0
        opt_version = <optimized out>
        opt_si = 0
        opt_config_dir_arg = <optimized out>
        opt_login_arg = <optimized out>
        opt_session_arg = <optimized out>
        search_path = <optimized out>
        accounts = <optimized out>
        sig_indx = 1
        sigset = {__val = {82950, 0 <repeats 15 times>}}
        errmsg = "`\305\374\367\377\177\000\000\225\223\336\367\377\177\000\000\001\000\000\000\377\177\000\000\000\300\374\367\377\177\000\000\000\300\377\377\377\177\000\000\000\000\000\000\000\000\000\000\020\202W\365\377\177\000\000\254\222\336\367\377\177\000\000\001\000\000\000\377\177\000\000\360\331\374\367\377\177\000\000\060\302\377\377\377\177", '\000' <repeats 11 times>"\202, W\365\377\177\000\000\254\222\336\367\377\177\000\000\001\000\000\000\377\177\000\000\b\325\374\367\377\177\000\000`\302\377\377\377\177\000\000\000\000\000\000\000\000\000\000\340\201W\365\377\177\000\000\254\222\336\367\377\177\000\000\001\000\000\000\377\177\000\000\000\320\374\367\377\177\000\000\220\302\377\377\377\177\000\000\000\000\000\000\000\000\000\000`\201W\365\377\177\000\000\254\222\336\367\377\177\000\000\001\000\000\000\000\000\000\000\000\352\374\367\377\177\000\000\300\302\377\377\377\177\000\000\000\000\000\000\000\000\000\000P\201W\365\377\177\000\000\254\222\336\367\377\177\000\000\001\000\000\000\061\000\000\000\000\345\374\367\377\177\000\000\360\302\377\377\377\177\000\000\000\000\000\000\000\000\000\000@\201W\365\377\177\000\000\254\222\336\367\377\177\000\000\001\000\000\000\000\000\000\000\000\340\374\367\377\177\000\000"...
        signal_channel = <optimized out>
        signal_status = <optimized out>
        signal_channel_watcher = 1
        segfault_message_tmp = <optimized out>
        error = 0x0
        opt = <optimized out>
        gui_check = <optimized out>
        debug_enabled = <optimized out>
        migration_failed = <optimized out>
        active_accounts = <optimized out>
        long_options = {{name = 0x5555556324f0 "config", has_arg = 1, flag = 0x0, val = 99}, {name = 0x55555562096e "debug", has_arg = 0, flag = 0x0, val = 100}, {
            name = 0x55555562dd9e "force-online", has_arg = 0, flag = 0x0, val = 102}, {name = 0x555555622554 "help", has_arg = 0, flag = 0x0, val = 104}, {
            name = 0x55555562dc4a "login", has_arg = 2, flag = 0x0, val = 108}, {name = 0x55555562ddab "multiple", has_arg = 0, flag = 0x0, val = 109}, {
            name = 0x55555562ddb4 "nologin", has_arg = 0, flag = 0x0, val = 110}, {name = 0x5555556324e6 "session", has_arg = 1, flag = 0x0, val = 115}, {
            name = 0x5555556261cb "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x5555556324f9 "display", has_arg = 1, flag = 0x0, val = 68}, {
            name = 0x55555562ef66 "sync", has_arg = 0, flag = 0x0, val = 83}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
(gdb) quit

@dequis
Copy link
Collaborator

dequis commented Aug 24, 2016

So, dupe of #11 with a less crappy backtrace, slightly different disconnection reason, and more log context.

(I thought I had tested this kind of failure mode...)

@conceptlane
Copy link
Author

conceptlane commented Aug 24, 2016

I'm still waiting for it to crash on its own. Not sure if it it was crashing because someone was sending a message across on Yahoo (because hardly anyone sends a message on that network nowadays).

@dequis
Copy link
Collaborator

dequis commented Aug 24, 2016

Hmm looks like closing two tickets from #13 didn't work. Well, anyway, closing as a duplicate of #11.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants