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.

Sign up for GitHub

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

prusa-gcodeviewer failes on Linux when used in AppImage and/or from File menu #4880

Closed
Area5142 opened this issue Oct 15, 2020 · 20 comments
Closed

prusa-gcodeviewer failes on Linux when used in AppImage and/or from File menu #4880

Area5142 opened this issue Oct 15, 2020 · 20 comments

Comments

@Area5142
Copy link

Version

PrusaSlicer-version_2.3.0-alpha0-1150-g58d57f9b7 and earlier versions

Operating system type + version

Linux Mint 19.3 x64

3D printer brand / version + firmware version (if known)

NA.

Behavior

Starting PrusaSlicer (PS) in gcode viewer mode fails when done from File->G-code preview... or when binary is contained in AppImage.

What is working:
Sym-linking the compiled binary prusa-slicer to prusa-gcodeviewer and executing on build server. This starts PS in gcode-view mode and gcode files can be loaded and viewed.

What is not working:

  1. Using the menu File->G-code preview... and opening gcode file. A splash screen is shown and dissapears again, PS is still running as nothing has happend. Loglevel=3 shows:
[2020-10-15 14:48:10.714408] [0x00007f4ab9fca5c0] [info]    Trying to spawn a new slicer "/home/.../src/PrusaSlicer/Build/src/prusa-gcodeviewer"

(prusa-gcodeviewer:118652): GLib-GObject-WARNING **: 14:48:10.832: invalid (NULL) pointer instance

(prusa-gcodeviewer:118652): GLib-GObject-CRITICAL **: 14:48:10.832: g_signal_handlers_block_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
...
(prusa-gcodeviewer:118652): GLib-GObject-CRITICAL **: 14:48:10.846: g_signal_handlers_unblock_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

  1. Starting PS with a symlink named prusa-gcodeviewer to AppImage with binary. PS starts in normal PS mode and ignores the symlink name.

  2. Trying to load/view gcode from menu File->G-code preview... when binary is contained in an AppImage has no effect, but the the loglevel=3 output tells that PS tries to spawn a new process:

[2020-10-15 15:04:54.077119] [0x00007fc868da75c0] [info] Trying to spawn a new slicer "/home/.../bin/AppImages/PrusaSlicer-version_2.3.0-alpha0-1150-g58d57f9b7.AppImage"

There is no official AppImage build instruction to follow, but my builds has the same structure as earlier PS AppImages, just with updated libraries and works great as Slicer.

Is this a new feature request?
No.

Project File (.3MF) where problem occurs

NA.
@bubnikv
Copy link
Collaborator

bubnikv commented Oct 15, 2020

I would say please wait for the first public alpha release, where the structure of the AppImage will reveal including the start scripts and symlinks. The alpha is to be released any day now, keep your fingers crossed.

@bubnikv bubnikv closed this as completed Oct 15, 2020
@Area5142
Copy link
Author

I will cross my finger and looks forward to see the changed structure of AppImage.

Even without the correct AppImage structure there is still a bug when the standalone prusa-slicer binary tries to execute the correctly named symlink prusa-gcodeviewer from menu File->G-code preview...
This call fails and is unrelated to any AppImage containment or structure.

I think this is still an issue and too soon to close.

@bubnikv
Copy link
Collaborator

bubnikv commented Oct 16, 2020 via email

@Area5142
Copy link
Author

To reproduce the error on Linux Mint 19.3:

  1. Execute binary prusa-slicer after build.
  2. Select File->G-code preview... and select a .gcode file.
  3. The PS splash screen is shown and then nothing happens.

It is like the spawn process succeeded and the symlink is executed, but terminates before showing the gcode. I have tried several different gcodes and the result is the same.

The symlink prusa-gcodeviewer pointing to prusa-slicer works and starts a gcode viewer. I can load and view gcodes from the viewers File->Open G-code... menu and if given on the command line too.

@bubnikv
Copy link
Collaborator

bubnikv commented Oct 16, 2020 via email

@Area5142
Copy link
Author

The difference I see is that the prusa-gcodeviewer symlink is executed from inside prusa-slicer binary (via menu) instead of from the commend line.
The prusa-gcodeviewer starts and shows the splash screen, but then for some reason terminates itself again.
The environment setup should be the same as it will be inherited from the spawning process (prusa-slicer).

My guess would be that the spawn process in the startup code finds a lock, locked ressource, invalid parameters or detects the parent process and decides to terminate. I get no usable output from setting --loglevel=4.
A more detailed log of how/when the symlink is executed would share some light on, what is happening.

As mentioned before, executing the prusa-gcodeviewer link directly works as intended.

@bubnikv
Copy link
Collaborator

bubnikv commented Oct 16, 2020 via email

@Area5142
Copy link
Author

I found this new setting following the change-log.

No single instance is not enabled. I can start multiple instances of prusa-slicer and on top of them start multiple instances of prusa-gcodeviewer.

@Area5142
Copy link
Author

Maybe I am closer to find the error.
When I replace the prusa-gcodeviewer with a bash script, it is possible to write out the environment and how the symlink was called.

Starting prusa-gcodeviewer in different ways on the command line reviled some interesting results.

Success:

  1. /home/joh/src/PrusaSlicer/Build/src/prusa-gcodeviewer ./gcode/Test.gcode
    (Full path to binary and relativ path to gcode file)

Fails:
2) /home/joh/src/PrusaSlicer/Build/src/prusa-gcodeviewer /home/joh/src/PrusaSlicer/Build/src/gcode/Test.gcode
(Full path to binary and gcode file)

  1. ./prusa-gcodeviewer /home/joh/src/PrusaSlicer/Build/src/gcode/Test.gcode
    (Relative path to binary and full path gcode file)

  2. ./prusa-gcodeviewer ./gcode/Test.gcode
    (Relative path to binary and gcode file)

The prusa-gcodeviewer only starts with succes when given full path to binary and relative path to gcode file.

When prusa-gcodeviewer is started from PS it is given full path to both binary and gcode and fails like case 2.

This is the failed code written to the console:

(prusa-gcodeviewer:3578): GLib-GObject-CRITICAL **: 17:16:46.552: g_signal_handlers_unblock_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Segmentation fault (core dumped)

The error may be located in start code of the gcode-viewer where the path to gcode is resolved. I could be a NULL pointer or other hard error that could give a segmentation fault - just my guess...

@bubnikv
Copy link
Collaborator

bubnikv commented Oct 16, 2020 via email

@Area5142
Copy link
Author

My test machine is a clean Linux Mint 19.3 x64 image added with only enough to compile the source. Compile and test directory is is located on main disk with no spaces/symlinks in any path or file names.

I will try gdb to get a call stack.

@Area5142
Copy link
Author

Here the gdb session with fault, frame info and bt (back trace of stack):

GDB_Stack_Dump.zip

@bubnikv
Copy link
Collaborator

bubnikv commented Oct 16, 2020 via email

@bubnikv
Copy link
Collaborator

bubnikv commented Oct 17, 2020

@lukasmatena notified me that he sees the G-code viewer sometimes opening below the terminal window or possibly PrusaSlicer window. I know there are issues with the order of OpenGL initialization on Linux, where we get OpenGL context initalized first at the first paint event. If the window is in the background, then we are possibly getting the paint event too late and accessing OpenGL crashes.

@Area5142
Copy link
Author

The gcode viewer only fails when started with a gcode file as parameter to the command. The splash screen is shown before it crashes.

Starting gcode viewer without gcode file as parameter works both as symlink and "prusa-slicer --gcodeviewer".

enricoturri1966 added a commit that referenced this issue Oct 17, 2020
@enricoturri1966
#4880 - Initialization of OpenGL data used by GCodeViewer done on the…
ce3fc31 
… first call of GCodeViewer::render()
@enricoturri1966
Copy link
Collaborator

@Area5142
Could you please test if ce3fc31 helps in solving this issue ?
PrusaSlicer-version_2.3.0-alpha0+1190-gce3fc31b4

@Area5142
Copy link
Author

Quick test of the new alpha1.

Open gcode file from menu File->G-code preview... in PS starts symlink to prusa-gcodeviewer and shows splash screen, shows small main windows and starts to load gcode. Then I get the following error popup:

Screenshot from 2020-10-17 19-05-51

If I start the symlink directly from command line with the same gcode file as parameter everything works.

@lukasmatena lukasmatena reopened this Oct 17, 2020
@Area5142 Area5142 mentioned this issue Oct 29, 2020
Closed
@bubnikv
Copy link
Collaborator

bubnikv commented Dec 5, 2020

I suppose this has been fixed and could be closed?

@Area5142
Copy link
Author

Area5142 commented Dec 5, 2020

Yes. Just tested with 2.3.0 beta 1 and it now works on Linux Mint 19.3 x64.

@bubnikv
Copy link
Collaborator

bubnikv commented Dec 5, 2020

Cool, thanks.

@bubnikv bubnikv closed this as completed Dec 5, 2020
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

No branches or pull requests
4 participants
@Area5142 @bubnikv @lukasmatena @enricoturri1966