Please have a look at my "revert" branch on gitlab: https://gitlab.com/mose/gnuastro/commits/revert  In particular the commit https://gitlab.com/mose/gnuastro/commit/36f3378db9a19ba50167e75cf88df8cb06239f5a

I verified that compilation runs smoothly, all tests are passed and the command reported here and in bug #46241 doesn't cause the program to crash.

I guess that the workaround introduced with

  * 2beb197 (2015-10-18)  Call manually the cropping functions in imgcrop

can now be reverted.

A possible way to workaround this bug could be not to define modefunction pointer and call the functions "by hand", i.e. for the single thread case something like

      if(p->imgmode)
        imgmodecrop(&crp[0]);
      else if(p->wcsmode)
        wcsmodecrop(&crp[0]);

but I didn't test this solution thoroughly.  I agree it's less elegant than the current implementation, but at least should avoid the crash.

The problem is only on the output file name (sorry for forgetting to mention it). Running this command from the top Gnuastro directory will reproduce the problem:

./src/imgcrop/astimgcrop --xc=50 --yc=50 ./tests/1_imgcat.fits --output=qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM1234567890.fits

When compiled with optimization flags, if the file names are longer than 50 to 50 characters, then for some reason, ImageCrop gives a segmentation fault on p->cp.dontdelete!

p->cp.dontdelete can be read and changed (accessed) within the cropping function (tested here in the image mode), but as soon as control comes to the main imgcrop function (prior to going into the printlog function) it is not accessible any more and trying to read or write to it causes a segmentation fault.