[DEV BUG] Multiple instances of projectm/playlist pair sometimes crash

[insel-maz]

Please confirm the following points:

• [X] This report is NOT about the Android apps in the Play Store
• [X] I have searched the project page to check if the issue was already reported

Affected Project

libprojectM (including the playlist library)

Affected Version

4.1.2

Operating Systems and Architectures

Windows (x64)

Build Tools

Compiler: Microsoft Windows SDK, Build Tool: CMake, Dependency Manager: vcpkg

Additional Project, OS and Toolset Details

No response

Type of Defect

Crash (unhandled exceptions, segmentation faults)

Log Output

The following error occurs:

Exception thrown at 0x00007FFA9847DD96 (atio6axx.dll) in projectM-Test-UI.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

At:

https://github.com/projectM-visualizer/projectm/blob/1b8004f7142e73df576bfbe962819b92307ede49/src/libprojectM/MilkdropPreset/FinalComposite.cpp#L133

Describe the Issue

When having more than one projectm and playlist instance pair in the same process, this lib (sometimes) crashes when switching a single projectm and playlist instance pair to the next preset via projectm_playlist_play_next. To assist debugging I have refactored the Test-UI code to create multiple windows: https://github.com/PinJuke/projectm/tree/multi-instances-test-ui (If you think this is good to have permanently, I can create a PR.)

[kblaschke]

Without a proper stack trace it's hard to tell where exactly the crash occurs. The information above says it's happening in the OpenGL vendor driver, so it's not necessarily something we can fix on projectM's side.

If possible, please provide a complete stack trace of a crash. Ideally, attach/provide a full core dump and the executable plus any PDB files so we can post-mortem debug it and see more details.

[insel-maz]

I did some more troubleshooting. I have solved the issue. The OpenGL context must be set when rendering as well when processing (window, keyboard, ...) events. I have pushed a new commit to my branch of Test-UI.

[kblaschke]

Ah, sure, makes sense if the context isn't active when pressing the preset change key (as loading a preset will compile shaders and allocate some GL buffers), then this will definitely wreak havoc. With just one instance, the same context is always active so that's not an issue.

[insel-maz]

Thank you for dealing with my issue. And thank you for an awesome library.

[kblaschke]

Sure thing! I guess in a more production-like environment that uses multiple instances, one would certainly wrap the projectM instance in a class that takes care of setting the proper context when calling functions that need it.

That said, I've taken a note to add this to the wiki, as it looks like an issue more devs will run into with their own projects, as it's not fully obvious to everyone that loading a new preset also requires a proper context - wouldn't be the case if we'd defer loading until the next frame render call, but as of now, the present is fully loaded in the load_data/_file methods.