Bug #1121

makecpt -Tztable causes "double free" error

Added by Masakazu 5 months ago. Updated 3 months ago.

Status:ClosedStart date:2017-06-23
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Affected version:5.x-svn Platform:

Description

When I run "gmt makecpt -Tin.txt", it causes an error as shown in the attached file makecpt.error.txt . The version of GMT is 5.4.1.
The error message suggests double free() is attempted in gmtapi_garbage_collection() at the end of GMT_makecpt().

I looked at source:trunk/src/makecpt.c@17897, and found that:
  • If Ctrl->T.file is true, the pointer "z" points to T->table[0]->segment[0]->data[GMT_X] at source:trunk/src/makecpt.c@17897#L394
  • Otherwise, "z" is allocated by gmt_M_memory() in makecpt.
  • After cpt is made, "z" is freed by gmt_M_free (GMT, z); at source:trunk/src/makecpt.c@17897#L473
  • At the end of makecpt, GMT tries to free all allocated memories including T->table[0]->segment[0]->data[GMT_X] with gmtapi_garbage collection(), causing the double free problem when Ctrl->T.file is true.

I think the following can fix the problem (it worked at least on my environment).

--- a/src/makecpt.c
+++ b/src/makecpt.c
@@ -470,7 +470,7 @@ int GMT_makecpt (void *V_API, int mode, void *args) {
                Pout = gmt_sample_cpt (GMT, Pin, z, nz, Ctrl->Z.active, Ctrl->I.mode & GMT_CPT_C_REVERSE, Ctrl->Q.mode, Ctrl->W.active);
        }

-       gmt_M_free (GMT, z);    /* It may also have been allocated inside gmtlib_log_array() */
+       if (!Ctrl->T.file) gmt_M_free (GMT, z); /* It may also have been allocated inside gmtlib_log_array() */

        if (Ctrl->A.active) gmt_cpt_transparency (GMT, Pout, Ctrl->A.value, Ctrl->A.mode);      /* Set transparency */

I would appreciate if you could examine it.

makecpt.error.txt Magnifier (1.31 KB) Masakazu, 2017-06-23 23:27

Associated revisions

Revision 18446
Added by Joaquim 5 months ago

Fix issue #1121

Revision 18447
Added by Joaquim 5 months ago

Merged revision(s) 18446 from trunk:
Fix issue #1121
........

History

#1 Updated by Joaquim 5 months ago

  • Status changed from New to Resolved

Thanks, fixed in r18447

#2 Updated by Paul 3 months ago

  • Status changed from Resolved to Closed

Closed as fixed.

Also available in: Atom PDF