[gnuastro-devel] [bug #46241] ImgCrop segfaults with long output file names

[Vladimir Markelov]

Update of bug #46241 (project gnuastro):

                  Status:                    None => In Progress            
             Assigned to:                    None => vvm                    

    _______________________________________________________

Follow-up Comment #1:

I found a place where application memory corrupts and makes the application
fail. It may fix bug 45380 as well.

Branch
<https://github.com/VladimirMarkelov/gnuastro-vvm/tree/buffer-overflow-imgcrop>

Patch
<https://github.com/VladimirMarkelov/gnuastro-vvm/commit/67650523426ebc0bf6a8a17b52615b283fc8b529>

=== Why I fixed it that way ===
I see a few ways to fix the memory corruption at this point:
*1. Increase GAL_TIMING_VERB_MSG_LENGTH_V*
If we do this we have to change a few other constants
(GAL_TIMING_VERB_MSG_LENGTH_T, GAL_TIMING_VERB_MSG_LENGTHS_2_V etc). It can
results in a lot of code changes - easy way to break something. Moreover, we
cannot say what will be the maximum file name length, so we have to reserve
decent amount of memory(hundreds of bytes at least)

*2. Do not use GAL_TIMING_VERB_MSG_LENGTH_V for buffer size and choose bigger
number.*
Similar to item 1: we do not know for sure the maximum file name length. But
it does not require to change other variables.

*3. Do not use static char buffer for the msg and allocate memory
dynamically*
It is fine for any file name length. The only drawback: I see format string
uses '%-30', so if we use longer strings the output will look ugly because
formatting won't work.

*4. Truncate file name to 30 characters*
It works with any file name and it keeps log output nice-looking because
format string '%-30' works always here.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?46241>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/