FS#29961 - [eclipse] Crash in libpng12.so provided by nxclient

Attached to Project: Arch Linux
Opened by mrxx (mrxx) - Sunday, 20 May 2012, 21:12 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 23 June 2012, 13:26 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:

When starting Eclipse, the JRE crashes.
The crash occurs after Eclipse's splash screen, when loading libpng12.so from /usr/lib/nx/lib/

# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f74e89fce30, pid=12907, tid=140141216528128
#
# JRE version: 6.0_31-b04
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.6-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libpng12.so.0+0x31e30] png_set_progressive_read_fn+0x0
#
# An error report file with more information is saved as:
# /home/mrxx/hs_err_pid12907.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.

Additional info:
extra/eclipse 3.7.2-3
extra/nxclient 3.5.0.7-2
AUR/jre6 6u31-b04

After uninstalling nxclient, Eclipse starts normally.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Saturday, 23 June 2012, 13:26 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed with nxclient 3.5.0.7-3 using a wrapper
Comment by Ionut Biru (wonder) - Sunday, 20 May 2012, 22:21 GMT
is logically to crash like that because gtk is using png15. there is nothing to do here sincce nxclient is a blob as well as eclipse.
Comment by Jan de Groot (JGC) - Sunday, 20 May 2012, 22:57 GMT
Eclipse can be compiled from source, but I don't know if it can be patched to use libpng15 exclusively.
Comment by Ionut Biru (wonder) - Sunday, 20 May 2012, 23:21 GMT
we used to do it back in the days and we moved to the blob because it was a nightmare to compile it.
Comment by Andreas Radke (AndyRTR) - Tuesday, 29 May 2012, 11:42 GMT
dupe of  FS#24932  that now comes back again?
Comment by Adrián Quintás (frostering) - Thursday, 07 June 2012, 20:26 GMT
This is very annoying. I can't use eclipse, if I close my eyes...crash. I'm not using nx, eclipse just crash randomly.

# JRE version: 7.0_04-b20
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b21 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libpng12.so.0+0x31e30] png_set_progressive_read_fn+0x0
Comment by xduugu (xduugu) - Friday, 08 June 2012, 20:53 GMT
It might be a stupid idea, but couldn't the symlinks in /usr/bin to the nx binaries replaced with a wrapper script that sets LD_LIBRARY_PATH and calls the binary afterwards instead of adding them to the linker path globally?
Comment by David Rosenstrauch (darose) - Wednesday, 13 June 2012, 18:32 GMT
I'm running into this as well, and it's a pretty horrible bug - makes Eclipse completely unusable.

The crash seems to happen whenever I mouse over a class name, where Eclipse would normally show a tooltip.

Is there any fix/workaround for this?
Comment by David Rosenstrauch (darose) - Thursday, 21 June 2012, 18:29 GMT
Anybody? Is *any* fix/workaround available for this?!?!?!?

This really is a horrendous bug. I'm not going to be able to continue to use Eclipse as an IDE if I can't find a way around this.

TIA!
Comment by Andreas Radke (AndyRTR) - Thursday, 21 June 2012, 18:37 GMT
The fix is to build Eclipse from source. So far no developer seems to be interested in doing this.
Comment by David Rosenstrauch (darose) - Thursday, 21 June 2012, 18:53 GMT
That is understandable. I remember when we (Paul Mattal?) used to build Eclipse from source, and it did become a big problem to build it as time went on.

But it seems to me that nxclient is the cause of the problem here, not Eclipse, and so it's the nxclient package that needs to be fixed. If nxclient happens to supply its own, old version of libpng, that shouldn't get put on the main system library load path where it can interfere with other apps.

Is there not any way to get rid of /etc/ld.so.conf.d/nxclient.conf, and then just have nxclient add /usr/lib/nx/lib/ onto its library path when it launches?

Or, alternately, perhaps it's possible to have nxclient use either libpng (1.5.11) or libpng12 (1.2.49) which are available in the repos?
Comment by Thomas Oster (thomas.oster) - Friday, 22 June 2012, 15:59 GMT
The Fix would be easy:

1. Remove the file /etc/ld.so.conf.d/nxclient.conf from the nxclient package (which is stupid anyway, because it adds the libraries packaged with nxclient to the global library search path
2. Fix nxclient to use it's library path without having it global (e.g. wrap the nxclient executable with a script, which adds /usr/lib/nx/lib to the LD_LIBRARY_PATH variable.

This is something the packager of nxclient should do, please.

Until that the workaround is, to manually delete the above mentioned file:

sudo rm /etc/ld.so.conf.d/nxclient.conf

Reload the cache

sudo ldconfig

And if you want to start NX-Client do it with:
LD_LIBRARY_PATH=/usr/lib/nx/lib:$LD_LIBRARY_PATH /usr/lib/nx/bin/nxclient
Comment by David Rosenstrauch (darose) - Friday, 22 June 2012, 16:34 GMT
Were you able to test out this fix and verify it works? If so, perhaps you can submit a patch to the nxclient packager?
Comment by Andreas Radke (AndyRTR) - Friday, 22 June 2012, 17:37 GMT
quicktest here: removed the /etc/ld.so.conf.d/nxclient.conf file and removed the /usr/bin/nxclient symlink, replced it with a wrapper:

#!/bin/sh
LD_LIBRARY_PATH=/usr/lib/nx/lib:$LD_LIBRARY_PATH /usr/lib/nx/bin/nxclient

That't doesn't work because nxclient presets some vars in /etc/profile.d/nxclient.sh. A simple "nxclient" (it's in $PATH
before /usr/bin) call or the menu entries will call /usr/lib/nx/bin/nxclient directly. That fails because linpng12 cannot be found.

[root@laptop64 andyrtr]# grep -iR bin /usr/share/applications/nxclient*.desktop
/usr/share/applications/nxclient-admin.desktop:Exec=/usr/lib/nx/bin/nxclient -admin
/usr/share/applications/nxclient-wizard.desktop:Exec=/usr/lib/nx/bin/nxclient -wizard
/usr/share/applications/nxclient.desktop:Exec=/usr/lib/nx/bin/nxclient

Any idea?
Comment by Thomas Oster (thomas.oster) - Friday, 22 June 2012, 17:46 GMT
I had the same problem. However starting from command line with the given LD_LIBRARY_PATH=/usr/lib/nx/lib:$LD_LIBRARY_PATH /usr/lib/nx/bin/nxclient works. I do not know why. I also played around with the /etc/profile.d/nx.sh (I do not have nxclient.sh), but setting variables there also seems to have no effect.
What is this profile.d anyway? And how can it be that an interactive bash-session works, but the same line as script doesn't ?
Comment by Thomas Oster (thomas.oster) - Friday, 22 June 2012, 17:47 GMT
If you get a wrapper working, one could either patch the .desktop files, or rename the original nxclient executable to replace it by the wrapper.
Comment by Thomas Oster (thomas.oster) - Friday, 22 June 2012, 17:48 GMT
I also added this as Bug for nxclient. See https://bugs.archlinux.org/task/30405
Comment by Thomas Oster (thomas.oster) - Friday, 22 June 2012, 17:49 GMT
nevermind....saw it's assigned to you and closed as a dup of this. I just thought it belongs to nxclient rather than eclipse
Comment by Andreas Radke (AndyRTR) - Friday, 22 June 2012, 17:58 GMT
I'm still thinking the bug is in Eclipse and not in nxclient packaging. It's not uncommon to add a library path when a package ships
libraries in an unusual directory.

I'm still wondering how eclipse is built that it fails here. The bug is in eclipse pkg and adding a wrapper to nxclient would be only workaround.
The bug should also be triggered when user install libpng12 from AUR I guess.
Comment by David Rosenstrauch (darose) - Friday, 22 June 2012, 18:12 GMT
Nope. I have libpng12 (1.2.49-1) from AUR installed, and nxclient removed, and now don't experience this issue.
Comment by mrxx (mrxx) - Friday, 22 June 2012, 19:55 GMT
I didn't want to include my personal workaround in the original bug report, but as it is quite similar to Thomas Oster's idea, here it is. I replaced the nxclient binary itself with the wrapper script (so I never run into Andreas Radke's problem):

su -
# Step 1 - remove nx libs from global linker path
rm /etc/ld.so.conf.d/nxclient.conf
ldconfig
# Step 2 - replace nxclient binary with the wrapper script
cd /usr/lib/nx/bin
mv nxclient nxclientx
cat <<EOF >nxclient
#!/bin/sh
LD_LIBRARY_PATH=/usr/lib/nx/lib:$LD_LIBRARY_PATH /usr/lib/nx/bin/nxclientx
EOF
chmod 755 nxclient

nxclient starts from command line as well as from the menu entries, and Eclipse is not troubled any more.

Loading...