[Paraview] Paraview crashes with netCDF

[Adam Dershowitz]

Thanks.

I actually just created a ticket also, a few minutes after you did:
https://gitlab.kitware.com/paraview/paraview/issues/17174

I’ll close mine since it is redundant with yours.


-- Adam


From: "Moreland, Kenneth" <kmorel at sandia.gov>
Date: Monday, February 13, 2017 at 4:01 PM
To: Dershowitz Adam <adershowitz at exponent.com>, "ParaView at paraview.org" <ParaView at paraview.org>
Subject: Re: [Paraview] Paraview crashes with netCDF

Adam,

Was able to replicate your problem. It looks like there are minor issues with both gdalwarp and ParaView that together are causing the crash.

The first problem is that gdalwarp is not writing the units attribute correctly when outputting the coordinates in feet. Instead, the units are set to an empty string. This seems wrong. The attribute should be set to “ft” or “feet”. When you use gdalwarp to write units of meters, it correctly writes this attribute as “m”. This is probably a bug, but it shouldn’t cause ParaView to crash.

So you probably already see where this is going. NetCDF attributes of empty strings are odd, and the ParaView reader probably has never encountered one before. Lo and behold in this case the reader tries to pull a pointer out of an empty std::string, and std::string throws an exception.

I’ve raised a bug for ParaView (https://gitlab.kitware.com/paraview/paraview/issues/17173<https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.kitware.com_paraview_paraview_issues_17173&d=DwMGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=u32SrVyuUNaoi48csYyFS2kh40P7XFwQINDUSttSej4&s=9gefX6ys8o9uDqRlJV0OmYf7KL3Dyq6bCpq_jGD9yTE&e=>) and will look into fixing this. I’ll leave it up to you whether you want to contact the GDAL developers about the issue with gdalwarp.

-Ken

From: ParaView [mailto:paraview-bounces at paraview.org] On Behalf Of Adam Dershowitz
Sent: Monday, February 13, 2017 9:20 AM
To: ParaView at paraview.org
Subject: [EXTERNAL] Re: [Paraview] Paraview crashes with netCDF

I found a bit more information.  When pareview crashes, here is part of the crash log:

Application Specific Information:
terminating with uncaught exception of type std::out_of_range: basic_string
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib                 0x00007fffcb43add6 __pthread_kill + 10
1   libsystem_pthread.dylib              0x00007fffcb526787 pthread_kill + 90
2   libsystem_c.dylib                           0x00007fffcb3a0420 abort + 129
3   libc++abi.dylib               0x00007fffc9efb85a abort_message + 266
4   libc++abi.dylib               0x00007fffc9f20c37 default_terminate_handler() + 243
5   libobjc.A.dylib                 0x00007fffcaa2af33 _objc_terminate() + 124
6   libc++abi.dylib               0x00007fffc9f1dd69 std::__terminate(void (*)()) + 8
7   libc++abi.dylib               0x00007fffc9f1d9f2 __cxa_rethrow + 99
8   QtCore                             0x000000010db17d2d QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 845
9   QtCore                             0x000000010db1ad97 QCoreApplication::exec() + 199
10  org.paraview.ParaView             0x000000010b083fd2 main + 386
11  libdyld.dylib                   0x00007fffcb30c255 start + 1

Any idea why that happens with one feet, but not meters in an otherwise identical file?

-- Adam


From: Dershowitz Adam <adershowitz at exponent.com<mailto:adershowitz at exponent.com>>
Date: Tuesday, February 7, 2017 at 11:58 AM
To: "ParaView at paraview.org<mailto:ParaView at paraview.org>" <ParaView at paraview.org<mailto:ParaView at paraview.org>>
Subject: Paraview crashes with netCDF

I have a geotiff file that I want to view in Paraview.  But, Paraview seems to not show the correct offset (0,0 instead of respected the offset).  The work around I have been trying is to warp it to the correct location using gdalwarp and to export it as a netCDF.  Then Paraview should be able to show it correctly.
But, I have run into a crash.
If I do this:
gdalwarp  -t_srs EPSG:3652 -of netCDF test.tiff test_ft.nc

then I try to open test.nc in Paraview immediately crashes.

While, instead if do this:

gdalwarp  -t_srs EPSG:3651 -of netCDF test.tiff test_m.nc

then it opens fine.  The difference between these two files is that EPSG 3652 uses feet (which is better for me, for this particular project) while 3651 uses meters.  Both appear to be valid NetCDF files.  I’ve tried both readers “CAM NetCDF (Unstructured)” and “NetCDF files generic and CF conventions” with the same results.

I’m running Paraview 5.2.0 64-bit on Mac OS 10.12.3.  But, I have seen identical results on an older Mac with a prior OS.  I had also tried an older version of Paraview with the same result.

Any ideas why this consistently crashes Paraview, or what to do about it?  Using netCDF was already a work around, and I willing to try others to view these files.  The offset and scale are important because I then need to put in other data that is in the correct location and units.

The files are too big for me to send to the mailing list, so I have not posted them.

Thanks,

-- Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20170213/3c2eff0f/attachment.html>