FS#45824 - [jre7-openjdk] 7.u85_2.6.1 leak ressources
Attached to Project:
Arch Linux
Opened by Ondřej Hruška (MightyPork) - Wednesday, 29 July 2015, 08:19 GMT
Last edited by Guillaume ALAUX (galaux) - Monday, 19 October 2015, 16:32 GMT
Opened by Ondřej Hruška (MightyPork) - Wednesday, 29 July 2015, 08:19 GMT
Last edited by Guillaume ALAUX (galaux) - Monday, 19 October 2015, 16:32 GMT
|
Details
After the following updates:
""" jre7-openjdk-headless (7.u79_2.5.5-1 -> 7.u85_2.6.1-1) jre7-openjdk (7.u79_2.5.5-1 -> 7.u85_2.6.1-1) jdk7-openjdk (7.u79_2.5.5-1 -> 7.u85_2.6.1-1) """ there's a regression where after a few hours (or less) running a Java application, sound system stops working - no apps can play sound and print mysterious errors like """ alsa audio output error: cannot open ALSA device "default": No space left on device """ Forum thread: https://bbs.archlinux.org/viewtopic.php?id=200184 I believe this is caused openjdk7, since after downgrading the packages or switching to openjdk8, the issue disappears. It also stops after restarting the said Java application (in my case PhpStorm), which has not been updated at all. |
This task depends upon
Closed by Guillaume ALAUX (galaux)
Monday, 19 October 2015, 16:32 GMT
Reason for closing: Fixed
Additional comments about closing: 7.u85_2.6.1-2 fixes this
Monday, 19 October 2015, 16:32 GMT
Reason for closing: Fixed
Additional comments about closing: 7.u85_2.6.1-2 fixes this
"""
[00007f07f8001268] xcb_xv vout display error: shared memory allocation error: No space left on device
"""
Note:
FS#45794seems to be the same issue.Do you think this comes from Arch Linux or directly OpenJDK or Icedtea? Have you found any upstream bug?
I usually have PhpStorm open, someone may have NetBeans or other Java app running all the time.
After some time—30 minutes, hour, 2 hours...—I decide to play some music or radio, and there it comes.
If it helps, this is a 64-bit ThinkPad with i7, 4GB ram. Shm settings—the defaults, I don't even know where it's configured.
I believe it's openjdk7 itself leaking resources when the app is running. I don't have IcedTea installed.
This is my only machine, so can't test if it happens on other distros (don't have space for dualboot either).
I googled the error messages and found nothing, but that can be because I had no clue what exactly to look for.
https://bugs.openjdk.java.net/secure/Dashboard.jspa
http://icedtea.classpath.org/bugzilla/
I'm also having the same severe resource hogging bug with that 7u85_2.6.1 version, on 64-bits system.
I have recently migrated to Manjaro, only have that version available, and must use JDK7 for work.
At some point I noticed I couldn't start some programs doing graphics access (typically SDL/ClanLib games, but also Java/Swing or Java/SWT once saturated).
Digging down I found that all SHM IPC were used up. One can use "ipcs -mu" to check the number currently used.
After discovering that, I had a "watch ipcs -mu" in a terminal beside my Java application.
I found that resizing a graphical pane with a slider consumes SHMs quite quickly.
For example, VisualVM is quite slow eating 5-10 SHMs at each resize (resize the left pane listing VMs, remote JMX, etc) while the Object pane in a SQL session of Squirrel-SQL eats up several hundreds of them at each resize (and you don't have to release the mouse button to eat them, like VisualVM), going to saturation in less than a minute.
So it's IPC' shared memory segments exhaustion which is causing all the trouble.
Maybe it's a big enough bug and annoyance to backtrack on the version provided in Arch, until it's corrected upstream ?
With 7.u85_2.6.1-1:
- I can reproduce this leak with VisualVM, Netbeans, IntelliJ every time
- Neither TuxGuitar nor Eclipse exhibit this issue
With 7.u79_2.5.5-1, none of the mentioned application leaks.
Mail sent to the IcedTeam mailing list:
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2015-October/033781.html
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2568
https://bugs.gentoo.org/show_bug.cgi?id=561500
7.u85_2.6.1-2 in [extra] is built with this patch and does not exhibit the leak anymore. Next upstream version will ship the fix.
Thanks for your help!