Skip Navigation
OpenRGB @lemmy.ml The_Linux_User @lemmy.ml

Cannot open V.0.9 on Fedora 38, getting std::bad_alloc error when running from terminal

Release 0.9 does not want to open, even after a complete reinstall. If I launch it from the Terminal I get the following error:

Connection attempt failed Local OpenRGB server unavailable. Running standalone. QSocketNotifier: Can only be used with threads started with QThread qt.qpa.qgnomeplatform.theme: The desktop style for QtQuick Controls 2 applications is not available on the system (qqc2-desktop-style). The application may look broken. [PluginManager] Plugin /home/USER/.config/OpenRGB/plugins/libOpenRGBVisualMapPlugin.so.1.0.0 has an incompatible API version [OpenRGBSchedulerPlugin] Loading plugin API version. [OpenRGBSchedulerPlugin] Time to free some memory. [PluginManager] Plugin /home/USER/.config/OpenRGB/plugins/libOpenRGBSchedulerPlugin.so.1.0.0 has an incompatible API version [OpenRGBSkinPlugin] Loading plugin API version. [OpenRGBSkinPlugin] Loading plugin info. [OpenRGBSkinPlugin] Time to free some memory. [OpenRGBSkinPlugin] Loading plugin API version. [OpenRGBSkinPlugin] Loading plugin. [OpenRGBSkinPlugin] Creating widget. terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

Information about my OS:

  • Linux Fedora 38 (Wayland session)
  • Kernel: 6.4.9-200.fc38.x86_64
  • Installed the RPM package
  • Ryzen 7 3700X
  • RTX 3070
  • 16Gb DDR4 (currently 5.18GB used)

I have already posted an issue on GitLab just before this post, maybe someone here knows the answer then I can close the issue.

5

You're viewing a single thread.

5 comments

  • Did you open a bug report on the Fedora side?

    • Nope, I opened an issue on the OpenRGB GitLab page. Since previous versions of OpenRGB didn't have this issue I'm guessing that it's not a Fedora issue, but I could be wrong of course!

      • It could be a dependency issue, and even if OpenRGB is truly at fault here, the patch would be backported way earlier if the maintainer know about the problem.

        As a general rule, always open a ticket on the maintainer side first, then open it on the upstream side if the maintainer tell you to do so. It helps rule out many problems upstream cannot easily test before asking them to sink time into the problem.