From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.1) Gecko/20060207 Fedora/1.5.0.1-2.1 Firefox/1.5.0.1 Description of problem: On a FC5T2/x86_64 install with all major components listed in text mode installed (as well as an everything install), rebuild-gcj-db always hangs part-way through the rebuild of the 64-bit classmap.db. I found out that rebuilding the database by merging invidivual components one by one (xargs -n 1), as opposed to all at once, avoids the problem. Sometimes the problem does not happen at all, even doing multiple .db files at a time. It might be some underlying database bug or even a race condition in the kernel. At first I thought it might be some hardware problem, but I've just got a new x86_64 box and, to my surprise, it displayed the very same problem. I haven't been able to pinpoint the exact conditions that trigger the problem, but I know gcj-dbtool always hangs at a futex call. With the automatic execution of rebuild-gcj-db multiple times during an update, this is a major pain. My temporary work-around: chmod -x /usr/bin/gcj-dbtool. That works until the next gcc update... Version-Release number of selected component (if applicable): libgcj-4.1.0-0.23 How reproducible: Sometimes Steps to Reproduce: 1.Run /usr/bin/rebuild-gcj-db on a box with lots of GCJ-compiled Java packages Actual Results: It freezes on a futex call Expected Results: It shouldn't freeze Additional info: This does NOT happen on Fedora/x86-32
*** This bug has been marked as a duplicate of 179228 ***
Since the kernel bug is getting so many dupes and people might not think of looking for it there, let's keep this one open, blocked on the kernel bug, which is what should have been done from the beginning.
Fixed in kernel-2.6.15-1.1939_FC5.