crash in ssl_read when doing "identify password" with Skype account

[stevie.trujillo@…]

Using bitlbee-3.2. I only have one account with Skype. It usually works ok for a few days, then it decides to crash.

It crashed when I wrote identify password:

<root> Welcome to the BitlBee gateway!
<root>  
<root> If you've never used BitlBee before, please do read the help information using the help command. Lots of FAQs are answered there.
<root> If you already have an account on this server, just use the identify command to identify yourself.
<boo> identify password
* Disconnected (Remote host closed socket).

./configure --prefix=/home/bitlbee/bitlbee --pidfile=/home/bitlbee/bitlbee/var/lib/bitlbee --pidfile=/home/bitlbee/bitlbee/var/run/bitlbee.pid --msn=0 --jabber=0 --oscar=0 --yahoo=0 --twitter=0 --purple=0 --skype=1

Core was generated by `/home/bitlbee/bitlbee/sbin/bitlbee -Dnv'.
Program terminated with signal 11, Segmentation fault.
#0  0xb76f1ee3 in ssl_read ()
(gdb) disas
Dump of assembler code for function ssl_read:
   0xb76f1ed0 <+0>:     push   %ebx
   0xb76f1ed1 <+1>:     sub    $0x18,%esp
   0xb76f1ed4 <+4>:     mov    0x20(%esp),%eax
   0xb76f1ed8 <+8>:     call   0xb76d35cb <_start+347>
   0xb76f1edd <+13>:    add    $0x13da3,%ebx
=> 0xb76f1ee3 <+19>:    mov    0xc(%eax),%ecx
   0xb76f1ee6 <+22>:    test   %ecx,%ecx
   0xb76f1ee8 <+24>:    je     0xb76f1f30 <ssl_read+96>
   0xb76f1eea <+26>:    mov    0x28(%esp),%edx
   0xb76f1eee <+30>:    mov    %edx,0x8(%esp)
   0xb76f1ef2 <+34>:    mov    0x24(%esp),%edx
   0xb76f1ef6 <+38>:    mov    %edx,0x4(%esp)
   0xb76f1efa <+42>:    mov    0x1c(%eax),%eax
   0xb76f1efd <+45>:    mov    %eax,(%esp)
   0xb76f1f00 <+48>:    call   0xb76d1f80 <gnutls_record_recv@plt>
   0xb76f1f05 <+53>:    cmp    $0xffffffcc,%eax
   0xb76f1f08 <+56>:    je     0xb76f1f20 <ssl_read+80>
   0xb76f1f0a <+58>:    cmp    $0xffffffe4,%eax
   0xb76f1f0d <+61>:    je     0xb76f1f20 <ssl_read+80>
   0xb76f1f0f <+63>:    movl   $0x0,0x1220(%ebx)
   0xb76f1f19 <+73>:    add    $0x18,%esp
   0xb76f1f1c <+76>:    pop    %ebx
   0xb76f1f1d <+77>:    ret    
   0xb76f1f1e <+78>:    xchg   %ax,%ax
   0xb76f1f20 <+80>:    movl   $0x2,0x1220(%ebx)
   0xb76f1f2a <+90>:    add    $0x18,%esp
   0xb76f1f2d <+93>:    pop    %ebx
   0xb76f1f2e <+94>:    ret    
   0xb76f1f2f <+95>:    nop
   0xb76f1f30 <+96>:    movl   $0x1,0x1220(%ebx)
   0xb76f1f3a <+106>:   mov    $0xffffffff,%eax
   0xb76f1f3f <+111>:   jmp    0xb76f1f19 <ssl_read+73>
End of assembler dump.
(gdb) info registers
eax            0x6a627573       1784837491
ecx            0x0      0
edx            0x18     24
ebx            0xb7705c80       -1217373056
esp            0xbfd4c7c0       0xbfd4c7c0
ebp            0xb722bf00       0xb722bf00 <skype_read_callback>
esi            0xb967a9a0       -1184388704
edi            0xbfd4c820       -1076574176
eip            0xb76f1ee3       0xb76f1ee3 <ssl_read+19>
eflags         0x10292  [ AF SF IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb) print (char *) ($esp+0x20)
$5 = 0xbfd4c7e0 "subj \310"

[anonymous]

I was told this backtrace thing is nice to have

#0  0xb76f1ee3 in ssl_read ()
#1  0xb722bf4e in skype_read_callback () from /home/bitlbee/bitlbee/lib/bitlbee/skype.so
#2  0xb76e97ed in ?? ()
#3  0xb76216fe in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4  0xb75e06d3 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5  0xb75e0a70 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#6  0xb75e0ecb in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7  0xb76e988d in b_main_run ()
#8  0xb76d2e96 in main ()

[dx]

This bug is old, but welp. Can't do anything with the information reported here.

You should compile bitlbee with --debug=1 if you want backtraces to be more useful.

Also, what SSL library are you building bitlbee against?

[dx]

Oh nevermind, asm sort of says what happened. I guess the conn in the gnutls ssl_read is null, but no idea how it gets there at that point.

[dx]

I never managed to reproduce this exact issue, but b87e5dc342b45e35656a747345b8496217f3b130 is highly likely to fix it, so closing.