# isoVolume crash
**URL:** https://discourse.paraview.org/t/isovolume-crash/2306
**Category:** ParaView Support
**Created:** [July 26, 2019, 2:57pm UTC](https://discourse.paraview.org/t/isovolume-crash/2306 "2019-07-26T14:57:57Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@ashirini](https://discourse.paraview.org/u/ashirini)
#### Post date: [July 26, 2019, 2:57pm UTC](https://discourse.paraview.org/t/isovolume-crash/2306/1 "2019-07-26T14:57:57Z")
Hi, I am trying to create isovolume from a 3D tiff stack. It crashes with this error message:
terminate called after throwing an instance of ‘std::bad\_array\_new\_length’
what(): std::bad\_array\_new\_length
Aborted (core dumped)
We tried Paraview 5.7 and 5.6 (linux and windows) with no luck. Any idea what the issue is?
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [August 5, 2019, 5:02pm UTC](https://discourse.paraview.org/t/isovolume-crash/2306/2 "2019-08-05T17:02:14Z")
Sounds like an overflow issue. However, iso-volume may not be the most memory (or computation) efficient here since it will generate an unstructured grid for the full extracted volume. If you’re just interested in the low-iso-value high-iso-value surfaces, contour filter may be the better option.
Another option is to run with a parallel pvserver, so that the data gets splits into multiple chucks and thus avoid the overflow.
I am going to try to see if I can determine where the overflow is happening locally.
---
### Author:  [@ashirini](https://discourse.paraview.org/u/ashirini)
#### Post date: [August 8, 2019, 1:30pm UTC](https://discourse.paraview.org/t/isovolume-crash/2306/3 "2019-08-08T13:30:17Z")
Hi Utkarsh,
pvserver also crashed. I ran pvserver on a server with 1.5TB ram and used a local paraview to create the isovolume.
mpirun -np 40 ./pvserver
terminate called after throwing an instance of ‘std::bad\_array\_new\_length’
what(): std::bad\_array\_new\_length
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [August 11, 2019, 12:53am UTC](https://discourse.paraview.org/t/isovolume-crash/2306/4 "2019-08-11T00:53:05Z")
while I am sure it’s overflow, I am not sure where it’s happening. Ideally a debug build in a debugger would help, but let’s try one more thing. Is it possible to try out with the latest 5.7-RC? 5.7 supports a `-l=` argument that will make it save a log file. Try runnning paraview as follows:
```auto
> paraview -l=,TRACE
```
this will trace all filter executions and hopefully narrow down the location of the exception.
---
### Author:  [@ashirini](https://discourse.paraview.org/u/ashirini)
#### Post date: [August 12, 2019, 12:53pm UTC](https://discourse.paraview.org/t/isovolume-crash/2306/5 "2019-08-12T12:53:19Z")
I tried v5.7, it crashed. I am attaching the log.
[isoVolumeTestLog.txt](https://discourse.paraview.org/uploads/short-url/w0dSAb9x0TExkeRCtTvGqsa0MjC.txt) (8.1 KB)
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [August 12, 2019, 1:58pm UTC](https://discourse.paraview.org/t/isovolume-crash/2306/6 "2019-08-12T13:58:44Z")
sweet, that helped! I see several `vtkIdType` to `int` conversions in `vtkTableBasedClipDataSet::ClipRectilinearGridData` which are causing the overflow. I’ll take a pass at cleaning it up for the next RC.
---
### Author:  [@ashirini](https://discourse.paraview.org/u/ashirini)
#### Post date: [August 29, 2019, 1:59pm UTC](https://discourse.paraview.org/t/isovolume-crash/2306/7 "2019-08-29T13:59:15Z")
Should I try 5.7.0-RC2?
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [August 29, 2019, 2:33pm UTC](https://discourse.paraview.org/t/isovolume-crash/2306/8 "2019-08-29T14:33:32Z")
the fix made it into `master` but not the 5.7 release. You’ll need to test with the nightly binaries (once they are available).