Crashing On Linux When Clicking "Edit" #84
Comments
|
I had a feeling it was probably opengl related. I probably should have pointed you to that section of the code. I will have a look later to see if there are settings that need changing for Linux |
|
I left the complete GDB dump at https://paste.ubuntu.com/p/PwmkhSyP7Q/ if you're interested in the full backtrace. |
gentlegiantJGC
added
type: bug
|
I am not really sure what is causing the issue. Google doesn't have anything of much use. You could try updating the UI library to the newest one since you said you are using a version of Ubuntu 20 with python 3.8 and the one that automatically installs is for Ubuntu 20 for python 3.7. https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-20.04/ We could really do with having someone on the dev team that knows more about linux (and mac) |
|
If that doesn't work you could try messing around with line 18 and line 24 of |
|
Funny you should mention that. In order to get Amulet to install initially, I had to use wxPython-4.1.0-cp38-cp38-linux_x86_64.whl for 20.04 because wxPython-4.1.0-cp37-cp37m-linux_x86_64.whl from 18.04 fails with a "Wrong OS" complaint, so I've actually been using the new version the whole time. Being on the dev team would be great. In my case, however, while I'm well versed in Linux, I don't know enough about Python to do much more than a basic "Hello World." |
|
Here are the docs for the two things you would need to change. I don't know what else to suggest. https://wxpython.org/Phoenix/docs/html/wx.glcanvas.GLContextAttrs.html This is what you would need to change Perhaps try changing line 19 to "32" like the docs say but I think that caused a crash on my computer |
|
As soon as I get home from work today, I'll check it out and let you know. =) |
|
On v0.6.11.0, I made the change from 24 to 32, and it doesn't kill the program, but it still fails to create the map: The program continues to run, and I can close the tab, or exit, or even open a new world, but I can't edit:
On v0.7.0.0, I can't get beyond the World Selection, so I have no idea what impact the change I made (again from 24 to 32) has: As with 0.6.11.0, I can still navigate the menus (quit normally, close the world, try to open a new one), but I can't do anything else. I just get trapped on the opening screen until I exit Amulet.
I'll keep playing around with things and see what happens. Edit Edit 2 |
|
I've spent 4 hours demolishishing and recreating Python virtual environments over and over, removing everything, reinstalling it all, and I'm getting nowhere. No matter what I do, each time I open a world on 0.7.0.0, it ends the same way: Nothing works. When I run python with I'm lost. |
|
Sounds like I missed a step in our build process |
|
Ah no you are running from source. The other libraries have changed so you will need to uninstall them and reinstall them |
|
You might need to run the pip command that clears the cache so that it doesn't use the cached old version |
|
Caching is such a pain sometimes. lol So I cleared the cache, and decided "What the hell!" and deleted the entire virtualENV I was working in, and started over. First, I cloned the GIT master branch. Then I patched Then, I opted to keep things cleaner this time around by doing Then I changed https://github.com/Amulet-Team/Amulet-Map-Editor/blob/master/amulet_map_editor/api/opengl/canvas/base.py#L19 from 24 to 32, and proceeded to load a world, which was going great until I clicked "edit" and again, it stopped working, but didn't die. I could still close the world, and navigate the menus. I still can't edit, but at least I'm not getting fatal errors now. In fact, on first glance, this seems to be almost the same thing I got from my patched version of 0.6.11.0. I'm not sure if there's still something messed up with my local install, so I'm going to try it on a virtual machine so I can just do a clean install of Mint, install only what's needed for Amulet, and not worry about contamination from older projects. |
|
Since I'm off today, I gave it a shot, and I get the same error on the virtual machine as I do on the real one. The VM is running a clean install of Mint 20 with only what was needed for Amulet, plus the tweak to https://github.com/Amulet-Team/Amulet-Map-Editor/blob/master/amulet_map_editor/api/opengl/canvas/base.py#L19, which I changed to 32.
Perhaps I should be filing the bug report against wxPython for this? It seems that's where the problem is coming from now, and not Amulet directly. I'll drop by their GIT and see what they say. ** Edit: Mint 20 (Mint release notes) is forked from Ubuntu 20.04 (Ubuntu release notes). |
|
I'm curious... The release notes for wxWidget say:
Where is this done in Amulet? |
|
I give up. Python makes my head hurt. |
|
This is still an issue we want to fix. I will leave it open in case someone else has the same issue |
|
I'm back! So, it took them a while, but they finally got back to me on the wxWidgets GIT, so I'm passing along their response in hopes this helps, and run it with his suggested tweaks and see what happens:
|
|
So I tested on my production rig this time, rather than the VM and set and And it fails under both those with both |
|
Do you have a link to that bug report you opened? GitHub will link the two reports. |
|
It's at https://trac.wxwidgets.org/ticket/18891 but I can't get to it right now with my home ISP. Only works on my mobile data for some reason. |
|
I posted this on the other thread as well, but it bears repeating. According to https://linuxconfig.org/how-to-enable-disable-wayland-on-ubuntu-20-04-desktop, Wayland is disabled by default on Ubuntu 20.04, which serves as the base for Mint 20, so the comment at https://blog.linuxmint.com/?p=3890#comment-154895 stating that Wayland is not even really supported on Mint 20 tracks, meaning I shouldn't need to force X11 through Edit: Mint team explains position on Wayland: https://blog.linuxmint.com/?p=3890#comment-154935 |
|
Indeed, I searched my |
|
Because X11 is asynchronous, does that impact the way Amulet creates the window on Linux? Or is this already factored by the OpenGL components in the back-end? On wxWidgets, they suggested setting the I'm going to play around with it some and see what happens. |
|
Yeah, I haven't had a lot of time to work through it since this ticket was
first opened, but nothing I've done has helped, and the precompiled
packages don't seem to want to run either.
This was originally developed for use on Windows, and as such, I've been
able to get the Windows binaries to work under WINE but it's a bit messy,
and doesn't always work because of regression issues that pop up from time
to time.
I don't find myself using it very often, but if you plan to use it
frequently, use Lutris or PlayOnLinux to create a WINE instance with a
version you know works, and let it be so that issues as a result of
regressions introduced by changes to WINE won't affect you.
…------------------------------------------------------------
"Yo, yo. I'm real happy for ya, and I'm glad you can read, but first, I
wanna say that Seann has the best email signatures of all time. OF ALL
TIME!"
-- Kanye West, 2009 Email Signature Awards
------------------------------------------------------------
On Wed., Oct. 28, 2020, 11:54 soulster, ***@***.***> wrote:
Funny you should mention that. In order to get Amulet to install
initially, I had to use wxPython-4.1.0-cp38-cp38-linux_x86_64.whl for 20.04
because wxPython-4.1.0-cp37-cp37m-linux_x86_64.whl from 18.04 fails with a
"Wrong OS" complaint, so I've actually been using the new version the whole
time.
I'm having the same issue on Ubuntu 20.04.1 LTS. I can open a world, but
it crashes if I click "3D Editor" tab. I also had to use this wxPython
wheel to get a successful install. I really don't have the chops to help
debug this issue, but I just wanted to confirm the issue.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#84 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZA7TSTHM4DFNTZTYPPMTLSNA5BRANCNFSM4P2MJHIA>
.
|
|
I've also observed this same issue. Backtracing with gdb got me to a GLX instance creation, at which point it seemed to throw the X11 error. I am using the Proprietary NVIDIA driver on Kernel 5.9 - maybe that also has something to do with it? Vulkan, OpenGL, and EGL all work fine for me, but I don't really have a good way of testing GLX directly. |
|
The X11 error is thrown asynchronously unless you use an environment
variable to disable this default behaviour, but I don't remember what it is.
Before I gave up and went to WINE, I was trying to get more detailed error
reporting using the guidelines at
https://vallentin.dev/2015/02/23/debugging-opengl which is admittedly a bit
dated by this point, but still useful.
|
|
Thanks for the tip - I tried debugging it with GDK_SYNCHRONIZE set and backtracing, which led to the same function as noted above. I think I may try to regression test this today, as Amulet definitely worked a few months ago on my system.
Edit: I can confirm that version 0.6.9.2 from the releases page does work on my system, although I've so far been unable to build it from source due to a lack of versioning in the pip dependencies (as it can't build against the latest Amulet libraries).
I currently suspect that something about the latest builds of wxPython on Debian might be problematic, just because I did a code comparison between these two versions and the regression still occurs even when the attribute code is completely reverted to its 0.6.9.2 equivalent.
|
|
Actually nevermind, I think I have traced the error :) Removing this part leads to everything fully initializing, although I have to reset my virtualenv in order to get a better idea about whether the actual rendering works as expected. It certainly doesn't crash though :) Edit 3: Success! I am not sure if this is a tenable workaround, but:
Replace instead with It looks like passing ctxAttrs to the context causes some sort of error on Linux.
I am not sure why this causes problems, but with these two changes made Amulet functions just as before on Linux (with flickering menus, but otherwise completely functional) This may well be a wxPython bug, but it could also have to do with the use of the NVIDIA driver, as that is where the actual X error is generated. |
|
Do you have the traceback for the dtype assertion? It is probably an internal issue. Also the world version you opened |
|
If you don't specify the attributes what does it use? I presume the defaults assuming that is compatible with what we are doing |
I tested it initially with both a 1.16.4 world (from a Spigot server) and a 1.16.3 world (from a Fabric server, but with only Lithium, Phoshor, and FabricProxy installed, so without custom blocks / chunkdata). Here is the traceback: I'm not sure what the default behaviour for attribute inheritance is, but I also assume that it would choose defaults somehow. It may also be related that this is quite a large world - more than a gigabyte at the moment, with approximately 3000x3000 blocks around 0,0 already generated by players using elytras. |
|
If a few more people on Linux can test that fix and confirm it works we can add it as a workaround for Linux. I will look into the assertion in a bit |
|
Which line (or lines?) did you alter in I tried removing Interestingly enough, I'm running version 455 of the nVidia proprietary driver, as I recently upgraded my video card to the GeForce GTX 1660. I think I should boot from my live environment thumb drive and see what happens when using the Nouveau driver instead of the proprietary one, tomorrow. ** Edit: My system has actually gone through a number of changes since I first tried Amulet. Complete specs are at https://termbin.com/xj9l if it helps anyone. |
|
If it causes you issues the last line of the traceback above. The line starts with |
|
This is the actual fix you need to try |
|
Side note: I've read that under Linux you can't set the OpenGL context until the window has a non-zero size, but I don't have the Python skills to verify this and change it if necessary. I tried stepping through line by line in PyCharm, and watching everything as it unfolded, but it got way too technical with code improvement suggestions for everything it encountered then telling me that the files in Also worth noting that Amulet crashes right out of the gate with Python 3.9 (which PyCharm defaulted to, and I had to change). With 3.8, it only crashes when I click the 3D tab. |
|
The context isn't set up until you click the edit button. That is the reason why it is crashing. Did you try making the suggested change to the context? |
I did change to It's the removal of the dtype assertion I was unclear on as it still crashes for me. |
|
That is close to the change they suggested but not exactly the same. They totally removed the context attributes lines. context_attributes = wx.glcanvas.GLContextAttrs()
context_attributes.CoreProfile().OGLVersion(
3, 3
).Robust().ResetIsolation().EndList()
self._context = glcanvas.GLContext(
self, ctxAttrs=context_attributes
) # setup the OpenGL contextshould become this self._context = glcanvas.GLContext(
self
) # setup the OpenGL contextWhat is the dtype crash? Have you removed the assert line? |
|
Ah. I misunderstood the change. So But I'm wondering if I botched that too because I still get that whole |
|
I'm not sure if this would help EvilSupahFly, but I would recommend reinstalling (--force-reinstall) the Amulet dependencies using pip3, and then resetting the git repo to head if you still have any uncommitted changes. I didn't actually have to change MinRGBA or the depth in order to avoid BadValue, but rather just remove the lines setting up context attributes as noted above. The dtype assertion never caused BadValue errors, just a crash of the renderer when loading my worlds. If you still see BadValue after trying that, could you try inserting print statements thoughout the file and investigating where it crashes ? Make sure to use GDK_SYNCHRONIZE=1 for that.
|
|
Well. I uninstalled everything first, using I set Now that I've come this far, and confirmed the findings from #84 (comment), I went into Now, it renders the world, but the buttons only appear for a short time when the mouse is over them, or when I'm rotating the map view. I tested Copy and Paste, which seemed to work, and was able to switch from Overworld to Nether, all of which you can see in https://youtu.be/3ZBt5f6A3wc. So, now it works, mostly. The menu flickering is a bit of an annoyance, but not fatal. |
|
Awesome news. I haven't gotten around to looking into why that assert is a problem. You can probably get by with just uncommenting it. The flickering is a problem |
|
When I uncomment it, Amulet crashes. I would have to remove the lines
entirely.
…------------------------------------------------------------
"Yo, yo. I'm real happy for ya, and I'm glad you can read, but first, I
wanna say that Seann has the best email signatures of all time. OF ALL
TIME!"
-- Kanye West, 2009 Email Signature Awards
------------------------------------------------------------
On Sun., Nov. 8, 2020, 16:24 gentlegiantJGC, ***@***.***> wrote:
Awesome news. I haven't gotten around to looking into why that assert is a
problem. You can probably get by with just uncommenting it.
The flickering is a problem
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#84 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZA7TQF2W4VW2GB7HMX5KDSO4EA3ANCNFSM4P2MJHIA>
.
|
|
Sorry I meant commenting it out |
I am not entirely sure why this fixes it or what issues this may cause
|
a07ee4c should fix the canvas issue |
|
a07ee4c has indeed fixed the assertion issue with the base canvas, and as you can see in this new video, aside from the flickering, the world editing seems very stable on Linux, and the edited world plays fine in Minecraft. |
|
Awesome. I have opened #127 for the flickering issue. I think that resolves all the issue for this report |
Quite nicely, I think. :) |
I'm running Amulet on Linux Mint 20 (based on Ubuntu, which is itself a Debian derivative).
I cloned the latest release of Amulet with GIT, installed the dependencies without a problem, and I'm running Python 3.8.2.
My system is pretty solid:
Using Amulet, I was able to open an old world and convert it to 1.16.1, but if I attempt to click the "Edit" button, it always crashes with the following complaint:
I saw a
logsdirectory, so I had a look, but it wasn't very helpful. Here's what I got from those log files, including a little extra info I had some of the subroutines dump to the log as I went through the debugging:I know Amulet doesn't support forge, so I expect it to have complaints about those worlds (which it does - the Underwater NPC Village worlds are older Forge worlds my daughter made on 1.6).
But when I attempt to edit any non-forge worlds I have, such as REDRED_3, listed above, it crashes.
After MUCH tinkering, and some excessive exploitation of Amulet's own logging function, I think I've managed to locate the moment the program crashes on my Linux install:
I had to do a lot of stepping through each line and function as I went, but I have generated a complete log, which I've posted to https://paste.ubuntu.com/p/vjdQGtF8VD/ if you want to look at the entire thing because it's 855 lines, and that's just too much to put here.
I hope this helps! :)
The text was updated successfully, but these errors were encountered: