Bug 275267 - KTorrent segfaults moments after starting every time, probably IPv6-related
Summary: KTorrent segfaults moments after starting every time, probably IPv6-related
Status: RESOLVED UPSTREAM
Alias: None
Product: ktorrent
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR crash
Target Milestone: ---
Assignee: Joris Guisson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-09 09:54 UTC by Justin Gottula
Modified: 2011-06-12 07:51 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Gottula 2011-06-09 09:54:19 UTC
Version:           unspecified (using KDE 4.6.3) 
OS:                Linux

For approximately the past day, KTorrent has crashed upon startup without fail. (I'm running 4.1.1 from Arch's repos, and I also tried the latest git revision.) The manner of the crash is also consistent: the app will start okay for the first few moments, and I can do stuff with the interface, but within 5-10 seconds it segfaults and sends me over to DrKonqi.

Reproducible: Always

Steps to Reproduce:
Run ktorrent.

Actual Results:  
Crashes with a sigsegv after 5-10 seconds.

Expected Results:  
Doesn't crash.

There are a couple of indications that the bug is IPv6-related, and it seems probable to me that this could be related to June 8 (i.e., yesterday) having been World IPv6 Day. The first hint at IPv6 problems is this collection of lines in the KTorrent log file:


Thu Jun 9 00:39:41 2011: Cannot bind to port fe80::21d:7dff:fe0a:3ef8:42001 : Invalid argument
Thu Jun 9 00:39:41 2011: Cannot bind to port fe80::21d:7dff:fe0a:3ef8:42001 : Invalid argument
Thu Jun 9 00:39:41 2011: Cannot bind to port fe80::21d:7dff:fe0a:3ef8:42003 : Invalid argument
Thu Jun 9 00:39:41 2011: DHT: Failed to bind to [fe80::21d:7dff:fe0a:3ef8]:42003


The backtrace is also fairly telling, seeing as the segfault comes from libresolv.so. (Unfortunately, I don't have debug symbols for any of these libraries.)


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd25fd700 (LWP 28658)]
0x00007fffe9f2aa65 in __libc_res_nquery () from /lib/libresolv.so.2
(gdb) bt
#0  0x00007fffe9f2aa65 in __libc_res_nquery () from /lib/libresolv.so.2
#1  0x00007fffe9f2af5e in ?? () from /lib/libresolv.so.2
#2  0x00007fffe9f2b545 in __libc_res_nsearch () from /lib/libresolv.so.2
#3  0x00007fffd3a7a947 in _nss_dns_gethostbyname4_r ()
   from /lib/libnss_dns.so.2
#4  0x00007ffff3da4ab1 in ?? () from /lib/libc.so.6
#5  0x00007ffff3da6b30 in getaddrinfo () from /lib/libc.so.6
#6  0x00007ffff6933d70 in ?? () from /usr/lib/libQtNetwork.so.4
#7  0x00007ffff6928cfa in ?? () from /usr/lib/libQtNetwork.so.4
#8  0x00007ffff56ecdc5 in ?? () from /usr/lib/libQtCore.so.4
#9  0x00007ffff56f7f95 in ?? () from /usr/lib/libQtCore.so.4
#10 0x00007ffff546ed60 in start_thread () from /lib/libpthread.so.0
#11 0x00007ffff3db8e0d in clone () from /lib/libc.so.6
#12 0x0000000000000000 in ?? ()


I also noticed these lines in the log file (and also on the regular stdout), which I at first thought were related to the crash, but after noticing that the UI loads and works and that the backtrace leads to libresolv, I don't think they are related.


Thu Jun 9 00:39:41 2011: Qt Warning: QWidget::insertAction: Attempt to insert null action
Thu Jun 9 00:39:41 2011: Qt Warning: QWidget::insertAction: Attempt to insert null action
Thu Jun 9 00:39:41 2011: Qt Warning: QWidget::insertAction: Attempt to insert null action
Comment 1 Joris Guisson 2011-06-11 11:54:46 UTC
The segfault is in libresolv, my googling results seem to indicate that this is happening to a lot of programs:

https://bugs.archlinux.org/task/24615

So this is something, which is outside of ktorrent. Closing as an upstream bug.
Comment 2 Justin Gottula 2011-06-12 07:51:44 UTC
After reading the discussions about the glibc issue, I can confirm that it is definitely an issue with glibc 2.14. The crash I was experiencing was completely resolved by a new revision of the glibc package from the Arch devs (glibc-2.14-2).

An additional option, for anyone else affected by this, is downgrading to glibc 2.13, as that version isn't affected.