Bug 806029

I've discovered that if nscd is running, then ktorrent starts up just fine. So, to work around this problem, do the following:

yum install nscd
service nscd start

Can't reproduce this so, lease report this bug to upstream:
https://bugs.kde.org/enter_bug.cgi?product=ktorrent

(In reply to comment #2)
> Can't reproduce this so, lease report this bug to upstream:
> https://bugs.kde.org/enter_bug.cgi?product=ktorrent

I've already reported this to upstream (see https://bugs.kde.org/show_bug.cgi?id=296560). Turns out, this is probably a bug in glibc. I'm creating a clone.

Can you verify what version of nscd is installed?  Can you also let me know if this system was updated from glibc-2.14-whatever to glibc-2.15-whatever at some point?  

Jeff

(In reply to comment #4)
> Can you verify what version of nscd is installed?  Can you also let me know if
> this system was updated from glibc-2.14-whatever to glibc-2.15-whatever at some
> point?  
> 
> Jeff

The version of nscd package is nscd-2.15-28.fc17.x86_64. Sorry I didn't provide this information right away.
As to glibc version, I installed Fedora 17 from the Fedora-17-Alpha-x86_64-Live-KDE CD, which has glibc-2.15-11.fc17.x86_64 on it. And the version which I have currently installed is glibc-2.15-28.fc17.x86_64. So, the answer to the second question is: no, there was no update from glibc-2.14 to glibc-2.15.

Leonid.

Thanks Leonid.  One theory bites the dust.

I've got another theory; specifically nscd_get_nl_timestamp appears to call nscd_get_mapping w/o locking the hst_map_handle data structure.

I see a potential data race on hst_map_handle_mapped (*mappedp in nscd_get_mapping).  A data race would easily account for the unpredictable behaviour.

I don't have an environment handy to reproduce this locally and test that theory.  If I built some test rpms could you test them?

http://koji.fedoraproject.org/koji/taskinfo?taskID=3935345

Contains a test fix for the above-mentioned issue.  If you could give it a spin and see if it fixes the faults in ktorrent, I'd be grateful.

It's a scratch build, so I have no idea how long it'll be available.

Ignore the build in c#7, I suspect using that will lock up your system as it fails to release the acquired lock.  This should be better:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3935519

Jeff,
I installed your build from c8:
# rpm -qa | egrep  "glibc|nscd" | sort
glibc-2.15-30.fc17.x86_64
glibc-common-2.15-30.fc17.x86_64
glibc-debuginfo-2.15-30.fc17.x86_64
glibc-debuginfo-common-2.15-30.fc17.x86_64
glibc-devel-2.15-30.fc17.x86_64
glibc-headers-2.15-30.fc17.x86_64
nscd-2.15-30.fc17.x86_64

Unfortunately, that didn't do the trick. The ktorrent application still fails to start approx. 8 times out of 10 - same as before. And, same as before, it happens only if nscd is not running.
I'm going to attach a couple of backtraces, just in case they are different from the original one.
If I can help in any way, just let me know.

Created attachment 573149 [details]
A few backtraces against the newer glibc.

Thanks.  Those backtraces are significantly different; which makes me wonder if I goof'd the locking...  Interestingly enough they do show us going through the nscd_get_nl_timestamp routine like I suspected (via check_pf).   So, well, hopefully I just typo'd or something in the locking code I added.

Expect new rpms reasonably soon.

I may have prematurely considered this the same failure as all the faults in nscd_get_mapping because the original kcrash files indicated you were at the same location in nscd_get_mapping when your crash occurred.

However, in your crash, according to kcrash the it's thread #1 that is faulting inside pthread_cond_wait; that's a significant difference between the other reports which are faulting in nscd_get_mapping.

Access to the raw core file and rpm -q -a list of the RPMs on your box might be helpful in diagnosing this further.  It'd be nice to rule out kcrash simply reporting the wrong active thread; furthermore, assuming kcrash has the right thread, examining the register state would be useful.

As I mentioned in c#12, I'm not 100% sure your problem is the same as the reported crashes in nscd_get_mapping, but I'm treating them as related until I can prove it otherwise.

Another gent testing this stuff noticed an oversight in the last patch which this set of RPMS fixes.  If you could test them it'd be greatly appreciated.

http://koji.fedoraproject.org/koji/taskinfo?taskID=3940526

Given I haven't bumped the NVR, you'll probably have to use the --force option to get RPM to install the newer version.

It's good news this time!
After installing the build from c13, I ran a simple script to test it. And ktorrent started up 200 times without a single crash. It seems that the issue is fixed, at least on my platform.
I have only x86_64 installation at hand. I'll try to test this build on i686 in a virtual machine.

*** Bug 806070 has been marked as a duplicate of this bug. ***

Patch installed into rawhide & f17.

(In reply to comment #16)
> Patch installed into rawhide & f17.

fixed in version...?

*** Bug 797783 has been marked as a duplicate of this bug. ***