Bug 27683 - [bisected] many cairo can't run caused by some modification on big endian
Summary: [bisected] many cairo can't run caused by some modification on big endian
Status: VERIFIED WONTFIX
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: 1.9.7
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-16 00:18 UTC by zhao jian
Modified: 2010-04-16 01:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
xorg.0.log (20.22 KB, text/plain)
2010-04-16 00:18 UTC, zhao jian
Details

Description zhao jian 2010-04-16 00:18:33 UTC
Created attachment 35080 [details]
xorg.0.log

System Environment:
--------------------------
Libdrm:         (master)3506173ba7e726a9d0a17ec42734a925a885b01e
Mesa:           (master)eee220d65d3d37030f33971b02823c614e3eb618
Xserver:                (master)7b6517526631a65891b806bca30be8f49955d0a8
Xf86_video_intel:       (master)324a2810da3fbae35637ba9080f31f9383db0868
Cairo:          (master)4142f0836d6719dd136a5fc6ac1adaddd681a3f2
Kernel: (drm-intel-next)7f8a85698f5c8a981641ec0bdf9926768786db9d

Bug detailed description:
-------------------------
There are many cairo cases run with error of "Out of Memory" on all the backends(including null, image and xlib). And I find it was caused by a commit of cairo on master "Fix script scanner endianness". The culprit commit is 55ce0b774869e9fa614c6f9fec7905f7205cb5ff. And if I apply the following patch, it works well. 

diff --git a/util/cairo-script/cairo-script-scanner.c b/util/cairo-script/cairo-script-scanner.c
index 24d1616..b1e612d 100644
--- a/util/cairo-script/cairo-script-scanner.c
+++ b/util/cairo-script/cairo-script-scanner.c
@@ -653,7 +653,7 @@ base85_end (csi_t *ctx, csi_scanner_t *scan, cairo_bool_t deflate)
     }

     if (deflate) {
-        uLongf len = be32 (*(uint32_t *) scan->buffer.base);
+        uLongf len =  (*(uint32_t *) scan->buffer.base);
        Bytef *source = (Bytef *) (scan->buffer.base + sizeof (uint32_t));

        status = csi_string_deflate_new (ctx, &obj,

commit 55ce0b774869e9fa614c6f9fec7905f7205cb5ff
Author: Andrea Canciani <ranma42@gmail.com>
Date:   Fri Feb 5 22:30:05 2010 +0100

    script: Fix script scanner endianness

    The script interpreter was reading the length of compressed data as
    an host-endian uint32_t, thus making cairo-script able to correctly
    read traces that were produced on the same endianness as the one they
    ran upon, but unsuitable for portabile cairo-scripts.

    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>


Reproduce steps:
--------------------
1. xinit&
2. ./cairo-perf-trace evolution.trace
Comment 1 Chris Wilson 2010-04-16 00:47:43 UTC
This was a deliberate break to fix the file format prior to its first stable release. Please update the traces from the cairo-traces.git and rerun make.

If you want to preserve bisection ability, you will need to keep two trace repositories around and switch between them depending on the version of Cairo.
Comment 2 zhao jian 2010-04-16 01:34:56 UTC
(In reply to comment #1)
> This was a deliberate break to fix the file format prior to its first stable
> release. Please update the traces from the cairo-traces.git and rerun make.
> If you want to preserve bisection ability, you will need to keep two trace
> repositories around and switch between them depending on the version of Cairo.

Yes. It runs well after I update the trace and its performance is almost same with before. BTW, if you change the traces directly, will it possibly cause the performance data not in accordance with before, and the data before may be useless? Thanks
Comment 3 Chris Wilson 2010-04-16 01:41:39 UTC
The modification to the traces was only to byteswap the u32 used to store the compressed string length, so the performance data should remain comparable. (Just that since this was inside a lzma compressed file, effectively the whole file was regenerated.)


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.