Vscode not starting/opening

well, i have no idea where it comes from or what it is, but if something mangled your system like this it is very likely other things (paths, library search paths etc etc) might have been mangled as well …

Does running unset LD_PRELOAD; code work?

no its not working…

From the latest error, this preload is coming from /etc/ld.so.preload not LD_PRELOAD. What put that there?

ls -lrt /etc/ld.so.preload
-rw-r--r-- 1 root root 49 Apr 23  2021 /etc/ld.so.preload

the content inside this file is just a single line

/usr/local/lib/AppProtection/libAppProtection.so

I didn’t put anything there atleast not yesterday

also I have lot of different application installed from snap those are working fine(like vlc, slack,)

Ack. I doubt the problem is from the preload failing. I think the real problem is the glibc failure

yeah, looks like that file has been modified a year ago already … still very suspicious that you do not know about it (and this is a serious security breach if you did not modify the file yourself)

anyway to fix that? is it because of the version? GLIBC_2.26

strings /snap/core/current/usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX  
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_DEBUG_MESSAGE_LENGTH

I think I did that for some reason because some application was not working.

i just installed VSCode on my 20.04 box here for a test and it runs fine … i wonder if anything modified your LD_LIBRARY_PATH so the snap does not find the libc from the core(16) snap anymore (classic snaps are very fragile if it comes to mixing libs like that)

ogra@acheron:~$ find /snap/code/current/ -name '*libX11.so*'
/snap/code/current/usr/lib/x86_64-linux-gnu/libX11.so.6
/snap/code/current/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0

your screenshot shows that it tries to load libX11 from outside the snap instead of the shipped one …

The LD_LIBRARY_PATH isn’t set to anything…

Please provide the output for

  • dpkg -S /usr/local/lib/AppProtection/libAppProtection.so
  • ldd /usr/local/lib/AppProtection/libAppProtection.so
$ dpkg -S /usr/local/lib/AppProtection/libAppProtection.so                                                                                                                
dpkg-query: no path found matching pattern /usr/local/lib/AppProtection/libAppProtection.so
linux-vdso.so.1 (0x00007ffc6e99e000)
/usr/local/lib/AppProtection/libAppProtection.so (0x00007f2fc42d1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2fc428d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2fc4287000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2fc4095000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f2fc3f56000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f2fc3f2c000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2fc3d48000)
libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007f2fc3d36000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2fc471d000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f2fc3d30000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f2fc3d28000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2fc3bd9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2fc3bbe000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f2fc3ba7000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f2fc3b8d000)

@user101 what happens if you move the libappprotection.so file, as well as temporarily move /etc/ld.so.preload file (move them away into a backup location, e.g. your home dir)?

1 Like

OK, I did a bit of digging, this is setup by Citrix https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html

And it seems to impact many applications:

The fact that this gets preloaded, breaks the rpaths setup by code itself to load its own libraries leading to the conflict.

so I just moved /etc/ld.so.preload to home dir and now its opening and working fine… <3

1 Like

Okay so I do have citrix workspace installed… I’ll try re-installing it without the app protection.

That make sense :slight_smile: Now you need to see if you can use the sdk without the library in place.

so should I move libappprotection.so file as well?

So I installed citrix workspace without app protection.
Tried to move ld.so.preload back to /etc after reboot couldn’t login via gui so removed ld.so.preload from etc.
So the solution was to remove the ld.so.preload file from /etc
Thanks alot.

1 Like