#473 remove_chan crashes thinking there are zero subints and changes channel number before loading data

[Mike Keith]

This was discovered whilst using the python interface, but I don't think it's specific to the python interface explicittly. This refers to using PSRFITS data, not sure if it affects other data.

The bug is that if you call remove_chans right after loading an archive, i.e.

ar = psrchive.Archive_load("test.ar")
ar.remove_chans(0,4)

psrchive will crash because it thinks there is a mismatch between the number of channels reported in the subint table and the number of channels in the Archive object. The crash occurs in ProfileColumn, but the bug really seems to be that remove_chans thinks there are zero subints in the file, and hence it changes the number of channels in the archive without actually deleting any channels from the subints.

remove_chan uses expert()->get_size() to determine the number of subints. My guess is that this tells the size of the subint array, which should be the number of subintegrations currently loaded, but if the file has only just been opened and the integrations have never been loaded then this is still zero.

I guess the fix is that remove_chans needs to check that the integrations have actually been loaded at least once somehow - but that has got beyond my ability to work out.

[Willem van Straten]

Have you tried replacing expert()->get_size() with get_nsubint()?

I can't figure out why the former would be necessary, but I guess that it must have been.

[Mike Keith]

I haven't tried it, but I guess I could - maybe I will have a look tomorrow. But yeah - my worry is that it will introduce some other bug...

[Paul Demorest]

Hi guys, looks like I wrote that code originally. I agree using the "expert" interface seems like an odd choice unless it was necessary for some reason. But it's been way too long to remember what that was. I think someone will just have to make the change and see what happens.

[Mike Keith]

I have made the committed the change in d2c905bef6e72c40be00d84a3f9e630f371b33d2. It fixes the bug in the python code, and nothing amazingly bad seemes to have happened...