Java Aplication freeze with futex_wait

[Fabrice]

Since update to Jaunty One java application will not start anymore.
Freeze is in the start window of the Application (Datastudio 7.0)

The java process has the spleeping and Waiting_channel is on "futex_wait"

I notice that gvfs-fuse-daemon is also on "futex_wait"

On 8.10 this application had not start problems

Other Java Application like Eclipse or Monodevelop does not have this problem

JRE is up to date 1.6.0.13

Does anyone else have this Problem ?

[Dmitry Zolotukhin (zlogic)]

I have this problem in reverse: Java apps start normally, but when I close them, the UI closes but the Java process continues running, waiting for "futex_wait". After opening and closing Eclipse a few times these waiting Java processes use gigabytes of RAM.

[Dmitry Zolotukhin (zlogic)]

It seems the problem may be caused by enabling Assistive Technologies in Gnome:

http://ubuntuforums.org/showthread.php?p=6144521

[Fabrice (fpeiffer)]

Hello

In my case Assistive Technologies are not activate in gnome

[Robert Hrovat (robi-hipnos)]

It happens to me after I close Flash based game in Firefox.

[Kaa (tselouyou)]

Hello,

I have the same problem: Java hangs with futex_wait status in system monitor.
The Java program opens, but then nothing works.
Sometimes, it's worth: nothing appears and another process is in futex_wait: gvfs-fuse-daemon.

Can you help, please?

I really need to use this software for my work and I do not want to change distribution!

Karen

[Fabio Marconi (fabiomarconi)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.
Is this bug reproducible with the latest Lucid packages ?
Thanks in advance.

[Antoszka (antoszka)]

This bug is still reproducible with a KVM-over-IP controlling program from Aten (in Java obviously).

Strace follows:

execve("/usr/lib64/jvm/java-6-sun/bin/java", ["/usr/lib64/jvm/java-6-sun/bin/ja"..., "-jar", "CS1716i.jar"], [/* 37 vars */]) = 0
brk(0) = 0x403ec000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe920336000
readlink("/proc/self/exe", "/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/java", 4096) = 45
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../lib/amd64/jli/tls/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../lib/amd64/jli/tls/x86_64", 0x7fffaa5ec880) = -1 ENOENT (No such file or directory)
open("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../lib/amd64/jli/tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../lib/amd64/jli/tls", 0x7fffaa5ec880) = -1 ENOENT (No such file or directory)
open("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../lib/amd64/jli/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../lib/amd64/jli/x86_64", 0x7fffaa5ec880) = -1 ENOENT (No such file or directory)
open("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../lib/amd64/jli/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../lib/amd64/jli", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../jre/lib/amd64/jli/tls/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../jre/lib/amd64/jli/tls/x86_64", 0x7fffaa5ec880) = -1 ENOENT (No such file or directory)
open("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../jre/lib/amd64/jli/tls/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../jre/lib/amd64/jli/tls", 0x7fffaa5ec880) = -1 ENOENT (No such file or directory)
open("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../jre/lib/amd64/jli/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../jre/lib/amd64/jli/x86_64", 0x7fffaa5ec880) = -1 ENOENT (No such file or directory)
open("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../jre/lib/amd64/jli/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../jre/lib/amd64/jli", 0x7fffaa5ec880) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=107792, ...}) = 0
mmap(NULL, 107792, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe92031b000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360Y\0\0\0\0\0\0"..., 8...

[davidm (vid)]

After seeing a few instances of this problem in the past, it's now happening constantly for me. Java programs get "stuck" in futex_wait." They will resume after a long wait (minutes) and the CPU runs loaded. This is really inhibiting my work using Ubuntu. :(

[Andrew P. (japoth)]

I'm seeing the futex_wait hang problem very frequently on Ubuntu 8.10 when running Adobe Reader 9 as a stand-alone or as a browser plugin. Adobe Reader shows as "sleeping" in System Monitor and doesn't respond to to the "End Process" button; the only way to terminate it is to right-click on the entry and Kill it. Assistive Technologies are not enabled.

[Anders Aagaard (aagaande)]

I just hit this bug on 2.6.37 and 2.7.38, not 2.6.35.

[i1abnrk (i1abnrk)]

I have this problem, too. Mine crashes on startup. From what I gather from the gvfs bug report it is a pulseaudio problem involving thread requests on the soundcard, when other threads, especially java and flash try to access it gvfs-fuse-daemon becomes zombie and that locks java or firefox in zombie. When I kill, home folder locks out with a IO message. "Failed to open directory 'user' Error stating file '/home/user/.gvfs': Transport endpoint not connected." This is happening for many people going back to Hardy. A google search for "gvfs-fuse-daemon futex_wait" shows it is a widespread problem and someone aught to convene a group.