Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account
Jump to bottom

Invoking prusa-slicer from $PATH environment variable crashes #5542

Closed
hzeller opened this issue Dec 20, 2020 · 3 comments
Closed

Invoking prusa-slicer from $PATH environment variable crashes #5542

hzeller opened this issue Dec 20, 2020 · 3 comments

Comments

@hzeller
Copy link
Contributor

Version

PrusaSlicer-2.3.0-beta3+linux-x64-202012121815

Operating system type + version

This is on Linux.

Behavior

Prusa slicer starts up when invoked directly with an absolute or relative path

tar xjf ~/Downloads/PrusaSlicer-2.3.0-beta3+linux-x64-202012121815.tar.bz2

# invoking the binary by providing the path to it starts up the application fine
PrusaSlicer-2.3.0-beta3+linux-x64-202012121815/bin/prusa-slicer

.. However, when invoked from the environment $PATH variable, it crashes

# Crashes
export PATH=`pwd`/PrusaSlicer-2.3.0-beta3+linux-x64-202012121815/bin/:$PATH

# Now invoking it just with prusa-slicer, the shell finds it in $PATH, but then binary crashes
prusa-slicer 
terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::canonical: No such file or directory: "/tmp/prusa-slicer"
Aborted

Note, how it attempts to assemble the path from the current directory + argv[0] and arrives at /tmp/prusa-slicer. Which is of course wrong.
hzeller added a commit to hzeller/PrusaSlicer that referenced this issue Dec 20, 2020
@hzeller
Fix determining the path to the binary.
e8c4109 
If the binary name is resolve from the shell $PATH
environment variable, this previously failed and crashed
with an exception.

This change does some more effort to attempt trying to
find the correct path in that case.

This fixes prusa3d#5542

Signed-off-by: Henner Zeller <h.zeller@acm.org>
@hzeller hzeller mentioned this issue Dec 20, 2020
Closed
@lukasmatena
Copy link
Collaborator

Thanks, I managed to reproduce it on Ubuntu 16.04. Related to #4973.

My attempt to fix it was

--- a/src/PrusaSlicer.cpp
+++ b/src/PrusaSlicer.cpp
@@ -28,6 +28,7 @@
 #include <boost/nowide/cenv.hpp>
 #include <boost/nowide/iostream.hpp>
 #include <boost/nowide/integration/filesystem.hpp>
+#include <boost/dll/runtime_symbol_info.hpp>
 
 #include "unix/fhs.hpp"  // Generated by CMake from ../platform/unix/fhs.hpp.in
 
@@ -598,7 +599,7 @@ bool CLI::setup(int argc, char **argv)
         }
     }
 
-    boost::filesystem::path path_to_binary = boost::filesystem::system_complete(argv[0]);
+    boost::filesystem::path path_to_binary = boost::dll::program_location();
 
     // Path from the Slic3r binary to its resources.
 #ifdef __APPLE__

And it works on my system. I peeked into boost source and it apparently does the same as you propose in #5543. At least on Linux (there is some OS-specific gymnastics for the other systems as well).

Anyone has some experience about how reliable this would be?

@hzeller
Copy link
Contributor Author

I confirm that this also works on my system. Given that this uses a boost-provided method that is dedicated for this task, I think this is the better solution @lukasmatena than my Linux-specific hack in #5543 .

@bubnikv bubnikv mentioned this issue Jan 12, 2021
Closed
bubnikv added a commit that referenced this issue Jan 13, 2021
@bubnikv
Fix of Invoking prusa-slicer from $PATH environment variable crashes #…
293f85b 
…5542

Also it likely fixes Crashes when started from symbolic link #5751
@bubnikv
Copy link
Collaborator

Fixed with 293f85b

@bubnikv bubnikv mentioned this issue Aug 6, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix determining the path to the binary. hzeller/PrusaSlicer
3 participants
@hzeller @bubnikv @lukasmatena