Launch failure "basic_string::_M_construct null not valid"
▶ flatpak run com.mojang.Minecraft
{{terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid}}
I'm trying to run the Minecraft launcher in a Flatpak container. Although it works on one system, it fails with the above error in another. It seems to be a launcher bug. It crashes instantly and no window appears.
{{}}
Flatpak bug report https://github.com/flathub/com.mojang.Minecraft/issues/25{{}}
Environment
Flatpak, OpenJDK 11
Created Issue:
Launch failure "basic_string::_M_construct null not valid"
▶ flatpak run com.mojang.Minecraft
{{terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid}}I'm trying to run the Minecraft launcher in a Flatpak container. Although it works on one system, it fails with the above error in another. It seems to be a launcher bug. It crashes instantly and no window appears.
{{}}
Flatpak bug report https://github.com/flathub/com.mojang.Minecraft/issues/25{{}}
Environment
Flatpak, OpenJDK 11
- Unresolved
- Open
- Unconfirmed
- Launcher Core
- crash
- 2.1.7658 (linux Beta)
is duplicated by
is duplicated by
is duplicated by
Thank you for your report!
We're tracking this issue as MCL-12281, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as Won't Fix, which means this is considered a bug but won't be fixed. The description of that ticket or the comments might explain the rationale. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! Please report any issues on Discord or Reddit
Thank you for your report!
We're tracking this issue as MCL-12281, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as Won't Fix, which means this is considered a bug but won't be fixed. The description of that ticket or the comments might explain the rationale. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Thank you for your report!
We're tracking this issue as MCL-12281, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as Won't Fix, which means this is considered a bug but won't be fixed. The description of that ticket or the comments might explain the rationale. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
I'm glad you all were able to figure out the issue.
For reference, at the time of this report's creation, we were already tracking this issue as MCL-12281 (if I'm understanding this report correctly).
The minecraft launcher is not delivered via flatpak.
Any such copy is illegal.EDIT: Nevermind, it seems to be downloading the launcher and wrapping it in some weird way.
Still, not supported. We don't ship the launcher this way.
Well, that was a premature response.
I realize you guys aren't as much into Linux as the players playing on that platform, but this is not a correct response. Flatpak is not "wrapping the application in some weird way". It's the recommended way to package proprietary applications on Linux, as you don't need to worry about what distribution you're running it on. Basically every application is containerized with the libraries it requires, and the versions it requires. I really recommend you look into it seriously as it's way easier to just support Flatpak than support every distro separately. I would recommend it over supporting .deb and AUR packages really, at least with Flatpak you're sure what libraries and versions they're using.
In my case, it's the only way I can play a proprietary game like Minecraft (or at least, run the launcher. I don't think the old Java launcher is still available somewhere is it?) because I run a non-standard distro with a different C library than most (Musl rather than glibc). Of course I realize you're not going to support my distro, but with Flatpak that wouldn't even be needed. The game would run on any distro on which Flatpak runs.
Seriously, please look into Flatpak packaging. Don't take my word as a stranger, do some little research yourself and you'll see the benefits.
I wouldn't recommend this to anyone.
No matter how hard you try, something will conflict in the end. I've tried going the 'full dependency tree shipped' route before, and what it gives you is an illusion of compatibility.
It pretty much falls apart the moment you need system libraries. And anything interesting will. Graphics, desktop/platform integration, the requirement of speaking the same versions of protocols (like talking to a screen reader over DBus) , so on, and so forth.
The sensible thing to do is to rely on the available stable ABIs. GTK, Qt, libcurl, glibc, libstdc++ - these all have stable ABIs and you can ship software based on them without shipping them on linux.
So, I'd rather go in the direction of minimizing the direct dependencies and not shipping anything that can get security updates from the OS.
The problem in this case is that my system isn't supported by the launcher either, as it uses Musl rather than glibc. If the launcher stayed away from using "GNUisms" (in this case glibc specific extension) and just used POSIX compatible functions, there wouldn't be a problem but apparently it doesn't. Flatpak would at least resolve that issue.
So ok, Flatpak aside, is there a chance I could get support for running the launcher on a Musl system? The game itself should run fine because of it using Java, it's a shame that I just can't launch it.
It would need some research first. There's a lot of code in the launcher. The libc part is the smallest, and probably the easiest thing to handle.
Well I'm glad you're not outright dismissing this issue, thank you for that. The error I'm getting when running:
At least that one is in the launcher only.
The source code of course doesn't call `_realpath_chk` - it calls `realpath`. Which means it's probably turned into `_realpath_chk` by some macros.
I found this thing:
https://code.foxkit.us/adelie/gcompat/tree/8d4cfd83df0aa386282bba149fd3f790745cfea8
It might help?
Yeah I've tried that before, it helps a bit but doesn't fix the symbol not found problem sadly. The error message is then just
Right. I managed to get rid of __realpath_chk, by not using the POSIX 2001 version of realpath that has horrible buffer size issues.
Here's a tarball:
https://drive.google.com/file/d/1VOywd6XHRW6rcFfuPt-4MlSKDyFjINrg/view?usp=sharing
In any case, here's the environment the launcher is built in:
So, bundling libraries from Ubuntu 16.04 would be the closest approximation you could possibly get for your wrapping efforts. No guarantees, of course.
Well, that's an improvement, at least no errors are printed to the CLI now. However, nothing happens either, it seems the binary quits immediately? There doesn't seem to be a "-v" or "--verbose" switch so I'm not sure how to get you more details.
Thanks for the help so far, but sadly as mentioned the launcher still doesn't run on a non-glibc environment. Did you make any progress with this?
Because this bug is marked as wontfix:
I found a really easy workaround that was in the flatpack issue:
Run minecraft with this environment value LC_ALL=C . This fixes flatpack as well as AUR repository
This means to run with flatpack command is: LC_ALL=C flatpak run com.mojang.Minecraft . And on archlinux if you have a problem with that: LC_ALL=C minecraft-launcher .
I just encountered the very same issue with the official DEB file.
I was not able to start the launcher from my Menu or from the Desktop shortcut.
Now here's the thing:
I was able to start it from my terminal when I typed "minecraft-launcher". So I decided to just make a bash script to start it for me. Went ahead and just made a two line script containing the shebang and the "minecraft-launcher" command.
That did NOT work and failed with the very same error mentioned in the issue above.
Then I tried to explicitly set the LC_ALL variable as mentioned above:
And this actually worked.
So this has to be a bug in the launcher as no Fallback language is defined.
(Im on the Launcher Beta Version 2.1.17785)
This error appears when I launch minecraft from ZSH and also from KDE PLasma's gui (there's a window updating and it closes) . Fixed when setting the above environment variable.