petr.mrazek

Attached report as a file, so it doesn't expire on pastebin.

It seems to be related to the skins functionality and/or the parser code in the skins implementation.

The cause is most likely different. Open a new bug please.

What are the contents of the report?

Also, what GPU and GPU drivers are you using?

Can you post what the launcher prints in the terminal when you do this?

I don't know. Post the whole log file.

Please test with the latest release, it looks like your issue is related to MCL-12341, which has been fixed.

Try renaming {{D:\BS\game}} to something else. Does it help?

The problem has been resolved in multiple places - the backend services, the main launcher executable, and the update checking logic in general. Closing.

The problem has been resolved in multiple places - the backend services, the main launcher executable, and the update checking logic in general. It should be very hard for it to fail in similar way ever again.

That sounds like you put the executable (`.exe` file) on your desktop instead of a shortcut.

The launcher is not supposed to run from the desktop folder. When you put the executable there, it will download all the other parts of the launcher and put them next to itself.

Learn the difference:
https://en.wikipedia.org/wiki/Shortcut_(computing)

In any case, this works as intended. And you might want to use the installer instead: https://launcher.mojang.com/download/MinecraftInstaller.msi

If you still want to use the .exe file, put it somewhere else and make a shortcut.

This should now be fixed.

@Aljaz S. No, you ran into mods being broken and abusing Java internals. That has nothing to do with this issue.

You will have to use Java 8 with modded and old versions. Anything above 8 will not work.

Looks like you are using a version of Java that is not compatible with older versions of Minecraft.

You need Java 8.

You are on linux, and on some linux distributions, the maintainers decided to stop shipping Java 8. You may have to find an alternative way of obtaining it, and ensure that it is used by the game.

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:

FROM ubuntu:16.04

RUN apt-get update && apt-get upgrade --yes && apt-get install --yes \
  ca-certificates \
  lsb-base \
  xdg-utils \
  wget \
  curl \
  zip \
  vim-common \
  python \
  build-essential \
  libssl-dev \
  libcurl4-openssl-dev \
  g++-4.9 \
  libstdc++-4.9-dev \
  libstdc++6 \
  libgl1-mesa-dev \
  libx11-dev \
  libbz2-1.0 \
  libbz2-dev \
  gconf-service \
  libasound2 \
  libatk1.0-0 \
  libc6 \
  libcairo2 \
  libcups2 \
  libdbus-1-3 \
  libexpat1 \
  libfontconfig1 \
  libfreetype6 \
  libgcc1 \
  libgconf-2-4 \
  libgdk-pixbuf2.0-0 \
  libglib2.0-0 \
  libgtk-3-0 \
  libgtk-3-dev \
  libepoxy-dev \
  libnspr4 \
  libnss3 \
  libpango1.0-0 \
  libstdc++6 \
  libx11-6 \
  libxcomposite1 \
  libxcursor1 \
  libxdamage1 \
  libxext6 \
  libxfixes3 \
  libxi6 \
  libxrandr2 \
  libxrender1 \
  libxss1 \
  libxtst6

So, bundling libraries from Ubuntu 16.04 would be the closest approximation you could possibly get for your wrapping efforts. No guarantees, of course.

I found this thing:

https://code.foxkit.us/adelie/gcompat/tree/8d4cfd83df0aa386282bba149fd3f790745cfea8

It might help?

/ > opt > minecraft-launc… >  > $ > grep -R __realpath_chk * 
Binary file liblauncher.so matches 
Binary file minecraft-launcher matches

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.

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.

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.