Closed Jordatious closed 1 year ago
@Jordatious would you be able to provide a test cube for investigation please?
Perhaps @amirkazemim can (privately, assuming it's proprietary data)?
Perhaps @amirkazemim can (privately, assuming it's proprietary data)?
a cutout (noisy sky) would be just useful if it is proprietary
I created a random noise array, saved it once with a 32-bit beam table and another time with the astropy-default (I think 64-bit) beam table.
There are two fits files in the zipped attachment, noise_cube_32.fits can be opened with CARTA. However, CARTA v3.0.1 stalls on noise_cube_64.fits because of its beam table. Hope this helps.
I created a random noise array, saved it once with a 32-bit beam table and another time with the astropy-default (I think 64-bit) beam table.
There are two fits files in the zipped attachment, noise_cube_32.fits can be opened with CARTA. However, CARTA stalls on noise_cube_64.fits because of its beam table. Hope this helps.
Thank you for supplying the test images.
@amirkazemim @Jordatious could you try the v4-beta release to see if the issue persists? I tried but both test images can be loaded just fine.
Are you able to check v4-beta @amirkazemim?
Unfortunately, I am not able to check with v4-beta, @Jordatious.
I'm unable to load the 64-bit image provided above in either v3.0.1 or v4.0-beta.1 using the IDIA controller / server version. Whenever I try to open it, or click on it within the file browser, the backend disconnects.
ok. with macOS Apple silicon chip, it works with v4-beta. However, with macOS intel chip, it crashes.
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000d00000000 Exception Codes: 0x0000000000000001, 0x0000000d00000000 Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [76499]
VM Region Info: 0xd00000000 is not in any region. Bytes after previous region: 51227545601 Bytes before following region: 123089651085312 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL VM_ALLOCATE (reserved) 112998000-11299b000 [ 12K] r--/r-- SM=NUL ...(unallocated) ---> GAP OF 0x6ffef8540000 BYTES Stack Guard 70000aedb000-70000aedc000 [ 4K] ---/rwx SM=NUL
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libcasa_fits.6.dylib 0x10befd289 casacore::BinaryTableExtension::~BinaryTableExtension() + 313
1 libcasa_fits.6.dylib 0x10bf42809 casacore::BinaryTable::BinaryTable(casacore::FitsInput&, void ()(char const, casacore::FITSError::ErrorLevel), bool, bool) + 19465
2 libcasa_images.6.dylib 0x10c5fe509 casacore::ImageFITSConverter::readBeamsTable(casacore::ImageInfo&, casacore::String const&, casacore::DataType) + 2729
3 libcasa_images.6.dylib 0x10c5436aa casacore::FITSImage::setup() + 954
4 libcasa_images.6.dylib 0x10c543225 casacore::FITSImage::FITSImage(casacore::String const&, unsigned int, unsigned int) + 245
5 carta_backend 0x10a41ae81 carta::FitsLoader::OpenFile(std::1::basic_string<char, std::__1::char_traits
An issue was discovered by @amirkazemim where certain FITS cubes he was producing with a custom script would not open on the IDIA CARTA server. CARTA would crash trying to read the FITS file in file browser, after which it would display a "Connection lost" error. Amir reduced the issue to the beam table being written as 64-bit floats (the astropy default), whereas when 32-bit beam tables were used, they opened just fine in CARTA. The cubes which have beam tables as 64-bit floats open fine in ds9, and were converted fine to IDIA's HDF5 schema. Therefore it seems like this might be a CARTA bug.
I was hoping one of the CARTA developers could reproduce the issue, but if not, please let us know and we can produce a cube.