Interesting - this doesn't happen on my build. Maybe try deleting Slicer-superbuild/VTK* and rebuilding? Does it happen with a nightly build?

Can't reproduce with nightly. I guess I'll try deleting VTK later and let it build overnight.

By the way, there is a significant lag when moving the cursor in paint mode, even in SlicerPreview release build. The circle freezes and doesn't move again until I stop moving the mouse. I realize Editor isn't really maintained going forward, but the performance is much worse than 4.8.1 so I'm curious about the root cause.

• in 4.8.1 the Editor paint interaction is about the same responsiveness as Segment Editor paint (except for brief slight hiccups)
• in SlicerPreview, Segment Editor paint doesn't seem noticeably worse than in 4.8.1

Can't reproduce in updated local release build. So I guess it may be specific to debug build.
Looks like the stack is being corrupted in between vtkImageStack::Stash and the call to
zlib_compress2. See frame 4 with garbage source/target and sourceLen=140200226884976.

<pre>
(lldb)
frame 0000006: 0x000000014daf1f61 libvtkSlicerEditorLibModuleLogic.dylibvtkImageStash::Stash(this=0x00007f82e8b88d70) at vtkImageStash.cxx:107 104 vtkIdType scalarSize = size * numPrims; 105 106 unsigned char *p = static_cast<unsigned char *>(scalars->WriteVoidPointer(0, numPrims)); -> 107 this->GetCompressor()->SetCompressionLevel(this->GetCompressionLevel()); 108 vtkUnsignedCharArray* compressedBuffer=this->GetCompressor()->Compress(p, scalarSize); // returns a new buffer that has to be deleted 109 // The compressor allocates space that has the size of an uncompressed volume 110 // and even if it uses less memory the buffer size is not reduced. (lldb) down frame 0000005: 0x0000000121e136e7 libvtkIO-9.0.1.dylibvtkZLibDataCompressor::CompressBuffer(unsigned char const, unsigned long, unsigned char, unsigned long) + 119
libvtkIO-9.0.1.dylibvtkZLibDataCompressor::CompressBuffer: 0x121e136e7 <+119>: cmpl $0x0, %eax 0x121e136ea <+122>: je 0x121e13976 ; <+774> 0x121e136f0 <+128>: movq -0xa0(%rbp), %rax 0x121e136f7 <+135>: movq %rax, -0x58(%rbp) (lldb) frame 0000004: 0x00000001226882f6 libvtkIO-9.0.1.dylibslicer_zlib_compress2(dest="UH\x89?H??0", destLen=0x0000700008c6fc78, source="", sourceLen=140200226884976, level=-1) at compress.c:49
46 err = deflateInit(&stream, level);
47 if (err != Z_OK) return err;
48
-> 49 err = deflate(&stream, Z_FINISH);
50 if (err != Z_STREAM_END) {
51 deflateEnd(&stream);
52 return err == Z_OK ? Z_BUF_ERROR : err;
(lldb)
</pre>

I haven't been able to reproduce this with either my own build or with (yesterday's) nightly build.

Also at least on my machine the paint brush performance seems completely normal for both my local build and the nightly. (Window/Level and slice scrolling do have odd delays for me with Qt5, but none of the Editor or Segment Editor effects seem to have problems.

To confirm Isaiah, you consistently get the crash with a Qt5 debug build, right? I'm trying a rebuild of that from scratch.

This code has been in Slicer for a long time, but maybe something is triggered by the updated VTK or use of zlib.

To confirm Isaiah, you consistently get the crash with a Qt5 debug build, right?

Yes.

I didn't try deleting the VTK build yet. Will let you know if that helps.

My mac qt5 debug build (just built from scratch) doesn't crash when I paint. Hopefully the same will work for you.

Regarding the performance issue, I do notice that the circle lags a bit in debug build (but not the recent nightly download) but there isn't a lag while I've got the button down to paint.

The nightly mac build from today works and I couldn't replicate the crash there either.

But today I did see the same performance issue with the paint brush circle cursor (not during actual painting).

I deleted and rebuilt VTK in my debug build last night, and now can't reproduce it.