Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Frequent SIGSEGV crashes in Kodi 18 on macOS & Linux 18.04 #29

Open
MarkCallow opened this issue Feb 10, 2019 · 40 comments
Open

Frequent SIGSEGV crashes in Kodi 18 on macOS & Linux 18.04 #29

MarkCallow opened this issue Feb 10, 2019 · 40 comments

Comments

@MarkCallow
Copy link

MarkCallow commented Feb 10, 2019 •
edited
Loading

ProjectM in Kodi 18 on macOS is crashing frequently with SIGSEGV as shown in the crashlog at https://paste.kodi.tv/fagiqelami. I am running Party Mode when this happens. I do not know how to make it happen on demand.
@MarkCallow MarkCallow changed the title Frequent crashes in Kodi 18 Frequent SIGSEGV crashes in Kodi 18 Feb 10, 2019
@MarkCallow MarkCallow changed the title Frequent SIGSEGV crashes in Kodi 18 Frequent SIGSEGV crashes in Kodi 18 on macOS Feb 10, 2019
@peak3d
Copy link
Contributor

peak3d commented Mar 6, 2019

@MarkCallow pls. try the current version 2.2.0

@MarkCallow
Copy link
Author

I am unable to try it as I am not now at the location where I have Kodi 18 on macOS. Where I am now I have Kodi 18 on Ubuntu 18.04 and I am having a very difficult time getting any visualization to run.

@MarkCallow MarkCallow mentioned this issue Mar 11, 2019
Closed
7 tasks
@MarkCallow
Copy link
Author

I am suffering crashes on Ubuntu 18.04. At first I thought it was a Kodi problem. See Kodi issue 15720 but as it only seems to happen when ProjectM is running, I've changed my mind. It looks like the same problem as this. Crashlogs can be found at:

https://paste.kodi.tv/roluzujika.kodi, a crash at 10:09
https://paste.kodi.tv/oyexakerix.kodi , a crash at 10:43

They're not helpful as the stack trace part is empty even though I was running with debug logging.

I'm using ProjectM 2.1.0.1 which is the latest version in the xmbc ppa repo.

@peak3d
Copy link
Contributor

peak3d commented Mar 26, 2019

@wsnipex can we pls. update repo with 2.2.0 ?

@wsnipex
Copy link
Member

wsnipex commented Mar 26, 2019

2.2.0 is in the nightly ppa.
create a leia branch and it will be in the stable ppa automatically.

@peak3d
Copy link
Contributor

peak3d commented Mar 26, 2019

done. @MarkCallow pls. try again with the updated version

@Rechi
Copy link
Member

Rechi commented Mar 26, 2019

Creating a branch called leia does not change anything.

@MarkCallow
Copy link
Author

Creating a branch called leia does not change anything.

Yeah. I'm not seeing any update either. I did sudo apt-get update followed by apt list --upgradeable | grep -i projectm. Nothing.

@wsnipex
Copy link
Member

wsnipex commented Mar 27, 2019

try again please, it's there now

@MarkCallow
Copy link
Author

Got the update to 2.2.0. Thanks. Running it now. Will report back.

@MarkCallow
Copy link
Author

2.2.0 doesn't help. First try crashed after 1 hr 48 mins of Party Mode. The second after only 48 minutes.

How can I get the Kodi crash log to include the stack trace on Ubuntu? Or is there another crash log I should be looking for.

@MarkCallow
Copy link
Author

How can I get a helpful stack trace for you?

Kodi runs all day if visualization is set to none so I am convinced ProjectM is the problem.

@MarkCallow MarkCallow changed the title Frequent SIGSEGV crashes in Kodi 18 on macOS Frequent SIGSEGV crashes in Kodi 18 on macOS & Linux 18.04 Apr 1, 2019
@Albinoman887
Copy link

Are your songs in different sample rates ? I.e. 44.1 and 48khz? There is a bug when switching sample rates with visuals on. I have a fix for that on my git. Check the 18.2+ branch . BUT the updated presets also cause another crash . If I revert to the presets from 1.2.1 it is fine with my included sample rate patch . So you could be having one of the two different issues

@MarkCallow
Copy link
Author

MarkCallow commented May 29, 2019 •
edited
Loading

I have several tracks in 88.2 kHz and others in 96 kHz. However the low percentage of these tracks in my collection compared with the frequency of the crashes I see, suggests the presets problem may be the primary issue I'm seeing.

When I have time I'll set up short playlist with both 44.1kHz and 96 kHz tracks and see what happens.

@mweisshaupt1988
Copy link

This happens to me regularly. I have attached a few crashlogs, maby they help to find the issue.

kodi_crashlog-20190519_130908.log
kodi_crashlog-20190524_154525.log
kodi_crashlog-20190524_165520.log
kodi_crashlog-20190525_222055.log
kodi_crashlog-20190530_142630.log

@Albinoman887
Copy link

Albinoman887 commented May 31, 2019 via email

@Albinoman887
Copy link

Albinoman887 commented May 31, 2019 via email

@Albinoman887
Copy link

Albinoman887 commented May 31, 2019 via email

@MarkCallow
Copy link
Author

for the previous guy who has different sample rate tracks check your stacktrace for activeae runstages.

The Kodi crashlogs being saved on Linux (Ubuntu Bionic) have empty stacktraces so I can't check.

Does anyone know how to override the opengl profile for Nvidia cards ? I know exporting mesa gl override works for Intel and amd but I think Nvidia bakes them into the driver.

They are not baked into any driver. The application chooses which profile it wants when it creates its OpenGL context. What I guess is happening with Kodi/ProjectM is that Kodi is creating a context with a newer profile and ProjectM is using that context, rather than creating its own, and hasn't been modified for the newer profile. I'd further guess that Kodi is creating a Core profile OpenGL 4.x context and ProjectM is using one of the deprecated features that was been removed in 4.2, most likely the GL_EXTENSIONS target to glGetString. The override causes Kodi to get a 3.0 context. Whether it is Kodi or the OpenGL library responding to the override, I don't know.

I read somewhere dropping the opengl profile to 3.0 fixes some crashes with project m but I can't test it since I can't change it on Nvidia

Yes it does. Before I did that I couldn't run ProjectM at all. It crashed almost immediately on starting.

@Albinoman887
Copy link

Albinoman887 commented May 31, 2019 via email

@Albinoman887
Copy link

Albinoman887 commented May 31, 2019 via email

@MarkCallow
Copy link
Author

Do you have gdb installed ?

Is that required in order to get a useful crash log - pretty daft if it is. Or are you suggesting I run Kodi under the debugger?

@Albinoman887
Copy link

Albinoman887 commented Jun 1, 2019 via email

@MarkCallow
Copy link
Author

I don't know if Kodi is choosing OpenGL 4.2 or if it is using the system default. Perhaps the latter since MESA_GL_OVERRIDE overrides the change for devices using the Mesa driver. If Kodi and ProjectM are NOT requesting a specific context version, they have a responsibility to check what version they have and act accordingly.,

I think NVIDIA's control panel on Windows (not familiar if they even have one on Linux) lets you select the default OpenGL context. I don't know any equivalent of MESA_GL_OVERRIDE.

Instead of using non-standard overrides to force 3.0, you'll be better off fixing ProjectM so it no longer uses functionality deprecated in 4.2. I'm pretty sure you'll find the issue is that it is using glGetString(GL_EXTENSIONS) to get extension information. That will be returning NULL, along with a GL error, if the app bothered to check. If it is using an extension helper like OpenGL Extension Wrangler, it needs to be updated to use a much more recent version.

@Albinoman887
Copy link

Albinoman887 commented Jun 1, 2019 via email

@mweisshaupt1988
Copy link

Martin, try pulling the presets from v1.2.1 branch

Thanks, did not have a crash since yesterday using the presets from this branch. I'll need to wait a little more and see what happens to confirm that this workaround fixed the issue for me but until now it is looking very good. Then this issue here is indeed not related to mine.

@Albinoman887
Copy link

Albinoman887 commented Jun 2, 2019 via email

@MarkCallow
Copy link
Author

@Albinoman887 it turns out I already have gdb installed yet the stack traces in the crashlogs are empty. What else could be wrong?

I made a playlist with an 88.2kHz song followed by a 44.1kHz song. Kodi does not crash on the song changeover but pretty reliably if I press the backspace key, after the song change to go from the OSD back to the playlist display.

If I could find the real source code for ProjectM I could help w.r.t the OpenGL stuff. Main.cpp, the only source in this repo, doesn't really do anything. Where is the rest of it? If ProjectM is creating its own OpenGL context the simplest fix is to change that initialization to request a 3.3 context.

@Albinoman887
Copy link

Albinoman887 commented Jun 3, 2019 via email

@Albinoman887
Copy link

Albinoman887 commented Jun 3, 2019 via email

@Albinoman887
Copy link

Albinoman887 commented Jun 3, 2019 via email

@Albinoman887
Copy link

Albinoman887 commented Jun 3, 2019 via email

@Albinoman887
Copy link

Albinoman887 commented Jun 4, 2019 via email

@Albinoman887
Copy link

Albinoman887 commented Jun 4, 2019 via email

@Albinoman887
Copy link

Albinoman887 commented Jun 7, 2019 via email

@AlwinEsch
Copy link
Member

Think this was tried to fix with projectM-visualizer/projectm#149 but not work always correct, see #37

@mbellew
Copy link

mbellew commented Nov 2, 2019

Just for background. I tried to fix two different problems that I saw causing crashes. One was bad syncronization in renderFrame with USE_THREADS and the other was in allocating Milkdrop presets in MilkdropPreset factory (assumed only two presets were ever allocated at once, which was not true).

I actually wondered if the USE_THREADS complexity was even worth it on a fast CPU with some of the new optimization (MMX and LLVM). Is running with USE_THREADS turned off actually a problem?

@mbellew
Copy link

mbellew commented Nov 3, 2019

Sorry that comment was meant for issue 243. I did notice this in the logs above

#0 0x0000000000000000 in ?? ()
#1 0x00007ffa7e71a251 in Renderer::RenderItems(Pipeline const&, PipelineContext const&) () from /usr/lib/x86_64-linux-gnu/libprojectM.so.2
#2 0x00007ffa7e71afc3 in Renderer::RenderFrame(Pipeline const&, PipelineContext const&) () from /usr/lib/x86_64-linux-gnu/libprojectM.so.2
#3 0x00007ffa7e6db434 in projectM::renderFrame() () from /usr/lib/x86_64-linux-gnu/libprojectM.so.2

If I recall correctly that was similiar to the crash I've seen when presets were overwriting each other. You end up trying to call through a vtable of freed RenderItem.

There could be a bug in one of my attempted fixes. I'm also wondering if KODI is calling into the libprojectm on multiple threads concurrently? That app obviously has a lot of threads, but the library is not thread safe.

@mbellew mbellew mentioned this issue Nov 3, 2019
Closed
@Albinoman887
Copy link

Albinoman887 commented Nov 3, 2019 via email

@mbellew
Copy link

mbellew commented Nov 4, 2019

Yes, it uses multiple threads internally (when transitioning presets), however, it does not expect the API to be called by different thread from the main app concurrently. E.g. say calling projectM::render() on one thread and projectM::switchPreset() on another. I'm trying to build everything out of curiosity, but I don't know if/when I'll get anywhere.

@revmischa revmischa mentioned this issue Nov 16, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@wsnipex @Albinoman887 @MarkCallow @mbellew @mweisshaupt1988 @Rechi @AlwinEsch @peak3d