slic3r / Slic3r

Open Source toolpath generator for 3D printers
https://slic3r.org/
GNU Affero General Public License v3.0
3.34k stars 1.3k forks source link

Segfault when attemting to "cut" models. #3953

Open NateTG opened 7 years ago

NateTG commented 7 years ago

Version

1.2.9-1006-gb52de343

(1.3.0-dev in the UI)

Operating system type + version

Debian GNU/Linux 9.0

Behavior

Loading an stl file into the slicer and pushing the cut button causes seg fault. It might have to do with the size of the mesh. The helix-simplified will segfault mid-cut - less often when "show preview" is disabled. (Zipped samples attached.)

helix-simplified.zip tlb.zip

lordofhyphens commented 7 years ago
edge 2 of facet 2536 doesn't match edge 1 of facet 2537
facet (2536)/ first facet
  vertex 0/2536  4.85633999E-001  1.31861997E+000  3.95191193E+000
  vertex 1/2536  7.91876018E-001  1.18335998E+000  3.78948402E+000
  vertex 2/2536  4.85810995E-001  1.31896603E+000  3.95191193E+000
facet (2537)/ second facet
  vertex 0/2537  7.92492986E-001  1.18448997E+000  3.78939390E+000
  vertex 1/2537  4.85810995E-001  1.31896603E+000  3.95191193E+000
  vertex 2/2537  4.85633999E-001  1.31861997E+000  3.95191193E+000
edge 1 of facet 2537 doesn't match edge 2 of facet 2536
facet (2537)/ first facet
  vertex 0/2537  7.92492986E-001  1.18448997E+000  3.78939390E+000
  vertex 1/2537  4.85810995E-001  1.31896603E+000  3.95191193E+000
  vertex 2/2537  4.85633999E-001  1.31861997E+000  3.95191193E+000
facet (2536)/ second facet
  vertex 0/2536  4.85633999E-001  1.31861997E+000  3.95191193E+000
  vertex 1/2536  7.91876018E-001  1.18335998E+000  3.78948402E+000
  vertex 2/2536  4.85810995E-001  1.31896603E+000  3.95191193E+000

Noticed these messages from Slic3r. Model does read as manifold and I can get it to crash on copies of the model as passed through netfabb's online system.

in stl_remove_facet: neighbor = 18049 numfacets = 33734 this is wrong
removing a facet in stl_remove_degenerate
Back to the first facet filling holes: probably a mobius part.
Try using a smaller tolerance or don't do a nearby check
edge 1 of facet 59663 doesn't match edge 1 of facet 58515
facet (59663)/ first facet
  vertex 0/59663 -1.15799997E-003 -1.40771997E+000  6.80000019E+000
  vertex 1/59663 -1.27799995E-003 -1.40775502E+000  6.80000019E+000
  vertex 2/59663 -1.20299996E-003 -1.40732801E+000  6.80000019E+000
facet (58515)/ second facet
  vertex 0/58515 -5.70999868E-002 -1.41130006E+000  6.76600075E+000
  vertex 1/58515 -1.27799995E-003 -1.40775502E+000  6.80000019E+000
  vertex 2/58515 -1.20299996E-003 -1.40732801E+000  6.80000019E+000
edge 2 of facet 59973 doesn't match edge 6 of facet 59969
facet (59973)/ first facet
  vertex 0/59973 -3.64940017E-002 -1.40397596E+000  6.80000019E+000
  vertex 1/59973 -3.63250002E-002 -1.40393496E+000  6.80000019E+000
  vertex 2/59973 -3.62880006E-002 -1.40392399E+000  6.80000019E+000
facet (59969)/ second facet
  vertex 0/59969 -3.64940017E-002 -1.40397596E+000  6.80000019E+000
  vertex 1/59969 -3.62880006E-002 -1.40392399E+000  6.80000019E+000
  vertex 2/59969 -3.47770005E-002 -1.40423906E+000  6.80000019E+000
removing a facet in stl_remove_degenerate
edge 2 of facet 5862 doesn't match edge 4 of facet 6152
facet (5862)/ first facet
  vertex 0/5862  1.93727002E-001 -1.41031504E+000  6.59999990E+000
  vertex 1/5862  1.70900032E-001 -1.41230011E+000  6.61960030E+000
  vertex 2/5862  1.93727002E-001 -1.41017795E+000  6.59999990E+000
facet (6152)/ second facet
  vertex 0/6152  1.93771005E-001 -1.41059399E+000  6.59999990E+000
  vertex 1/6152  1.93727002E-001 -1.41031504E+000  6.59999990E+000
  vertex 2/6152  1.93727002E-001 -1.41017795E+000  6.59999990E+000

More log items; I believe these are all from the helixical shape.

The other design crashes immediately on opening the cut dialog, due to the rendering of the preview; the default cut position on that model happens to be in a "bad" spot.

The problem is somewhere in the actual cut code, I'm suspecting the repair calls myself right now.

bubnikv commented 7 years ago

The triangulation library is certainly not numerically stable and it needs to be replaced with something else. Until that all bets are off.

On Sun, May 14, 2017 at 9:24 PM, Joseph Lenox notifications@github.com wrote:

edge 2 of facet 2536 doesn't match edge 1 of facet 2537 facet (2536)/ first facet vertex 0/2536 4.85633999E-001 1.31861997E+000 3.95191193E+000 vertex 1/2536 7.91876018E-001 1.18335998E+000 3.78948402E+000 vertex 2/2536 4.85810995E-001 1.31896603E+000 3.95191193E+000 facet (2537)/ second facet vertex 0/2537 7.92492986E-001 1.18448997E+000 3.78939390E+000 vertex 1/2537 4.85810995E-001 1.31896603E+000 3.95191193E+000 vertex 2/2537 4.85633999E-001 1.31861997E+000 3.95191193E+000 edge 1 of facet 2537 doesn't match edge 2 of facet 2536 facet (2537)/ first facet vertex 0/2537 7.92492986E-001 1.18448997E+000 3.78939390E+000 vertex 1/2537 4.85810995E-001 1.31896603E+000 3.95191193E+000 vertex 2/2537 4.85633999E-001 1.31861997E+000 3.95191193E+000 facet (2536)/ second facet vertex 0/2536 4.85633999E-001 1.31861997E+000 3.95191193E+000 vertex 1/2536 7.91876018E-001 1.18335998E+000 3.78948402E+000 vertex 2/2536 4.85810995E-001 1.31896603E+000 3.95191193E+000

Noticed these messages from Slic3r. Model does read as manifold and I can get it to crash on copies of the model as passed through netfabb's online system.

in stl_remove_facet: neighbor = 18049 numfacets = 33734 this is wrong removing a facet in stl_remove_degenerate Back to the first facet filling holes: probably a mobius part. Try using a smaller tolerance or don't do a nearby check edge 1 of facet 59663 doesn't match edge 1 of facet 58515 facet (59663)/ first facet vertex 0/59663 -1.15799997E-003 -1.40771997E+000 6.80000019E+000 vertex 1/59663 -1.27799995E-003 -1.40775502E+000 6.80000019E+000 vertex 2/59663 -1.20299996E-003 -1.40732801E+000 6.80000019E+000 facet (58515)/ second facet vertex 0/58515 -5.70999868E-002 -1.41130006E+000 6.76600075E+000 vertex 1/58515 -1.27799995E-003 -1.40775502E+000 6.80000019E+000 vertex 2/58515 -1.20299996E-003 -1.40732801E+000 6.80000019E+000 edge 2 of facet 59973 doesn't match edge 6 of facet 59969 facet (59973)/ first facet vertex 0/59973 -3.64940017E-002 -1.40397596E+000 6.80000019E+000 vertex 1/59973 -3.63250002E-002 -1.40393496E+000 6.80000019E+000 vertex 2/59973 -3.62880006E-002 -1.40392399E+000 6.80000019E+000 facet (59969)/ second facet vertex 0/59969 -3.64940017E-002 -1.40397596E+000 6.80000019E+000 vertex 1/59969 -3.62880006E-002 -1.40392399E+000 6.80000019E+000 vertex 2/59969 -3.47770005E-002 -1.40423906E+000 6.80000019E+000 removing a facet in stl_remove_degenerate edge 2 of facet 5862 doesn't match edge 4 of facet 6152 facet (5862)/ first facet vertex 0/5862 1.93727002E-001 -1.41031504E+000 6.59999990E+000 vertex 1/5862 1.70900032E-001 -1.41230011E+000 6.61960030E+000 vertex 2/5862 1.93727002E-001 -1.41017795E+000 6.59999990E+000 facet (6152)/ second facet vertex 0/6152 1.93771005E-001 -1.41059399E+000 6.59999990E+000 vertex 1/6152 1.93727002E-001 -1.41031504E+000 6.59999990E+000 vertex 2/6152 1.93727002E-001 -1.41017795E+000 6.59999990E+000

More log items; I believe these are all from the helixical shape.

The other design crashes immediately on opening the cut dialog, due to the rendering of the preview; the default cut position on that model happens to be in a "bad" spot.

The problem is somewhere in the actual cut code, I'm suspecting the repair calls myself right now.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3953#issuecomment-301333944, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I42HtE45PntEhVtupItru2NIKoG0ks5r51UDgaJpZM4NaLv0 .

lordofhyphens commented 7 years ago

The tlb model did not segfault when cut in X or Y.

lordofhyphens commented 7 years ago

The segfault is occurring in poly2tri. Currently unsure as to why.

bubnikv commented 7 years ago

The segfault is occurring in poly2tri. Currently unsure as to why.

Because poly2tri is not numerically stable, therefore the decision it makes topologically do not correspond with the geometry. And if you do that, all bets are off and the application will crash. Depending on the data, it may happen rarely or more often.

One could either ditch poly2tri completely or try to fix it.

I did not have time for that, but I would just replace poly2tri with a time proven triangle.

https://www.cs.cmu.edu/~quake/triangle.html

On Sun, May 14, 2017 at 10:42 PM, Joseph Lenox notifications@github.com wrote:

The segfault is occurring in poly2tri. Currently unsure as to why.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3953#issuecomment-301338549, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I2f-Db32OwYVDDougSvtkSleYkpZks5r52clgaJpZM4NaLv0 .

lordofhyphens commented 7 years ago

Someone else found that, at least for their usage, sanitizing the inputs with clipper before getting to poly2tri worked for them, and broke out the work into a library. I'd need to confirm that it would work in these situations.

http://stackoverflow.com/questions/16042940/robust-fast-complex-polygon-with-holes-triangulation-c-c-library-with-permi

@bubnikv triangle has problems with license compatibility, it's only permitted under its default license for noncommercial use.

https://softwareengineering.stackexchange.com/questions/214904/is-free-for-non-commercial-use-license-compatible-with-gnu-gplv3-license

NateTG commented 7 years ago

Numerical stability totally makes sense. Those are models with tiny triangles, and it crashed less after I simplified the models.

bubnikv commented 7 years ago

Someone else found that, at least for their usage, sanitizing the inputs with clipper before getting to poly2tri worked for them, and broke out the work into a library. I'd need to confirm that it would work in these situations.

http://stackoverflow.com/questions/16042940/robust- fast-complex-polygon-with-holes-triangulation-c-c-library-with-perm http://stackoverflow.com/questions/16042940/robust-fast-complex-polygon-with-holes-triangulation-c-c-library-with-permi i http://stackoverflow.com/questions/16042940/robust-fast-complex-polygon-with-holes-triangulation-c-c-library-with-permi

I saw that try. It lowers the amount of crashes to some extent, but it does not mitigate them.

@bubnikv https://github.com/bubnikv triangle has problems with license compatibility, it's only permitted under its default license for noncommercial use.

Long live FSF.

On Sun, May 14, 2017 at 11:09 PM, NateTG notifications@github.com wrote:

Numerical stability totally makes sense. Those are models with tiny triangles.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3953#issuecomment-301340169, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I4fLIAfLXOwkgRSHjpv2fM7U6NR1ks5r522cgaJpZM4NaLv0 .

lordofhyphens commented 7 years ago

There's polypartition as well.

Yeah, FOSS is much preferred. Could probably do a darkroom implementation of Triangle from their published papers if one had time.

alranel commented 7 years ago

I tried polypartition in the past (we even have it in the codebase) but it was worse.

gege2b commented 7 years ago

on my win10, cut dialog didn't even show up, it crash as soon as I click on the "cut" button in the toolbar

lordofhyphens commented 7 years ago

Yeah, I saw this behavior on Windows 10. It is because preview is on by default and that is a nasty model for the library we use.