Inochi2D/inochi-creator

[BUG] Crash with any other argument than a valid inochi2d file

Opened this issue · 1 comments

lowczarc commented

Validations

  • I have checked for similar bug reports and could not find any.
  • I have tested and confirmed that this is an issue in an official branded build.

Describe the bug

I am the package maintainer of inochi-creator on Arch linux.

I've noticed while updating to 0.8.4 that calling inochi-creator --version, --help or anything other than an inochi2d file in the argument is causing a segfault.

Other than that everything seems to be working correctly.

The issue was also there on v0.8.3 and I got the confirmation from Grillo on discord that it also happens on his RPM package version.

In itself it is not a big deal since it doesn't seems to break anything important, but I guess it might be a bit weird for CLI users to have their first interaction with the software be a segmentation fault.

I'm not familiar at all with DLang but I guess it would not be very hard to add a check "if file doesn't exists, print the usage", so I can look into it myself.

Reproduction

Launch inochi-creator --version from the CLI

System Architecture

x86_64

Operating System

Linux

Version

0.8.4

Logs

$ inochi-creator --version
Segmentation fault (core dumped)

Additional Context

(I lied to github when saying I tested it's in an officially branded build since I am unable to launch said officially branded build from my setup, sorry about that, but as said before, since it's been confirmed by Grillo that it also happens on his side I'm pretty confident it is also the case in official builds. Feel free to bonk me and close this issue if it's not the case and I'll make a patch for my build instead)

grillo-delmal commented

Just to be clear, the SegFault does affect official builds.

Studying the issue, I noticed that the problem is caused by the incOpenProject that is called in source/app.d
If for any reason the incOpenProject function fails to open a file, it tries to declare a dialog and returns, leaving the app in an unexpected state with no puppet loaded, this causes the app to crash when trying to update the UI for the first time.

This can be easily verified by changing the call to incOpenProject!false, that way the method is able to throw an exception and show the actual problem instead of crashing.

grillo@rivaia:~/src/inochi2d/inochi2d-build$ ./run-creator.sh /tmp/poto 
GLInfo:
        3.2.0 NVIDIA 545.29.06
        NVIDIA Corporation
        NVIDIA GeForce RTX 2060/PCIe/SSE2
        1.50 NVIDIA via Cg compiler
        gls=gl32
object.Exception@../inochi2d/source/inochi2d/fmt/package.d(49): Invalid file format of  at path /tmp/poto
----------------
../inochi2d/source/inochi2d/fmt/package.d:49 [0x4a8e9e]
source/creator/package.d:235 [0x52dd08]
source/creator/package.d:216 [0x4776d2]
source/app.d:85 [0x60ab45]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() [0x7fe9ae5a0b8c]
??:? _d_run_main2 [0x7fe9ae5a09a2]
??:? _d_run_main [0x7fe9ae5a07ec]
/usr/lib/ldc/x86_64-redhat-linux-gnu/include/d/core/internal/entrypoint.d:42 [0x60ace1]
??:? [0x7fe9add65149]
??:? __libc_start_main [0x7fe9add6520a]
??:? [0x474cc4]

I think this can be better handled by using the incOpenProject!false function, catching the thrown exception and either

  • Closing the app with a proper error message
  • Fixing the invalid state by declaring an empty puppet and continue the opening process and show an error message.

I'm more inclined to the first of the 2.

Regarding the --version and --help commands, I can tell from source/app.d history that the app never had an implementation of those commands, but I agree that it would be nice to have them.

  • 👍1