Bug 95227

Summary: [Patch] Cairo potentially spams stdout in certain places
Product: cairo Reporter: Ed Schouten <ed>
Component: generalAssignee: Andrea Canciani <ranma42>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: medium CC: darxus
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Patch to remove use of stdout

Description Ed Schouten 2016-05-01 12:04:31 UTC
Created attachment 123386 [details]
Patch to remove use of stdout

Hi there,

While porting Cairo over to CloudABI (https://nuxi.nl/), I noticed that there are some places in the code where the library writes to stdout, even though it should have used the provided file handle. In one case there is also a debug printf left.
Comment 1 Darxus 2016-08-18 20:52:13 UTC
Can you provide examples?
Comment 2 Ed Schouten 2016-08-19 17:33:31 UTC
(In reply to Darxus from comment #1)
> Can you provide examples?

I'm not sure I follow this. What kind of examples do you need?

I've merely observed that there are some pieces of code that do something that you don't expect. Functions that take a file handle, but write their output to stdout, instead of making use of the provided file handle.
Comment 3 Darxus 2016-08-19 17:46:04 UTC
Filenames and line numbers that are doing this?

How to reproduce it?
Comment 4 Andrea Canciani 2016-08-30 20:18:03 UTC
(In reply to Darxus from comment #3)
> Filenames and line numbers that are doing this?

You can find those in the diff file:

src/cairo-debug.c:265
src/cairo-pattern.c:4610,4617
src/cairo-surface-observer.c:1222

> 
> How to reproduce it?

I did not check throughly, but I am pretty confident that the issue in the first file would only be visible when compiling cairo with TRACE-ing enabled (manually, in src/cairoint.h), that is unusual and only meant for debugging.

The bugs in src/cairo-pattern.c would not be visible without some significant changes, as all of the _cairo_debug_print_*pattern() functions are currently dead code. Again, they are meant as an aid when debugging cairo itself and are not (or at least should not be) exposed through the public API.

The last one looks like a genuine bug that can easily be triggered:

#include <cairo.h>

int
main (int argc, char *argv[])
{
    cairo_surface_t *image = cairo_image_surface_create (CAIRO_FORMAT_ARGB32, 32, 32);
    cairo_surface_t *surface = cairo_surface_create_observer (image, CAIRO_SURFACE_OBSERVER_NORMAL);

    cairo_surface_mark_dirty (surface);
    
    cairo_surface_destroy (surface);
    cairo_surface_destroy (image);

    return 0;
}

All of the changes look good to me (the first two in order to improve debugging, the last one as an actual bug fix). Only nit is I would also remove one of the two consecutive blank lines in the change for cairo-surface-observer.c ;)

If nobody raises concerns about the patch, I will merge it in the weekend.
Comment 5 Andrea Canciani 2016-09-04 09:07:24 UTC
Fixed in

commit a69e5af9cd62d1e8d9f503a9d74338a49e31f9cd
Author: Ed Schouten <ed@nuxi.nl>
Date:   Sun Sep 4 08:41:27 2016 +0200

    Write debugging information to the debugging file
    
    Some debugging functions wrote to stdout, which is inconsistent with
    the other debugging functions of the same groups.
    
    Instead they should write to the debugging file that they are given as
    input.
    
    Reviewed-by: Andrea Canciani <ranma42@gmail.com>
    
    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=95227

commit efc40a94939a75c78474862638647bd5363d08cf
Author: Ed Schouten <ed@nuxi.nl>
Date:   Sun Sep 4 08:34:49 2016 +0200

    Prevent observer surfaces from writing to stdout
    
    Invoking cairo_surface_mark_dirty () on an observer surface would
    cause it to print debugging output to stdout.
    
    Reviewed-by: Andrea Canciani <ranma42@gmail.com>
    
    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=95227

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.