Application fails when has to generate thumbnail for certain 3mf file because of a crash on exit about f3d HOT 22 CLOSED

I reproduce the issue. Thank you for reporting, I'm adding that to the next release project.

from f3d.

Running the same command than the thumbnailer manually works: f3d --output test.png --config=thumbnail --verbose=quiet --resolution 200,200 calibration-cube.3mf 🤔

from f3d.

The files are very small (~300kB), it's not related.

from f3d.

I found some interesting behavior. I have attached a zip file with files 01.3mf (no preview generated) and 02.3mf (preview generated).

Scenario 1, procedure:

• run the F3D application
• drag and drop the 01.3mf file into it
• 3d model will be displayed
• drag and drop the 02.3mf file into the same application
• nothing happens and after a few seconds the application crashes
  The event log contains a record of the application crashing.

And then this, the scenario (procedure with reversed file order):

• run the F3D application
• drag and drop the 02.3mf file into it
• the 3d model is displayed
• drag and drop the 01.3mf file into the same application
• 3d model will be displayed

files.zip

from f3d.

Sounds like the thumbnailers crash on exit then

from f3d.

Fixed in assimp master already, updating assimp on the next release should fix it:
assimp/assimp#5361

from f3d.

Great job guys, thanks for solving it out ;) looking forward to the next release ;)

from f3d.

So lets wait for their next minor release to close this: assimp/assimp#5489

from f3d.

--output test.png --config=thumbnail --verbose=quiet --resolution 200,200 calibration-cube.3mf

I also tried running the command to generate the test.png and it generated the image without any problems for me as well. Interesting. Maybe the problem is not in generating the image but in saving it? Isn't it possible that the thumbnail cache update is locked at that moment? Or some similar problem?

from f3d.

I tried to create a new directory in which I put only one file, the 3mf one. I wanted to try if the preview would be created if more images were not cached, but still the preview was not created.

from f3d.

The file in the testing folder (cube_gears.zip) is working fine so it's not related to the 3MF reader itself.

from f3d.

I can confirm your 3mf file got the correct preview immediately after extracting it from the archive.

My files are created by saving from the slicer. There will probably be a lot of other metadata in the file besides the model(s) that the slicer puts in.

from f3d.

As soon as I open the 3mf in slicer and save as another file, it shows that the saved file is larger and no preview is created.

The thumbnail will not be created.

Here is zipped resaved file:
cube_gears-slicer-project.zip

from f3d.

Big files are skipped by the thumbnailers, but you can change that in the config. How big are the files ?

from f3d.

Some files are quite large, but most are small, under about 500KB.

from f3d.

Sounds like the thumbnailers crash on exit then

It almost looks like a memory/resource release crash.

from f3d.

Now I remember I had crashes on exit for some 3MF files. I'm pretty sure this is an Assimp issue, probably related to this one: assimp/assimp#5328

from f3d.

Indeed:

 ./bin/f3d ~/data/tmp/calibration-cube.3mf --output=a.png
free(): invalid size
Aborted (core dumped)

from f3d.

Confirmed caused by assimp:

(gdb) bt
#0  0x00007ffff74b9e89 in free () from /usr/lib/libc.so.6
#1  0x00007ffff538ff09 in aiScene::~aiScene() () from /usr/lib/libassimp.so.5
#2  0x00007ffff5372fc7 in Assimp::Importer::~Importer() () from /usr/lib/libassimp.so.5
#3  0x00007ffff7d0f0a2 in vtkF3DAssimpImporter::vtkInternals::~vtkInternals (this=0x555557471350, __in_chrg=<optimized out>)
    at /home/glow/dev/f3d/f3d/src/plugins/assimp/module/vtkF3DAssimpImporter.cxx:43
#4  0x00007ffff7d0f0c8 in std::default_delete<vtkF3DAssimpImporter::vtkInternals>::operator() (this=0x555557282eb0, __ptr=0x555557471350) at /usr/include/c++/13.2.1/bits/unique_ptr.h:99
#5  0x00007ffff7d0c832 in std::unique_ptr<vtkF3DAssimpImporter::vtkInternals, std::default_delete<vtkF3DAssimpImporter::vtkInternals> >::~unique_ptr (this=0x555557282eb0, 
    __in_chrg=<optimized out>) at /usr/include/c++/13.2.1/bits/unique_ptr.h:404
#6  0x00007ffff7d01046 in vtkF3DAssimpImporter::~vtkF3DAssimpImporter (this=0x555557282e20, __in_chrg=<optimized out>)
    at /home/glow/dev/f3d/f3d/src/plugins/assimp/module/vtkF3DAssimpImporter.cxx:891
#7  0x00007ffff7d0107e in vtkF3DAssimpImporter::~vtkF3DAssimpImporter (this=0x555557282e20, __in_chrg=<optimized out>)
    at /home/glow/dev/f3d/f3d/src/plugins/assimp/module/vtkF3DAssimpImporter.cxx:891

from f3d.

So lets wait for their next minor release to close this: assimp/assimp#5489

They just released 5.4.0 last night.

from f3d.

Hi @Aapenootjes @ByPS128

So we just updated assimp in our build system here: f3d-app/f3d-superbuild#167

So you should be able to use our binary nightly release and it should work out of the box!

https://github.com/f3d-app/f3d/releases/tag/nightly

from f3d.

Hi @Aapenootjes @ByPS128

Hi,
I tried tonight's build and it's a blast. all the files that didn't generate previews are now generating and I think it's even faster.
Great work, thanks a lot.

I noticed that you can also do gcode ;)

from f3d.