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

Segfault and lesser issues with autoreload #43

Open
egassemcinatas opened this issue Apr 2, 2019 · 5 comments
Open

Segfault and lesser issues with autoreload #43

egassemcinatas opened this issue Apr 2, 2019 · 5 comments
Labels

Comments

@egassemcinatas
Copy link

I am using fstl to display designs for 3D printing that are frequently modified and regenerated. The default-enabled autoreload feature has some drawbacks in that use case.

First, fstl frequently crashes while the .stl is being regenerated. This is because in Loader::read_stl_ascii(), the size of the vector returned by split() is not checked before using the elements. When a vertex row has not yet been completely written, fstl crashes.

Additionally it would be really neat if fstl either waited before autoreloading until the file size does not change any more, or if it reloaded again without an error pop-up in that case. Otherwise I have had to click away several message dialogs from the same reload.

Finally the focus stealing on autoreload is a pain when one does not want to switch to fstl despite regenerating the .stl.

@DeveloperPaul123
Copy link
Member

DeveloperPaul123 commented Apr 2, 2019

Looks like this might be related to #37 as far as .stl reloading goes. Overall, seems like you outlined 3 distinct issues:

  1. fstl crashes when reloading (or trying) a *.stl file that is actively being re-written.
  2. fstl attempts to reload a file immediately upon any change to the file resulting in multiple error pop-ups that must be cleared.
  3. fstl steals focus after reloading a file successfully.

For item 3, just curious but are you using fstl in an environment that has multiple monitors? Or is it a single monitor setup?

@egassemcinatas
Copy link
Author

egassemcinatas commented Apr 2, 2019 via email

@DeveloperPaul123
Copy link
Member

Ok thanks for the details, I may have some time this week to look into making some improvements to fstl.

@DanielJoyce
Copy link

Well, how does fstl know the file is complete.

What should happen is the program generating the file should write it to a temp file, then rename it to the file fstl is trying to reload. Renames are atomic. So something like "mv -f tempfile.stl file-fstl-is-viewing.stl"

@Wren6991
Copy link

  1. fstl attempts to reload a file immediately upon any change to the file resulting in multiple error pop-ups that must be cleared.

Seems like this one is mostly solved by #107. In case anyone else like me is still hitting raciness with the 100 ms threshold, it can be worked around by the classic "write to a temp file, move to the final file", like here in the export from my CadQuery script:

# Workaround issue with fstl reading the file mid-rewrite
def safe_write_stl(obj, fname):
    cq.exporters.export(obj, fname + ".tmp", exportType="STL")
    os.replace(fname + ".tmp", fname)

I guess CadQuery just has some >100 ms pauses to think whilst it's writing out a large STL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants