This page suggests calling meshobj.mlab_source.reset() to efficiently change the underlying geometry source data for a plotted mesh.

I've found that this crashes, as reported here ~5 years ago.

I've come up with a test case that seems to reliably reproduce the crash, which I'll attach. I'm using Python 2.7.14, mayavi 4.6.2.

I suspect what's going on is the following:

• The underlying vtkPolyData object is initialized with a points array of size N, and triangle data that has indices up to and including values of N-1.
• Later, MTriangularMeshSource.reset() is called with new data of size M, <<N.
• During the reset, the polydata.points trait is set first to the M-sized array, but leaves the existing N-referencing triangle data in place. Either the python polydata wrapper or the underlying C object then tries to rebuild some data structures, but ends up indexing into the new M-sized points array with values >= M <= N-1. Memory is accessed that shouldn't be, and it crashes.

Attached you'll find an example crash.zip, which has the following test cases (run as first argument).

• CRASH: crashes as described, by initializing the mesh with hi-index triangles, and then reset() to lo-index triangles.
• CRASHMEDIUM: same as crash, but the "hi index" triangles are greatly reduced to just [0,5], rather than thousands.
• AVOID: uses the medlo as initial input. the same large numbers of points that CRASH uses, but triangles are reduced to only the index range [0,2]. Avoids the crash later.
• SKIP: just skip the call to mlab_source.reset() altogether.
• WORKAROUND: Use an alternate_reset() function that switches the order in which the points and triangles traits are set if it's reducing points in size. Seems to avoid the crash, but I'm not sure it's precisely correct (does anything need to be rebuilt if you set these traits in this order)?

Please review & verify that you see the same crashes, and then weigh in on the workaround, and if there's additional stuff that needs to be reset (I'm unfamiliar with vtk).

I haven't looked at the other mlab sources, but they may show similar problems if they use PolyData internally.