GhostPDF - fix memory leak with colour spaces

If, while setting a colour space by name, we detect that the current
space is already the required space, then we short-circuit the setting
of the space.

But we were doing that after retrieving the object representing the
named colour space, and not counting down the object leading to a
memory leak.

Instead, we can check the space early and avoid creating the object
at all.

1 files changed, 4 insertions, 3 deletions

diff --git a/pdf/pdf_colour.c b/pdf/pdf_colour.c
index ccfdef962..e082e63ec 100644
--- a/pdf/pdf_colour.c
+++ b/pdf/pdf_colour.c
@@ -2359,14 +2359,15 @@ pdfi_create_colorspace_by_name(pdf_context *ctx, pdf_name *name,
         code = pdfi_create_JPX_space(ctx, "sgray", 1, ppcs);
     } else {
         pdf_obj *ref_space = NULL;
+
+        if (ppcs == NULL && check_same_current_space(ctx, name) == 1)
+            return 0;
+
         code = pdfi_find_resource(ctx, (unsigned char *)"ColorSpace", name, (pdf_dict *)stream_dict,
                                   page_dict, &ref_space);
         if (code < 0)
             return code;
 
-        if (ppcs == NULL && check_same_current_space(ctx, name) == 1) {
-            return 0;
-        }
 
         ctx->currentSpace = name;
         /* recursion */