Plexamp 3.8.2 on Linux Quickly Turns into a Grey Screen and Stops Working

[sibmorris]

I’ve been using Plexamp on Linux for over a year and it always has worked great. The other day it started acting funny. While it opens fine it quickly will turn grey and stop working. This seems to happen while it is play, or even while it sits idle.

I’ve tried the various solutions from this post, Plex amp 3.01 on ubuntu 16.04 just displays a blank screen on start, however I had no luck with any of them.

I tried to find the plexamp.log log file but I was also unsuccessful. Unfortunatly, Plexamp debug logs & how to extract them didn’t give any insights into where they are on Linux. I looked in ~/.local/share/Plexamp but there were no logs.

With that leading to a dead end I tried running the AppImage in the terminal. This was the output when it turned grey and stopped working:

It didn’t shed any light onto the issue either. I’m suspecting it might have something with it updating to 3.8.2 but I haven’t confirmed this yet.

I’m at a loss for what is happening.

System Information

OS: Linux Mint 20.2 x86_64 
Kernel: 5.13.0-21-generic 
Uptime: 19 mins 
Packages: 2848 (dpkg), 9 (flatpak) 
Shell: zsh 5.8 
Resolution: 1920x1080, 1920x1080 
DE: Cinnamon 
WM: Mutter (Muffin) 
WM Theme: Mint-Y-Dark-Red (Mint-Y-Dark) 
Theme: Mint-Y-Dark-Red [GTK2/3] 
Icons: Mint-Y-Dark-Red [GTK2/3] 
Terminal: gnome-terminal 
CPU: Intel i7-2600K (8) @ 3.800GHz 
GPU: AMD ATI Radeon RX 5500/5500M / Pro 5500M 
Memory: 4813MiB / 15979MiB 

[FlyingEwok]

I’ve also been encountering this issue on Fedora 35. I’ve tried a lot of things in the post Plex amp 3.01 on ubuntu 16.04 just displays a blank screen on start but had no luck.

It is able to get to the login page fine without error.

When I click login (doesn’t matter what way I login) it goes grey.

I don’t seem to get any logs generated either.

Another thing I would like to mention is that Plexamp works perfectly fine on my desktop which is running Linux Mint 20.2 Kernel 5.4.0.
System Information

OS: Fedora Linux 35 (Workstation Edition) x86_64
Host: 82BG Yoga 9 14ITL5
Kernel: 5.15.4-201.fc35.x86_64
Uptime: 1 hour, 20 mins
Packages: 1879 (rpm)
Shell: zsh 5.8
Resolution: 1920x1080
DE: GNOME 41.1
WM: Mutter
WM Theme: Adwaita
Theme: Adwaita-dark [GTK2/3]
Icons: Adwaita [GTK2/3]
Terminal: gnome-terminal
CPU: 11th Gen Intel i7-1185G7 (8) @ 4.800GHz
GPU: Intel TigerLake-LP GT2 [Iris Xe Graphics]
Memory: 3751MiB / 7521MiB

[sibmorris]

Thanks to the amazing @plexamp Twitter account I’ve been able to look more into what is happening.

Here is the start of the thread:

Scott

It appears that what is happening is that the render process of Electron is crashing.

In order to interact with Plexamp I had to extract the AppImage package and run the application directly. This didn’t produce any further logs.

./plexamp.AppImage --appimage-extract

After learning about the existence of LLDB, I was able to connect the debugger to the render process and learn more details, that I hope will help here.

When the render process crashes it spits out the following information, which is an unrecoverable error.

With the use of the bt command I was able to produce a stack trace when the render process crashes.

It appears there is an issue in the treble.node lib.

I hope this helps someone!

[sibmorris]

Upon going through the release notes it appears a similar issue happened on Windows and was fixed in 3.8.2.

From Plexamp Release Notes - #35 by elan

Windows: Gray screen on startup.

Following up with the thread relating to that issue it appears that it was also related to the treble.node lib.

Plexamp 3.8.0 starts up with an empty window on Windows 10

Wife’s Windows 10 Surface laptop got updated to 3.8.0 and plexamp no longer will run. It starts up with a grey window that can’t be moved (but can be resized). If I install 3.7.1 it runs fine but will auto update to the non working version. I removed appdata/local/Plexamp, uninstalled, rebooted. Any suggestions? Can auto updates be turned off?

The eventual fix, Plexamp 3.8.0 starts up with an empty window on Windows 10 - #31 by elan, seems to have been to include a missing DLL. I’m not sure if this is a result of changes to how the module is built or not, but it might be.

[elan]

The windows issue was totally different, yours looks like a curl-related crash.

[anon5074910]

This may or may not help. Many apps which use electron have been having problems on F35 most notably atom. See Atom crash everytime on new Fedora Worktation 35 · Issue #23259 · atom/atom · GitHub

I’ve subsequently moved away from fedora but when I was using F35 both the --no-sandbox and --in-process-gpu worked to get atom functional. You could try each of them and see if it helps.

[sibmorris]

In a weird twist of events, while I was trying to debug a bit more I accidentally killed my playlist. Since then Plexamp has been functioning as expected. I’m going to keep an eye on it and if it happens again I can see if I can get more information.

Thanks @elan for that clarification. I was skeptical but the behaviour and the files looked to be similar. I’m not sure why the playlist would impact curl, unless there was a file in it that it was unable to resolve and it would crash instead of ignoring the error.

@anon5074910, perhaps the issue that @FlyingEwok is seeing is actually unrelated to my issue, but their render process is also failing (producing the same outcome.) I’m on Mint so I can’t test this one specifically.

[jamerst]

I also have the same issue on Fedora 35.

I’ve just done a clean install from Fedora 33. I had the same problem in 33 too, but I managed to get it working by adding the --no-sandbox argument and setting the LD_PRELOAD env variable to /usr/lib64/libcrypto.so.

That workaround doesn’t appear to work any more though.

The --in-process-gpu argument has no effect for me.

[jamerst]

After a bit more investigation I’ve discovered that you need an older version of libcrypto.so to get it to work.

Fedora 33 has a package for an older version of openssl (compat-openssl10), but this package is no longer available in Fedora 34 or 35.

The package is still in CentOS 8 however, so you can just grab a copy from here and install it manually.

To start Plexamp, run the following: LD_PRELOAD=/usr/lib64/libcrypto.so.1.0.2o Plexamp-3.8.2.AppImage --no-sandbox.

It seems to work perfectly after doing this, though it would be nice if this bug could be fixed rather than relying on this workaround.

[HBot106]

@jamerst

LD_PRELOAD=/usr/lib64/libcrypto.so.1.0.2o Plexamp-3.8.2.AppImage --no-sandbox

Having this same issue on Fedora 35 but this didn’t solve it for me. Did you do anything else besides installing the old openssl and setting the env variable before running?

[jamerst]

I didn’t do anything else that I’m aware of that would affect it.

What display server are you using? I’m using X11.

[HBot106]

Ah Wayland here, so there’s a difference.

[HBot106]

I removed the appimage and installed it with flatpak and it just worked without any additional effort. No idea what the problem was though…

[FlyingEwok]

I can confirm that installing it with flatpak does work

[SE2Dev]

I’m having the same issue with the AppImage, but I’m able to open the application and it appears to function normally; however occasionally the renderer process will crash after I’ve had PlexAmp open for a few hours.

[sibmorris]

I’ve been monitoring my issue and somehow clearing the queue seemed to be the fix 🤷. Since then it doesn’t seem to be having any issues. I’m not sure what was up with the curl crash that was killing the renderer but it hasn’t returned.

Did you try connecting LLDB to the render process? What I did was:

1. Extract the Plexamp app image, ./plexamp.AppImage --appimage-extract.
2. Run Plexamp from the extracted contents.
3. Run ps -ef | grep plexamp to get the pid of the render process
4. Start LLDB (I had to run it as root to attach to the process) and attach to the pid, (lldb) process attach --pid 1234 where 1234 is your pid.
5. It will break the process, enter c to continue.
6. Reproduce the crash and see what LLDB has to say, to get a stack trace use the bt command.

I wonder if it is related my issue or some other issue that might be arising that is killing the renderer.

[SE2Dev]

I managed to catch my issue with the debugger, it ended up exiting with code 11 (0x0000000b) when I tried to continue afterwards:

* thread #17, name = 'Network Manager', stop reason = signal SIGSEGV: invalid address (fault address: 0x39)
    frame #0: 0x0000563a8c9770b4 plexamp`___lldb_unnamed_symbol165$$plexamp + 35204
plexamp`___lldb_unnamed_symbol165$$plexamp:
->  0x563a8c9770b4 <+35204>: movb   $0x21, 0x39
    0x563a8c9770bc <+35212>: popq   %rbp
    0x563a8c9770bd <+35213>: retq   
    0x563a8c9770be <+35214>: int3   
  thread #50, name = 'Opening Thread', stop reason = signal SIGSEGV: invalid address (fault address: 0x39)
    frame #0: 0x0000563a8c9770b4 plexamp`___lldb_unnamed_symbol165$$plexamp + 35204
plexamp`___lldb_unnamed_symbol165$$plexamp:
->  0x563a8c9770b4 <+35204>: movb   $0x21, 0x39
    0x563a8c9770bc <+35212>: popq   %rbp
    0x563a8c9770bd <+35213>: retq   
    0x563a8c9770be <+35214>: int3  

Edit:

Looks like it’s from this, but I forgot to collect an actual stack trace - so I’ll need to capture it again.

[sibmorris]

Did you happen to get a stack trace from this crash? Use bt to print one out.

[SE2Dev]

Honestly, I forgot to grab a stack trace… but according to my system logs this same segfault seems to happen roughly every few days, so I’ll grab a stack trace the next time it occurs.

[sgdurf]

Ah I have been seeing the same thing (grey screen after login) when using the AppImage on Gentoo.

Thanks for debugging.