Pidgeot / python-lnp

Cross-platform re-implementation of the Lazy Newb Pack launcher.
ISC License
65 stars 10 forks source link

0.9 x64 version crashes on dfhack start #50

Closed Pidgeot closed 4 years ago

Pidgeot commented 4 years ago

:D Hi I just wanted to document a crash I got while testing.

I was testing the new LNP configuration on Ubuntu with with the PyLNP 0.9 linux-x64 version and DFHack 0.40.24-r0 when I encountered a crash. When trying to start DFhack through the GUI, it crashes silently and dwarf fortress never starts; no windows appear. I tested it with both the i686 and x64 versions, same error. Dfhack and DF each work independently from the gui.

Here is the error I found in Output log:

#!python

Exception in Tkinter callback

Traceback (most recent call last):

  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/Tkinter", line 1486, in __call__

  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/core.launcher", line 46, in run_df

  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/core.launcher", line 83, in run_program

  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/core.launcher", line 123, in program_is_running

TypeError: decode() argument 1 must be string, not None

Distro:

Let me know if there is anymore information you need, or anything else I can do.

Thank you so much for all your hard work and releasing cross platform to linux!! :D

[Issue created by beaubouchard: 2015-01-24] [Last updated on bitbucket: 2015-02-05]

[Comment created by Pidgeot: 2015-02-05] Use a fallback encoding when checking for running processes with ps (fixes #57)

→ <<cset 175ca30253f5>>

[Comment created by Pidgeot: 2015-02-04] So, the thing it's complaining about it this line:

    return path in s.decode(sys.getfilesystemencoding())

Specifically, it's saying that on your systems, sys.getfilesystemencoding() is returning None, at least when run from the binaries. Apparently this will happen if the system doesn't specify a specific encoding.

I'm adding a fallback to UTF-8 for that particular case, and telling it to ignore errors during decoding (in the rare event of a non UTF-8 *nix/OSX).

[Comment created by Pidgeot: 2015-02-05] Actually fix #57

→ <<cset 05b0ae1bd09d>>

[Comment created by cptmashek: 2015-01-28] This also happens in Linux Mint Debian Edition, amd64.

[Comment created by beaubouchard: 2015-01-26] also happens with DFHack 0.40.24-r1